Azure Cosmos DB for NoSQL のアーキテクチャのベスト プラクティス

シンプルなデザインを選択し、不要な機能を避けます。 複数プライマリの書き込みやカスタム インデックス作成など、ワークロードに不必要に複雑さを加える機能を採用しないでください。 Azure Cosmos DB ではこれらの機能がサポートされていますが、複雑さと運用上の負担が大幅に増える可能性があります。 ワークロードに高度な機能が必要かどうかを慎重に評価します。

認証と承認のための Microsoft Entra ID、監視用の Azure Monitor と Application Insights など、ワークロードの責任と横断的な懸念を他のサービスにオフロードします。

ワークロード フローを特定し、優先順位を付けます。 アプリケーション内のすべてのフローが同じように重要であるとは言えない。 重要なパスを特定し、各フローに優先順位を割り当てて、設計上の決定を導きます。 ユーザー フローの設計は、Azure Cosmos DB データベースに割り当てるサービス レベル、機能、容量に影響を与える可能性があります。

特別な処理が必要になる可能性がある重要なフローを特定するには、データ処理機能の観点からそれらを区別する処理要件をキャプチャします。 たとえば、一部のフローでは、スループットの高さが必要になったり、待機時間の問題に対して敏感になる場合があります。 また、一部のソリューション フローでは、異なるトランザクション整合性レベルが必要になる場合があります。

障害モード分析を使用して、ワークロード内の潜在的な障害を特定します。 潜在的な障害の軽減戦略を計画します。 次の表に、エラー モード分析の例を示します。

詳細については、「Azure アプリケーションのエラー モード分析」を参照してください。

冗長性を構築して回復性を向上させ、信頼性目標を満たすのに役立ちます。 Azure の少なくとも 2 つのリージョンにまたがるように、データベース アカウントのデプロイを設計します。 Azure リージョンでサポートされている場合は、アカウントを複数の可用性ゾーンに分散します。

ワークロードの複数リージョンと単一リージョンの書き込み戦略を評価します。 単一リージョンの書き込みでは、フェールオーバー用に少なくとも 2 番目の読み取りリージョンを持つワークロードを設計します。 単一リージョンの書き込みと複数リージョンの読み取りシナリオで自動フェールオーバーを有効にします。 複数リージョンの書き込みの場合は、複雑さと一貫性のトレードオフと、複数のリージョンへの書き込みの利点を比較します。 詳細については、リージョン停止時における単一リージョンおよび複数リージョンの書き込みアカウントでの期待される事項を参照してください。

整合性レベルとレプリケーション モードが、リージョン全体の停止における目標復旧ポイント (RPO) にどのように影響するかを検討します。

データベースのフェールオーバーとフェールバックのテストを含む、アプリケーションの高可用性のエンド ツー エンド テストを設計します。

ネイティブのディザスター リカバリーとバックアップ機能を使用します。 要件を満たすために、データベースとコンテナーのバックアップと復元を実装します。 復元シナリオには、ポイントインタイム リストア、偶発的な破壊的操作からの復旧、削除されたリソースの復元、特定の時点での別のリージョンへの復元などがあります。 継続的バックアップを使用してアカウントを構成します。 ビジネス要件に基づいて適切な保有期間を選択します。

Azure Cosmos DB の設計を、業界標準のアプリケーション設計のガイダンスとパターンに合わせます。 回復性のあるアプリケーションを設計し、SDK の既定の再試行ポリシーを確認し、特定の一時的なエラーに対するカスタム処理を計画するためのガイドを確認します。 これらのガイドでは、一時的なエラーに対するアプリケーション コードの回復性を高めるベスト プラクティスを提供します。

セキュリティ ベースラインを確認します。 ワークロードのセキュリティ体制を強化するには、 Azure データベースのセキュリティ チェックリスト と Azure Cosmos DB のセキュリティ ベースラインを確認します。 少なくとも、Azure Cosmos DB アカウントをセキュリティ で保護するために、データ保護 と ID 管理の セキュリティ ベースラインを実装します。

