次の方法で共有

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

  • [アーティクル]

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

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

重要

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

ビッグ データの 4 つの V

"ビッグ データの 4 つの V" は、高可用性データ プラットフォームの必要な特性と、データを使用してビジネス価値を最大化する方法をより深く理解するためのフレームワークを提供します。 したがって、このセクションでは、適切なデータ テクノロジを使用してデータ プラットフォームを設計するために、概念レベルで Volume (ボリューム)、Velocity (ベロシティ)、Variety (多様性)、Veracity (正確性) の特性を適用する方法について説明します。

  • Volume (ボリューム): ストレージ容量と階層化の要件を通知するために使用されるデータの量 (データセットのサイズ) です。
  • Velocity (ベロシティ): バッチまたは連続ストリームとしてデータが処理される速度 (フローの速度) です。
  • Variety (多様性): データの編成と形式、構造化形式、半構造化形式、非構造化形式のキャプチャで、複数のストアまたは型にわたるデータです。
  • Veracity (正確性): ガバナンスとデータの品質保証のために考慮されたデータ セットの実証とキュレーションが含まれます。つまりデータの精度です。

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

量

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

    • データ ボリュームには、データ自体とインデックス、ログ、テレメトリ、およびその他の適用可能なデータセットが含まれている必要があります。
    • 大規模なビジネス クリティカル アプリケーションとミッション クリティカル アプリケーションでは、通常、大量の (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 などの分析ランタイム環境には、多言語データ構造を分析するための統合制限がある場合があります。

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

正確性 (Veracity)

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

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

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

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

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

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

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

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

  • Azure では、サービスが管理するキー、Key Vault でユーザーが管理するキー、またはユーザーが制御するハードウェア上でユーザーが管理するキーを使用したサーバー側暗号化など、さまざまな暗号化モデルがサポートされています。

    • クライアント側の暗号化を使用すると、Key Vault または別のセキュリティで保護された場所でキーを管理できます。

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

    • パケットは送信前にデバイス上で暗号化と復号化が行われ、物理的な "中間者" 攻撃、スヌーピング攻撃、盗聴攻撃を防ぎます。

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

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

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

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

設計上の推奨事項

量

  • オーガニック成長に関連する将来のデータ量が、データ プラットフォームの機能を超えないようにします。

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

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

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

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

    • データセットを "ホット"、"ウォーム"、"コールド" (アーカイブ) の階層に分類することを検討します。
      • たとえば、基本的な参照実装では、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 ですべての機能が同じ方法で利用できるわけではありません。

正確性 (Veracity)

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

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

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

    • 2 つの個別の書き込みレプリカで同じデータ項目が変更された場合、いずれかの変更をレプリケートする前に競合を作成する場合は、競合解決のビジネス要件を検討してください。
      • 可能な限り、"最後の変更を優先" などの標準化された競合解決ポリシーを使用します
        • カスタム ロジックを使用するカスタム戦略が必要な場合は、カスタム ロジックを管理するために 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 では、Gateway と Direct の接続モードがサポートされています。Direct では TCP 経由のバックエンド Azure Cosmos DB レプリカ ノードへの接続が容易になり、少ないネットワーク ホップ数でパフォーマンスを向上します。Gateway はフロントエンド ゲートウェイ ノードへの HTTPS 接続を提供します。

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

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

  • Azure Cosmos DB では、1 つのリージョン内に 4 つのデータ レプリカが保持され、Availability Zone (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 でのみ使用でき、コンテナー作成時にのみ設定できます。

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

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

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

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

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

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

  • 単一の書き込みリージョンでデプロイする場合、すべての読み取りリージョン レプリカを考慮して定義されたフェールオーバー優先度に基づいて自動フェールオーバーを行うように 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/秒の値を保証するために必要なリソースが割り当てられます。
      • 標準は、プロビジョニングされたスループットに対して 1 時間ごとに課金されます。
    • 自動スケーリングでは最大スループット値が定義され、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 のアクセス機能

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

    • キーまたはリソース トークンを使用してコントロール プレーンのアクセスを制限すると、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 冗長ストレージ (GRS) 内に格納されます。
        • バックアップ ストレージはプライマリ "ハブ" リージョン内に存在し、基になるストレージ レプリケーションを通じてペアのリージョンにレプリケートされます。
        • 基になるバックアップ ストレージ アカウントの冗長性構成は、ゾーン冗長ストレージまたはローカル冗長ストレージに構成できます。
      • お客様が直接復元を実行することはできないため、復元操作の実行にはサポート リクエストが必要です。
        • サポート チケットを開く前に、データ損失イベントから 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 をサポートするリージョン内でローカル冗長ストレージ (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 がサポートされているすべてのデプロイ リージョンで Availability Zone (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 メトリックを使用して、アプリケーションのトラフィック パターンが自動スケーリングに適しているかどうかを判断します。

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

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

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

  • コンピューティング プラットフォームとして 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 フレーバーの最適な使用に焦点を当てています。

設計上の考慮事項

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

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

    • たとえば、シャーディングは多くの場合、テナントのグループを個別のデータ プラットフォーム コンストラクトに分離するために、マルチテナント 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 が提供されますが、Availability Zones をサポートしているリージョンでは、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%
    • Availability Zoneの冗長性を提供するフレキシブル サーバー、SLA 99.99%
    • Hyperscale (Citus)、高可用性モードが有効になっている場合は SLA 99.95%。

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

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

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

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

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

    • バックアップ ストレージの超過使用分については、使用された GB/月に応じて課金されます。

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

設計上の推奨事項

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

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

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

Azure SQL Database

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

  • 仮想コア ベースの消費モデルを使用すると、ワークロードのボリュームとスループットの要件に合わせて、コンピューティング リソースとストレージ リソースを個別に選択できます。

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

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

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

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

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

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

重要

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

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

  • Azure Monitor と Azure SQL Analytics を使用して、信頼性インシデントの検出に関する Azure SQL DB の凖リアルタイムの運用分析情報を取得します。

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

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

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

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

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

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

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

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

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

Azure Database for PostgreSQL

  • フレキシブル サーバーは、Availability Zoneをサポートしているため、ビジネス クリティカルなワークロードに使用することをお勧めします。

  • ビジネス クリティカルなワークロードに 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 とフラッシュの不揮発性メモリ ストレージの組み合わせで実行され、これによって若干のパフォーマンス低下が発生する一方で、クラスタリングによって最大 13TB という非常に大きなキャッシュ・サイズが可能になります。

  • 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 Synapse から Azure Cosmos DB データに対する大規模な分析を Azure Cosmos DB トランザクション ワークロードに影響を与えることなく実現できます。

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

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

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

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

  • Azure Synapse Analytics SQL サーバーレス プールでは、自動的に更新されたビューまたは 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

設計上の推奨事項

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

アプリケーション分析

AIOps と運用分析

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

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

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

次のステップ

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

ネットワークと接続