Share via

Azure Well-Architected Framework レビュー – Azure Cosmos DB for NoSQL

  • [アーティクル]

この記事では、Azure Cosmos DB for NoSQL のベスト プラクティスについて説明します。 これらのベスト プラクティスにより、効率的で信頼性が高く、セキュリティで保護され、コストに最適化され、運用上優れたソリューションを Azure Cosmos DB にデプロイできます。 このガイダンスでは、適切に設計されたフレームワークにおけるアーキテクチャエクセレンスの 5 つの柱に焦点を 当てています。

このレビュー ガイドでは、Azure Cosmos DB に関する実用的な知識があり、その機能に精通していることを前提としています。 詳細については、Azure Cosmos DB for NoSQL に関するページを参照してください。

前提条件

適切に設計されたフレームワークの柱を理解することは、高品質で安定した効率的なクラウド アーキテクチャを生み出すのに役立ちます。 まず、Azure Well-Architected Framework Review 評価を使用してワークロードを確認することをお勧めします。

詳細については、このガイドの考慮事項を設計に反映するさまざまな参照アーキテクチャを確認してください。 これらのアーキテクチャには次のものが含まれますが、これらに限定されるわけではありません。

信頼性

他のクラウド サービスと同様に、サービス側とワークロード側の両方で障害が発生する可能性があります。 すべての潜在的な障害を防ぐことは不可能ですが、単一の失敗したコンポーネントがワークロード全体に与える影響を最小限に抑える方が良い目標です。 このセクションには、1 回限りの障害の結果を最小限に抑えるための考慮事項と推奨事項が含まれています。

設計チェック リスト

推奨事項

推奨事項 特長
可用性ゾーン間で Azure Cosmos DB アカウントを分散します (使用可能な場合)。 可用性ゾーンでは、個別の電源、ネットワーク、冷却によって、ハードウェア障害をレプリカのサブセットに分離できます。 Azure Cosmos DB には、可用性ゾーン機能が使用されていない場合に、1 つのランダム可用性ゾーンにまたがる複数のレプリカがあります。 可用性ゾーン機能が使用されている場合、レプリカは複数の可用性ゾーンにまたがる。
少なくとも 2 つのリージョンにまたがるように Azure Cosmos DB アカウントを構成します。 複数のリージョンにまたがると、分離リージョンの停止が発生した場合にアカウントが完全に使用できなくなります。
アカウントのサービス管理フェールオーバーを有効にします。 サービスマネージド フェールオーバーを使用すると、Azure Cosmos DB は、可用性を維持するために複数リージョン アカウントの書き込みリージョンを変更できます。 この変更は、ユーザーの操作なしで発生します。 サービス管理フェールオーバーとのトレードオフを理解し、必要に応じて強制フェールオーバーを計画します。 詳細については、高可用性アプリケーションの構築を参照してください。
サービス管理フェールオーバーを一時的に無効にして、フェールオーバーを手動でテストして可用性を検証します。 サービス管理フェールオーバーを一時的に無効にすると、スクリプトまたは Azure portal を使用して手動フェールオーバーを開始して、アプリケーションのエンド ツー エンドの高可用性を検証できます。 その後、サービスで管理されたフェールオーバーを再び可能にすることができます。

Azure Policy の定義

セキュリティ

セキュリティは、利便性のために簡単に見落とすことができるアーキテクチャの重要な部分です。 最初のリソースまたは概念実証が作成される前に、さまざまなセキュリティのベスト プラクティスを事前に検討して、最終的なワークロードのセキュリティを強化します。 このセクションには、最終的なワークロードのセキュリティ脆弱性の数を減らすための考慮事項と推奨事項が含まれています。

設計チェック リスト

推奨事項