現在のグローバルな個人データ要件のコンテキストで、サービス レベルの コンプライアンス と 認定を 評価します。

厳密で条件付きで監査可能な ID とアクセス管理を実装します。 ワークロードの認証と承認のニーズに Microsoft Entra ID を使用します。 Microsoft Entra ID は、一元的な承認とアクセス管理を提供します。

アカウントへのコントロール プレーンとデータ プレーン アクセスの場合は、 最小特権アクセスの原則に基づいてロール、グループ、割り当てを作成します。 キーベースの認証を無効にすることを検討してください。

データを暗号化します。サービスマネージド キーまたはカスタマー マネージド キーを使用して、保存データまたは移動中のデータを暗号化します。

ネットワークのセグメント化とセキュリティ制御を適用します。 ネットワーク設計で意図的なセグメント化と境界を作成し、すべてのネットワーク境界でローカライズされたネットワーク制御を使用して多層防御の原則を適用します。

Azure Cosmos DB の セキュリティ ベースライン に従ってプライベート エンドポイントを使用して、攻撃領域を減らします。

包括的なセキュリティ監視戦略を実装します。 コントロール プレーン ログを使用して、ユーザー アクセス、セキュリティ侵害、およびリソース操作を監査します。

データ プレーン メトリックを使用して、データエグレス、データ変更、使用状況、待機時間を監視します。

セキュリティで保護された開発とテストのプラクティスを使用します。 データへの安全なアクセスのために、最適なソフトウェア開発プラクティスに従ってください。 Azure Cosmos DB と対話するアプリケーションを開発するときは、セキュリティで保護されたコーディングプラクティスに従い、セキュリティで保護されたコード レビューを実行します。

Azure Cosmos DB のスケーリング戦略を最適化します。 Azure Cosmos DB が ストレージとスループットのスケーリングを処理する方法について説明します。 要件を満たすために、パフォーマンスとコストの適切なバランスを決定します。

ワークロードに適したスループット割り当てスキーマを選択します。 データベースまたはコンテナー レベルで分散される標準スループットと自動スケーリング スループットの利点を確認します。 また、必要に応じてサーバーレス オプションを検討してください。 ワークロードのトラフィック パターンを分析して、 最適なスループット割り当てスキームを選択します。

カーディナリティが高く、変更されていないパーティション キーまたはパーティション キーのセットを決定します。 既存のガイダンスとベスト プラクティスを使用して、適切なパーティション キーを選択します。 また、パーティション キーを決定するときは、 インデックス作成ポリシー を検討してください。

Azure Cosmos DB のデータ コストを最適化します。 データのインベントリを取得し、ワークロードに予想される全体的なデータ ストレージを計算します。 項目とインデックスの両方のサイズは、データ ストレージ のコストに影響します。 レプリケーションとバックアップがストレージ コストに与える影響を計算します。

使用または不要になった古いアイテムを自動的に削除する戦略を作成します。 必要に応じて、これらの項目を削除する前に、低コストのストレージ ソリューションにエクスポートします。

コストに合わせてクエリを最適化します。 パーティション間の参照を最小限に抑える最も一般的なクエリを評価します。 この情報を使用して、パーティション キーを選択するか、インデックス作成ポリシーをカスタマイズするプロセスを通知します。

プロジェクションを使用して、大規模なクエリ結果セットのスループット コストを削減します。 クエリを作成して、結果セットで必要とされる最小限のフィールド数のみを推定します。 フィールドの計算が必要な場合は、サーバー側とクライアント側の計算を実行する場合のスループット コストを評価します。

無制限のクロスパーティション クエリは使用しないでください。 クエリを評価して作成し、可能な限り単一の論理パーティション内で検索するようにします。 クエリ フィルターを使用して、クエリの対象となる論理パーティションを制御します。 クエリが論理パーティション間で検索する必要がある場合は、フル スキャンではなく、論理パーティションのサブセットのみを検索するようにクエリをバインドします。

ワークロード内の一般的な操作とクエリを考慮するインデックス作成ポリシーを設計します。

