Azure でのミッション クリティカルなワークロードに関するデータ プラットフォームに関する考慮事項

  • [アーティクル]

効果的なアプリケーション データ プラットフォームの選択は、他の設計領域に広範囲に及ぶ影響を及ぼす、さらに重要な決定領域です。 最終的に Azure には、多数のリレーショナル、非リレーショナル、分析データ プラットフォームが用意されており、機能が大きく異なります。 そのため、重要な非機能要件を、一貫性、操作性、コスト、複雑さなどの他の意思決定要因と共に完全に考慮することが不可欠です。 たとえば、複数リージョンの書き込み構成で動作する機能は、グローバルに利用可能なプラットフォームの適合性に重大な影響を及ぼします。

この設計領域では 、アプリケーションの設計が拡張され、最適なデータ プラットフォームの選択を通知するための重要な考慮事項と推奨事項が提供されます。

重要

この記事は、 Azure Well-Architected ミッション クリティカルなワークロード シリーズの 一部です。 このシリーズに慣れていない場合は、ミッション クリティカルなワークロードの概要から始めてお勧めします。

ビッグ データの 4 対

"Four Vs of Big Data" は、高可用性データ プラットフォームの必要な特性と、データを使用してビジネス価値を最大化する方法をより深く理解するためのフレームワークを提供します。 そのため、このセクションでは、適切なデータ テクノロジを使用してデータ プラットフォームを設計するのに役立つ概念レベルで Volume、Velocity、Variety、Veracity の特性を適用する方法について説明します。

  • Volume: ストレージ容量と階層化の要件を通知するために提供されるデータの量 (つまり、データセットのサイズ)。
  • Velocity: データがバッチまたは連続ストリームとして処理される速度 (フローの速度)。
  • Variety: データのorganizationと形式。構造化形式、半構造化形式、非構造化形式をキャプチャします。これは、複数のストアまたは型間のデータです。
  • Vの消去: ガバナンスとデータの品質保証のために考慮されたデータ セットの実証とキュレーション (データの精度) が含まれます。

デザインに関する考慮事項

数量

  • 既存の (存在する場合) と、ビジネス目標と計画に合わせた予測データの増加率に基づく将来のデータ量。

    • データ ボリュームには、データ自体とインデックス、ログ、テレメトリ、およびその他の適用可能なデータセットが含まれている必要があります。
    • 大規模なビジネス クリティカル アプリケーションとミッション クリティカル アプリケーションでは、通常、大量の (GB と TB) を毎日生成して格納します。
    • データの拡張に関連して、コストに大きな影響を与える可能性があります。

  • データ ボリュームは、ビジネス環境の変化やハウスキープ処理の手順によって変動する可能性があります。

  • データ ボリュームは、データ プラットフォームのクエリパフォーマンスに大きな影響を与える可能性があります。

  • データ プラットフォームのボリューム制限に達すると、大きな影響を受ける可能性があります。

    • ダウンタイムが発生しますか?もしそうなら、どれくらいの期間?
    • 軽減手順は何ですか?軽減策にはアプリケーションの変更が必要ですか?
    • データ損失のリスクはありますか?

  • Time to Live (TTL) などの機能を使用すると、レコードの作成または変更を使用して、ある時間の経過後にレコードを自動的に削除することで、データの増加を管理できます。

    • たとえば、Azure Cosmos DB には組み込みの TTL 機能が用意されています。

ベロシティ

  • さまざまなアプリケーション コンポーネントからデータが出力される速度と、データをコミットおよび取得する必要がある速度のスループット要件は、主要なワークロード シナリオに最適なデータ テクノロジを決定するために重要です。

    • スループット要件の性質は、読み取り負荷や書き込み負荷が高いワークロード シナリオなど、ワークロード シナリオによって異なります。
      • たとえば、分析ワークロードは通常、大きな読み取りスループットに対応する必要があります。
    • 必要なスループットは何ですか? スループットはどのように向上すると予想されますか?
    • 参照読み込みレベルでの P50/P99 でのデータ待機時間の要件は何ですか?

  • 高スループットを実現するには、ロック不要の設計、インデックスのチューニング、整合性ポリシーのサポートなどの機能が不可欠です。

    • 高スループットの構成を最適化するとトレードオフが発生します。これは完全に理解する必要があります。
    • 負荷平準化の永続化とメッセージング パターン (CQRS やイベント ソーシングなど) を使用して、スループットをさらに最適化できます。

  • 多くのアプリケーション シナリオで、負荷レベルは自然に変動します。自然のピーク時に、スループットと待機時間を維持しながら、変動する需要を処理するための十分な弾力性が必要です。

    • アジャイル スケーラビリティは、容量レベルをオーバープロビジョニングすることなく、可変スループットと負荷レベルを効果的にサポートするための鍵です。
      • 読み取りと書き込みのスループットはどちらも、アプリケーションの要件と負荷に応じてスケーリングする必要があります。
      • 垂直方向と水平方向の両方のスケール操作を適用して、負荷レベルの変化に対応できます。

  • スループットの低下の影響は、ワークロードのシナリオによって異なる場合があります。

    • 接続の中断は発生しますか?
    • コントロール プレーンが引き続き動作している間、個々の操作でエラー コードが返されますか?
    • データ プラットフォームは調整をアクティブにします。その場合、どのくらいの期間有効になりますか?

  • アクティブ/アクティブな地理的分散を使用するための基本的なアプリケーション設計の推奨事項では、データの整合性に関する課題が発生します。

    • 完全な ACID トランザクション セマンティクスと従来のロック動作に関して、一貫性とパフォーマンスの間にはトレードオフがあります。
      • 書き込み待機時間を最小限に抑えることは、データの一貫性を犠牲にすることになります。

  • 複数リージョンの書き込み構成では、必要に応じて競合解決を使用して、すべてのレプリカ間で変更を同期およびマージする必要があり、パフォーマンス レベルとスケーラビリティに影響を与える可能性があります。

  • 読み取り専用レプリカ (リージョン内およびリージョン間) を使用して、ラウンドトリップ待機時間を最小限に抑え、トラフィックを分散してパフォーマンス、スループット、可用性、スケーラビリティを向上させることができます。

  • キャッシュ レイヤーを使用すると、読み取りスループットを向上させ、ユーザー エクスペリエンスとエンド ツー エンドのクライアント応答時間を向上させることができます。

    • データの最新性を最適化するには、キャッシュの有効期限とポリシーを考慮する必要があります。

多様性 (Variety)

  • データ モデル、データ型、データ リレーションシップ、および目的のクエリ モデルは、データ プラットフォームの決定に強く影響します。

    • アプリケーションにはリレーショナル データ モデルが必要ですか、それとも変数スキーマまたは非リレーショナル データ モデルをサポートできますか?
    • アプリケーションでデータのクエリを実行する方法 また、クエリはリレーショナル結合などのデータベース層の概念に依存しますか? または、アプリケーションはそのようなセマンティクスを提供しますか?

  • アプリケーションによって考慮されるデータセットの性質は、画像やビデオなどの非構造化コンテンツや、CSV や Parquet などの構造化されたファイルなど、さまざまな場合があります。

    • 複合アプリケーション ワークロードには、通常、個別のデータセットおよび関連する要件があります。

  • リレーショナル データ プラットフォームまたは非リレーショナル データ プラットフォームに加えて、グラフまたはキー値データ プラットフォームは、特定のデータ ワークロードにも適している場合があります。

    • 一部のテクノロジは変数スキーマ データ モデルに対応しており、データ項目は意味的に似ているか、一緒に格納および照会されますが、構造は異なります。

  • マイクロサービス アーキテクチャでは、単一のモノリシック データストアに応じてではなく、個別のシナリオ最適化データストアを使用して個々のアプリケーション サービスを構築できます。

    • SAGA などの設計パターンを適用して、異なるデータストア間の一貫性と依存関係を管理できます。
      • データベース間直接クエリでは、併配置制約が適用される可能性があります。
    • 複数のデータ テクノロジを使用すると、包括的なテクノロジを維持するための管理オーバーヘッドが増加します。

  • 各 Azure サービスの機能セットは、言語、SDK、API によって異なります。これは、適用できる構成チューニングのレベルに大きな影響を与える可能性があります。

  • データ モデルと包含されるデータ型との最適化されたアラインメントの機能は、データ プラットフォームの決定に大きく影響します。

    • ストアド プロシージャやオブジェクト リレーショナル マッパーなどのクエリ レイヤー。
    • セキュリティで保護された REST API レイヤーなど、言語に依存しないクエリ機能。
    • バックアップや復元などのビジネス継続性の機能。

  • 分析データストアは、通常、さまざまな種類のデータ構造のポリグロット ストレージをサポートします。

    • Apache Spark などの分析ランタイム環境には、ポリグロット データ構造を分析するための統合制限がある場合があります。

  • エンタープライズコンテキストでは、既存のプロセスとツールの使用、およびスキルの継続性は、データ プラットフォームの設計とデータ テクノロジの選択に大きな影響を与える可能性があります。

