Azure SQL Database によるスケール アウトScaling out with Azure SQL Database

Elastic Database ツールを使用すると、Azure SQL Database を簡単にスケールアウトできます。You can easily scale out Azure SQL databases using the Elastic Database tools. これらのツールと機能では、Azure SQL Database のデータベースのリソースを使用して、トランザクションのワークロードに対するソリューション、特にサービスとしてのソフトウェア (SaaS) アプリケーションを作成できます。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 の機能を含めたアーキテクチャを示しています。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. エラスティック データベース ジョブは、すべてのデータベースに対して、スケジュールされた、またはアドホックの T-SQL スクリプトを実行します。An Elastic Database job runs scheduled or ad hoc T-SQL scripts against all databases.
  5. 1 つのシャードから別のシャードにデータを移動するときには、 分割/マージ ツール を使用します。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 Storage では簡単でした。単純にユニットの追加や削除、能力の増強を行えばよかったからです。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. そこで、同じ構造を持つ多くのデータベース間でデータを分散し処理を行う手法 ("シャーディング" と呼ばれているスケールアウト パターン) が、コストと弾力性の両面で従来のスケールアップ アプローチの代替案となります。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.”

ほとんどのクラウド規模のデータベース アプリケーションでは、この 2 つの手法を組み合わせて使用しています。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 コマンドレットを使用してサービス レベルを変更するか、エラスティック プールにデータベースを配置して実行します。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) 製品をサービスで作成するクラウド開発者の間でよく知られています。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
  • ワークロード全体のトランザクションのスループットが 1 つのデータベースの能力を超えている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. これが典型的なマルチテナントのシャーディング パターンです。このパターンの利用は、1 つのアプリケーションが多数の小さなテナントを管理するという状況により促進されます。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 を識別するキーまたはシャーディング キーを格納するように設計されます。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.