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

  • [アーティクル]

適用対象:Azure SQL Database

Elastic Database ツールを使用すると、Azure SQL データベース のデータベースを簡単にスケールアウトできます。 これらのツールと機能では、Azure SQL Database のデータベースのリソースを使用して、トランザクションのワークロードに対するソリューション、特にサービスとしてのソフトウェア (SaaS) アプリケーションを作成できます。 Elastic Database は、次の機能で構成されています。

次の図は、データベースのコレクションに関連する Elastic Database の機能を含めたアーキテクチャを示しています。

この図では、データベースの色は、スキーマを表しています。 同じ色のデータベースは、同じスキーマを共有します。

  1. SQL データベースが、シャーディング アーキテクチャを使用して Azure でホストされています。
  2. Elastic Database クライアント ライブラリ は、シャード セットの管理に使用します。
  3. 一部のデータベースは、エラスティック プールに入っています。 (「プールとは」をご覧ください)。
  4. エラスティック データベース ジョブは、すべてのデータベースに対して、スケジュールされた、またはアドホックの T-SQL スクリプトを実行します。
  5. 1 つのシャードから別のシャードにデータを移動するときには、 分割/マージ ツール を使用します。
  6. Elastic Database クエリ では、シャード セット内のすべてのデータベースにまたがるクエリを記述することができます。
  7. エラスティック トランザクションでは、複数のデータベースにまたがるトランザクションを実行できます。

Elastic Database tools

ツールを使用する理由とは

クラウド アプリケーションにおいて弾力性と拡張性を実現することは、VM と Blob Storage では簡単でした。単純にユニットの追加や削除、能力の増強を行えばよかったからです。 ところが、リレーショナル データベースでのステートフルなデータ処理では、それが依然として困難でした。 これらのシナリオでの課題:

  • ワークロードのリレーショナル データベース部分の容量の拡張および縮小。
  • 負荷の高いエンド ユーザー (テナント) など、データの特定のサブセットに影響を及ぼす可能性があるホットスポットの管理。

これまで、このようなシナリオには、大規模なサーバーに投資を行ってアプリケーションをサポートすることで、対処してきました。 ただし、この方法には、すべての処理が事前に定義済みのコモディティ ハードウェアで実行されるクラウドでは限りがあります。 そこで、同じ構造を持つ多くのデータベース間でデータを分散し処理を行う手法 ("シャーディング" と呼ばれているスケールアウト パターン) が、コストと弾力性の両面で従来のスケールアップ アプローチの代替案となります。

水平および垂直方向のスケーリング

次の図は、水平および垂直方向のスケーリングを示しています。Elastic Databaseのスケーリングでは、どちらも基本的な方法です。

Horizontal versus vertical scale-out

水平方向のスケーリングとは、容量または全体のパフォーマンスを調整するためにデータベースを追加または削除することを意味します。"スケールアウト" とも呼ばれます。 シャーディングは、水平方向のスケーリングを実装する一般的な手法で、同じ構造を持つデータベースのコレクションでデータがパーティション分割されます。

垂直方向のスケーリングとは、個々のデータベースのコンピューティング サイズを増減することを意味します。"スケールアップ" とも呼ばれます。

ほとんどのクラウド規模のデータベース アプリケーションでは、この 2 つの手法を組み合わせて使用しています。 たとえば、サービス アプリケーションとしてのソフトウェアでは、水平方向のスケーリングを使用して新しいエンド ユーザーをプロビジョニングし、垂直方向のスケーリングを使用して、各エンドユーザーのデータベースがワークロードで必要される条件に応じてリソースを拡大縮小できるようにします。

  • 水平方向のスケーリングは、 Elastic Database クライアント ライブラリを使用して管理します。
  • 垂直方向のスケーリングは、Azure PowerShell コマンドレットを使用してサービス レベルを変更するか、エラスティック プールにデータベースを配置して実行します。

シャーディング

"シャーディング" は、同じ構造を持つ大量のデータを数多くの独立したデータベースに分散する手法です。 この手法は、エンド ユーザーまたは企業向けにサービスとしてのソフトウェア (SAAS) 製品をサービスで作成するクラウド開発者の間でよく知られています。 これらのエンド カスタマーは、多くの場合、"テナント" と呼ばれます。 シャーディングは、次のような理由で必要になります。

  • データの合計数が多すぎて、個別のデータベースの制約に適合しない
  • ワークロード全体のトランザクションのスループットが個別のデータベースの能力を超えている
  • テナントを互いに物理的に独立させる必要があり、テナントごとに別個のデータベースが必要になる
  • コンプライアンス、パフォーマンス、または地政学上の理由から、データベースの異なる部分を異なる地理的場所に配置することが必要になる