信憑性

  • アプリケーション内のデータの精度を検証するには、いくつかの要因を考慮する必要があります。また、これらの要因の管理は、データ プラットフォームの設計に大きな影響を及ぼす可能性があります。

    • データの整合性。
    • プラットフォームのセキュリティ機能。
    • データ ガバナンス。
    • 変更管理とスキーマの進化。
    • データセット間の依存関係。

  • 複数のデータ レプリカを持つ分散アプリケーションでは、 CAP と PACELC の定理で表されているように、一貫性と待機時間の間にトレードオフがあります。

    • リーダーとライターが明確に配布されている場合、アプリケーションは、別のレプリカ内のそのデータ項目の完全な書き込み (更新) と比較して最新でない場合でも、最も速く利用可能なバージョンのデータ項目を返すか、最新の状態を判断して取得するための追加の待機時間が発生する可能性があるデータ項目の最新バージョンを返すように選択する必要があります。
    • 整合性と可用性は、プラットフォーム レベルまたは個々のデータ要求レベルで構成できます。
    • 別のレプリカの最新の状態を反映していないユーザーに最も近いレプリカからデータを提供する場合のユーザー エクスペリエンスは何ですか?つまり、アプリケーションは古いデータを提供する可能性をサポートできますか?

  • 複数リージョンの書き込みコンテキストでは、いずれかの変更をレプリケートする前に 2 つの個別の書き込みレプリカで同じデータ項目が変更されると、競合が作成され、解決する必要があります。

    • "最終書き込み優先" などの標準化された競合解決ポリシー、またはカスタム ロジックを使用したカスタム戦略を適用できます。

  • セキュリティ要件の実装は、スループットやパフォーマンスに悪影響を与える可能性があります。

  • 保存時の暗号化は、クライアント側の暗号化を使用してアプリケーション層に実装することも、必要に応じてサーバー側暗号化を使用してデータ層に実装することもできます。

  • Azure では、サービスマネージド キーを使用するサーバー側暗号化、Key Vaultのカスタマー マネージド キー、カスタマー マネージド ハードウェア上のカスタマー マネージド キーなど、さまざまな暗号化モデルがサポートされています。

    • クライアント側の暗号化を使用すると、キーをKey Vaultまたは別の安全な場所で管理できます。

  • MACsec (IEEE 802.1AE MAC) データ リンク暗号化は、Microsoft バックボーン ネットワーク上の Azure データセンター間を移動するすべてのトラフィックをセキュリティで保護するために使用されます。

    • パケットは送信される前にデバイスで暗号化および復号化され、物理的な "man-in-the-middle" 攻撃やスヌーピング/ワイヤートマッピング攻撃を防ぎます。

  • データ プレーンとコントロール プレーンに対する認証と承認。

    • データ プラットフォームは、アプリケーション アクセスと運用アクセスをどのように認証および承認しますか?

  • プラットフォームの正常性とデータ アクセスの監視による可観測性。

    • 許容される運用境界外の条件に対してアラートはどのように適用されますか?

設計上の推奨事項

数量

  • 有機的な成長に関連する将来のデータ ボリュームが、データ プラットフォームの機能を超える可能性がないことを確認します。

    • ビジネス計画に合わせてデータの増加率を予測し、確定された率を使用して継続的な容量要件を通知します。
    • 集計およびデータごとのレコード ボリュームをデータ プラットフォームの制限と比較します。
    • 例外的な状況で制限に達する危険性がある場合は、ダウンタイムとデータ損失を防ぐために、運用上の軽減策を必ず実施します。

  • スケール制限と予想されるデータ増加率を考慮して、データ ボリュームを監視し、容量モデルに対して検証します。

    • スケール操作がストレージ、パフォーマンス、整合性の要件と一致していることを確認します。
    • 新しいスケール ユニットが導入されると、基になるデータをレプリケートする必要がある場合があり、レプリケーションの実行中に時間がかかり、パフォーマンスが低下する可能性があります。 そのため、可能であれば、これらの操作が重要な営業時間外に実行されるようにします。

  • 古いデータの削除またはオフロードを容易にするために、使用状況と重要度に基づいてデータセットを分類するアプリケーション データ層を定義します。

    • データセットを 'hot'、'warm'、および 'cold' ('archive') レベルに分類することを検討してください。
      • たとえば、基本的な参照実装では、Azure Cosmos DB を使用して、アプリケーションによってアクティブに使用される "ホット" データを格納します。一方、Azure Storage は分析目的で "コールド" 操作データに使用されます。

  • ハウスキーパーの手順を構成して、データの増加を最適化し、クエリのパフォーマンスやデータ拡張の管理などのデータ効率を高めます。

    • 不要になり、長期的な分析値がないデータに対して Time-To-Live (TTL) の有効期限を構成します。
      • アプリケーションに悪影響を与えることなく、古いデータを安全にセカンダリ ストレージに階層化したり、完全に削除したりできることを検証します。
    • 重要ではないデータはセカンダリ コールド ストレージにオフロードし、分析値用として、また監査要件を満たすために保持します。
    • データ プラットフォームのテレメトリと使用状況の統計を収集して、DevOps チームがハウスキーピング要件と "適切なサイズ" データストアを継続的に評価できるようにします。

  • マイクロサービス アプリケーションの設計に沿って、複数の異なるデータ テクノロジを並列で使用し、特定のワークロード シナリオとボリューム要件に合わせて最適化されたデータ ソリューションを使用することを検討してください。

    • 拡張によるデータ ボリュームの管理が困難な可能性がある単一のモノリシック データストアを作成しないようにします。

ベロシティ

  • データ プラットフォームは、シナリオ最適化データ ソリューションを使用してパフォーマンスを最大化するために、ワークロードを異なるコンテキストに分割して、高スループットをサポートするように本質的に設計および構成する必要があります。

    • 必ず、各データ シナリオの読み取りおよび書き込みスループットを、予期しない変動に対する十分な許容範囲で、予想されるロード パターンに従ってスケーリングできるようにします。
    • トランザクション操作や分析操作などのさまざまなデータ ワークロードを個別のパフォーマンス コンテキストに分離します。

  • CQRS またはイベント ソーシング パターンの使用など、非同期の非ブロッキング メッセージングを使用した読み込みレベル。

    • 書き込み要求と新しいデータが読み取り可能になったときの間に待機時間が発生する可能性があり、ユーザー エクスペリエンスに影響を与える可能性があります。
      • この影響は、主要なビジネス要件のコンテキストで理解し、許容できる必要があります。

  • アジャイルスケーラビリティを確保して、可変スループットと負荷レベルをサポートします。

    • 負荷レベルが揮発性が高い場合は、スループットとパフォーマンスが維持されるように、容量レベルのオーバープロビジョニングを検討してください。
    • スループットを維持できない場合に複合アプリケーションのワークロードに与える影響をテストして検証します。

  • 負荷レベルの変動に迅速に対応できるように、自動スケール操作を備えた Azure ネイティブ データ サービスを優先します。

    • サービスの内部しきい値とアプリケーションで設定されたしきい値に基づいて自動スケールを構成します。
    • スケーリングは、ビジネス要件と一致する期間で開始および完了する必要があります。
    • 手動操作が必要なシナリオの場合、手動操作アクションを実行するのではなく、トリガーできる自動化された運用 'プレイブック' を作成します。
      • 後続のエンジニアリング投資の一環として自動トリガーを適用できるかどうかを検討します。

  • P50/P99 待機時間の要件に対してアプリケーション データの読み取りと書き込みのスループットを監視し、アプリケーション容量モデルに合わせます。

  • 過剰なスループットは、データ プラットフォームまたはアプリケーション レイヤーによって適切に処理され、運用表現のために正常性モデルによってキャプチャされる必要があります。

  • 応答時間を最小限に抑えるために、"ホット" データ シナリオのキャッシュを実装します。

    • キャッシュの有効期限と家の保管に適切なポリシーを適用して、暴走データの増加を回避します。
      • バッキング データが変更されたときにキャッシュ 項目を期限切れにします。
      • キャッシュの有効期限が厳密に Time-To-Live (TTL) ベースである場合は、古いデータを提供する影響とカスタマー エクスペリエンスを理解する必要があります。

多様性 (Variety)

  • クラウドと Azure ネイティブの設計の原則に合わせて、運用と管理の複雑さを軽減し、Microsoft の将来のプラットフォーム投資を活用するために、マネージド Azure サービスに優先順位を付けることを強くお勧めします。

  • 疎結合マイクロサービス アーキテクチャのアプリケーション設計原則に合わせて、個々のサービスが個別のデータ ストアとシナリオ最適化データ テクノロジを使用できるようにします。

    • 特定のワークロード シナリオでアプリケーションが処理するデータ構造の種類を特定します。
    • 単一のモノリシック データストアへの依存関係を作成しないようにします。
      • データストア間の依存関係が存在する SAGA 設計パターンについて考えてみましょう。

  • 必要な機能が、選択したデータ テクノロジで使用可能であることを検証します。

    • 必要な言語と SDK 機能のサポートを確認します。 すべての言語/SDK で同じ方法ですべての機能を使用できるわけではありません。

