Azure SQL Database를 사용하여 규모 확장Scaling out with Azure SQL Database

Elastic Database 도구를 사용하여 Azure SQL 데이터베이스의 규모를 쉽게 확장할 수 있습니다.You can easily scale out Azure SQL databases using the Elastic Database tools. 이러한 도구와 기능을 사용하면 Azure SQL Database의 데이터베이스 리소스를 사용하여 트랜잭션 워크로드에 대한 솔루션, 특히 SaaS(Software as a Service) 응용 프로그램을 만들 수 있습니다.These tools and features let you use the database resources of Azure SQL Database to create solutions for transactional workloads, and especially Software as a Service (SaaS) applications. Elastic Database 기능은 다음으로 구성됩니다.Elastic Database features are composed of the:

  • Elastic Database 클라이언트 라이브러리: 클라이언트 라이브러리는 분할된 데이터베이스를 만들고 유지 관리할 수 있도록 해주는 기능입니다.Elastic Database client library: The client library is a feature that allows you to create and maintain sharded databases. Elastic Database 도구 시작하기를 참조하세요.See Get started with Elastic Database tools.
  • Elastic Database 분할-병합 도구: 분할된 데이터베이스 간에 데이터를 이동합니다.Elastic Database split-merge tool: moves data between sharded databases. 다중 테넌트 데이터베이스에서 단일 테넌트 데이터베이스(또는 그 반대로)로 데이터를 이동하는 데 유용합니다.This is useful for moving data from a multi-tenant database to a single-tenant database (or vice-versa). 탄력적 데이터베이스 분할-병합 도구 자습서를 참조하세요.See Elastic database Split-Merge tool tutorial.
  • Elastic Database 작업 (미리 보기): 작업을 사용하여 많은 수의 Azure SQL 데이터베이스를 관리합니다.Elastic Database jobs (preview): Use jobs to manage large numbers of Azure SQL databases. 작업을 사용하여 스키마 변경, 자격 증명 관리, 참조 데이터 업데이트, 성능 데이터 수집 또는 테넌트(고객) 원격 분석 컬렉션 등의 관리 작업을 쉽게 수행합니다.Easily perform administrative operations such as schema changes, credentials management, reference data updates, performance data collection, or tenant (customer) telemetry collection using jobs.
  • Elastic Database 쿼리 (미리 보기): 여러 데이터베이스에 걸쳐 있는 Transact-SQL 쿼리를 실행할 수 있습니다.Elastic Database query (preview): Enables you to run a Transact-SQL query that spans multiple databases. 이를 통해 Excel, PowerBI, Tableau 등과 같은 보고 도구에 연결할 수 있습니다.This enables connection to reporting tools such as Excel, PowerBI, Tableau, etc.
  • 탄력적 트랜잭션: 이 기능을 사용하면 Azure SQL Database의 여러 데이터베이스에 걸쳐 트랜잭션을 실행할 수 있습니다.Elastic transactions: This feature allows you to run transactions that span several databases in Azure SQL Database. 탄력적 데이터베이스 트랜잭션은 ADO .NET을 사용하여 .NET 응용 프로그램에서 사용할 수 있고 System.Transaction 클래스를 사용하여 친숙한 프로그래밍 환경과 통합될 수 있습니다.Elastic database transactions are available for .NET applications using ADO .NET and integrate with the familiar programming experience using the System.Transaction classes.

아래 그림은 데이터베이스 컬렉션과 관련된 Elastic Database 기능 을 포함하는 아키텍처를 보여 줍니다.The following graphic shows an architecture that includes the Elastic Database features in relation to a collection of databases.

이 그래픽에서 데이터베이스의 색은 스키마를 나타냅니다.In this graphic, colors of the database represent schemas. 동일한 색의 데이터베이스는 동일한 스키마를 공유합니다.Databases with the same color share the same schema.

  1. Azure SQL 데이터베이스 집합은 분할 아키텍처를 사용하여 Azure에서 호스트됩니다.A set of Azure SQL databases are hosted on Azure using sharding architecture.
  2. Elastic Database 클라이언트 라이브러리는 분할된 데이터베이스 집합을 관리하는 데 사용됩니다.The Elastic Database client library is used to manage a shard set.
  3. 데이터베이스 하위 집합은 탄력적 풀에 배치됩니다.A subset of the databases are put into an elastic pool. ( 풀이란?참조).(See What is a pool?).
  4. Elastic Database 작업은 모든 데이터베이스에 대해 예약된 또는 임시 T-SQL 스크립트를 실행합니다.An Elastic Database job runs scheduled or ad hoc T-SQL scripts against all databases.
  5. 분할-병합 도구 는 데이터를 하나의 분할된 데이터베이스에서 다른 분할된 데이터베이스로 이동하는 데 사용됩니다.The split-merge tool is used to move data from one shard to another.
  6. Elastic Database 쿼리 를 통해 분할된 데이터베이스 집합의 모든 데이터베이스에 걸쳐 있는 쿼리를 작성할 수 있습니다.The Elastic Database query allows you to write a query that spans all databases in the shard set.
  7. 탄력적 트랜잭션을 통해 여러 데이터베이스에 걸쳐 트랜잭션을 실행할 수 있습니다.Elastic transactions allow you to run transactions that span several databases.

