<p><!--META { "title": "Azure Cosmos DBにおけるデータモデルとRUの最適化戦略", "primary_category": "Azure", "secondary_categories": ["Database", "NoSQL"], "tags": ["Azure", "CosmosDB", "DataModeling", "RU", "NoSQL", "CloudArchitecture"], "summary": "Azure Cosmos DBのデータモデルとRUは、パフォーマンスとコストを最適化する上で不可欠な要素である。適切な設計により、高いスケーラビリティと効率的な運用が実現可能となる。", "mermaid": true } --> Azure Cosmos DBのデータモデルとRUは、パフォーマンスとコストを最適化する上で不可欠な要素である。適切な設計により、高いスケーラビリティと効率的な運用が実現可能となる。</p> <h1 class="wp-block-heading">Azure Cosmos DBのデータモデルとRU</h1> <h2 class="wp-block-heading">アーキテクチャ</h2> <p>Azure Cosmos DBは、グローバル分散型、マルチモデルデータベースサービスであり、ドキュメント、キーバリュー、グラフ、カラムナといった多様なデータモデルをサポートする。その中核概念は「Request Unit (RU)」であり、これはデータベース操作のコストを抽象化したものとなる。データモデル設計は、RU消費量、クエリパフォーマンス、およびストレージ利用効率に直接影響を与える。</p> <p>データモデリングでは、エンティティの格納形式、リレーションシップ、インデックス戦略を検討する。特に、パーティションキーの選択は重要である。パーティションキーは、データを論理パーティションに分散させるために使用され、適切なキー設定により、データの均等な分散とホットパーティションの回避が可能となる。これにより、大規模なワークロードでも高いスループットと低レイテンシーが維持される。</p> <p>RUはCPU、メモリ、IOPSなどのリソース消費を正規化した単位で、読み取り、書き込み、クエリ、インデックス操作など、あらゆるデータベース操作に適用される。プロビジョニングスループットはRU/秒で指定され、この値がアプリケーションのピーク負荷に対応するように設定されるべきである。オートスケールスループットは、ワークロードに応じてRU/秒を自動的に調整し、コスト効率とパフォーマンスのバランスを取る。</p> <div class="wp-block-merpress-mermaidjs diagram-source-mermaid"><pre class="mermaid"> graph LR A["クライアントアプリケーション"] -->|CRUD操作| B("Azure Cosmos DB Gateway") B --> C{"論理パーティションキーの評価"} C --> D1["物理パーティション P1"] C --> D2["物理パーティション P2"] C --> D3["物理パーティション P3"] D1 --> E["データアイテム A(\"パーティションキー=X\")"] D2 --> F["データアイテム B(\"パーティションキー=Y\")"] D3 --> G["データアイテム C(\"パーティションキー=Z\")"] E --> H{"データモデルとインデックス"} F --> H G --> H H --> I["RU消費"] I --> J["RU/秒のプロビジョニング"] subgraph データモデルとRUの関係 C --- I D1 --- E E --- I end style A fill:#f9f,stroke:#333,stroke-width:2px style B fill:#bbf,stroke:#333,stroke-width:2px style C fill:#ccf,stroke:#333,stroke-width:2px style D1 fill:#fcf,stroke:#333,stroke-width:2px style D2 fill:#fcf,stroke:#333,stroke-width:2px style D3 fill:#fcf,stroke:#333,stroke-width:2px style E fill:#efe,stroke:#333,stroke-width:2px style F fill:#efe,stroke:#333,stroke-width:2px style G fill:#efe,stroke:#333,stroke-width:2px style H fill:#eef,stroke:#333,stroke-width:2px style I fill:#fef,stroke:#333,stroke-width:2px style J fill:#fdf,stroke:#333,stroke-width:2px </pre></div> <h2 class="wp-block-heading">設定手順</h2> <p>Cosmos DBアカウント、データベース、コンテナの作成はAzure CLIまたはPowerShellを用いて実行可能である。パーティションキーはコンテナ作成時に不可逆的に設定されるため、慎重な検討が必要である。</p> <h3 class="wp-block-heading">Azure CLIを用いたCosmos DBリソース作成とスループット設定</h3> <div class="codehilite"> <pre data-enlighter-language="generic"># 1. リソースグループの作成 az group create --name MyCosmosDBResourceGroup --location japaneast # 2. Cosmos DBアカウントの作成 (Core (SQL) API) az cosmosdb create \ --name mycosmosdbaccount123 \ --resource-group MyCosmosDBResourceGroup \ --kind GlobalDocumentDB \ --default-consistency-level Session \ --locations RegionName="Japan East" FailoverPriority=0 \ --enable-free-tier true # 開発/テスト環境向け、本番では非推奨 # 3. データベースの作成 az cosmosdb sql database create \ --account-name mycosmosdbaccount123 \ --name MyDatabase \ --resource-group MyCosmosDBResourceGroup # 4. コンテナの作成 (パーティションキーは /categoryId、オートスケールRU設定) az cosmosdb sql container create \ --account-name mycosmosdbaccount123 \ --database-name MyDatabase \ --name MyContainer \ --partition-key-path /categoryId \ --resource-group MyCosmosDBResourceGroup \ --max-throughput 4000 # オートスケール最小400 RU/s、最大4000 RU/s # または固定RU/sの場合: # --throughput 400 </pre> </div> <h2 class="wp-block-heading">運用監視</h2> <p>Cosmos DBの運用では、可観測性と継続的な最適化が重要となる。</p> <ul class="wp-block-list"> <li><strong>可観測性</strong>: Azure MonitorはCosmos DBの主要な監視ツールである。 <ul> <li><strong>メトリック</strong>: 総RU消費量、正規化されたRU消費量、パーティションのRU消費量、遅延、スループットエラーなどを監視する。特に「正規化されたRU消費量」は、プロビジョニングされたRU/秒に対する実際の消費量の割合を示し、スロットリングの発生可能性を判断するのに役立つ。</li> <li><strong>ログ</strong>: 診断ログをAzure Log Analyticsワークスペースに送信し、操作ログ、リクエストログ、整合性ログを収集・分析する。これにより、不正アクセス、パフォーマンス問題、データ整合性に関する詳細な洞察を得る。</li> </ul></li> <li><strong>SLA</strong>: Cosmos DBは、スループット、レイテンシー、可用性、整合性に関して99.999%（マルチリージョンアカウント）のSLAを提供する。これを維持するため、RU/sの適切なプロビジョニングと、リージョン間のレプリケーション戦略が重要となる。</li> <li><strong>バックアップとDR</strong>: <ul> <li><strong>継続的バックアップ</strong>: 最大30日間のポイントインタイムリストアが可能で、予期せぬデータ削除や破損からの回復を支援する。</li> <li><strong>定期的バックアップ</strong>: 自動的に最大2回のバックアップが、追加費用なしで90日間保持される。</li> <li><strong>DR (Disaster Recovery)</strong>: マルチリージョン書き込み構成を利用することで、リージョン障害時にもアプリケーションの継続的な可用性を確保できる。フェイルオーバーは自動的に行われる。</li> </ul></li> </ul> <h2 class="wp-block-heading">セキュリティ</h2> <p>Cosmos DBのセキュリティは、Azure Entra IDとの統合を中心に構築される。</p> <ul class="wp-block-list"> <li><strong>アイデンティティと権限境界</strong>: <ul> <li><strong>Azure Entra ID (旧 Azure AD)</strong>: Cosmos DBの管理プレーンおよびデータプレーンのアクセス制御に利用される。</li> <li><strong>ロールベースアクセス制御 (RBAC)</strong>: <ul> <li>管理プレーン: Azure組み込みロール（例: Cosmos DB Contributor）をEntra IDユーザー/グループ/サービスプリンシパルに割り当て、アカウント、データベース、コンテナの管理操作を制御する。</li> <li>データプレーン: 特定のデータ操作（例: ドキュメントの読み取り/書き込み）には、Cosmos DBのデータプレーンRBACロール（例: Cosmos DB Built-in Data Reader, Cosmos DB Built-in Data Contributor）を使用し、きめ細かなアクセス制御を実現する。これにより、最小権限の原則が適用される。</li> </ul></li> </ul></li> <li><strong>条件付きアクセス (CA)</strong>: Entra IDの条件付きアクセスは、Cosmos DB管理プレーンへのアクセスを保護するために適用可能である。例えば、特定のネットワークロケーションからのアクセスのみを許可したり、多要素認証 (MFA) を必須にしたりするポリシーを設定できる。</li> <li><strong>ネットワークセキュリティ</strong>: Azure Private LinkやVNet統合により、Cosmos DBへのトラフィックをパブリックインターネットから分離し、プライベートな接続パスを確保する。</li> <li><strong>Defender for Cloud</strong>: Azure Defender for Cosmos DBを有効化することで、異常なデータベースアクセスパターン、SQLインジェクション、資格情報の不正使用など、潜在的な脅威に対するリアルタイムアラートと推奨事項を受け取れる。</li> </ul> <h2 class="wp-block-heading">コスト</h2> <p>Cosmos DBのコストは主に以下の要素で構成される。</p> <ol class="wp-block-list"> <li><strong>スループット (RU/秒)</strong>: プロビジョニングされたRU/sまたはオートスケール設定に基づく。</li> <li><strong>ストレージ</strong>: データおよびインデックスに消費されるストレージ容量。</li> <li><strong>データ転送</strong>: リージョン間データ転送、CDNなど。</li> </ol> <h3 class="wp-block-heading">コスト最適化戦略</h3> <ul class="wp-block-list"> <li><strong>RU/sの最適化</strong>: <ul> <li><strong>オートスケールスループット</strong>: ワークロードの変動が大きい場合に有効。最小RU/sを設定し、最大RU/sまで自動的にスケールアップ/ダウンする。これにより、ピーク時のパフォーマンスを確保しつつ、アイドル時の過剰なプロビジョニングを回避する。</li> <li><strong>プロビジョニングスループット</strong>: 予測可能な安定したワークロードに適している。適切なベースラインRU/sを設定し、必要に応じて手動で調整する。</li> <li><strong>RU消費量の監視</strong>: Azure Monitorで正規化されたRU消費量を監視し、スロットリングが発生していないか、あるいは過剰なRUをプロビジョニングしていないかを確認する。</li> </ul></li> <li><strong>リザーブドキャパシティ (Reserved Capacity)</strong>: 1年または3年の契約で、RU/秒の割引を受けることができる。予測可能な長期的なワークロードを持つ場合に大きなコスト削減効果がある。</li> <li><strong>パーティションキーの最適化</strong>: ホットパーティションを回避し、RUを均等に分散させることで、最小限のRU/sで最大のパフォーマンスを引き出す。</li> <li><strong>インデックス戦略の最適化</strong>: 不要なインデックスを削除し、必要なインデックスのみを定義することで、ストレージコストと書き込み操作時のRU消費を削減する。</li> <li><strong>TimeToLive (TTL)</strong>: 古いデータや不要なデータを自動的に削除することで、ストレージコストを削減する。</li> </ul> <h2 class="wp-block-heading">落とし穴</h2> <ul class="wp-block-list"> <li><strong>不適切なパーティションキー</strong>: データが均等に分散されず、特定のパーティションにアクセスが集中する「ホットパーティション」が発生し、パフォーマンスボトルネックやスロットリングを引き起こす。</li> <li><strong>過剰なインデックス</strong>: 全てのフィールドにインデックスを設定すると、ストレージ使用量が増加し、書き込み操作のRU消費も増大する。必要なクエリをサポートする最小限のインデックスに留めるべきである。</li> <li><strong>RUの不足または過剰プロビジョニング</strong>: 不足するとアプリケーションでスロットリングエラーが発生し、パフォーマンスが低下する。過剰プロビジョニングは不要なコスト増大を招く。</li> <li><strong>グローバル分散時の整合性レベルの選択</strong>: 強力な整合性レベルは読み取り時に高コストとなる可能性があり、最終的な整合性レベルは読み取りパフォーマンスを向上させるが、書き込みレプリケーションの遅延を許容する必要がある。アプリケーションの要件に応じて適切に選択すべきである。</li> </ul> <h2 class="wp-block-heading">まとめ</h2> <p>Azure Cosmos DBのデータモデルとRUは、サービスの性能、スケーラビリティ、およびコスト効率を決定する重要な要素である。最適なパーティションキーの選択、効率的なデータモデル設計、そしてRU消費量の継続的な監視と調整が不可欠となる。また、Entra IDベースのRBACやDefender for Cloudといったセキュリティ機能を活用し、データ保護を強化する必要がある。これらのベストプラクティスを適用することで、堅牢で高性能かつコスト効率の高いアプリケーション基盤を構築できる。</p>