信憑性

  • アプリケーション エンドポイントにデータを近づけることで信頼性、可用性、パフォーマンスを最大限に高めるために、マルチリージョンのデータ プラットフォーム設計を採用し、リージョン間でレプリカを分散します。

    • リージョン内のAvailability Zones (AZ) にデータ レプリカを分散 (またはゾーン冗長サービス レベルを使用) して、リージョン内の可用性を最大化します。

  • 一貫性の要件が許容される場合は、複数リージョンの書き込みデータ プラットフォーム設計を使用して、全体的な可用性と信頼性を最大化します。

    • 2 つの個別の書き込みレプリカで同じデータ項目が変更された場合は、いずれかの変更をレプリケートして競合を作成する前に、競合解決のビジネス要件を検討してください。
      • 可能な限り、"最後の 1 つ優先" などの標準化された競合解決ポリシーを使用する
        • カスタム ロジックを使用したカスタム戦略が必要な場合は、カスタム ロジックを管理するために CI/CD DevOps プラクティスが適用されていることを確認します。

  • 継続的デリバリー プロセス内でのカオス テストを通じて、バックアップと復元の機能とフェールオーバー操作をテストおよび検証します。

  • パフォーマンス ベンチマークを実行して、スループットとパフォーマンスの要件が、暗号化などの必要なセキュリティ機能を含めることによって影響を受けないようにします。

    • 継続的デリバリー プロセスでは、既知のパフォーマンス ベンチマークに対するロード テストを検討してください。

  • 暗号化を適用する場合、管理の複雑さを軽減する方法として、サービスマネージド暗号化キーを使用することを強くお勧めします。

    • カスタマー マネージド キーに固有のセキュリティ要件がある場合は、考慮されたすべてのキーの可用性、バックアップ、ローテーションを確保するために、必ず適切なキー管理手順を適用します。

Note

より広範な組織実装と統合する場合は、アプリケーション設計のデータ プラットフォーム コンポーネントのプロビジョニングと操作にアプリケーション中心のアプローチを適用することが重要です。

具体的には、信頼性を最大化するために、個々のデータ プラットフォーム コンポーネントが、他のアプリケーション コンポーネントを含む可能性のある運用アクションを通じてアプリケーションの正常性に適切に対応することが重要です。 たとえば、追加のデータ プラットフォーム リソースが必要なシナリオでは、容量モデルに従ってデータ プラットフォームを他のアプリケーション コンポーネントと共にスケーリングすることが必要になる可能性があります。場合によっては、追加のスケール ユニットをプロビジョニングする必要があります。 このアプローチは、分離してデータ プラットフォームに関連する問題に対処するために一元化された運用チームのハード依存関係がある場合に、最終的に制約されます。

最終的に、一元化されたデータ サービス (中央 IT DBaaS) を使用すると、運用上のボトルネックが発生します。これは、ほとんどコンテキストに依存しない管理エクスペリエンスを通じて機敏性を大幅に妨げ、ミッション クリティカルまたはビジネス クリティカルなコンテキストでは回避する必要があります。

その他の参照情報

その他のデータ プラットフォーム ガイダンスについては、「Azure アプリケーション アーキテクチャ ガイド」を参照してください。

グローバル分散マルチリージョン書き込みデータストア

アプリケーション設計のグローバルに分散されたアクティブ/アクティブの願望に完全に対応するために、分散マルチリージョン書き込みデータ プラットフォームを検討することを強くお勧めします。このプラットフォームでは、個別の書き込み可能レプリカに対する変更が同期され、必要に応じて競合解決が行われます。

重要

マイクロサービスに分散マルチリージョン書き込みデータストアが必要な場合もあります。そのため、各ワークロード シナリオのアーキテクチャ コンテキストとビジネス要件を考慮する必要があります。

Azure Cosmos DB は、グローバルに分散され高可用性の NoSQL データストアを提供し、マルチリージョンの書き込みと調整可能な一貫性をすぐに提供します。 そのため、このセクションの設計上の考慮事項と推奨事項は、最適な Azure Cosmos DB の使用に焦点を当てます。

設計上の考慮事項

Azure Cosmos DB

  • Azure Cosmos DB はコンテナー内にデータを格納します。これは、応答時間がミリ秒単位で高速なトランザクション読み取りと書き込みを可能にするように設計された、インデックス付きの行ベースのトランザクション ストアです。

  • Azure Cosmos DB では、SQL、Cassandra、MongoDB など、機能セットが異なる複数の異なる API がサポートされています。

    • ファースト パーティの Azure Cosmos DB for NoSQL は、最も豊富な機能セットを提供し、通常は新しい機能が最初に使用できるようになる API です。

  • Azure Cosmos DB では 、ゲートウェイと直接接続モードがサポートされています。Direct を使用すると、TCP 経由のバックエンド Azure Cosmos DB レプリカ ノードへの接続が容易になり、ネットワーク ホップ数が少ないパフォーマンスが向上し、ゲートウェイはフロントエンド ゲートウェイ ノードへの HTTPS 接続を提供します。

    • ダイレクト モードは、Azure Cosmos DB for NoSQL を使用している場合にのみ使用でき、現在は .NET および Java SDK プラットフォームでのみサポートされています。

  • 可用性ゾーンが有効なリージョン内では、Azure Cosmos DB は、リージョン内のゾーン障害に対する高可用性と回復性に対する可用性 ゾーン (AZ) 冗長 サポートを提供します。

  • Azure Cosmos DB では、1 つのリージョン内に 4 つのデータ レプリカが保持されており、可用性ゾーン (AZ) の冗長性が有効になっている場合、Azure Cosmos DB では、ゾーン障害から保護するために、データ レプリカが複数の AZ に確実に配置されます。

    • Paxos コンセンサス プロトコルは、リージョン内のレプリカ間でクォーラムを実現するために適用されます。

  • Azure Cosmos DB アカウントは、1 つのリージョンが使用できなくなるリスクを軽減するために、複数のリージョン間でデータをレプリケートするように簡単に構成できます。

    • レプリケーションは、単一リージョンの書き込みまたは複数リージョンの書き込みを使用して構成できます。
      • 単一リージョンの書き込みでは、プライマリ "ハブ" リージョンを使用してすべての書き込みを処理します。この "ハブ" リージョンが使用できなくなった場合は、別のリージョンを書き込み可能として昇格させるためにフェールオーバー操作が発生する必要があります。
      • 複数リージョンの書き込みを使用すると、アプリケーションは構成済みのデプロイ リージョンに書き込むことができます。これにより、他のすべてのリージョン間で変更がレプリケートされます。 リージョンが使用できない場合は、書き込みトラフィックの処理に残りのリージョンが使用されます。

  • 複数リージョンの書き込み構成では、ライターが複数のリージョンで同じ項目を同時に更新する場合 に、更新 (挿入、置換、削除) の競合 が発生する可能性があります。

  • Azure Cosmos DB には、競合に自動的に対処するために適用できる 2 つの競合解決ポリシーが用意されています。

    • Last Write Wins (LWW) は、システム定義のタイムスタンプ _ts プロパティを競合解決パスとして使用して、時刻同期クロック プロトコルを適用します。 競合の場合、競合解決パスの値が最も高いアイテムが勝者になり、複数のアイテムの数値が同じ場合、システムは勝者を選択して、すべてのリージョンが同じバージョンのコミット済みアイテムに収束できるようにします。
      • 削除の競合では、競合解決パスの値に関係なく、削除されたバージョンは常に挿入または置換の競合よりも優先されます。
      • "最後の書き込みが有効" が、既定の競合解決ポリシーです。
      • Azure Cosmos DB for NoSQL を使用する場合、競合解決にはカスタム タイムスタンプ定義などのカスタム数値プロパティを使用できます。
    • カスタム解決ポリシーを使用すると、アプリケーション定義のセマンティクスで、競合が検出されたときに自動的に呼び出される登録済みのマージ ストアド プロシージャを使用して競合を調整できます。
      • システムにより、コミットメント プロトコルの一部としてマージ プロシージャの実行が 1 回だけとなることが保証されます。
      • カスタム競合解決ポリシーは、Azure Cosmos DB for NoSQL でのみ使用でき、コンテナーの作成時にのみ設定できます。

  • 複数リージョンの書き込み構成では、1 つの Azure Cosmos DB の "ハブ" リージョンに依存してすべての競合解決を実行し、ハブ リージョン内のレプリカ間でクォーラムを達成するために、Paxos コンセンサス プロトコルが適用されます。

    • プラットフォームは、ハブ リージョン内の書き込み競合を読み込みレベルにするためのメッセージ バッファーを提供し、一時的な障害の冗長性を提供します。
      • バッファーは、コンセンサスを必要とする数分分の書き込み更新を格納できます。

Azure Cosmos DB プラットフォームの戦略的な方向性は、複数リージョンの書き込み構成で競合解決のためにこの単一リージョンの依存関係を削除し、2 フェーズの Paxos アプローチを利用してグローバル レベルおよびリージョン内でクォーラムを達成することです。

  • プライマリ "ハブ" リージョンは、Azure Cosmos DB が構成されている最初のリージョンによって決まります。

    • 優先順位の順序は、フェールオーバーのために追加のサテライトデプロイリージョン用に構成されます。

  • 最適なパフォーマンスと可用性を実現するために、論理パーティションと物理パーティション間のデータ モデルとパーティション分割が重要な役割を果たします。

  • 1 つの書き込みリージョンでデプロイする場合、Azure Cosmos DB は、すべての読み取りリージョン レプリカを考慮して、定義されたフェールオーバー優先度に基づいて 自動フェールオーバー 用に構成できます。

  • Azure Cosmos DB プラットフォームによって提供される RTO は最大 10 分から 15 分で、ハブ リージョンに影響を与える致命的な災害が発生した場合に、Azure Cosmos DB サービスのリージョン フェールオーバーを実行するための経過時間をキャプチャします。

    • この RTO は、競合解決のための単一の "ハブ" リージョンへの依存関係を考えると、マルチリージョンの書き込みコンテキストにも関連します。
      • "ハブ" リージョンが使用できなくなった場合、サービスがフェールオーバーされ、新しいハブ リージョンが確立されるまで競合解決が行われないため、メッセージ バッファーがいっぱいになると、他のリージョンへの書き込みは失敗します。