Azure Cosmos DB インスタンスを監視します。 ワークロード監視ソリューションには、リージョン間で Azure Cosmos DB インスタンスを含めます。

ワークロードを区別するために、クライアント アプリケーションで識別子を作成します。 各ログ エントリまたはメトリックに関連付ける必要があるワークロードを識別するには、ユーザー エージェント サフィックスなどのフラグを検討してください。

さまざまなワークロードを区別し、例外的なシナリオにフラグを設定し、例外とエラーのパターンを追跡し、ホスト マシンのパフォーマンスを追跡するためのログとメトリックの監視戦略を下書きします。

調整の監視、スループットの割り当ての分析、データのサイズの追跡を行う複数のアラートを定義します。

パーティションとインデックスの設計に基づいて、予想されるメトリックしきい値を計画します。 これらのメトリックを監視して、計画されたしきい値にどの程度近いかを判断する計画を作成します。

コードとしてのインフラストラクチャ (IaC) を使用してデプロイを自動化します。 コードデプロイプラクティスに、インフラストラクチャのデプロイや構成の変更など、すべての Azure Cosmos DB の変更を組み込みます。

Azure Cosmos DB for NoSQL アカウントとリソースのデプロイを自動化するためのベスト プラクティスを作成して適用します。

チームが同じテンプレートを使用して、他の非運用環境にデプロイすることを確認します。

Azure Cosmos DB の容量を計画し、事前に管理します。 アプリケーションのパフォーマンス ベースラインを定義します。 処理する必要がある同時ユーザーとトランザクションの数を測定します。 平均的なユーザー フロー、一般的な操作、使用量の急増などのワークロードの特性を考慮してください。

ターゲット ユーザーを調査します。 それらに最も近い Azure リージョンを決定します。

データ設計を最適化します。 対応する JSON ドキュメントができるだけ小さいように項目を設計します。 必要に応じて、複数の項目にデータを分割することを検討してください。

アイテムのサイズ を 100 KB 未満にしてください。 項目が大きいほど、一般的な読み取りと書き込みの操作により多くのスループットが消費されます。 すべてのフィールドを射出する大きな項目に対するクエリでは、スループットコストも大幅に増加する可能性があります。

適切なレベル、機能、課金モデルを選択します。 ワークロードに分析ストアが必要かどうかを判断します。 複雑なクエリについては、 Azure Synapse Link などの分析ストアとサービスを検討してください。

デプロイ モデルを最適化します。 エンド ユーザーに最も近いリージョンに Azure Cosmos DB for NoSQL をデプロイします。 |エンド ユーザーに最も近いリージョンに Azure Cosmos DB for NoSQL をできるだけデプロイすることで、待機時間を短縮します。

パフォーマンスのためにクエリを最適化します。 クエリ パフォーマンスの ヒント を確認し、ユース ケースに適用する戦略を適用します。

1 つ以上の順序フィールドを使用するクエリを識別します。 また、複数のフィールドに影響する操作を特定します。 これらのフィールドをインデックス作成ポリシーの設計に明示的に含めます。

可能な限り一括操作を使用するように大規模なワークロードを設計します。

子配列に対するクエリを特定し、 それらがより効率的なサブクエリの候補であるかどうかを判断します。

最も一般的で複雑なクエリを調査します。 複数の参照、結合、または集計を使用するクエリを識別します。 パーティション キーまたはインデックス作成ポリシーの設計上の考慮事項で、これらのクエリを検討してください。

最も一般的なクエリでは、各ページに予想される結果の数を決定します。 この数値は、プリフェッチされた結果のバッファー内の項目数を形式化するのに役立ちます。

コード ロジックを最適化します。 ほとんどの SDK で、 CosmosClient クラスのシングルトン パターンを使用します。 ほとんどの SDK のクライアント クラスをシングルトンとして使用します。 クライアント クラスは独自のライフサイクルを管理し、破棄されないように設計されています。 インスタンスを常に作成して破棄すると、パフォーマンスが低下する可能性があります。