Elastic Database 도구

도구를 사용하는 이유Why use the tools?

클라우드 응용 프로그램에 대한 탄력성 및 규모 달성은 VM 및 Blob 저장소에 대해 복잡하지 않습니다. 단순히 단위를 더하거나 빼고 성능을 늘립니다.Achieving elasticity and scale for cloud applications has been straightforward for VMs and blob storage - simply add or subtract units, or increase power. 하지만 관계형 데이터베이스의 상태 저장 데이터 처리는 과제로 남아 있습니다.But it has remained a challenge for stateful data processing in relational databases. 이러한 시나리오에서 발생하는 문제:Challenges emerged in these scenarios:

  • 작업의 관계형 데이터베이스에 대한 용량 확장 및 축소Growing and shrinking capacity for the relational database part of your workload.
  • 바쁜 최종 고객(테넌트)과 같이 데이터의 특정 하위 집합에 영향을 발생시킬 수 있는 핫스팟 관리.Managing hotspots that may arise affecting a specific subset of data - such as a busy end-customer (tenant).

일반적으로 이러한 시나리오는 응용 프로그램을 지원하기 위해 대규모 데이터베이스를 서버에 투자하여 해결되었습니다.Traditionally, scenarios like these have been addressed by investing in larger-scale database servers to support the application. 그러나 이 옵션은 미리 정의된 상용 하드웨어에서 모든 처리가 이루어지는 클라우드에서는 제한됩니다.However, this option is limited in the cloud where all processing happens on predefined commodity hardware. 대신에, 데이터 배포 및 많은 동일한 구조의 데이터베이스 간의 처리("Sharding"이라고 알려진 확장 패턴)는 비용 및 탄력성 측면에서 기존 확장 방식에 대한 대안을 제공합니다.Instead, distributing data and processing across many identically structured databases (a scale-out pattern known as "sharding") provides an alternative to traditional scale-up approaches both in terms of cost and elasticity.

수평 및 수직적 크기 조정Horizontal and vertical scaling

아래 그림에서는 탄력적 데이터베이스 크기를 조정할 수 있는 기본적인 방법인 조정의 가로 및 세로 크기를 보여 줍니다.The following figure shows the horizontal and vertical dimensions of scaling, which are the basic ways the elastic databases can be scaled.

수평 규모 확장과 수직 규모 확장 비교

용량이나 전체적인 성능을 조절 하기 위해 데이터베이스를 추가하거나 제거 하려면 수평적 확장을 참조합니다.Horizontal scaling refers to adding or removing databases in order to adjust capacity or overall performance. “확장"이라고도 합니다.This is also called “scaling out”. 분할은 동일한 구조 데이터베이스 컬렉션 간의 분할된 데이터의 수평적 확장 구현을 위한 일반적인 방법입니다.Sharding, in which data is partitioned across a collection of identically structured databases, is a common way to implement horizontal scaling.

수직적 크기 조정은 개별 데이터베이스 성능 수준의 증가 또는 감소를 나타냅니다. “강화”라고도 합니다.Vertical scaling refers to increasing or decreasing the performance level of an individual database—this is also known as “scaling up.”

대부분의 클라우드 규모 데이터베이스 응용 프로그램에 이러한 두 가지 전략이 결합하여 사용됩니다.Most cloud-scale database applications use a combination of these two strategies. 예를 들어, 서비스 응용 프로그램 같은 소프트웨어는 새로운 최종고객을 프로비전하기 위해 수평적 확장을 사용할 것이고, 워크로드의 필요에 의해 개별 최종 고객의 데이터베이스 리소스를 늘리거나 줄이기 위해 수직적 확장을 사용할 것입니다.For example, a Software as a Service application may use horizontal scaling to provision new end-customers and vertical scaling to allow each end-customer’s database to grow or shrink resources as needed by the workload.

  • 수평적 크기 조정은 Elastic Database 클라이언트 라이브러리를 사용하여 관리됩니다.Horizontal scaling is managed using the Elastic Database client library.
  • 수직적 크기 조정은 서비스 계층을 변경하도록 Azure PowerShell cmdlet을 사용하거나 탄력적 풀에 데이터베이스를 배치하여 수행됩니다.Vertical scaling is accomplished using Azure PowerShell cmdlets to change the service tier, or by placing databases in an elastic pool.