Azure Cosmos DB プラットフォームの戦略的な方向性は、パーティション レベルのフェールオーバーを許可することで RTO を約 5 分に減らすことです。

  • 復旧ポイント目標 (RPO) と目標復旧時間 (RTO) は、データの持続性とスループットのトレードオフを伴う一貫性レベルを使用して構成できます。

    • Azure Cosmos DB では、複数リージョンの書き込みを伴う緩やかな整合性レベルの場合は最小 RTO が 0、単一書き込みリージョンとの強力な整合性を確保するために RPO が 0 になります。

  • Azure Cosmos DB では、複数の Azure リージョンを書き込み可能として構成したデータベース アカウントの読み取りと書き込みの両方の可用性に対して 、99.999% の SLA が 提供されます。

    • SLA は、100% - 平均エラー率として計算される月間稼働時間の割合で表されます。
    • 平均エラー率は、請求月の各時間のエラー率の合計を請求月の合計時間数で割った値として定義されます。ここで、エラー率は、指定された 1 時間の間隔で失敗した要求の合計数を合計要求数で割った値です。

  • Azure Cosmos DB では、5 つの整合性レベルのいずれかで構成されている場合、1 つの Azure リージョンにスコープを設定したデータベース アカウントのスループット、一貫性、可用性、待機時間に対して 99.99% の SLA が提供されます。

    • 99.99% SLA は、4 つの緩やかな整合性レベルのいずれかで構成された複数の Azure リージョンにまたがるデータベース アカウントにも適用されます。

  • Azure Cosmos DB でプロビジョニングできるスループットには、標準と 自動スケーリングの 2 種類があります。これは、1 秒あたりの要求ユニット数 (RU/秒) を使用して測定されます。

    • 標準スループットは、指定された RU/秒の値を保証するために必要なリソースを割り当てます。
      • Standard は、プロビジョニングされたスループットに対して時間単位で課金されます。
    • 自動スケーリングでは最大スループット値が定義され、Azure Cosmos DB はアプリケーションの負荷に応じて、最大スループット値と最大スループット値の最小 10% の間で自動的にスケールアップまたはスケールダウンされます。
      • 自動スケーリングは、消費される最大スループットに対して 1 時間ごとに課金されます。

  • 可変ワークロードで静的にプロビジョニングされたスループットでは、調整エラーが発生する可能性があり、これにより、認識されるアプリケーションの可用性に影響を与える可能性があります。

    • 自動スケーリングでは、Azure Cosmos DB を必要に応じてスケールアップできるようにすることで調整エラーから保護します。一方、負荷が減少したときにスケールダウンすることでコスト保護を維持します。

  • Azure Cosmos DB が複数のリージョンにレプリケートされると、プロビジョニングされた要求ユニット (RU) はリージョンごとに課金されます。

  • マルチリージョン書き込み構成と単一リージョン書き込み構成の間にはコストの差が大きく、多くの場合、マルチマスター Azure Cosmos DB データ プラットフォームのコストが非常に大きくなる可能性があります。

単一リージョンの読み取り/書き込み 単一リージョン書き込み - デュアル リージョン読み取り デュアル リージョンの読み取り/書き込み
1 RU 2 RU 4 RU

単一リージョン書き込みとマルチリージョン書き込みの間の差分は、実際には上記の表に反映されている 1 対 2 の比率よりも小さくなります。 具体的には、単一書き込み構成の書き込み更新に関連するリージョン間データ転送料金があります。これは、複数リージョンの書き込み構成と同様に RU コスト内ではキャプチャされません。

  • 使用されたストレージは、特定の時間のデータとインデックスをホストするために消費されたストレージ (GB) の合計量に対して定額として課金されます。

  • Session は、データが書き込みと同じ順序で受信されるため、既定で最も広く使用される 整合性レベル です。

  • Azure Cosmos DB では、Microsoft Entra ID または Azure Cosmos DB キーとリソース トークンを使用した認証がサポートされています。これにより、重複する機能が提供されます。