推奨事項 特長
少なくとも、データ保護と ID 管理のセキュリティ ベースラインを実装します。 ID 管理やデータ保護を含むセキュリティ ベースラインを確認します。 Azure Cosmos DB アカウントをセキュリティで保護するための推奨事項を実装します。
パブリック エンドポイントを無効にし、可能な限りプライベート エンドポイントを使用します。 不要なパブリック エンドポイントや未使用のパブリック エンドポイントをアカウントに対するセキュリティ攻撃に使用できないようにします。
ロールベースのアクセス制御を使用して、コントロール プレーン アクセスを特定の ID とグループに制限し、適切に定義された割り当てのスコープ内に限定します。 ロールベースのアクセス制御を使用して、アカウントへの意図しないアクセスを防ぎます。 Azure Cosmos DB にアクセスするユーザーまたはアプリケーションに適切なロールとアクセス許可を割り当てます。
仮想ネットワーク エンドポイントとルールを作成して、アカウントへのアクセスを制限します。 仮想ネットワーク サービス エンドポイントとファイアウォール規則を実装して、Azure Cosmos DB アカウントへのアクセスを制限します。 ネットワーク セキュリティ グループ (NSG) を使用して、Azure Cosmos DB リソースとの間の送受信トラフィックを制御します。 信頼されたネットワークへのアクセスを制限し、適切なネットワーク セキュリティ対策を適用することで、未承認のアクセスからデータを保護できます。
データへの安全なアクセスのために、最適なソフトウェア開発プラクティスに従ってください。 Azure Cosmos DB と対話するアプリケーションを開発するときに、セキュリティで保護されたコーディングプラクティスに従い、安全なコード レビューを実行します。 インジェクション攻撃、クロスサイト スクリプティング (XSS)、安全でない直接オブジェクト参照 (IDOR) などの一般的なセキュリティ脆弱性から保護します。 セキュリティ リスクを防ぐために、一般的な HTTP 状態コードの入力検証、パラメーター化されたクエリ、および適切なエラー処理を実装します。
コントロール プレーン ログの侵害を監視します。 監視を使用すると、アクセス パターンと監査ログを追跡し、データベースがセキュリティで保護され、関連するデータ保護規制に準拠メインを確保できます。 データ プレーンメトリックの監視は、セキュリティ侵害を明らかにする可能性のある未知のパターンを特定するのにも役立ちます。 詳細については、Azure データベースのセキュリティ チェックリストを参照してください。
Microsoft Defender for Azure Cosmos DB を有効にする Microsoft Defender は、Azure Cosmos DB for NoSQL アカウント内のデータベースを悪用しようとする試みを検出します。 Defender は、潜在的な SQL インジェクション、疑わしいアクセス パターン、およびその他の潜在的な悪用を検出します。

Azure Policy の定義

コストの最適化

ワークロードの特性とソリューションの実装は、Azure での実行の最終的なコストに影響を与える可能性があります。 ワークロードの設計時メインパーティション分割戦略、整合性レベル、レプリケーション、書き込みの種類などのドライバーを検討してください。 ワークロードのサイズを設定するときは、データの読み取り/書き込みの性質、平均項目のサイズ、正規化、TTL を考慮してください。 このセクションには、ワークロードのコストを効率化するための考慮事項と推奨事項が含まれています。

  • ワークロードで一般的に行う操作とクエリを考慮したインデックス作成ポリシーを設計します。
  • カードの高い値を持ち、変更されないパーティション キーまたはパーティション キーのセットを決定します。 既存のガイダンスとベスト プラクティスを使用して、適切なパーティション キーを選択します。 また、パーティション キーを決定するときは、インデックス作成ポリシーを検討してください。
  • ワークロードに適したスループット割り当てスキーマを選択します。 データベースまたはコンテナー レベルで分散される標準スループットと自動スケーリング スループットの利点を確認します。 また、必要に応じてサーバーレスを検討してください。 スループット割り当てスキームを選択するコンテキストで、ワークロードのトラフィック パターン を確認します。
  • ワークロードに関連する整合性レベルを検討してください。 また、クライアント セッションで既定の整合性レベルを変更する必要があるかどうかを検討してください。
  • ワークロードに予想される全体的なデータ ストレージを計算します。 項目とインデックスのサイズはすべて、データ ストレージ コストに影響します。 レプリケーションとバックアップがストレージ コストに与える影響を計算します。
  • 使用または不要になった古いアイテムを自動的に削除する戦略を作成します。 必要に応じて、これらの項目を削除する前に、低コストのストレージ ソリューションにエクスポートします。
  • パーティション間の参照を最小限に抑える最も一般的なクエリを評価します。 この情報を使用して、パーティション キーを選択するか、インデックス作成ポリシーをカスタマイズするプロセスを通知します。

推奨事項