他のシナリオ (たとえば、分散されたデバイスからのデータの取り込み) では、シャーディングを使用して、一時的に構成されたデータベースのセットに値を入力できます。 たとえば、別個のデータベースをそれぞれの日または週専用に使用できます。 その場合、シャーディング キーとして (シャード化テーブルのすべての行に存在する) 日付を表す整数を使用できます。アプリケーションは、日付の範囲の情報を取得するクエリを、対象の範囲をカバーするデータベースのサブセットにルーティングする必要があります。

シャーディングは、アプリケーションのすべてのトランザクションをシャーディング キーの単一の値に制限できる場合に最適です。 これにより、すべてのトランザクションが特定のデータベースにローカルであることが保証されます。

マルチ テナントとシングル テナント

一部のアプリケーションでは、テナントごとに別個のデータベースを作成する最も単純なアプローチが使用されています。 このアプローチは、テナント単位で分離、バックアップ/復元、およびリソースのスケーリングを可能にする、単一テナントのシャーディング パターンです。 単一テナントのシャーディングでは、各データベースは特定のテナント ID 値 (または顧客キー値) に関連付けられますが、キーは必ずしもデータ自体に存在する必要はありません。 各要求を適切なデータベースにルーティングするのはアプリケーションの責任です。クライアント ライブラリはこの作業を簡素化できます。

Single tenant versus multi-tenant

複数のテナントを別個のデータベースに分離する代わりに、一緒にデータベースにパックするシナリオもあります。 このパターンが典型的なマルチテナントのシャーディング パターンです。このパターンの利用は、1 つのアプリケーションが多数の小さなテナントを管理するという状況により促進されます。 マルチテナントのシャーディングでは、データベース テーブル内の行は、テナント ID を識別するキーまたはシャーディング キーを格納するように設計されます。 ここでも、アプリケーション層は、テナントの要求を適切なデータベースにルーティングする役割を負います。これは、エラスティック データベース クライアント ライブラリによってサポートされます。 さらに、行レベルのセキュリティを使用して、各テナントがアクセスできる行をフィルター処理することができます。詳細については、「Elastic Database ツールと行レベルのセキュリティを使用したマルチテナント アプリケーション」をご覧ください。 マルチ テナントのシャーディング パターンでは、データを複数のデータベース間で再分散することが必要な場合があります。この再分散は、エラスティック データベースの分割/マージ ツールで容易に行うことができます。 エラスティック プールを使用する SaaS アプリケーションの設計パターンの詳細については、「 Azure SQL Database を使用するマルチテナント SaaS アプリケーションの設計パターン」を参照してください。

マルチテナントデータベースからシングルテナント データベースへのデータ移動

SaaS アプリケーションを作成する場合は、見込顧客に試用版のソフトウェアを提供するのが一般的です。 この場合は、データにマルチテナント データベースを使用すると費用対効果を高めることができます。 ただし、見込顧客が実際に顧客になった場合、シングルテナント データベースを使用した方がパフォーマンスが向上します。 このため、顧客が試用期間中にデータを作成していた場合には、 分割/マージ ツール を使用して、マルチテナント データベースから新しいシングルテナント データベースにデータを移動します。

注意

マルチテナント データベースからシングル テナントに復元することはできません。

次のステップ

クライアント ライブラリの使い方を示すサンプル アプリについては、「Elastic Database ツールの概要」をご覧ください。

ツールを使用するように既存のデータベースを変換する方法については、「既存のデータベースを移行してスケールアウト」をご覧ください。

エラスティック プールの詳細を確認するには、「エラスティック プールの価格およびパフォーマンスに関する考慮事項」を参照するか、エラスティック プールで新しいプールを作成してください。

その他のリソース

まだ弾力性データベース ツールを使用していない場合は、 ファースト ステップ ガイドを参照してください。 ご質問がある場合は、SQL Database に関する Microsoft Q&A 質問ページを参照してください。機能に関するご要望は、SQL Database に関するフィードバック フォーラムで新しいアイデアを追加したり、既存のアイデアに投票したりしてください。