Azure Cosmos DB アクセス機能

  • キーまたはリソース トークンを使用してリソース管理操作を無効にして、キーとリソース トークンをデータ操作のみに制限し、ロールベースのアクセス制御 (RBAC) を使用してきめ細かいリソース アクセス制御Microsoft Entra可能にすることができます。

    • キーまたはリソース トークンを使用してコントロール プレーンへのアクセスを制限すると、Azure Cosmos DB SDK を使用するクライアントのコントロール プレーン操作が無効になり、十分に 評価およびテストする必要があります。
    • この設定はdisableKeyBasedMetadataWriteAccess、ARM テンプレート IaC 定義または組み込みAzure Policyを使用して構成できます。

  • Azure Cosmos DB Microsoft Entra RBAC のサポートは、アカウントおよびリソース コントロール プレーンの管理操作に適用されます。

    • アプリケーション管理者は、ユーザー、グループ、サービス プリンシパル、またはマネージド ID のロールの割り当てを作成して、Azure Cosmos DB リソースに対するリソースと操作へのアクセスを許可または拒否できます。
    • ロールの割り当てに使用できる 組み込みの RBAC ロール がいくつかあります。 また、カスタム RBAC ロール を使用して特定の 特権の組み合わせを形成することもできます。
      • Cosmos DB アカウント 閲覧者 は、Azure Cosmos DB リソースへの読み取り専用アクセスを有効にします。
      • DocumentDB アカウント共同作成者 は、キーやロールの割り当てを含む Azure Cosmos DB アカウントの管理を有効にしますが、データ プレーン アクセスは有効にしません。
      • Cosmos DB オペレーター。DocumentDB アカウント共同作成者に似ていますが、キーまたはロールの割り当てを管理する機能は提供されていません。

  • Azure Cosmos DB リソース (アカウント、データベース、コンテナー) は、 リソース ロックを使用して誤った変更や削除から保護できます。

    • リソース ロックは、アカウント、データベース、またはコンテナー レベルで設定できます。
    • リソースに設定されたリソース ロックは、すべての子リソースによって継承されます。 たとえば、Azure Cosmos DB アカウントに設定されたリソース ロックは、アカウント内のすべてのデータベースとコンテナーによって継承されます。
    • リソース ロックはコントロール プレーン操作 にのみ 適用され、データの作成、変更、削除などのデータ プレーン操作は防止 されません 。
    • コントロール プレーンへのアクセスが で disableKeyBasedMetadataWriteAccess制限されていない場合、クライアントはアカウント キーを使用してコントロール プレーン操作を実行できます。

  • Azure Cosmos DB 変更フィードは、Azure Cosmos DB コンテナー内のデータに対する変更の時間順フィードを提供します。

    • 変更フィードには、ソース Azure Cosmos DB コンテナーへの挿入操作と更新操作のみが含まれます。削除は含まれません。

  • 変更フィードは、アプリケーションによって使用されるプライマリ コンテナーとは別のデータ ストアを維持するために使用でき、ソース コンテナーからの変更フィードによってフィードされたターゲット データ ストアに対する継続的な更新が行われます。

    • 変更フィードを使用すると、追加のデータ プラットフォーム冗長性のために、または後続の分析シナリオのためにセカンダリ ストアを設定できます。

  • 削除操作がソース コンテナー内のデータに日常的に影響を与える場合、変更フィードによってフィードされるストアは不正確になり、削除されたデータが参照されなくなります。

    • データ レコードが変更フィードに含まれるように、 論理的な削除 パターンを実装できます。
      • データ レコードを明示的に削除する代わりに、項目が削除されたと見なされることを示すフラグ (例: IsDeleted) を設定することで、データ レコードが更新されます。
      • 変更フィードによってフィードされたターゲット データ ストアは、削除されたフラグが True に設定されたアイテムを検出して処理する必要があります。論理的に削除されたデータ レコードを格納する代わりに、ターゲット ストア内の 既存 のバージョンのデータ レコードを削除する必要があります。
    • 通常、短い Time-To-Live (TTL) は論理的な削除パターンと共に使用され、Azure Cosmos DB は期限切れのデータを自動的に削除しますが、削除されたフラグが True に設定された変更フィード内に反映された後にのみ使用されます。
      • 変更フィードを通じて削除を反映しながら、元の削除意図を実行します。

  • Azure Cosmos DB は 分析ストアとして構成できます。これは、最適化された分析クエリの列形式を適用して、従来の ETL パイプラインで発生する複雑さと待機時間の課題に対処します。

  • Azure Cosmos DB は、パフォーマンスや可用性に影響を与えることなく、RU/秒を消費することなく、定期的にデータを自動的にバックアップします。

  • Azure Cosmos DB は、2 つの異なるバックアップ モードに従って構成できます。

    • Periodic は、すべてのアカウントの既定のバックアップ モードです。バックアップは定期的な間隔で作成され、サポート チームに要求を作成することでデータが復元されます。
      • 既定の定期的なバックアップ保有期間は 8 時間で、既定のバックアップ間隔は 4 時間です。つまり、既定では最新の 2 つのバックアップのみが格納されます。
      • バックアップ間隔と保持期間は、アカウント内で構成できます。
        • 最大保有期間は、1 時間の最小バックアップ間隔で 1 か月まで延長されます。
        • バックアップ ストレージの冗長性を構成するには、Azure の "Cosmos DB アカウント閲覧者ロール" へのロールの割り当てが必要です。
      • 2 つのバックアップ コピーは追加コストなしで含まれますが、追加のバックアップには追加のコストが発生します。
      • 既定では、定期的なバックアップは、直接アクセスできない個別の Geo-Redundant Storage (GRS) 内に格納されます。
        • バックアップ ストレージはプライマリ "ハブ" リージョン内に存在し、基になるストレージ レプリケーションを通じてペアになっているリージョンにレプリケートされます。
        • 基になるバックアップ ストレージ アカウントの冗長性構成は、 ゾーン冗長ストレージまたは Locally-Redundant Storage に構成できます。
      • 復元操作を実行するには、顧客が復元を直接実行できないため、サポート リクエストが必要です。
        • サポート チケットを開く前に、データ損失イベントから 8 時間以内にバックアップ保有期間を少なくとも 7 日間に増やす必要があります。
      • 復元操作により、データが復旧される新しい Azure Cosmos DB アカウントが作成されます。
        • 既存の Azure Cosmos DB アカウントを復元に使用することはできません
        • 既定では、 という名前 <Azure_Cosmos_account_original_name>-restored<n> の新しい Azure Cosmos DB アカウントが使用されます。
          • この名前は、元のアカウントが削除された場合に既存の名前を再利用するなどして調整できます。
      • スループットがデータベース レベルでプロビジョニングされている場合、バックアップと復元はデータベース レベルで行われます
        • 復元するコンテナーのサブセットを選択することはできません。
    • 連続 バックアップ モードでは、過去 30 日以内の任意の時点に復元できます。
      • 復元操作を実行して、1 秒の粒度で特定の時点 (PITR) に戻ることができます。
      • 復元操作に使用できる期間は最大 30 日です。
        • リソースのインスタンス化状態に復元することもできます。
      • 継続的バックアップは、Azure Cosmos DB アカウントが存在するすべての Azure リージョン内で作成されます。
        • 継続的バックアップは、Availability Zonesをサポートするリージョン内の Locally-Redundant Storage (LRS) またはゾーン冗長ストレージ (ZRS) を使用して、各 Azure Cosmos DB レプリカと同じ Azure リージョン内に格納されます。
      • セルフサービス復元は、Azure portalまたは ARM テンプレートなどの IaC 成果物を使用して実行できます。
      • 継続的バックアップにはいくつかの 制限があります 。
        • 現在、連続バックアップ モードは、複数リージョンの書き込み構成では使用できません。
        • 現時点では、継続的バックアップ用に構成できるのは、Azure Cosmos DB for NoSQL と Azure Cosmos DB for MongoDB のみです。
        • コンテナーに TTL が構成されている場合、TTL を超えた復元されたデータはすぐに削除される可能性があります
      • 復元操作では、ポイントインタイム リストア用の新しい Azure Cosmos DB アカウントが作成されます。
      • 継続的バックアップと復元操作には 、追加のストレージ コスト が発生します。

  • 既存の Azure Cosmos DB アカウントは、定期的から継続的に移行できますが、継続的から定期的に移行することはできません。移行は一方向であり、元に戻すことはできません。

  • 各 Azure Cosmos DB バックアップは、データ自体と、プロビジョニングされたスループット、インデックス作成ポリシー、デプロイ リージョン、コンテナー TTL 設定の構成の詳細で構成されます。

  • 定期的なアプローチと継続的なアプローチが適していないシナリオでは、カスタムのバックアップと復元の機能を実装できます。

    • カスタム アプローチでは、大きなコストと追加の管理オーバーヘッドが発生します。これを理解し、慎重に評価する必要があります。
      • データ項目でのアカウント、データベース、コンテナーの破損や削除など、一般的な復元シナリオをモデル化する必要があります。
      • バックアップのスプロールを防ぐために、ハウスキーピング手順を実装する必要があります。
    • Azure Storage または代替データ テクノロジを使用できます(代替の Azure Cosmos DB コンテナーなど)。
      • Azure Storage と Azure Cosmos DB は、Azure FunctionsやAzure Data Factoryなどの Azure サービスとのネイティブ統合を提供します。

  • Azure Cosmos DB のドキュメントは、カスタム バックアップを実装するための 2 つのオプションを示しています。

    • 別のストレージ機能にデータを書き込む Azure Cosmos DB 変更フィード。
    • 変更フィードを使用して、継続的または定期的な (バッチ処理された) カスタム バックアップを実装できます。
    • Azure Cosmos DB の変更フィードには削除がまだ反映されていないため、ブール型プロパティと TTL を使用して論理的な削除パターンを適用する必要があります。
      • 変更フィードで完全に忠実な更新が提供される場合、このパターンは必要ありません。
    • Azure Data Factory Connector for Azure Cosmos DB (Azure Cosmos DB for NoSQL または MongoDB API コネクタ) を使用してデータをコピーします。
      • Azure Data Factory (ADF) では、手動実行とスケジュール、タンブリング ウィンドウ、およびイベント ベースのトリガーがサポートされます。
        • Storage と Event Grid の両方のサポートを提供します。
      • ADF は、バッチ指向オーケストレーションのために定期的なカスタム バックアップ実装に主に適しています。
        • オーケストレーションの実行オーバーヘッドが原因でイベントが頻繁に発生する継続的バックアップの実装には適していません。
      • ADF では、高ネットワーク セキュリティ シナリオのAzure Private Linkがサポートされます

Azure Cosmos DB は多くの Azure サービスの設計内で使用されるため、Azure Cosmos DB のリージョンが大幅に停止すると、そのリージョン内のさまざまな Azure サービスに連鎖的な影響が及びます。 特定のサービスへの正確な影響は、基になるサービス設計で Azure Cosmos DB がどのように使用されているかによって大きく異なります。

設計上の推奨事項

Azure Cosmos DB

  • 要件が可能なプライマリ データ プラットフォームとして Azure Cosmos DB を使用します。

  • ミッション クリティカルなワークロード シナリオの場合は、待機時間を短縮し、冗長性を最大限に高めるために、各デプロイ リージョン内に書き込みレプリカを使用して Azure Cosmos DB を構成します。

    • アプリケーションの負荷、パフォーマンス、およびリージョン RU/秒の消費量を最適化するために、書き込みと読み取りに ローカル Azure Cosmos DB レプリカの使用を優先 するようにアプリケーションを構成します。
    • マルチリージョン書き込み構成は大きなコストがかかるので、最大限の信頼性を必要とするワークロード シナリオにのみ優先順位を付ける必要があります。

  • 重要度の低いワークロード シナリオでは、グローバル分散読み取りレプリカでの単一リージョン書き込み構成 (Availability Zones を使用する場合) の使用に優先順位を付けます。これは、高レベルのデータ プラットフォーム信頼性 (読み取り用の場合は 99.999% SLA、書き込み操作の場合は 99.995% SLA) をより魅力的な価格ポイントで提供するためです。

    • ローカルの Azure Cosmos DB 読み取りレプリカを使用して読み取りパフォーマンスを最適化するようにアプリケーションを構成します。

  • 複数リージョンの書き込み構成で競合解決が行われ、すべての書き込みが単一リージョンの書き込み構成で実行される最適な "ハブ" デプロイ リージョンを選択します。

    • 他のデプロイ リージョンとの相対的な距離と、プライマリ リージョンの選択に関連する待機時間、およびAvailability Zonesサポートなどの必要な機能を考慮してください。

  • リージョン内のゾーン障害に対する回復性を確保するために、AZ がサポートされているすべてのデプロイ リージョンで可用性 ゾーン (AZ) 冗長性 を使用して Azure Cosmos DB を構成します。

  • Azure Cosmos DB for NoSQL は、特にパフォーマンス チューニングに関係する最も包括的な機能セットを提供するため、使用します。

    • 代替 API は、主に移行または互換性のシナリオで考慮する必要があります。
      • 代替 API を使用する場合は、最適な構成とパフォーマンスを確保するために、選択した言語と SDK で必要な機能が使用できることを検証します。

  • 直接接続モードを使用して、バックエンドの Azure Cosmos DB ノードへの直接 TCP 接続を使用してネットワーク パフォーマンスを最適化し、ネットワーク 'ホップ' の数を減らします。

