データベースのスケーラビリティのためのソリューションを推奨する
あなたは Tailwind Traders の CTO として、リレーショナル データを格納するための、待機時間が短く、高可用性のデータベース ソリューションに関心があります。 5 つのデプロイ オプションを確認した後、Azure SQL Database のフル マネージド サービス機能を実装することにしました。 可用性ゾーンを使用する場合は、Business Critical サービス レベルで提供される高可用性 SLA を得たいと考えています。
次に、リレーショナル データベースのスケーラビリティをサポートする方法を決定します。 可用性やパフォーマンスに影響を与えることなく、長期にわたって増大する要求を処理できる、動的にスケーラブルなソリューションが必要です。
Azure SQL Database と動的スケーラビリティ
Azure SQL Database では動的スケーラビリティをサポートしています。 最小限のダウンタイムで、CPU パワー、メモリ、I/O スループット、ストレージなど、データベースに割り当てられたリソースを簡単に変更できます。 Azure portal を使用して、既存のインフラストラクチャを変更したり、新しいハードウェアを購入したりせずに、Azure SQL Database をスケーリングします。
動的スケーラビリティについて知っておくべきこと
Azure SQL データベースの動的スケーラビリティの次の特性を確認します。
DTU モデルまたは仮想コア モデルを選択し、1 つのデータベース実装で各データベースに割り当てるリソースの最大量を定義します。
エラスティック データベース プールを使用し、グループのリソースを購入して、プール内のデータベースに対して最小と最大のリソース制限を設定します。
垂直方向または水平方向のスケーリングを実装します。
垂直方向: 個々のデータベースのコンピューティング サイズを増減します (スケールアップとも呼ばれます)。
水平方向: データベースを追加または削除して、容量または全体のパフォーマンスを調整します (スケールアウトとも呼ばれます)。
シャーディングを使用してデータをパーティション分割するか、スケールアウト プロビジョニングを読み取って水平方向のスケーリングを適用します。
垂直方向のスケーリングについて知っておくべきこと
SQL Database エラスティック データベース プールを使用して垂直方向のスケーリングを実装します。 割り当てられたリソースをエラスティック データベース プール内のデータベースで共有します。 垂直方向のスケーリングを使用すると、一連のデータベースのコンピューティング サイズを変更できます。 平均使用率は低いが、使用率の急上昇がまれにある場合は、グループ対する急上昇を管理するのに十分な容量をプールに割り当てることができます。
SQL エラスティック データベース プールを適切に構成してサーバーのコストを削減するには、適切な購入モデルとサービス レベルを選択します。
| DTU モデル | 仮想コア モデル |
|---|---|
| Basic、Standard、Premium サービス レベル | General Purpose と Business Critical レベル |
ビジネス シナリオ
垂直方向のスケーリングを使用するビジネス シナリオを見てみましょう。 小規模企業は、グローバルに急速に成長しています。 企業は、店舗ごとに個別の SQL データベースを保守し、スケーリングする必要があります。 増加率とデータベース負荷は大きく変化します。 リソースの要件は予測できません。 理想的な動的スケーリング ソリューションは、垂直方向のスケーリングで SQL エラスティック データベース プールを使用することです。 一連の SQL データベースのスケーリング、パフォーマンス管理、コスト管理を行うことができます。 詳細については、「SQL エラスティック データベース プール」を参照してください。
水平方向のスケーリングについて知っておくべきこと
水平方向のスケーリングは、SQL Database の Elastic Database クライアント ライブラリを使用して管理します。 水平方向のスケーリングを適用するには、読み取りスケールアウト プロビジョニングとシャーディングの 2 つの方法があります。
シャーディング: 同じ構造の SQL データベースのセット間でデータをパーティション分割します。 1 つのセットは、プライマリ読み取り/書き込みレプリカと、セカンダリ読み取り専用レプリカで構成されています。 大規模なデータベースを小さなコンポーネントに分割して、パフォーマンスを向上させ、管理しやすくすることができます。
読み取りスケールアウト: SQL データベースのセットに対して読み取り専用ワークロードを負荷分散します。 読み取り/書き込みレプリカでワークロードを実行するのではなく、読み取り専用レプリカのコンピューティング容量を使用して読み取り専用ワークロードをオフロードします。 一部の読み取り専用ワークロードを読み取り/書き込みワークロードから分離し、パフォーマンスに影響を与えないようにします。 次の表では、Azure SQL Database と Azure SQL Managed Instance の読み取りスケールアウト プロビジョニングのサポートについて示しています。
Azure SQL Managed Instance Azure SQL データベース Basic、Standard、General Purpose レベル: 読み取りスケールアウトは使用できません Basic、Standard、General Purpose レベル: 読み取りスケールアウトは使用できません Business Critical レベル:読み取りスケールアウトは自動プロビジョニングされます Business Critical と Premium レベル: 読み取りスケールアウトは自動プロビジョニングされます 該当するレベルなし Hyperscale レベル: 少なくとも 1 つのセカンダリ レプリカが作成されている場合は、読み取りスケールアウトを使用できます
ビジネス シナリオ: シャーディング
シャーディングによる水平方向のスケーリングを使用するビジネス シナリオを見てみましょう。 データベースの容量を超える大量のトランザクション スループットがあるデータベースにアクセスするアプリケーションのデータベースの問題を解決する必要があります。 パフォーマンスと可用性を確保できるようにデータベースを構成する方法を探しています。 考えられる解決策は、シャーディングによる水平方向のスケーリングまたは行方向のパーティション分割です。 これは、同じ構造を持つ大量のデータを、独立したデータベースのセットに分散させる手法です。
シャーディングは、多くの状況で役立ちます。 次に例をいくつか示します。
データの総量が大きすぎて、単一のデータベースの制約に適合しません。
ワークロード全体のトランザクション スループットが、個々のデータベースの容量を超過しています。
異なる顧客やテナントのデータの場合、物理的にそれぞれを分離する必要があります。
組織内では、コンプライアンス上の理由からデータが地理的に分離されています。
ビジネス シナリオ: 読み取りスケールアウト
読み取りスケールアウト プロビジョニングを適用するビジネス シナリオを見てみましょう。 アプリケーションのデータベースは、オンライン トランザクション処理 (OLTP) がデータベースを更新するためにアクセスされ、読み取り専用ワークロードが視覚化をレンダリングするために分析アプリケーションによってアクセスされます。 アプリケーションのパフォーマンスが影響を受けないように、コンピューティング容量の一部をオフロードできる水平方向のスケーリング ソリューションが必要です。 簡単に選択できるのは、特定のサービス レベルに対して事前にプロビジョニングされた読み取りスケールアウト機能を使用することです。 読み取り/書き込みレプリカでワークロードを実行するのではなく、いずれかの読み取り専用レプリカのコンピューティング容量を使用して読み取り専用ワークロードをオフロードできます。 このアプローチにより、一部の読み取り専用ワークロードを読み取り/書き込みワークロードから分離できるため、そのパフォーマンスに影響が及ぶことはありません。
次の図は、Business Critical サービス レベルで水平方向の読み取りスケールアウト プロビジョニングがどのように適用されるかを示しています。
データとログ ファイルはすべて直接接続されている SSD 上で実行され、ネットワーク待機時間が大幅に短縮されます。 このアーキテクチャ グループには、3 つのセカンダリ レプリカがあります。 何らかの障害が発生した場合、レプリカが既に存在し、データが接続されているため、セカンダリ レプリカへのフェールオーバーは高速になります。
Azure SQL Database と Azure SQL Managed Instance の Premium レベルと Business Critical レベルには、Always On 可用性グループがあります。 このグループは、アプリケーションのディザスター リカバリーと高可用性を実現するためのものです。 プライマリ読み取り/書き込みレプリカと、複数のセカンダリ読み取り専用レプリカがあります。 セカンダリ レプリカは、プライマリ レプリカと同じコンピューティング サイズでプロビジョニングされます。 接続文字列オプションを設定して、接続を書き込みレプリカにルーティングするか、読み取り専用レプリカにルーティングするかを決定します。
Premium または Business Critical のサービス レベルの単一データベースとエラスティック プール データベースで読み取りスケールアウトを無効にしてから、もう一度有効できます。 これらの機能は、Azure portal、PowerShell、REST API で使用できます。
Note
プライマリ レプリカで行ったデータの変更は、読み取り専用レプリカに対して非同期的に伝達されます。 読み取り専用レプリカに接続されたセッション内では、読み取りが、常にトランザクション整合性が確保された状態となります。 ただし、データ伝達の待ち時間は変動するため、レプリカが異なれば、返されるデータの時点も、プライマリ レプリカや他のレプリカと比べてわずかに異なる場合があります。
スケーラビリティ ソリューションを選択する際に考慮すべき事項
次のスケーリング シナリオを確認し、どのデータベース スケーリング戦略が Tailwind Traders に有効であるかを検討します。
| シナリオ | スケーリングに関する解決策 |
|---|---|
| 予測不可能なさまざまなリソース要件がある複数の Azure SQL データベースを管理し、スケーリングする | エラスティック データベース プールと垂直方向のスケーリング。 エラスティック データベース プールを使用して、データベースが必要なときに必要なパフォーマンス リソースを確実に取得できるようにします。 エラスティック プールでは、予測可能な予算の範囲内でシンプルなリソース割り当てメカニズムが提供されます。 エラスティック プールの料金は、データベース単位ではありません。 課金は、使用量や、プールがアクティブであったのが 1 時間未満かどうかといったことには関係なく、プールが存在する期間について 1 時間ごとに、最高の eDTU または仮想コア数で行われます。 |
| コンプライアンス上の理由から、データベースのさまざまなセクションが異なる地理的な場所に存在する | 水平方向のスケーリングとシャーディング。 シャーディングを使用して、データを複数のデータベースに分割し、個別にスケーリングできます。 シャード マップ マネージャーは、シャード セット内のすべてのシャード (データベース) についてのグローバル マッピング情報を保持する特殊なデータベースです。 メタデータにより、アプリケーションはシャーディング キーの値に基づいて適切なデータベースに接続できます。 |
| Excel、Power BI、Tableau で使用できるように、複数のデータベースから 1 つの全体的な結果に行が提供される商用 BI やデータ統合ツールなどの依存関係のサポート | エラスティック データベース ツールとエラスティック クエリ。 エラスティック データベース ツールとエラスティック クエリ機能を使用して、複数のデータベースにまたがるデータにアクセスします。 エラスティック クエリは Standard レベルで使用できます。 クエリは、Azure SQL Database の複数のデータベースにまたがる T-SQL で実行できます。 複数のデータベースにまたがるクエリを実行してリモート テーブルにアクセスし、Microsoft とサードパーティのツール (Excel、Power BI、Tableau など) を接続し、データ層間でクエリを実行します。 クエリを大規模なデータ層にスケールアウトし、結果をビジネス インテリジェンス レポートで視覚化できます。 |