다중 테넌트 SaaS 데이터베이스 테넌시 패턴Multi-tenant SaaS database tenancy patterns

적용 대상: Azure SQL Database

이 문서에서는 다중 테 넌 트 SaaS 응용 프로그램에 사용할 수 있는 다양 한 테 넌 트 모델을 설명 합니다.This article describes the various tenancy models available for a multi-tenant SaaS application.

다중 테넌트 SaaS 애플리케이션을 디자인할 때 애플리케이션의 요구에 가장 잘 맞는 테넌시 모델을 신중하게 선택해야 합니다.When designing a multi-tenant SaaS application, you must carefully choose the tenancy model that best fits the needs of your application. 테 넌 시 모델은 각 테 넌 트의 데이터가 저장소에 매핑되는 방식을 결정 합니다.A tenancy model determines how each tenant's data is mapped to storage. 선택한 테넌시 모델은 애플리케이션 디자인 및 관리에 영향을 줍니다.Your choice of tenancy model impacts application design and management. 나중에 다른 모델로 전환하려고 하면 비용이 많이 들 수도 있습니다.Switching to a different model later is sometimes costly.

A.A. SaaS 개념 및 용어SaaS concepts and terminology

Saas(Software as a Service) 모델에서 회사는 소프트웨어에 대한 라이선스 를 판매하지 않습니다.In the Software as a Service (SaaS) model, your company does not sell licenses to your software. 대신 각 고객은 회사에 임대료를 지불하여 각 고객을 회사의 테넌트 로 만듭니다.Instead, each customer makes rent payments to your company, making each customer a tenant of your company.

각 테넌트는 임대료를 지불하는 대가로 SaaS 애플리케이션 구성 요소에 대한 액세스 권한을 받고, SaaS 시스템에 해당 데이터를 저장합니다.In return for paying rent, each tenant receives access to your SaaS application components, and has its data stored in the SaaS system.

테넌트 모델 이라는 용어는 테넌트의 저장된 데이터가 구성되는 방법을 가리킵니다.The term tenancy model refers to how tenants' stored data is organized:

  • 단일 테 넌 트:   각 데이터베이스는 하나의 테 넌 트 에서만 데이터를 저장 합니다.Single-tenancy:  Each database stores data from only one tenant.
  • 다중 테 넌 트:   각 데이터베이스는 데이터 개인 정보 보호를 위한 메커니즘을 사용 하 여 여러 개별 테 넌 트의 데이터를 저장 합니다.Multi-tenancy:  Each database stores data from multiple separate tenants (with mechanisms to protect data privacy).
  • 하이브리드 테넌트 모델도 사용할 수 있습니다.Hybrid tenancy models are also available.

B.B. 적절한 테넌시 모델을 선택하는 방법How to choose the appropriate tenancy model