Azure Cosmos DB SLA は、失敗した要求を平均化することによって計算されます。これは、99.999% の信頼性レベルのエラー予算と直接一致しない可能性があります。 そのため、99.999% SLO 用に設計する場合は、リージョンとマルチリージョンの Azure Cosmos DB 書き込み不可を計画し、後続の再生用の永続化されたメッセージ キューなどの障害が発生した場合にフォールバック ストレージ テクノロジを配置することが重要です。

  • 論理パーティションと物理パーティションの両方でパーティション分割戦略を定義し、データ モデルに従ってデータ分散を最適化します。

    • クロス パーティション クエリを最小化する。
    • 最適なパフォーマンスを確保するために、パーティション分割戦略を繰り返 しテストして検証 します。

  • 最適なパーティション キーを選択します。

    • パーティション キーは、コレクション内に作成された後は変更できません。
    • パーティション キーは、変更されないプロパティ値である必要があります。
    • カーディナリティが高く、使用可能な値の範囲が広いパーティション キーを選択します。
    • パーティション キーは、RU 消費量とデータ ストレージをすべての論理パーティションに均等に分散して、物理パーティション間で RU 消費量と記憶域の分散を確保する必要があります。
    • パーティション分割された列に対して読み取りクエリを実行して、RU の消費量と待機時間を削減します。

  • インデックス作成 はパフォーマンスにも重要であるため、インデックスの除外を使用して RU/秒とストレージの要件を減らします。

    • クエリ内でのフィルター処理に必要なフィールドにのみインデックスを作成します。最も使用される述語のインデックスを設計します。

  • Azure Cosmos DB SDK の組み込みのエラー処理、再試行、より広範な信頼性機能を活用します。

  • 管理の複雑さを軽減するには、サービスマネージド暗号化キーを使用します。

    • カスタマー マネージド キーに特定のセキュリティ要件がある場合は、バックアップやローテーションなど、適切なキー管理手順が適用されていることを確認します。

  • 組み込みのAzure Policyを適用して、Azure Cosmos DB のキーベースのメタデータ書き込みアクセスを無効にします。

  • Azure Monitor で、プロビジョニング済みスループット (RU/秒) などの主要なメトリックと診断ログを収集できるようにします。

    • Azure Monitor の運用データを、アプリケーション設計内の Azure Cosmos DB およびその他のグローバル リソース専用の Log Analytics ワークスペースにルーティングします。
    • Azure Monitor メトリックを使用して、アプリケーション トラフィック パターンが自動スケーリングに適しているかどうかを判断します。

  • アプリケーション トラフィック パターンを評価して、 プロビジョニングされたスループットの種類に最適なオプションを選択します。

    • ワークロードの需要を自動的に平準化するために、プロビジョニングされたスループットを自動スケールすることを検討してください。

  • 待機時間とスループットを向上させるためにクライアント側とサーバー側の構成を最適化するために 、Azure Cosmos DB の Microsoft のパフォーマンスに 関するヒントを評価します。

  • コンピューティング プラットフォームとして AKS を使用する場合: クエリを集中的に使用するワークロードの場合は、高速ネットワークが有効になっている AKS ノード SKU を選択して、待機時間と CPU ジッターを減らします。

  • 単一書き込みリージョンのデプロイでは、 自動フェールオーバー用に Azure Cosmos DB を構成することを強くお勧めします。

  • Azure Cosmos DB に更新プログラムを書き込む、システム フロー内での非同期の非ブロッキング メッセージングの使用による読み込みレベル。

  • Azure Cosmos DB アカウントを継続的バックアップ用に構成して、過去 30 日間の復旧ポイントの細分性を取得します。

    • 包含データまたは Azure Cosmos DB アカウントが削除または破損するシナリオでは、Azure Cosmos DB バックアップの使用を検討してください。
    • 絶対に必要な場合を除き、カスタム バックアップ アプローチの使用は避けてください。

  • 標準のビジネス継続性運用の準備の一環として、非運用リソースとデータに対して復旧手順を実践することを強くお勧めします。

  • IaC 成果物を定義して、Azure Cosmos DB バックアップ復元の構成設定と機能を再確立します。

  • Azure Cosmos DB のバックアップと復旧に関する Azure セキュリティ ベースライン 制御ガイダンスを評価して適用します。

  • 複数リージョンの可用性を必要とする分析ワークロードの場合は、最適化された分析クエリに列形式を適用する Azure Cosmos DB 分析ストアを使用します。

リレーショナル データ テクノロジ

高度なリレーショナル データ モデルまたは既存のリレーショナル テクノロジへの依存関係があるシナリオでは、複数リージョンの書き込み構成での Azure Cosmos DB の使用は直接適用できない場合があります。 そのような場合は、アプリケーション デザインの複数リージョンのアクティブ/アクティブの目標を維持するように、使用されるリレーショナル テクノロジを設計および構成することが重要です。

Azure には、mySQL、PostgreSQL、MariaDB などの一般的な OSS リレーショナル ソリューション用の Azure SQL Database や Azure Database など、多くのマネージド リレーショナル データ プラットフォームが用意されています。 そのため、このセクションの設計上の考慮事項と推奨事項では、信頼性とグローバルな可用性を最大化するために、Azure SQL Database と Azure Database OSS フレーバーの最適な使用に焦点を当てます。

設計上の考慮事項

  • リレーショナル データ テクノロジは読み取り操作を簡単にスケーリングするように構成できますが、通常、書き込みでは 1 つのプライマリ インスタンスを通過するように制限されます。これにより、スケーラビリティとパフォーマンスに大きな制約が発生します。

  • シャーディングを 適用して、複数の同一の構造化データベースにデータと処理を分散し、データベースを水平方向にパーティション分割してプラットフォームの制約をナビゲートできます。

    • たとえば、シャーディングは多くの場合、テナントのグループを個別のデータ プラットフォーム コンストラクトに分離するために、マルチテナント SaaS プラットフォームで適用されます。

Azure SQL Database

  • Azure SQL Database には、最新の安定したバージョンの SQL Server データベース エンジンと基になるオペレーティング システムで常に実行されているフル マネージド データベース エンジンが用意されています。

    • パフォーマンス チューニング、脅威の監視、脆弱性評価などのインテリジェントな機能を提供します。

  • Azure SQL Database には、リージョンの高可用性とターンキー geo レプリケーションが組み込まれており、Azure リージョン間で読み取りレプリカを分散できます。

    • geo レプリケーションでは、フェールオーバーが開始されるまで、セカンダリ データベース レプリカは読み取り専用のままです。
    • 同じリージョンまたは異なるリージョンで最大 4 つのセカンダリがサポートされます。
    • セカンダリ レプリカを読み取り専用クエリ アクセスに使用して、読み取りパフォーマンスを最適化することもできます。
    • フェールオーバーは手動で開始する必要がありますが、自動化された操作手順でラップできます。

  • Azure SQL Database には、データベースをセカンダリ サーバーにレプリケートし、障害が発生した場合に透過的なフェールオーバーを可能にする自動フェールオーバー グループが用意されています。

    • 自動フェールオーバー グループは、グループ内のすべてのデータベースの geo レプリケーションを、別のリージョン内の 1 つのセカンダリ サーバーまたはインスタンスにのみサポートします。
    • 自動フェールオーバー グループは、Hyperscale サービス レベルでは現在サポートされていません。
    • セカンダリ データベースを使用して、読み取りトラフィックをオフロードできます。

  • Premium または Business Critical サービス レベルのデータベース レプリカは、追加料金なしでAvailability Zonesに分散できます。

    • また、コントロール リングは、3 つのゲートウェイ リング (GW) として複数のゾーンにまたがって複製されます。
      • 特定のゲートウェイ リングへのルーティングは Azure Traffic Manager によって制御されます。
    • Business Critical レベルを使用している場合、ゾーン冗長構成は Gen5 コンピューティング ハードウェアが選択されている場合のみ利用できます。

  • Azure SQL Database では、すべてのサービス レベルでベースライン 99.99% の可用性 SLA が提供されますが、可用性ゾーンをサポートするリージョンでは、Business Criticalまたは Premium レベルに対して 99.995% 以上の SLA が提供されます。

    • Azure SQL Database Business Critical または Premium レベルがゾーン冗長デプロイ用に構成されていない場合、可用性 SLA は 99.99% です。

  • geo レプリケーションを使用して構成すると、Azure SQL Database Business Critical レベルでは、デプロイされた時間の 100% に対して 30 秒の目標復旧時間 (RTO) が提供されます。

  • geo レプリケーションを使用して構成した場合、Azure SQL Database Business Critical レベルの目標復旧ポイント (RPO) は、デプロイされた時間の 100% に対して 5 秒です。

  • Azure SQL Database Hyperscale レベルは、少なくとも 2 つのレプリカで構成されている場合、可用性 SLA は 99.99% です。

  • Azure SQL Database に関連付けられているコンピューティング コストは、予約割引を使用して削減できます。

    • DTU ベースのデータベースに予約容量を適用することはできません。

  • ポイントインタイム リストア を使用して、データベースと包含データを以前の時点に返すことができます。

  • geo リストア を使用して、geo 冗長バックアップからデータベースを復旧できます。

Azure Database For PostgreSQL

  • Azure Database For PostgreSQL は、次の 3 つの異なるデプロイ オプションで提供されています。

    • 単一サーバー、SLA 99.99%
    • 可用性ゾーンの冗長性を提供するフレキシブル サーバー、SLA 99.99%
    • Hyperscale (Citus)、高可用性モードが有効になっている場合の SLA 99.95%。

  • Hyperscale (Citus) は、アプリケーションを変更せずにシャーディングを通じて動的なスケーラビリティを提供します。

    • Hyperscale (Citus) でスケーラブルなクエリを確保するには、複数の PostgreSQL サーバーにテーブル行を分散することが重要です。
    • 複数のノードは、従来のデータベースよりも多くのデータをまとめて保持でき、多くの場合、ワーカー CPU を並列で使用してコストを最適化できます。

  • 自動スケーリング は、Runbook オートメーションを使用して構成して、トラフィック パターンの変化に応じて弾力性を確保できます。

  • フレキシブル サーバーは、サーバーを停止または起動する機能と、継続的なコンピューティング容量を必要としないワークロードに適したバースト可能なコンピューティング レベルを通じて、非運用ワークロードのコスト効率を実現します。

  • プロビジョニングされたサーバー ストレージ全体の最大 100% に対して、バックアップ ストレージに追加料金はかかりません。

    • バックアップ ストレージの追加使用量は、消費された GB/月に応じて課金されます。

  • Azure Database for PostgreSQLに関連付けられているコンピューティング コストは、単一サーバー予約割引または Hyperscale (Citus) 予約割引のいずれかを使用して削減できます。