분할Sharding

분할이란 동일하게 구조화된 대량의 데이터를 여러 독립적인 데이터베이스에 분산하는 기술입니다.Sharding is a technique to distribute large amounts of identically structured data across a number of independent databases. 특히 최종 고객 또는 비즈니스에 대한 SAAS(Software as a Service) 제품을 만드는 클라우드 개발자가 이 기법을 많이 사용합니다.It is especially popular with cloud developers creating Software as a Service (SAAS) offerings for end customers or businesses. 이러한 최종 고객을 보통 "테넌트"라고 합니다.These end customers are often referred to as “tenants”. 분할은 다음과 같은 여러 가지 이유로 필요할 수 있습니다.Sharding may be required for any number of reasons:

  • 총 데이터 양이 너무 커서 단일 데이터베이스의 제약 조건에 맞지 않습니다.The total amount of data is too large to fit within the constraints of a single database
  • 전반적인 작업의 트랜잭션 처리량이 단일 데이터베이스의 기능을 초과합니다.The transaction throughput of the overall workload exceeds the capabilities of a single database
  • 테넌트는 물리적으로 서로 격리되어야 할 수 있으므로 각 테넌트에는 별도의 데이터베이스가 필요합니다.Tenants may require physical isolation from each other, so separate databases are needed for each tenant
  • 데이터베이스의 다양한 섹션이 규정 준수, 성능 또는 지정학적인 이유로 인해 서로 다른 지리적 위치에 상주해야 할 수 있습니다.Different sections of a database may need to reside in different geographies for compliance, performance, or geopolitical reasons.

분산된 장치에서 데이터 수집과 같은 다른 시나리오에서는 분할을 사용하여 일시적으로 구성된 데이터베이스 집합을 채울 수 있습니다.In other scenarios, such as ingestion of data from distributed devices, sharding can be used to fill a set of databases that are organized temporally. 예를 들어, 매일 또는 주별로 별도의 데이터베이스를 전용할 수 있습니다.For example, a separate database can be dedicated to each day or week. 이 경우 분할 키는 날짜를 나타내는 정수(분할된 테이블의 모든 행에 있음)일 수 있으며, 응용 프로그램에서 해당하는 범위를 포함하는 데이터베이스의 하위 집합으로 날짜 범위에 대한 정보를 검색하는 쿼리를 라우팅해야 합니다.In that case, the sharding key can be an integer representing the date (present in all rows of the sharded tables) and queries retrieving information for a date range must be routed by the application to the subset of databases covering the range in question.

분할은 응용 프로그램의 모든 트랜잭션이 분할 키의 단일 값으로 제한될 수 있는 경우에 가장 적합합니다.Sharding works best when every transaction in an application can be restricted to a single value of a sharding key. 그렇게 하면 모든 트랜잭션이 특정 데이터베이스에 로컬이 됩니다.That ensures that all transactions are local to a specific database.

다중 테넌트 및 단일 테넌트Multi-tenant and single-tenant

일부 응용 프로그램은 각 테넌트에 대해 별도의 데이터베이스를 만드는 가장 간단한 접근 방식을 사용합니다.Some applications use the simplest approach of creating a separate database for each tenant. 이 방식은 테넌트 단위에서 격리, 백업/복원 기능 및 리소스 확장 기능을 제공하는 단일 테넌트 분할 패턴 입니다.This is the single tenant sharding pattern that provides isolation, backup/restore ability, and resource scaling at the granularity of the tenant. 단일 테넌트 분할을 사용하면 각 데이터베이스가 특정 테넌트 ID 값(또는 고객의 키 값)과 연결되지만 해당 키가 데이터 자체에 존재하지 않아도 됩니다.With single tenant sharding, each database is associated with a specific tenant ID value (or customer key value), but that key need not always be present in the data itself. 각 요청을 적절한 데이터베이스에 라우팅하는 것은 응용 프로그램의 책임이고 클라이언트 라이브러리는 이것을 단순하게 해줍니다.It is the application’s responsibility to route each request to the appropriate database - and the client library can simplify this.

다중 테넌트 대 단일 테넌트