推奨事項 特長
RU/秒の使用率とパターンを監視します。 メトリックを使用して、ソリューションの最初から RU 消費量を監視します。 クエリやその他のデータ調査手法を使用して、アプリケーション コード内のアンチパターンを見つけます。
ワークロードにマップするようにインデックス作成ポリシーをカスタマイズします。 既定のインデックス作成ポリシーはアイテム内のすべてのパスにインデックスを付け、このポリシーは RU の消費とコストに大きな影響を与える可能性があります。 一般的なクエリのインデックス作成に必要なパスのみに基づいて設計されたインデックス作成ポリシーを使用します。 書き込み負荷の高いワークロードの場合は、クエリで使用されない列の自動インデックス作成を無効にします。
ワークロードに最適なパーティション キーを選択します。 パーティション キーは、スループットの消費量とデータ ストレージを論理パーティション間で均等に分散する必要があります。 また、無制限のパーティション間クエリの数も最小限に抑える必要があります。 不均衡なパーティションではスループット コストと一時的なエラーが増加する可能性があり、トラフィックの量が不均衡になるホット パーティションは避けてください。 最も一般的な検索クエリを使用して、単一パーティションまたは境界付きのクロスパーティション クエリのみを実行する可能性のあるパーティション キーを特定します。
ワークロードに適した場合は、データベースレベルまたはコンテナー レベルで、サーバーレスまたはプロビジョニング済みスループット、手動プロビジョニングまたは自動スケーリングを使用します。 プロビジョニングされたスループットの種類 を比較し、ワークロードに適したオプションを選択します。 一般に、小規模で開発/テストのワークロードは、データベース レベルでのサーバーレス スループットまたは手動共有スループットの恩恵を受ける可能性があります。 ミッション クリティカルなワークロードが大きくなると、コンテナー レベルで割り当てられたプロビジョニング済みスループットのメリットが得られる場合があります。
アプリケーションの既定の 整合性レベル を構成します。 必要に応じて、 クライアント セッションの既定の整合性レベル をダウングレードします。 標準の既定の整合性レベルを変更したり、クライアント セッションでオーバーライドしたりする必要がない場合があります。 より強力な整合性レベルでの読み取りに関連するコストが高いことを検討してください。
開発/テスト ワークロードの場合は、Azure Cosmos DB エミュレーターを使用します。 Azure Cosmos DB エミュレーターは、開発/テストと継続的インテグレーションのオプションであり、開発チームのこれらの一般的なワークロードのコストを節約できます。 エミュレーターは、Docker コンテナー イメージとしても使用できます。
トランザクション バッチ操作を使用する 挿入する論理パーティション キー内のトランザクション バッチ操作を利用するようにパーティションを設計します。 1 つのトランザクション要求で複数のドキュメントを挿入、更新、または削除するには、クライアント側 SDKS でバッチ操作を使用します。 この手順により、個々の要求の数が減り、最終的にスループット効率が向上する可能性があります。
プロジェクションを使用して、大規模なクエリ結果セットのスループット コストを削減します。 クエリを作成して、結果セットに必要なフィールドの数を最小限に抑えるだけです。 フィールドの計算が必要な場合は、サーバー側とクライアント側の計算を実行する場合のスループット コストを評価します。
無制限のクロスパーティション クエリは使用しないでください。 クエリを評価して作成し、可能な限り単一の論理パーティション内で検索するようにします。 クエリ フィルターを使用して、クエリの対象となる論理パーティションを制御します。 クエリが論理パーティション間で検索する必要がある場合は、フル スキャンではなく、論理パーティションのサブセットのみを検索するようにクエリをバインドします。
Time to Live (TTL) を実装して、未使用の項目を削除します。 TTL を使用して、不要になったデータを自動的に削除します。 期限切れまたは古いデータを削除して、ストレージ コストを管理します。 必要に応じて、期限切れのデータを低コストのストレージ ソリューションにエクスポートします。
重い集計の分析ストアを検討してください。 Azure Cosmos DB 分析ストアは、データを別の列ストアに自動的に同期して、大規模な集計、レポート、分析クエリを最適化します。

Azure Policy の定義

オペレーショナルエクセレンス

ワークロードが意図したとおりに実行されるように、デプロイ後にワークロードを監視する必要があります。 さらに、ワークロードの監視は、計画フェーズですぐには明らかではない新しい効率のロックを解除するのに役立ちます。 致命的なシナリオでは、重大度の高いインシデントが発生した理由を明らかにするための鍵となるのが診断データです。 このセクションには、ワークロードのイベントと特性を監視するための考慮事項と推奨事項が含まれています。