設計上の推奨事項

  • プラットフォームの制約の移動、スケーラビリティと可用性の最大化、障害の分離に役立てるために、アプリケーションとデータのさまざまなコンテキストに基づいてリレーショナル データベースをパーティション分割するシャーディングを検討します。

    • この推奨事項は、アプリケーションの設計で 3 つ以上の Azure リージョンが考慮される場合に特に一般的です。これは、リレーショナル テクノロジの制約によって、グローバルに分散されたデータ プラットフォームが大幅に妨げられる可能性があるためです。
    • シャーディングはすべてのアプリケーション シナリオに適しているわけではないため、状況に即した評価が必要です。

  • Azure プラットフォームでの成熟度と幅広い信頼性機能のために、リレーショナル要件が存在する Azure SQL Database を優先的に使用します。

Azure SQL Database

  • 重要な回復性機能へのアクセスなど、信頼性と可用性を最大限に高めるために、Business-Critical サービス レベルを使用します。

  • 仮想コア ベースの消費モデルを使用して、ワークロードのボリュームとスループットの要件に合わせて調整されたコンピューティング リソースとストレージ リソースの独立した選択を容易にします。

    • コンピューティングリソースとストレージリソースの要件を通知するために、定義された容量モデルが適用されていることを確認します。
      • 潜在的なコストの最適化を提供するには、 予約容量 を検討してください。

  • Zone-Redundant デプロイ モデルを構成して、同じリージョン内Business Criticalデータベース レプリカをAvailability Zonesに分散します。

  • アクティブ geo レプリケーションを使用して、すべてのデプロイ リージョン (最大 4 つ) 内に読み取り可能なレプリカをデプロイします。

  • 自動フェールオーバー グループを使用してセカンダリ リージョンへの 透過的なフェールオーバー を提供し、geo レプリケーションを適用して、読み取りの最適化とデータベースの冗長性のために追加のデプロイ リージョンへのレプリケーションを提供します。

    • 2 つのデプロイ リージョンのみに制限されているアプリケーション シナリオの場合、自動フェールオーバー グループを優先的に使用する必要があります。

  • 自動フェールオーバー グループ内のプライマリとセカンダリに影響を与える障害が発生した場合は、アプリケーション正常性モデルに合わせたアラートに基づいて自動運用トリガーを検討し、geo レプリケートされたインスタンスへのフェールオーバーを実行します。

重要

4 つ以上のデプロイ リージョンを検討しているアプリケーションの場合は、Azure Cosmos DB などの複数リージョンの書き込みテクノロジをサポートするために、アプリケーション スコープのシャーディングまたはリファクタリングに真剣に考慮する必要があります。 ただし、これがアプリケーション ワークロード のシナリオで実現できない場合は、geo レプリケートされたインスタンスを含むプライマリ状態に 1 つの地域内のリージョンを、より均等に分散された読み取りアクセスに昇格することをお勧めします。

  • 読み取りパフォーマンスを最適化するために、読み取りクエリのレプリカ インスタンスにクエリを実行するようにアプリケーションを構成します。

  • 信頼性インシデントを検出するために、Azure SQL DB のほぼリアルタイムの運用分析情報には、Azure Monitor と Azure SQL Analytics を使用します。

  • Azure Monitor を使用して、すべてのデータベースの使用状況を評価し、適切なサイズに設定されているかどうかを判断します。

    • 適切なデータ プラットフォームの動作を検証するために、必ず CD パイプラインで代表的な負荷レベルでのロード テストが考慮されるようにします。

  • データベース コンポーネントの正常性メトリックを計算して、ビジネス要件とリソース使用率に関連する正常性を観察し、 監視とアラート を使用して、必要に応じて自動化された運用アクションを推進します。

    • サービスの低下が発生したときに迅速なアクションを実行できるように、主要なクエリ パフォーマンス メトリックが組み込まれていることを確認します。

  • Query Performance Insights と Microsoft が提供する一般的なパフォーマンスに関する推奨事項を使用して、クエリ、テーブル、データベースを最適化します。

  • SDK を使用して再試行ロジックを実装し、データベース接続に影響する一時的なエラー Azure SQL軽減します。

  • 保存時の暗号化にサーバー側の Transparent Data Encryption (TDE) を適用する場合は、サービスマネージド キーの使用に優先順位を付けます。

    • カスタマー マネージド キーまたはクライアント側 (AlwaysEncrypted) 暗号化が必要な場合は、バックアップと自動ローテーション機能を使用してキーに適切な回復性があることを確認します。

  • 重大な構成エラーから回復するために、ポイント インタイム リストア を運用プレイブックとして使用することを検討してください。

Azure Database For PostgreSQL

  • フレキシブル サーバーは、可用性ゾーンのサポートにより、ビジネスクリティカルなワークロードに使用することをお勧めします。

  • ビジネスクリティカルなワークロードに Hyperscale (Citus) を使用する場合は、高可用性モードを有効にして 99.95% の SLA 保証を受け取ります。

  • Hyperscale (Citus) サーバー構成を使用して、複数のノード間の可用性を最大化します。

  • アプリケーションの容量モデルを定義して、データ プラットフォーム内のコンピューティングリソースとストレージ リソースの要件を通知します。

ホット層データのキャッシュ

メモリ内キャッシュ レイヤーを適用して、読み取りスループットを大幅に向上させ、ホット層データ シナリオのエンド ツー エンドのクライアント応答時間を向上させることで、データ プラットフォームを強化できます。

Azure には、キー データ構造をキャッシュするための適用可能な機能を備えたサービスがいくつか用意されており、データ プラットフォームの読み取りアクセスを抽象化および最適化するために配置Azure Cache for Redisがあります。 したがって、このセクションでは、追加の読み取りパフォーマンスとデータ アクセスの持続性が必要なシナリオでのAzure Cache for Redisの最適な使用に焦点を当てます。

デザインに関する考慮事項

  • キャッシュ層は、基になるデータ テクノロジに影響を与える障害が発生した場合でも、キャッシュ層を介してアプリケーション データ スナップショットにアクセスできるため、追加のデータ アクセスの持続性を提供します。

  • 特定のワークロード シナリオでは、メモリ内キャッシュをアプリケーション プラットフォーム自体に実装できます。

Azure Cache for Redis

  • Redis cache は、メモリ内ストレージ システムオープンソース NoSQL キー値です。

  • Enterprise および Enterprise Flash レベルは、geo レプリケーションを使用して、リージョン内のAvailability Zonesと異なる Azure リージョン間でアクティブ/アクティブ構成でデプロイできます。

    • 少なくとも 3 つの Azure リージョンにデプロイされ、各リージョンに 3 つ以上のAvailability Zonesがデプロイされ、すべてのキャッシュ インスタンスに対してアクティブ geo レプリケーションが有効になっている場合、Azure Cache for Redisは 1 つのリージョン キャッシュ エンドポイントへの接続に対して 99.999% の SLA を提供します。
    • 1 つの Azure リージョン内の 3 つのAvailability Zonesにデプロイすると、99.99% の接続 SLA が提供されます。

  • Enterprise Flash レベルは、RAM とフラッシュ非揮発性メモリ ストレージの組み合わせで実行されます。これにより、パフォーマンスの低下が小さくなりますが、クラスタリングを使用して最大 13 TB の非常に大きなキャッシュ サイズも可能になります。

  • geo レプリケーションでは、キャッシュ インスタンスに関連する直接コストに加えて、リージョン間のデータ転送の料金も適用されます。

  • スケジュールされた更新機能には、基になる VM オペレーティング システムに適用された Azure の更新プログラムや更新プログラムは含まれません。

  • データが新しいインスタンスに移行されている間、スケールアウト操作中の CPU 使用率が増加します。

設計上の推奨事項

  • 読み取りスループットを向上させ、応答時間を向上させるために、"ホット" データ シナリオ用に最適化されたキャッシュ レイヤーを検討します。

  • キャッシュの有効期限とハウスキーピングに適切なポリシーを適用して、データの急増を回避します。

    • バッキング データが変更された場合にキャッシュ項目を期限切れにすることを検討します。

Azure Cache for Redis

  • Premium または Enterprise SKU を使用して、信頼性とパフォーマンスを最大化します。

    • データ ボリュームが非常に大きいシナリオの場合、Enterprise Flash レベルを検討する必要があります。
    • パッシブ geo レプリケーションのみが必要なシナリオの場合、Premium レベルも検討できます。

  • 考慮されるすべてのデプロイ リージョンにわたって、アクティブな構成で geo レプリケーションを使用してレプリカ インスタンスをデプロイします。

  • レプリカ インスタンスが、考慮された各 Azure リージョン内のAvailability Zones全体にデプロイされていることを確認します。

  • Azure Monitor を使用してAzure Cache for Redisを評価します。

    • リージョン キャッシュ コンポーネントの正常性スコアを計算して、ビジネス要件とリソース使用率に対する正常性を確認します。
    • CPU 使用率の高い、メモリ使用量が多い、サーバーの負荷が高い、削除されたキーなどの主要なメトリックを監視してアラートを生成し、キャッシュをスケーリングする際の分析情報を得ます。

  • 再試行ロジック、タイムアウトを実装し、Redis 接続マルチプレクサーのシングルトン実装を使用して、接続の 回復性 を最適化します。

  • Redis Server の更新プログラムがキャッシュに適用される日時を指定するように 、スケジュールされた 更新プログラムを構成します。