다른 시나리오에서는 여러 테넌트를 개별 데이터베이스로 격리하지 않고 함께 데이터베이스에 포함합니다.Others scenarios pack multiple tenants together into databases, rather than isolating them into separate databases. 이 방식은 일반적인 다중 테넌트 분할 패턴이며, 응용 프로그램이 작은 테넌트 여러 개를 관리하는 경우 적용될 수 있습니다.This is a typical multi-tenant sharding pattern - and it may be driven by the fact that an application manages large numbers of small tenants. 다중 테넌트 분할에서 데이터베이스 테이블의 행은 모두 테넌트 ID 또는 키 분할을 식별하는 키 ID를 제공하도록 설계되었습니다.In multi-tenant sharding, the rows in the database tables are all designed to carry a key identifying the tenant ID or sharding key. 또한 응용 프로그램 계층이 적합한 데이터베이스로 테넌트의 요청을 라우팅하고 탄력적 데이터베이스 클라이언트 라이브러리가 보조할 수 있습니다.Again, the application tier is responsible for routing a tenant’s request to the appropriate database, and this can be supported by the elastic database client library. 또한 행 수준 보안은 행 각각의 세부 정보에 액세스할 수 있는 필터에 사용될 수 있습니다. 자세한 내용은 Elastic Database 도구 및 행 수준 보안을 제공하는 다중 테넌트 응용 프로그램을 참조하세요.In addition, row-level security can be used to filter which rows each tenant can access - for details, see Multi-tenant applications with elastic database tools and row-level security. 데이터베이스 간 데이터 재배포는 다중 테넌트 분할 패턴을 필요로 할 수 있고, 탄력적 데이터베이스 분할 병합 도구는 이 작업을 수월하게 만들어줍니다.Redistributing data among databases may be needed with the multi-tenant sharding pattern, and this is facilitated by the elastic database split-merge tool. 탄력적 풀을 사용한 SaaS 응용 프로그램의 디자인 패턴에 대해 자세히 알아보려면 Azure SQL Database를 사용한 다중 테넌트 SaaS 응용 프로그램 디자인 패턴을 참조하세요.To learn more about design patterns for SaaS applications using elastic pools, see Design Patterns for Multi-tenant SaaS Applications with Azure SQL Database.

다중 테넌트 데이터베이스에서 단일 테넌트 데이터베이스로 데이터 이동Move data from multiple to single-tenancy databases

SaaS 응용 프로그램을 만들 때 잠재 고객에게 평가판 소프트웨어를 제공하는 것은 일반적입니다.When creating a SaaS application, it is typical to offer prospective customers a trial version of the software. 이 경우 데이터에 대해 다중 테넌트 데이터베이스를 사용하는 것이 비용 효율적입니다.In this case, it is cost-effective to use a multi-tenant database for the data. 그러나 잠재 고객이 고객이 되면 단일 테넌트 데이터베이스가 더 나은 성능을 제공하므로 단일 테넌트 데이터베이스가 더 좋습니다.However, when a prospect becomes a customer, a single-tenant database is better since it provides better performance. 고객이 평가판 사용 기간 동안 데이터를 만든 경우 분할-병합 도구 를 사용하여 데이터를 다중 테넌트에서 새 단일 테넌트 데이터베이스로 이동합니다.If the customer had created data during the trial period, use the split-merge tool to move the data from the multi-tenant to the new single-tenant database.

다음 단계Next steps

클라이언트 라이브러리를 보여 주는 샘플 앱은 Elastic Database 도구 시작하기를 참조하세요.For a sample app that demonstrates the client library, see Get started with Elastic Database tools.

도구를 사용하도록 기존 데이터베이스를 변환하려면 확장하기 위해 기존 데이터베이스 마이그레이션을 참조하세요.To convert existing databases to use the tools, see Migrate existing databases to scale out.

탄력적 풀의 세부 사항을 보려면 탄력적 풀의 가격 및 성능 고려 사항을 참조하거나 탄력적 풀을 사용하여 새로운 풀을 만드세요.To see the specifics of the elastic pool, see Price and performance considerations for an elastic pool, or create a new pool with elastic pools.

추가 리소스Additional resources

아직 탄력적인 데이터베이스 도구를 사용 하지 않나요?Not using elastic database tools yet? 시작 가이드를 확인합니다.Check out our Getting Started Guide. 의문 사항이 있으면 SQL Database 포럼에 문의하고, 기능에 대한 요청이 있는 경우 해당 기능을 SQL Database 사용자 의견 포럼에 추가하세요.For questions, please reach out to us on the SQL Database forum and for feature requests, please add them to the SQL Database feedback forum.