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

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

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

ビッグ データの 4 対

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

• Volume: ストレージ容量と階層化の要件を知らせるデータの量、つまりデータセットのサイズです。
• Velocity: データがバッチまたは連続ストリームとして処理される速度、それがすなわちフローの速度です。
• Variety: データの編成と形式、構造化形式、半構造化形式、非構造化形式の取り込み、つまり、複数のストアや型にわたるデータです。
• Vの信頼性: 考慮されたデータ セットの出所とキュレーション、ガバナンスおよびデータ品質保証を含みます。それはデータの精度を意味します。

設計に関する考慮事項

数量

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

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

• 業務状況の変化やハウスキーピングの手順により、データ量が変動する場合があります。

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

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

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

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

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

速度

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

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

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

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

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

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

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

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

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

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

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

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

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

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

バラエティー

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

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

• アプリケーションによって考慮されるデータセットの性質は、画像やビデオなどの非構造化コンテンツや、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" 攻撃やスヌーピング/盗聴攻撃を防ぎます。

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

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

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

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

設計に関する推奨事項

数量

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

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

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

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

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

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

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

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

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

  • 拡張からのデータ ボリュームの管理が困難な場合がある単一のモノリシック データストアを作成することは避けてください。

速度

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

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

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

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

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

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

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

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

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

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

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

  • キャッシュの有効期限とハウスキーピングに適切なポリシーを適用して、データの肥大化を回避します。
    • バッキング データが変更されたときにキャッシュ 項目を期限切れにします。
    • キャッシュの有効期限が厳密にタイム・トゥー・リブ (TTL) ベースである場合は、更新されていないデータを提供することによる影響とカスタマーエクスペリエンスを理解する必要があります。

バラエティー

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

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

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

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

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

正確さ

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

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

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

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

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

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

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

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

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

その他のリファレンス

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

• Azure Data Store デシジョン ツリー
• データ ストアを選択するための条件
• 非リレーショナル データ ストア
• リレーショナル OLTP データ ストア

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

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

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 でのみ使用でき、コンテナー作成時にのみ設定できます。

• 複数リージョンの書き込み構成では、すべての競合解決を実行する単一の 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/秒) を使用して測定されます。

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

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

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

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

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

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

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

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

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

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

  • キーまたはリソース トークンを使用してコントロール プレーンアクセスを制限すると、Azure Cosmos DB SDK を使用するクライアントのコントロール プレーン操作が無効になり、徹底的に 評価およびテストする必要があります。
  • disableKeyBasedMetadataWriteAccess設定は、ARM テンプレートのIaC定義またはBuilt-In 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 に設定されたアイテムを検出して処理する必要があります。論理的に削除されたデータ レコードを格納する代わりに、ターゲット ストア内の 既存 のバージョンのデータ レコードを削除する必要があります。
  • 短いタイム・トゥ・ライブ (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) 内に格納されます。
      • バックアップ ストレージはプライマリ "ハブ" リージョン内に存在し、基になるストレージ レプリケーションを通じてペアリージョンにレプリケートされます。
      • 基になるバックアップ ストレージ アカウントの冗長性構成は、ゾーン冗長ストレージまたはローカル冗長ストレージに設定できます。
    • 復元操作を実行するには、お客様が直接復元を実行できないため、サポート リクエストが必要です。
      • サポート チケットを開く前に、データ損失イベントから 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 リージョン内で作成されます。
      • 継続的バックアップは、可用性ゾーンをサポートするリージョン内の 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 設定の構成の詳細で構成されます。

  • バックアップには、 ファイアウォール設定、 仮想ネットワーク アクセス制御リスト、 プライベート エンドポイント設定、 整合性設定 (セッション整合性でアカウントが復元される)、 ストアド プロシージャ、 トリガー、 UDF、または 複数リージョンの設定は含まれません。
    • お客様は、機能と構成設定を再デプロイする責任があります。 これらは Azure Cosmos DB バックアップを使用して復元されません。
  • Azure Synapse Link 分析ストア データは、Azure Cosmos DB バックアップにも含まれません。

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

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

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

  • Azure Cosmos DB 変更フィードはデータを別のストレージ施設に書き込みます。
    • Azure 関数または同等のアプリケーション プロセスでは、変更フィード プロセッサを使用して変更フィードにバインドし、項目をストレージに処理します。
  • 変更フィードを使用して、継続的または定期的な (バッチ処理された) カスタム バックアップの両方を実装できます。
  • 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 を構成します。

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

• 重要度の低いワークロード シナリオでは、グローバル分散読み取りレプリカで単一リージョン書き込み構成 (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 の組み込みのエラー処理、再試行、より広範な信頼性機能を活用します。

  • クライアント上の 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 セキュリティ ベースライン 制御ガイダンスを評価して適用します。

  • BR-1: 定期的な自動バックアップを確保する
  • BR-3: カスタマー マネージド キーを含むすべてのバックアップを検証する
  • BR-4、キーが失われるリスクを軽減する

• 複数リージョンの可用性を必要とする分析ワークロードの場合は、最適化された分析クエリに列形式を適用する 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 データベース

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

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

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

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

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

  • 自動フェールオーバー グループでは、グループ内のすべてのデータベースを別のリージョン内の 1 つのセカンダリ サーバーまたはインスタンスのみに geo レプリケーションできます。
  • 自動フェールオーバー グループは、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 つのレプリカで構成されている場合、99.99%の可用性 SLA を持ちます。

• 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 データベース

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

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

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

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

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

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

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

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

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

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

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

  • CD パイプラインでは、適切なデータ プラットフォームの動作を検証するために、代表的な負荷レベルでのロード テストを検討してください。

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

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

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

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

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

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

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

Azure Database For PostgreSQL

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

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

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

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

  • 潜在的なコストの最適化を提供するには、 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 リージョン間でアクティブ/アクティブ構成にデプロイできます。

  • すべてのキャッシュ インスタンスに対してアクティブ geo レプリケーションが有効になっている状態で、各リージョンに少なくとも 3 つの Azure リージョンと 3 つ以上の Availability Zones にデプロイされた場合、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) 分析シナリオは、信頼性の高いデータ プラットフォームの重要な側面を形成します。

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

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

• Azure Synapse Link を使用すると、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 コマンドを使用して分析ストアに対してクエリを実行できます。

• また、プロビジョニングされた Azure Synapse SQL プール リソースを使用できるように、Spark を使用して Azure Cosmos DB 分析ストアから専用の 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 ビッグ データ、データ エクスプローラーなどの分析機能が統合されます。

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

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

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

設計に関する推奨事項

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

Application Analytics

• Azure Synapse Link と Azure Cosmos DB 分析ストアを使用して、最適化されたデータ ストアを作成して Azure Cosmos DB の運用データに対して分析を実行します。これはトランザクション のパフォーマンスに影響しません。

  • Azure Cosmos DB アカウントで Azure Synapse Link を有効にします。
  • 分析ストアが有効になっているコンテナーを作成するか、 分析ストアの既存のコンテナーを有効にします。
  • Azure Synapse ワークスペースを Azure Cosmos DB 分析ストアに接続 して、Azure Synapse の分析ワークロードで Azure Cosmos DB データのクエリを実行できるようにします。 読み取り専用の Azure Cosmos DB キーで接続文字列を使用します。

• Azure Cosmos DB 変更フィードを使用して分析データ ストアを維持するのではなく、Azure Synapse Link を使用して Azure Cosmos DB 分析ストアに優先順位を付けます。

  • Azure Cosmos DB の変更フィードは、非常に単純な分析シナリオに適している場合があります。

AIOps と Operational Analytics

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

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

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

次のステップ

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