設計チェック リスト

  • さまざまなワークロードを区別し、例外的なシナリオにフラグを付け、例外/エラーのパターンを追跡し、ホスト マシンのパフォーマンスを追跡するためのログとメトリックの監視戦略を下書きします。
  • 可能な限り一括操作を使用するように大規模なワークロードを設計します。
  • 調整の監視、スループットの割り当ての分析、データのサイズの追跡を行う複数のアラートを定義します。
  • リージョン間でソリューションを利用できるように監視戦略を設計します。
  • Azure Cosmos DB for NoSQL アカウントとリソースのデプロイを自動化するためのベスト プラクティスを作成して適用します。
  • パーティションとインデックスの設計に基づいて、予想されるメトリックしきい値を計画します。 これらのメトリックを監視して、計画されたしきい値にどの程度近づくかを判断する計画があることを確認します。

推奨事項

推奨事項 特長
アプリケーション開発者が最新バージョンの開発者 SDK を使用していることを確認します。 各 Azure Cosmos DB for NoSQL SDK には、推奨される最小バージョンがあります。 詳細については、「.NET SDK と Java SDK」を参照してください。
ワークロードを区別するために、クライアント アプリケーションで識別子を作成します。 各ログ エントリまたはメトリックに関連付ける必要があるワークロードを識別するには、ユーザー エージェント サフィックスなどのフラグを検討してください。
開発者 SDK を使用して補足診断をキャプチャします。 各 SDK の診断インジェクション手法を使用して、既定のメトリックとログと共にワークロードに関する補足情報を追加します。 詳細については、「.NET SDK と Java SDK」を参照してください。
ホスト コンピューター リソースに関連付けられたアラートを作成します。 接続と可用性の問題は、クライアント側のホスト コンピューターの問題が原因で発生する可能性があります。 Azure Cosmos DB for NoSQL SDK を使用して、クライアント アプリケーションを使用してホスト マシン上の CPU、メモリ、ストレージなどのリソースを監視します。
大規模な操作には、クライアント SDK の一括機能を使用します。 高いスループットを必要とするシナリオでは、SDK の一括機能を使用するとメリットがあります。 一括機能は、スループットを最大化するために操作を自動的に管理およびバッチ処理します。
スループット調整のアラートを作成します。 アラートを使用して、予想されるしきい値を超えるスループット調整を追跡します。 時間の経過と同時に、Azure Cosmos DB に関するワークロードの詳細を確認し、アラートを調整します。 正規化された RU 消費量メトリックは、データベースまたはコンテナーでのプロビジョニング済みスループットの使用率を測定するメトリックです。 このメトリックが一貫して 100% の場合、要求は一時的なエラーを返す可能性があります。
メトリックを使用してクエリのパフォーマンスを追跡します。 メトリックを使用して、時間の経過に伴う上位クエリのパフォーマンスを追跡します。 インデックス作成ポリシーを更新するか、クエリを変更して、効率が見つかるかどうかを評価します。 クエリのパフォーマンスが低い場合は、パフォーマンスのトラブルシューティングを行い、クエリのベスト プラクティスを適用します。 詳細については、クエリのパフォーマンスに関するヒントを参照してください。
テンプレートを使用して、アカウント リソースを自動的にデプロイします。 アカウントとその後のリソースのデプロイを自動化するには、Azure Resource Manager、Bicep、または Terraform テンプレートを検討してください。 チームが同じテンプレートを使用して、他の非運用環境にデプロイしていることを確認します。
主要なメトリックを追跡して、ワークロード内の一般的な問題を特定します。 特定のメトリックを使用して、ワークロード内の一般的な問題 (以下を含むがこれらに限定されない) を見つけます。RU 使用率、パーティションごとの RU 使用率、調整、および要求ボリュームの種類別。 詳細については、モニター・データ・リファレンスを参照してください。

Azure Policy の定義

パフォーマンス効率

  • アプリケーションのパフォーマンス ベースラインを定義します。 処理する必要がある同時ユーザーとトランザクションの数を測定します。 平均的なユーザー フロー、一般的な操作、使用量の急増などのワークロードの特性を考慮してください。
  • 最も一般的で最も複雑なクエリを調査します。 複数の参照、結合、または集計を使用するクエリを識別します。 パーティション キーまたはインデックス作成ポリシーの設計上の考慮事項で、これらのクエリを検討してください。
  • 最も一般的なクエリでは、1 ページあたりに予想される結果の数を決定します。 この数値は、プリフェッチされた結果のバッファー内の項目数を形式化するのに役立ちます。
  • ターゲット ユーザーを調査します。 それらに最も近い Azure リージョンを決定します。
  • 1 つ以上の順序フィールドを使用するクエリを識別します。 また、複数のフィールドに影響する操作を特定します。 これらのフィールドをインデックス作成ポリシーの設計に明示的に含めます。
  • 対応する JSON ドキュメントができるだけ小さいように項目を設計します。 必要に応じて複数の項目をまたがるデータの分割を検討します。
  • 子配列に対するクエリを特定し、それらがより効率的なサブクエリの 候補であるかどうかを判断します。
  • ワークロードに分析ストアが必要かどうかを判断します。 非常に複雑なクエリについては、Azure Synapse Link などの分析ストアとサービスを検討してください。