일반적으로 테넌시 모델은 애플리케이션의 기능에 영향을 주지 않지만 전체 솔루션의 다른 측면에 영향을 주기 쉽습니다.In general, the tenancy model does not impact the function of an application, but it likely impacts other aspects of the overall solution. 각 모델을 평가하는 데 다음 기준이 사용됩니다.The following criteria are used to assess each of the models:

  • 향상Scalability:

    • 테넌트의 수Number of tenants.
    • 테넌트당 스토리지Storage per-tenant.
    • 집계한 스토리지Storage in aggregate.
    • 워크로드Workload.
  • 테 넌 트 격리:   데이터 격리 및 성능 (한 테 넌 트의 워크 로드가 다른 테 넌 트에 영향을 주는지 여부)Tenant isolation:  Data isolation and performance (whether one tenant's workload impacts others).

  • 테 넌 트 당 비용:   데이터베이스 비용.Per-tenant cost:  Database costs.

  • 개발 복잡성:Development complexity:

    • 스키마 변경 내용Changes to schema.
    • 쿼리 변경 내용(패턴에 필요)Changes to queries (required by the pattern).
  • 운영 복잡성:Operational complexity:

    • 성능 모니터링 및 관리Monitoring and managing performance.
    • 스키마 관리입니다.Schema management.
    • 테넌트 복원Restoring a tenant.
    • 재해 복구Disaster recovery.
  • 사용자 지정 가능성:   테 넌 트 특정 또는 테 넌 트 클래스 전용의 지원 스키마 사용자 지정의 용이성Customizability:  Ease of supporting schema customizations that are either tenant-specific or tenant class-specific.

테넌시 관련 논의는 데이터 계층에 중점을 둡니다.The tenancy discussion is focused on the data layer. 그렇지만 잠시 동안 애플리케이션 계층을 생각해보세요.But consider for a moment the application layer. 애플리케이션 계층은 단일 엔터티로 취급됩니다.The application layer is treated as a monolithic entity. 애플리케이션을 많은 작은 구성 요소로 나눌 경우 선택하는 테넌시 모델이 달라질 수 있습니다.If you divide the application into many small components, your choice of tenancy model might change. 테넌시와 사용되는 스토리지 기술 또는 플랫폼을 고려해서 일부 구성 요소를 다른 구성 요소와 다르게 취급할 수 있습니다.You could treat some components differently than others regarding both tenancy and the storage technology or platform used.

C.C. 단일 테넌트 데이터베이스를 포함하는 독립 실행형 단일 테넌트 앱Standalone single-tenant app with single-tenant database

애플리케이션 수준 격리Application level isolation

이 모델에서는 전체 애플리케이션이 각 테넌트에 한 번씩 반복해서 설치됩니다.In this model, the whole application is installed repeatedly, once for each tenant. 앱의 각 인스턴스는 독립 실행형 인스턴스이므로 다른 독립 실행형 인스턴스와 상호 작용하지 않습니다.Each instance of the app is a standalone instance, so it never interacts with any other standalone instance. 앱의 각 인스턴스에는 테넌트가 1개만 있으므로 데이터베이스가 1개만 필요합니다.Each instance of the app has only one tenant, and therefore needs only one database. 테넌트에는 자체 데이터베이스가 있습니다.The tenant has the database all to itself.

정확히 하나의 단일 테넌트 데이터베이스가 있는 독립 실행형 앱 디자인Design of standalone app with exactly one single-tenant database.

각 앱 인스턴스는 별도 Azure 리소스 그룹에 설치됩니다.Each app instance is installed in a separate Azure resource group. 리소스 그룹은 소프트웨어 공급업체 또는 테넌트에서 소유한 구독에 속할 수 있습니다.The resource group can belong to a subscription that is owned by either the software vendor or the tenant. 두 경우 모두 공급업체는 테넌트의 소프트웨어를 관리할 수 있습니다.In either case, the vendor can manage the software for the tenant. 각 애플리케이션 인스턴스는 해당 데이터베이스에 연결되도록 구성됩니다.Each application instance is configured to connect to its corresponding database.

각 테넌트 데이터베이스는 단일 데이터베이스로 배포됩니다.Each tenant database is deployed as a single database. 이 모델은 가장 큰 데이터베이스 격리를 제공합니다.This model provides the greatest database isolation. 하지만 격리를 위해서는 각 데이터베이스에 최대 부하를 처리하기 위한 충분한 리소스가 할당되어야 합니다.But the isolation requires that sufficient resources be allocated to each database to handle its peak loads. 다른 리소스 그룹이나 다른 구독에 배포된 데이터베이스에 탄력적 풀을 사용할 수 없다는 점도 중요합니다.Here it matters that elastic pools cannot be used for databases deployed in different resource groups or to different subscriptions. 이러한 제한으로 인해 이 독립 실행형 단일 테넌트 앱은 전체적인 데이터베이스 비용 관점에서 가장 비싼 솔루션을 모델링하게 됩니다.This limitation makes this standalone single-tenant app model the most expensive solution from an overall database cost perspective.

공급업체 관리Vendor management

공급업체는 앱 인스턴스가 다른 테넌트 구독에 설치된 경우에도 모든 독립 실행형 앱 인스턴스의 모든 데이터베이스에 액세스할 수 있습니다.The vendor can access all the databases in all the standalone app instances, even if the app instances are installed in different tenant subscriptions. 이러한 액세스는 SQL 연결을 통해 구현됩니다.The access is achieved via SQL connections. 이 인스턴스 간 액세스를 통해 공급업체는 스키마 관리와 보고 또는 분석을 위한 데이터베이스 간 쿼리를 중앙 집중식으로 관리할 수 있습니다.This cross-instance access can enable the vendor to centralize schema management and cross-database query for reporting or analytics purposes. 이러한 종류의 중앙 집중식 관리가 필요한 경우 데이터베이스 URI에 테넌트 식별자를 매핑하는 카탈로그를 배포해야 합니다.If this kind of centralized management is desired, a catalog must be deployed that maps tenant identifiers to database URIs. Azure SQL Database는 카탈로그를 제공 하는 데 함께 사용 되는 분할 라이브러리를 제공 합니다.Azure SQL Database provides a sharding library that is used together to provide a catalog. 분할 라이브러리는 공식 명칭이 Elastic Database 클라이언트 라이브러리입니다.The sharding library is formally named the Elastic Database Client Library.

D.D. 테넌트별 데이터베이스가 있는 다중 테넌트 앱Multi-tenant app with database-per-tenant

이러한 다음 패턴은 모두 단일 테넌트 데이터베이스에 해당하는 많은 데이터베이스를 포함하는 다중 테넌트 애플리케이션을 사용합니다.This next pattern uses a multi-tenant application with many databases, all being single-tenant databases. 새 데이터베이스는 각 새로운 테넌트용으로 프로비전됩니다.A new database is provisioned for each new tenant. 애플리케이션 계층의 경우 노드당 더 많은 리소스를 추가하여 수직으로 규모를 확장 합니다.The application tier is scaled up vertically by adding more resources per node. 또는 노드를 더 추가하여 앱을 수평으로 스케일 아웃 합니다.Or the app is scaled out horizontally by adding more nodes. 크기 조정은 워크로드를 기준으로 하며, 개별 데이터베이스의 수나 크기와는 별개입니다.The scaling is based on workload, and is independent of the number or scale of the individual databases.

테넌트별 데이터베이스가 있는 다중 테넌트 앱 디자인Design of multi-tenant app with database-per-tenant.

테넌트에 맞게 사용자 지정Customize for a tenant

독립 실행형 앱 패턴처럼 단일 테넌트 데이터베이스를 사용하면 강력한 테넌트 격리가 구현됩니다.Like the standalone app pattern, the use of single-tenant databases gives strong tenant isolation. 해당 모델이 단일 테넌트 데이터베이스만 지정하는 앱에서는 해당 데이터베이스에 대한 스키마를 테넌트에 맞게 사용자 지정하고 최적화할 수 있습니다.In any app whose model specifies only single-tenant databases, the schema for any one given database can be customized and optimized for its tenant. 이 사용자 지정은 앱의 다른 테넌트에 영향을 주지 않습니다.This customization does not affect other tenants in the app. 모든 테넌트에 필요한 기본 데이터 필드 이외의 데이터가 테넌트에 필요할 수도 있습니다.Perhaps a tenant might need data beyond the basic data fields that all tenants need. 또한 추가 데이터 필드에 인덱스가 필요할 수도 있습니다.Further, the extra data field might need an index.

테넌트별 데이터베이스를 사용하면 하나 이상의 개별 테넌트에 대한 스키마를 쉽게 사용자 지정할 수 있습니다.With database-per-tenant, customizing the schema for one or more individual tenants is straightforward to achieve. 애플리케이션 공급업체는 스키마 사용자 지정을 전반적으로 신중하게 관리하기 위한 절차를 디자인해야 합니다.The application vendor must design procedures to carefully manage schema customizations at scale.

탄력적 풀Elastic pools

같은 리소스 그룹에 배포되는 데이터베이스는 탄력적 풀로 그룹화할 수 있습니다.When databases are deployed in the same resource group, they can be grouped into elastic pools. 풀은 많은 데이터베이스에서 리소스를 공유하는 비용 효율적인 방법을 제공합니다.The pools provide a cost-effective way of sharing resources across many databases. 이러한 풀 옵션은 발생하는 최대 사용량을 수용할 수 있을 만큼, 각 데이터베이스를 크게 유지하는 것보다 더 저렴한 방법입니다.This pool option is cheaper than requiring each database to be large enough to accommodate the usage peaks that it experiences. 풀링된 데이터베이스는 리소스에 대한 액세스를 공유하지만 높은 수준의 성능 격리를 달성할 수 있습니다.Even though pooled databases share access to resources they can still achieve a high degree of performance isolation.

탄력적 풀을 사용하여 테넌트별 데이터베이스가 있는 다중 테넌트 앱 디자인Design of multi-tenant app with database-per-tenant, using elastic pool.

Azure SQL Database는 공유를 구성, 모니터링 및 관리하는 데 필요한 도구를 제공합니다.Azure SQL Database provides the tools necessary to configure, monitor, and manage the sharing. 풀 수준 및 데이터베이스 수준 성능 메트릭은 Azure Portal 및 Azure Monitor 로그를 통해 사용할 수 있습니다.Both pool-level and database-level performance metrics are available in the Azure portal, and through Azure Monitor logs. 이러한 메트릭을 통해 집계 및 테넌트별 성능을 보다 잘 이해할 수 있습니다.The metrics can give great insights into both aggregate and tenant-specific performance. 개별 데이터베이스를 풀 간에 이동하여 특정 테넌트에 예약된 리소스를 제공할 수 있습니다.Individual databases can be moved between pools to provide reserved resources to a specific tenant. 이러한 도구를 사용하여 비용 효율적인 방식으로 좋은 성능을 보장할 수 있습니다.These tools enable you to ensure good performance in a cost effective manner.

테넌당 데이터베이스의 작업 규모 조정Operations scale for database-per-tenant

Azure SQL Database에는 10만 개 이상의 데이터베이스와 같이 대규모 데이터베이스를 대규모로 관리 하도록 설계 된 많은 관리 기능이 있습니다.Azure SQL Database has many management features designed to manage large numbers of databases at scale, such as well over 100,000 databases. 이러한 기능은 테넌트별 데이터베이스 패턴을 적절히 지원합니다.These features make the database-per-tenant pattern plausible.

예를 들어, 시스템에 1000 테넌트 데이터베이스가 유일한 데이터베이스로 사용된다고 가정합니다.For example, suppose a system has a 1000-tenant database as its only one database. 이 데이터베이스에는 20개의 인덱스가 있을 수 있습니다.The database might have 20 indexes. 시스템이 1000개의 단일 테넌트 데이터베이스를 포함하는 방식으로 변환될 경우 인덱스 수는 20,000개로 증가합니다.If the system converts to having 1000 single-tenant databases, the quantity of indexes rises to 20,000. 자동 조정의 일부로 Azure SQL Database 자동 인덱싱 기능이 기본적으로 사용 하도록 설정 되어 있습니다.In Azure SQL Database as part of Automatic tuning, the automatic indexing features are enabled by default. 자동 인덱싱은 20,000개의 모든 인덱스와 지속적인 생성 및 삭제 최적화를 자동으로 관리합니다.Automatic indexing manages for you all 20,000 indexes and their ongoing create and drop optimizations. 이러한 자동화된 작업은 개별 데이터베이스 내에서 발생하며 다른 데이터베이스의 비슷한 작업에 따라 조정되거나 제한되지 않습니다.These automated actions occur within an individual database, and they are not coordinated or restricted by similar actions in other databases. 자동 인덱싱은 덜 바쁜 데이터베이스와 바쁜 데이터베이스에서 인덱스를 다르게 처리합니다.Automatic indexing treats indexes differently in a busy database than in a less busy database. 이러한 방대한 관리 작업을 수동으로 처리해야 한다면 테넌트별 데이터베이스 수준에서 이러한 유형의 인덱스 관리 사용자 지정을 수행하는 것은 비현실적인 일일 것입니다.This type of index management customization would be impractical at the database-per-tenant scale if this huge management task had to be done manually.

잘 확장되는 다른 관리 기능은 다음과 같습니다.Other management features that scale well include the following:

  • 기본 제공 백업Built-in backups.
  • 고가용성.High availability.
  • 디스크 암호화On-disk encryption.
  • 성능 원격 분석Performance telemetry.

AutomationAutomation

관리 작업은 devops 모델을 통해 스크립팅하고 제공할 수 있습니다.The management operations can be scripted and offered through a devops model. 애플리케이션에서도 작업을 자동화하고 노출할 수 있습니다.The operations can even be automated and exposed in the application.

예를 들어, 이전 시점으로의 단일 테넌트 복구를 자동화할 수 있습니다.For example, you could automate the recovery of a single tenant to an earlier point in time. 테넌트를 저장하는 하나의 단일 테넌트 데이터베이스만 복원하면 복구가 이루어집니다.The recovery only needs to restore the one single-tenant database that stores the tenant. 이 복원이 다른 테넌트에는 영향을 미치지 않으며, 관리 작업은 각 개별 테넌트의 정밀하게 세분화된 수준에서 진행될 수 있습니다.This restore has no impact on other tenants, which confirms that management operations are at the finely granular level of each individual tenant.

E.E. 다중 테넌트 데이터베이스가 있는 다중 테넌트 앱Multi-tenant app with multi-tenant databases

사용 가능한 또 다른 패턴은 다중 테넌트 데이터베이스에 여러 테넌트를 저장하는 것입니다.Another available pattern is to store many tenants in a multi-tenant database. 애플리케이션 인스턴스는 제한 없는 수의 다중 테넌트 데이터베이스를 포함할 수 있습니다.The application instance can have any number of multi-tenant databases. 다중 테넌트 데이터베이스의 스키마에는 특정 테넌트의 데이터를 선택적으로 검색할 수 있도록 하나 이상의 테넌트 식별자 열이 있어야 합니다.The schema of a multi-tenant database must have one or more tenant identifier columns so that the data from any given tenant can be selectively retrieved. 또한 스키마에 일부 테넌트에서만 사용되는 소수의 테이블이나 열이 필요할 수도 있습니다.Further, the schema might require a few tables or columns that are used by only a subset of tenants. 그러나 정적 코드 및 참조 데이터는 한 번만 저장된 후 모든 테넌트에서 공유됩니다.However, static code and reference data is stored only once and is shared by all tenants.

테넌트 격리 효과는 제한됩니다.Tenant isolation is sacrificed

데이터:   다중 테 넌 트 데이터베이스는 테 넌 트 격리를 반드시 sacrifices 합니다.Data:  A multi-tenant database necessarily sacrifices tenant isolation. 다중 테넌트의 데이터는 하나의 데이터베이스에 함께 저장됩니다.The data of multiple tenants is stored together in one database. 개발 중에 쿼리가 둘 이상의 테넌트에 있는 데이터를 절대 노출하지 않는지 확인하세요.During development, ensure that queries never expose data from more than one tenant. SQL Database는 쿼리에서 반환된 데이터 범위가 단일 테넌트로 지정될 수 있게 행 수준 보안을 지원합니다.SQL Database supports row-level security, which can enforce that data returned from a query be scoped to a single tenant.

처리:   다중 테 넌 트 데이터베이스는 모든 테 넌 트에서 계산 및 저장소 리소스를 공유 합니다.Processing:  A multi-tenant database shares compute and storage resources across all its tenants. 데이터베이스을 전반적으로 모니터링하여 만족스러운 성능을 나타내는지 확인할 수 있습니다.The database as a whole can be monitored to ensure it is performing acceptably. 그러나 Azure 시스템에는 이러한 리소스에 대한 개별 테넌트 사용을 모니터링하거나 관리할 수 있는 기본 제공 방법이 없습니다.However, the Azure system has no built-in way to monitor or manage the use of these resources by an individual tenant. 따라서 다중 테넌트 데이터베이스는 주변 환경을 혼잡하게 하기 쉽습니다. 즉, 한 테넌트에서 과도한 워크로드가 발생할 경우 같은 데이터베이스에 있는 다른 테넌트의 성능에도 영향을 주게 됩니다.Therefore, the multi-tenant database carries an increased risk of encountering noisy neighbors, where the workload of one overactive tenant impacts the performance experience of other tenants in the same database. 추가 애플리케이션 수준 모니터링으로 테넌트 수준의 성능을 모니터링할 수 있습니다.Additional application-level monitoring could monitor tenant-level performance.

비용 절감Lower cost

일반적으로 다중 테넌트 데이터베이스는 테넌트당 비용이 가장 낮습니다.In general, multi-tenant databases have the lowest per-tenant cost. 단일 데이터베이스의 리소스 비용은 같은 크기의 탄력적 풀의 리소스 비용보다 더 낮습니다.Resource costs for a single database are lower than for an equivalently sized elastic pool. 또한 테넌트가 제한된 스토리지만 필요로 하는 시나리오에서는 수백만 개의 테넌트가 단일 데이터베이스에 저장될 수 있습니다.In addition, for scenarios where tenants need only limited storage, potentially millions of tenants could be stored in a single database. 탄력적 풀은 수백만 개의 데이터베이스를 포함할 수 없습니다.No elastic pool can contain millions of databases. 그러나 풀당 1,000개의 데이터베이스를 포함하는 솔루션은 수백만 규모에 도달하여 관리하기 어려워질 수 있습니다.However, a solution containing 1000 databases per pool, with 1000 pools, could reach the scale of millions at the risk of becoming unwieldy to manage.

다음에서는 가장 유연하고 확장이 용이한 분할된 다중 테넌트 모델을 사용하여 다중 테넌트 데이터베이스 모델의 두 가지 변형에 대해 설명합니다.Two variations of a multi-tenant database model are discussed in what follows, with the sharded multi-tenant model being the most flexible and scalable.

F.F. 단일 다중 테넌트 데이터베이스가 있는 다중 테넌트 앱Multi-tenant app with a single multi-tenant database

가장 단순한 다중 테넌트 데이터베이스 패턴은 단일 데이터베이스를 사용하여 모든 테넌트에 대한 데이터를 호스트합니다.The simplest multi-tenant database pattern uses a single database to host data for all tenants. 더 많은 테넌트가 추가되면 더 많은 스토리지 및 컴퓨팅 리소스로 데이터베이스 규모가 확장됩니다.As more tenants are added, the database is scaled up with more storage and compute resources. 항상 궁극적으로 규모 제한이 적용되긴 하지만 처음에는 이러한 규모 확장만 해결되면 충분할 수 있습니다.This scale up might be all that is needed, although there is always an ultimate scale limit. 그러나 곧 이러한 제한에 도달하게 되고 데이터베이스를 관리하기 어려워집니다.However, long before that limit is reached the database becomes unwieldy to manage.

각 개별 테넌트에 초점을 맞춘 관리 작업을 다중 테넌트 데이터베이스에서 구현하려고 하면 좀 더 어렵습니다.Management operations that are focused on individual tenants are more complex to implement in a multi-tenant database. 또한 이러한 작업은 전반적으로 너무 느릴 수 있습니다.And at scale these operations might become unacceptably slow. 한 테넌트만을 대상으로 하는 데이터의 지정 시간 복원을 그 예로 들 수 있습니다.One example is a point-in-time restore of the data for just one tenant.

G.G. 공유되는 다중 테넌트 데이터베이스가 있는 다중 테넌트 앱Multi-tenant app with sharded multi-tenant databases

대부분의 SaaS 애플리케이션은 한 번에 한 테넌트의 데이터에만 액세스합니다.Most SaaS applications access the data of only one tenant at a time. 이 액세스 패턴을 사용하면 테넌트 데이터가 여러 데이터베이스 간에 또는 분할된 데이터베이스에서 분산될 수 있습니다. 후자의 경우 한 테넌트의 모든 데이터가 하나의 분할된 데이터베이스에 포함됩니다.This access pattern allows tenant data to be distributed across multiple databases or shards, where all the data for any one tenant is contained in one shard. 다중 테넌트 데이터베이스 패턴과 분할 모델을 함께 사용하면 거의 무제한으로 확장할 수 있게 됩니다.Combined with a multi-tenant database pattern, a sharded model allows almost limitless scale.

공유되는 다중 테넌트 데이터베이스가 있는 다중 테넌트 앱 디자인Design of multi-tenant app with sharded multi-tenant databases.

분할된 데이터베이스 관리Manage shards

분할을 사용하면 디자인 측면과 운영 관리 측면에서 복잡해집니다.Sharding adds complexity both to the design and operational management. 테넌트와 데이터베이스 간에 매핑을 유지 관리할 카탈로그가 필요합니다.A catalog is required in which to maintain the mapping between tenants and databases. 또한 분할된 데이터베이스 및 테넌트 채우기를 관리하기 위한 관리 절차도 필요합니다.In addition, management procedures are required to manage the shards and the tenant population. 예를 들어, 분할된 데이터베이스를 추가 및 이동하고 분할된 데이터베이스 간에 테넌트 데이터를 이동하기 위한 절차를 계획해야 합니다.For example, procedures must be designed to add and remove shards, and to move tenant data between shards. 크기를 조정하는 한 가지 방법은 새 분할된 데이터베이스를 추가하고 새 테넌트로 채우는 것입니다.One way to scale is to by adding a new shard and populating it with new tenants. 조밀하게 채워진 분할된 데이터베이스를 2개의 덜 채워진 분할된 데이터베이스로 분할할 수도 있습니다.At other times you might split a densely populated shard into two less-densely populated shards. 여러 테넌트가 이동되거나 사용이 중단된 후에 부분적으로 채워진 분할된 데이터베이스를 함께 병합할 수 있습니다.After several tenants have been moved or discontinued, you might merge sparsely populated shards together. 이렇게 병합하면 좀 더 비용 효율적인 리소스 사용률이 구현됩니다.The merge would result in more cost-efficient resource utilization. 또한 분할된 데이터베이스 간에 테넌트를 이동하여 작업 부하를 분산할 수도 있습니다.Tenants might also be moved between shards to balance workloads.

SQL Database는 분할 라이브러리 및 카탈로그 데이터베이스와 함께 작동하는 분할/병합 도구를 제공합니다.SQL Database provides a split/merge tool that works in conjunction with the sharding library and the catalog database. 제공된 앱은 분할된 데이터베이스를 분할 및 병합할 수 있으며 분할된 데이터베이스 간에 테넌트 데이터를 이동할 수 있습니다.The provided app can split and merge shards, and it can move tenant data between shards. 또한 이 앱은 이러한 작업 동안 카탈로그를 유지 관리하며, 영향을 받은 테넌트를 이동하기 전에 오프라인으로 표시합니다.The app also maintains the catalog during these operations, marking affected tenants as offline prior to moving them. 이동 후에 앱은 새 매핑으로 카탈로그를 다시 업데이트하고 테넌트를 다시 온라인으로 표시합니다.After the move, the app updates the catalog again with the new mapping, and marking the tenant as back online.

데이터베이스가 작아야 더 쉽게 관리할 수 있음Smaller databases more easily managed

분할된 다중 테넌트 솔루션은 테넌트를 여러 데이터베이스에 걸쳐 분산하여 관리가 보다 용이한 더 작은 데이터베이스가 생성됩니다.By distributing tenants across multiple databases, the sharded multi-tenant solution results in smaller databases that are more easily managed. 예를 들어, 특정 테넌트를 이전 시점으로 복원하면 모든 테넌트를 포함하는 더 큰 데이터베이스가 아니라 더 작은 단일 데이터베이스를 백업에서 복원하게 됩니다.For example, restoring a specific tenant to a prior point in time now involves restoring a single smaller database from a backup, rather than a larger database that contains all tenants. 워크로드 및 관리 업무의 균형을 유지하기 위해 데이터베이스 크기 및 데이터베이스당 테넌트 수를 선택할 수 있습니다.The database size, and number of tenants per database, can be chosen to balance the workload and the management efforts.

스키마의 테넌트 식별자Tenant identifier in the schema

사용하는 분할 방법에 따라, 데이터베이스 스키마에 추가 제약 조건이 적용될 수 있습니다.Depending on the sharding approach used, additional constraints may be imposed on the database schema. SQL Database 분할/병합 애플리케이션에서는 스키마에 일반적으로 테넌트 식별자에 해당하는 분할 키가 포함되어야 합니다.The SQL Database split/merge application requires that the schema includes the sharding key, which typically is the tenant identifier. 테넌트 식별자는 모든 분할된 테이블의 기본 키 맨 앞에 나오는 요소입니다.The tenant identifier is the leading element in the primary key of all sharded tables. 테넌트 식별자를 사용하여 분할/병합 애플리케이션은 특정 테넌트와 연결된 데이터를 빠르게 찾아서 이동할 수 있습니다.The tenant identifier enables the split/merge application to quickly locate and move data associated with a specific tenant.

분할된 데이터베이스에 대한 탄력적 풀Elastic pool for shards

분할된 다중 테넌트 데이터베이스는 탄력적 풀에 배치될 수 있습니다.Sharded multi-tenant databases can be placed in elastic pools. 일반적으로 하나의 풀에 많은 단일 테넌트 데이터베이스를 둘 경우 소스의 다중 테넌트 데이터베이스에 많은 테넌트를 두는 것보다 비용 효율적입니다.In general, having many single-tenant databases in a pool is as cost efficient as having many tenants in a few multi-tenant databases. 다중 테넌트 데이터베이스는 비교적 덜 활동적인 테넌트가 많이 있을 때 더 유용합니다.Multi-tenant databases are advantageous when there are a large number of relatively inactive tenants.

H.H. 하이브리드 분할된 다중 테넌트 데이터베이스 모델Hybrid sharded multi-tenant database model

하이브리드 모델에서는 모든 데이터베이스의 스키마에 테넌트 식별자가 있습니다.In the hybrid model, all databases have the tenant identifier in their schema. 데이터베이스는 항상 둘 이상의 테넌트를 저장할 수 있으며 분할될 수 있습니다.The databases are all capable of storing more than one tenant, and the databases can be sharded. 따라서 스키마 관점에서 보면 모두가 다중 테넌트 데이터베이스입니다.So in the schema sense, they are all multi-tenant databases. 그렇지만 실제로 이러한 데이터베이스의 일부는 하나의 테넌트만 포함합니다.Yet in practice some of these databases contain only one tenant. 그렇더라도 하나의 특정 데이터베이스에 저장되는 테넌트의 수는 데이터베이스 스키마에 영향을 주지 않습니다.Regardless, the quantity of tenants stored in a given database has no effect on the database schema.

테넌트 이동Move tenants around

언제든지 특정 테넌트 자체 다중 테넌트 데이터베이스로 이동할 수 있습니다.At any time, you can move a particular tenant to its own multi-tenant database. 또한 언제든지 마음이 바뀌면 테넌트를 여러 테넌트가 포함된 데이터베이스로 다시 이동할 수 있습니다.And at any time, you can change your mind and move the tenant back to a database that contains multiple tenants. 또한 새 데이터베이스를 프로비전할 때 새로운 단일 테넌트 데이터베이스에 테넌트를 할당할 수 있습니다.You can also assign a tenant to new single-tenant database when you provision the new database.

하이브리드 모델은 식별 가능한 테넌트 그룹의 리소스 요구량이 큰 차이를 보일 때 특히 유용합니다.The hybrid model shines when there are large differences between the resource needs of identifiable groups of tenants. 예를 들어 평가판에 참여하는 테넌트가 구독 테넌트와 동일한 높은 수준의 성능을 보장하지 못할 경우를 가정해보세요.For example, suppose that tenants participating in a free trial are not guaranteed the same high level of performance that subscribing tenants are. 정책에 따라 평가 단계에 있는 테넌트가 모든 평가 테넌트 간에 공유되는 다중 테넌트 데이터베이스에 저장되어야 할 수도 이습니다.The policy might be for tenants in the free trial phase to be stored in a multi-tenant database that is shared among all the free trial tenants. 평가판 테넌트가 기본 서비스 계층을 구독하면 더 적은 수의 테넌트를 포함할 수 있는 다른 다중 테넌트 데이터베이스로 이동될 수 있습니다.When a free trial tenant subscribes to the basic service tier, the tenant can be moved to another multi-tenant database that might have fewer tenants. 프리미엄 서비스 계층 비용을 지불하는 구독자는 자체적인 새 단일 테넌트 데이터베이스로 이동될 수 있습니다.A subscriber that pays for the premium service tier could be moved to its own new single-tenant database.

Pools

이 하이브리드 모델에서 구독자 테넌트용 단일 테넌트 데이터베이스를 리소스 풀에 배치하여 테넌트별 데이터베이스 비용을 줄일 수 있습니다.In this hybrid model, the single-tenant databases for subscriber tenants can be placed in resource pools to reduce database costs per tenant. 테넌트별 데이터베이스 모델에서도 이 작업을 수행할 수 있습니다.This is also done in the database-per-tenant model.

9.I. 테넌시 모델 비교Tenancy models compared

다음 표에서는 주 테넌시 모델 간의 차이점을 요약해서 보여 줍니다.The following table summarizes the differences between the main tenancy models.

측정Measurement 독립 실행형 앱Standalone app 테넌트별 데이터베이스Database-per-tenant 분할된 다중 테넌트Sharded multi-tenant
확장Scale 중간Medium
1-100s1-100s
매우 높음Very high
1-100,000s1-100,000s
제한 없음Unlimited
1-1,000,000s1-1,000,000s
테넌트 격리Tenant isolation 매우 높음Very high 높음High 낮음, 단일 테넌트의 경우는 예외입니다(MT db에만 단독으로 존재하는 경우).Low; except for any single tenant (that is alone in an MT db).
테넌트별 데이터베이스 비용Database cost per tenant 높음, 최대 크기에 맞게 조정됩니다.High; is sized for peaks. 낮음. 풀이 사용됩니다.Low; pools used. 가장 낮음. MT DB의 작은 테넌트용입니다.Lowest, for small tenants in MT DBs.
성능 모니터링 및 관리Performance monitoring and management 테넌트별로 구분되는 경우만 해당Per-tenant only 집계 + 테넌트별Aggregate + per-tenant 집계, 단일 항목에 대해서만 테넌트별로 구분됩니다.Aggregate; although is per-tenant only for singles.
개발 복잡성Development complexity 낮음Low 낮음Low 중간, 분할로 야기됩니다.Medium; due to sharding.
운영 복잡성Operational complexity 높음-낮음Low-High. 개별적으로는 단순하고 전체적으로는 복잡합니다.Individually simple, complex at scale. 낮음-중간Low-Medium. 패턴으로 전체적인 복잡성을 해결합니다.Patterns address complexity at scale. 높음-낮음Low-High. 개별 테넌트 관리가 복잡합니다.Individual tenant management is complex.
 

다음 단계Next steps