graph LR
    A["クライアントアプリケーション"] -->|CRUD操作| B("Azure Cosmos DB Gateway")
    B --> C{"論理パーティションキーの評価"}
    C --> D1["物理パーティション P1"]
    C --> D2["物理パーティション P2"]
    C --> D3["物理パーティション P3"]
    D1 --> E["データアイテム A(\"パーティションキー=X\")"]
    D2 --> F["データアイテム B(\"パーティションキー=Y\")"]
    D3 --> G["データアイテム C(\"パーティションキー=Z\")"]
    E --> H{"データモデルとインデックス"}
    F --> H
    G --> H
    H --> I["RU消費"]
    I --> J["RU/秒のプロビジョニング"]
    subgraph データモデルとRUの関係
        C --- I
        D1 --- E
        E --- I
    end
    style A fill:#f9f,stroke:#333,stroke-width:2px
    style B fill:#bbf,stroke:#333,stroke-width:2px
    style C fill:#ccf,stroke:#333,stroke-width:2px
    style D1 fill:#fcf,stroke:#333,stroke-width:2px
    style D2 fill:#fcf,stroke:#333,stroke-width:2px
    style D3 fill:#fcf,stroke:#333,stroke-width:2px
    style E fill:#efe,stroke:#333,stroke-width:2px
    style F fill:#efe,stroke:#333,stroke-width:2px
    style G fill:#efe,stroke:#333,stroke-width:2px
    style H fill:#eef,stroke:#333,stroke-width:2px
    style I fill:#fef,stroke:#333,stroke-width:2px
    style J fill:#fdf,stroke:#333,stroke-width:2px

# 1. リソースグループの作成
az group create --name MyCosmosDBResourceGroup --location japaneast

# 2. Cosmos DBアカウントの作成 (Core (SQL) API)
az cosmosdb create \
  --name mycosmosdbaccount123 \
  --resource-group MyCosmosDBResourceGroup \
  --kind GlobalDocumentDB \
  --default-consistency-level Session \
  --locations RegionName="Japan East" FailoverPriority=0 \
  --enable-free-tier true # 開発/テスト環境向け、本番では非推奨

# 3. データベースの作成
az cosmosdb sql database create \
  --account-name mycosmosdbaccount123 \
  --name MyDatabase \
  --resource-group MyCosmosDBResourceGroup

# 4. コンテナの作成 (パーティションキーは /categoryId、オートスケールRU設定)
az cosmosdb sql container create \
  --account-name mycosmosdbaccount123 \
  --database-name MyDatabase \
  --name MyContainer \
  --partition-key-path /categoryId \
  --resource-group MyCosmosDBResourceGroup \
  --max-throughput 4000 # オートスケール最小400 RU/s、最大4000 RU/s
# または固定RU/sの場合:
# --throughput 400