推奨事項 特長
パフォーマンス ベースラインに基づいてスループットを構成します。 容量計算ツールなどのツールを使用して、パフォーマンス ベースラインに必要なスループットの量を決定します。 自動スケーリングなどの機能を使用して、実際のスループットを実際のワークロードに合わせてスケーリングします。 その後、実際のスループット消費量を監視し、調整を行います。
必要に応じて、クライアント側とサーバー側で最適化手法を使用します。 組み込みの 統合キャッシュを利用します。 ページごとにプリフェッチ (バッファー処理) されて返される項目の数を管理するように SDK を構成します。
エンド ユーザーに最も近いリージョンに Azure Cosmos DB for NoSQL をデプロイします。 エンド ユーザーに最も近いリージョンに Azure Cosmos DB for NoSQL をできるだけデプロイすることで、待機時間を短縮します。 読み取りレプリケーションを利用して、書き込みの構成方法 (単一または複数のリージョン) に関係なく、パフォーマンスの高い読み取りパフォーマンスを実現します。 エンド ユーザーに近いリージョンを優先するように (.NET/Java) SDK を構成します。
ダイレクト モード用に SDK を構成します。 最適なパフォーマンスを得るための推奨オプションは、ダイレクト モードです。 このモードを使用すると、クライアントはサービス内のパーティションに直接 TCP 接続を開き、中間ゲートウェイなしで直接要求を送信できます。 このモードでは、ネットワーク ホップが少なくなるため、パフォーマンスが向上します。
一括操作のインデックス作成を無効にします。 挿入/置換/アップサート操作が多数ある場合は、インデックス作成を無効にして、対応する SDK の一括サポートを使用しながら操作の速度を向上させます。 インデックス作成は、後ですぐに再び有効化できます。
複雑な操作で使用されるフィールドの複合インデックスを作成します。 複合インデックスを使用すると、複数のフィールドに対する操作の効率を桁違いに高めることができます。 多くの場合、複数のフィールドを持つステートメントにはORDER BY複合インデックスを使用します。
SDK のホスト クライアント マシンを最適化します。 最も一般的なケースでは、SDK (.NET/Java) を使用して、64 ビット ホスト マシンで少なくとも 4 コアと 8 GB のメモリを使用します。 また、ホスト マシンで高速ネットワークを有効にします。
ほとんどの SDK のクラスにシングルトン パターンを CosmosClient 使用します。 ほとんどの SDK のクライアント クラスをシングルトンとして使用します。 クライアント クラスは独自のライフサイクルを管理し、破棄されないように設計されています。 インスタンスを常に作成して破棄すると、パフォーマンスが低下する可能性があります。
項目のサイズを 100 KB (キロバイト)未満にしてください。 一般的な読み取り操作と書き込み操作では、より大きな項目コンシューマーのスループットが向上します。 すべてのフィールドを射出する大きな項目に対するクエリでも、スループットコストが大幅に増加する可能性があります。
サブクエリを戦略的に使用して、大規模なデータ セットを結合するクエリを最適化します。 子配列を結合するクエリは、複数の配列が含まれ、フィルター処理されていない場合、複雑さが増す可能性があります。 たとえば、少なくとも 10 個の項目の 2 つ以上の配列を結合するクエリは、1,000 以上のタプルに拡張できます。 サブクエリを使用して自己結合式を 最適化し、項目内の配列を結合する前に 配列をフィルター処理します。 パーティション間クエリの場合は、クエリを最適化してパーティション キーのフィルターを含め、可能な限り最小限のパーティションへのクエリのルーティングを最適化します。
最も複雑なクエリには分析ワークロードを使用します。 大規模なコンテナーに対して頻繁に集計または結合クエリを実行する場合は、分析ストアを有効にして、Azure Synapse Analytics でクエリを実行することを検討してください。

Azure Policy の定義

その他のリソース

Azure Cosmos DB for NoSQL に関連するその他のリソースを検討してください。

Azure アーキテクチャ センターのガイダンス

クラウド導入フレームワークのガイダンス

次のステップ

Bicep テンプレートを使用して Azure Cosmos DB for NoSQL アカウントをデプロイする