分析シナリオ

ミッション クリティカルなアプリケーションでは、包含されるデータ フローから追加の価値を引き出す手段として分析シナリオを検討することがますます一般的になります。 したがって、アプリケーションと運用 (AIOps) 分析シナリオは、信頼性の高いデータ プラットフォームの重要な側面を形成します。

分析ワークロードとトランザクション ワークロードでは、それぞれのコンテキスト内で許容されるパフォーマンスのために、さまざまなデータ プラットフォーム機能と最適化が必要です。

説明 分析 トランザクション
ユース ケース 非常に大量のデータ ("ビッグ データ") を分析する 大量の個々のトランザクションを処理する
最適化の対象 多くのレコードに対するクエリと集計の読み取り 少数のレコードに対するほぼリアルタイムの作成/読み取り/更新/削除 (CRUD) クエリ
主な特性 - レコードのデータ ソースからの統合
- 列ベースのストレージ
- 分散ストレージ
- 並列処理
-非 正規 化
- コンカレンシーの低い読み取りと書き込み
- 圧縮を使用してストレージ ボリュームを最適化する		 - アプリケーションのレコードのデータ ソース
- 行ベースのストレージ
- 連続するストレージ
- 対称処理
-正規化
- 高コンカレンシーの読み取りと書き込み、インデックスの更新
- メモリ内ストレージを使用して高速データ アクセスを最適化する

Azure Synapseでは、Azure Cosmos DB などの Azure サービスとの組み込みの統合を使用して、リレーショナル データと非リレーショナル データを Spark テクノロジと組み合わせて、ビッグ データ分析を容易にするエンタープライズ分析プラットフォームが提供されます。 そのため、このセクションの設計上の考慮事項と推奨事項は、分析シナリオに最適なAzure Synapseと Azure Cosmos DB の使用に焦点を当てます。

デザインに関する考慮事項

  • 従来、大規模な分析シナリオは、後続の分析クエリ用に最適化された別のデータ プラットフォームにデータを抽出することによって容易に実行できるようになります。
    • 抽出、変換、読み込み (ETL) パイプラインは、データを抽出するために使用され、スループットが消費され、トランザクション ワークロードのパフォーマンスに影響します。
    • ETL パイプラインを頻繁に実行してスループットとパフォーマンスへの影響を減らすと、分析データの最新の状態が低下します。
    • ETL パイプラインの開発とメンテナンスのオーバーヘッドは、データ変換が複雑になるにつれて増加します。
      • たとえば、ソース データが頻繁に変更または削除される場合、ETL パイプラインは、追加/バージョン管理されたアプローチ、ダンプと再読み込み、または分析データに対するインプレース変更を通じて、分析クエリのターゲット データの変更を考慮する必要があります。 これらのアプローチはそれぞれ、インデックスの再作成や更新など、二次的な影響を与えます。

Azure Cosmos DB

  • Azure Cosmos DB トランザクション データに対して実行される分析クエリは、通常、大量のデータに対してパーティション間で集計され、大量の要求ユニット (RU) スループットが消費され、周辺のトランザクション ワークロードのパフォーマンスに影響を与える可能性があります。

  • Azure Cosmos DB 分析ストアは、スキーマ化された完全に分離された列指向データ ストアを提供します。これにより、Azure Cosmos DB トランザクション ワークロードに影響を与えることなく、Azure Synapseから Azure Cosmos DB データに対する大規模な分析が可能になります。

    • Azure Cosmos DB コンテナーが分析ストアとして有効になっている場合、コンテナー内の運用データから新しい列ストアが内部的に作成されます。 この列ストアは、コンテナーの行指向トランザクション ストアとは別に永続化されます。
    • 運用データに対する作成、更新、および削除操作は分析ストアに自動的に同期されるため、変更フィードや ETL 処理は必要ありません。
    • 操作ストアから分析ストアへのデータ同期では、コンテナーまたはデータベースにプロビジョニングされたスループット要求ユニット (RU) は使用されません。 トランザクション ワークロードにパフォーマンスへの影響はありません。 分析ストアでは、Azure Cosmos DB データベースまたはコンテナーに追加の RU を割り当てる必要はありません。
    • 自動同期は、操作データの変更が分析ストアに自動的に同期されるプロセスです。 自動同期の待機時間は通常、2 分未満です。
      • 自動同期の待機時間は、共有スループットと多数のコンテナーを持つデータベースの場合、最大 5 分です。
      • 自動同期が完了するとすぐに、最新のデータをAzure Synapseから照会できます。
    • 分析ストア ストレージでは、使用量ベースの 価格モデル を使用します。このモデルでは、データの量と読み取り操作と書き込み操作の数が課金されます。 分析ストアの価格は、トランザクション ストアの価格とは別です。

  • Azure Synapse リンクを使用すると、Azure Cosmos DB 分析ストアに対してAzure Synapseから直接クエリを実行できます。 これにより、Synapse からの ETL なしのハイブリッド Transactional-Analytical 処理 (HTAP) が可能になるため、Azure Cosmos DB データを Synapse の他の分析ワークロードと共にほぼリアルタイムで照会できます。

  • Azure Cosmos DB 分析ストアは、既定ではパーティション分割されません。

    • 特定のクエリ シナリオでは、クエリ述語で頻繁に使用されるキーを使用して 分析ストア データをパーティション分割 することで、パフォーマンスが向上します。
    • パーティション分割は、Synapse Linkを使用して Spark ノートブックを実行するAzure Synapseのジョブによってトリガーされます。これにより、Azure Cosmos DB 分析ストアからデータが読み込まれて、Synapse ワークスペースのプライマリ ストレージ アカウントの Synapse パーティション ストアに書き込まれます。

  • Azure Synapse Analytics SQL Server レス プールでは、自動的に更新されたビューまたはコマンドを使用して分析ストアに対してクエリをSELECT / OPENROWSET実行できます。

  • Azure Synapse Analytics Spark プールでは、自動的に更新された Spark テーブルまたは コマンドを使用して分析ストアに対してクエリをspark.read実行できます。

  • Spark を使用して Azure Cosmos DB 分析ストアから専用の Synapse SQL プールにデータをコピーすることもできます。これにより、プロビジョニングされたAzure Synapse SQL プール リソースを使用できます。

  • Azure Cosmos DB 分析ストア のデータは、Azure Synapse Spark を使用してクエリを実行できます。

    • Spark ノートブックを使用すると、 Spark データフレーム の組み合わせを使用して、Azure Cosmos DB 分析データを他のデータ セットと集計および変換したり、変換されたデータを他のストアに書き込んだり、AIOps Machine Learning モデルをトレーニングしたりするなど、他の高度な Synapse Spark 機能を使用できます。

Azure Cosmos DB 分析列ストア

Azure Synapse

  • Azure Synapseでは、SQL データ ウェアハウス、Spark ビッグ データ、ログ分析と時系列分析用のData Explorerなどの分析機能が組み込まれています。

    • Azure Synapseでは、リンクされたサービスを使用して、Azure Storage などの他のサービスへの接続を定義します。
    • データは、サポートされているソースからCopy アクティビティ経由で Synapse Analytics に取り込むことができます。 これにより、ソース データ ストアに影響を与えることなく Synapse のデータ分析が可能になりますが、データ転送による時間、コスト、待機時間のオーバーヘッドが増加します。
    • サポートされている外部ストアでデータをインプレースクエリすることもできます。データインジェストと移動のオーバーヘッドを回避できます。 Data Lake Gen2 を使用した Azure Storage は Synapse でサポートされているストアであり、 Log Analytics のエクスポートされたデータは Synapse Spark を介してクエリを実行できます。

  • Azure Synapse Studio では、インジェストタスクとクエリタスクが統合されます。

    • Azure Cosmos DB 分析ストア データや Log Analytics エクスポート データなどのソース データは、ビジネス インテリジェンスやその他の集計された分析ユース ケースをサポートするためにクエリと処理が行われます。

Azure Synapse Analytics

設計上の推奨事項

  • トランザクション パフォーマンスを維持するために、必ず分析ワークロードがトランザクション アプリケーション ワークロードに影響を与えないようにします。

Application Analytics

AIOps と Operational Analytics

  • リソースからの運用データが送信されるソース Azure Storage アカウントごとに、リンクされたサービスとデータ セットを含む単一のAzure Synapse ワークスペースを作成します。

  • 専用の Azure Storage アカウントを作成し、それをワークスペース プライマリ ストレージ アカウントとして使用して、Synapse ワークスペース カタログのデータとメタデータを格納します。 Azure Data Lake Gen2 を有効にするために、階層型名前空間を使用して構成します。

    • ソース分析データと Synapse ワークスペース データとメタデータの分離を維持します。
      • 運用データが送信されるリージョンまたはグローバルの Azure Storage アカウントの 1 つを使用しないでください。

次のステップ

ネットワークに関する考慮事項を確認します。

ネットワークと接続性