<p><!--META { "title": "Azure Cosmos DBのコスト最適化", "primary_category": "クラウド>Azure", "secondary_categories": ["データベース","DevOps"], "tags": ["AzureCosmosDB","CostOptimization","Autoscale","ReservedCapacity","CLI"], "summary": "Azure Cosmos DBのコストを最適化するためのアーキテクチャ、設定、運用、セキュリティ戦略を解説。", "mermaid": true, "verify_level": "L0", "tweet_hint": {"text":"Azure Cosmos DBのコストを最適化する実践的なガイド！自動スケーリング、リザーブドキャパシティ、適切なパーティション設計で無駄をなくし、効率的な運用を実現しましょう。#Azure #CosmosDB #CostOptimization","hashtags":["#Azure","#CosmosDB","#CostOptimization"]}, "link_hints": ["https://learn.microsoft.com/ja-jp/azure/cosmos-db/optimize-cost"] } --> 本記事は<strong>Geminiの出力をプロンプト工学で整理した業務ドラフト（未検証）</strong>です。</p> <h1 class="wp-block-heading">Azure Cosmos DBのコスト最適化</h1> <p>クラウドネイティブアプリケーションにおいて、高い可用性とスケーラビリティを提供するAzure Cosmos DBは強力なデータベースサービスですが、その利用コストは設計や運用方法によって大きく変動します。本記事では、クラウドアーキテクトの視点からAzure Cosmos DBのコストを最適化するための具体的な戦略と手順を解説します。</p> <h2 class="wp-block-heading">アーキテクチャ</h2> <p>Azure Cosmos DBのコスト最適化は、初期設計段階から運用フェーズに至るまで、継続的に考慮すべき重要な要素です。主要なコスト要因は「スループット（RU/s）」と「ストレージ」であり、これらをワークロードに最適化することが肝要です。プロビジョンドスループットとサーバーレスモデルの選択、適切なパーティションキー設計、インデックスポリシーの最適化が、初期アーキテクチャにおけるコスト削減の基盤となります。</p> <p>以下に、Cosmos DBのコスト最適化における意思決定フローを示します。</p> <div class="wp-block-merpress-mermaidjs diagram-source-mermaid"><pre class="mermaid"> flowchart TD A["Cosmos DB コスト最適化"] --> B{"ワークロードタイプは？"} B --|予測可能・高スループット| --> C["プロビジョンドスループットモデル"] B --|突発的・低利用率| --> D["サーバーレスモデル"] C --> E{"DBまたはコンテナーのスループット割り当て？"} E --|データベースレベルで共有| --> F["共有スループットデータベース"] E --|コンテナーレベルで個別| --> G["専用スループットコンテナー"] F --> H{"特定のコンテナーが高負荷？"} H --|はい| --> I["高負荷コンテナーを専用スループットに分離検討"] H --|いいえ| --> J["データベースレベルのRU/sを最適化"] G --> K{"自動スケーリングは有効？"} K --|はい| --> L["最大RU/sと最小RU/s設定の最適化"] K --|いいえ| --> M["手動スループットの適切な設定"] D --> N["利用量に基づく課金"] N --> O["ストレージと利用リクエストの監視"] L --> P["リザーブドキャパシティの検討"] M --> P J --> P I --> P O --> Q["データモデルの最適化|ストレージ削減"] Q --> R["インデックスポリシー調整|RU消費削減"] R --> S["TTL設定による古いデータの自動削除"] P --> T["継続的な監視と調整"] S --> T </pre></div> <h2 class="wp-block-heading">設定手順</h2> <p>コスト最適化のための設定は、Azure CLIまたはPowerShellを用いて実施できます。ここでは、自動スケーリングを有効にしたコンテナーの作成と、Time-to-Live (TTL) の設定例を示します。</p> <h3 class="wp-block-heading">自動スケーリングが有効なコンテナーの作成 (Azure CLI)</h3> <p>自動スケーリングは、ワークロードの変動に応じてRU/sを自動調整し、無駄なプロビジョニングを削減します。</p> <div class="codehilite"> <pre data-enlighter-language="generic"># 事前準備: リソースグループとCosmos DBアカウントの作成 RESOURCE_GROUP_NAME="myCosmosDbResourceGroup" LOCATION="eastus" ACCOUNT_NAME="mycostoptimizedcosmosdb$(date +%s)" # ユニークなアカウント名 az group create --name $RESOURCE_GROUP_NAME --location $LOCATION az cosmosdb create \ --name $ACCOUNT_NAME \ --resource-group $RESOURCE_GROUP_NAME \ --default-consistency-level Session \ --locations regionName=$LOCATION failoverPriority=0 # データベースの作成 DATABASE_NAME="myAutoScaledDatabase" az cosmosdb sql database create \ --account-name $ACCOUNT_NAME \ --resource-group $RESOURCE_GROUP_NAME \ --name $DATABASE_NAME # 自動スケーリング（Autoscale）が有効なコンテナーの作成 # --max-throughput は最大RU/sを指定し、最小は最大RU/sの10%に自動設定される CONTAINER_NAME="myAutoScaledContainer" PARTITION_KEY_PATH="/category" MAX_THROUGHPUT=4000 # 最大4000 RU/s。最小は400 RU/s az cosmosdb sql container create \ --account-name $ACCOUNT_NAME \ --resource-group $RESOURCE_GROUP_NAME \ --database-name $DATABASE_NAME \ --name $CONTAINER_NAME \ --partition-key-path $PARTITION_KEY_PATH \ --max-throughput $MAX_THROUGHPUT \ --idx-policy '{"indexingMode":"consistent","automatic":true,"includedPaths":[{"path":"/*"}],"excludedPaths":[{"path":"/\"_etag\"/?"}]}' echo "自動スケーリングが有効なコンテナー '$CONTAINER_NAME' が作成されました。" </pre> </div> <h3 class="wp-block-heading">Time-to-Live (TTL) の設定 (Azure CLI)</h3> <p>TTLは、一定期間経過したアイテムを自動的に削除し、ストレージコストを削減します。</p> <div class="codehilite"> <pre data-enlighter-language="generic"># 既存のコンテナーのTTLを有効にする例 # TTLを秒単位で指定 (例: 86400秒 = 24時間) CONTAINER_NAME="myAutoScaledContainer" # 上記で作成したコンテナー名を使用 TTL_SECONDS=86400 # 24時間後にアイテムを自動削除 az cosmosdb sql container update \ --account-name $ACCOUNT_NAME \ --resource-group $RESOURCE_GROUP_NAME \ --database-name $DATABASE_NAME \ --name $CONTAINER_NAME \ --default-ttl $TTL_SECONDS echo "コンテナー '$CONTAINER_NAME' のデフォルトTTLが '$TTL_SECONDS' 秒に設定されました。" </pre> </div> <h2 class="wp-block-heading">運用監視</h2> <p>効果的なコスト最適化には、継続的な監視が不可欠です。</p> <ul class="wp-block-list"> <li><p><strong>Azure Monitor</strong>: Cosmos DBのメトリック（プロビジョンドRU/s、正規化RU消費量、ストレージ使用量など）とログを監視します。正規化RU消費量がプロビジョンドRU/sを安定して下回る場合は、RU/sを削減する機会です。</p></li> <li><p><strong>Azure Advisor</strong>: コスト、パフォーマンス、セキュリティに関する推奨事項を提供します。Cosmos DBに関するAdvisorの推奨事項は、RU/sの最適化やリザーブドキャパシティの利用を促すことがあります。</p></li> <li><p><strong>アラート</strong>: 異常なRU消費量やストレージ増加、スロットルされたリクエスト数などに対してアラートを設定し、早期に対応できるようにします。</p></li> <li><p><strong>SLAとバックアップ/DR</strong>: Azure Cosmos DBは99.999%のSLA（マルチリージョンアカウント）を提供します。連続バックアップや定期バックアップポリシーの選択、複数リージョンへのレプリケーションは、可用性とデータ保護を高めますが、コストに直結します。ビジネス要件に基づいて適切なバックアップとDR戦略を選択し、過剰な対策によるコスト増を避けます。</p></li> </ul> <h2 class="wp-block-heading">セキュリティ</h2> <p>セキュリティ対策は、Entra ID (旧 Azure AD) と密接に連携し、最小権限の原則に基づいて設計します。</p> <ul class="wp-block-list"> <li><p><strong>Entra ID 統合とRBAC</strong>: Azure Cosmos DBはAzureロールベースのアクセス制御 (RBAC) をサポートしています。組み込みロール（例: <code>Cosmos DB Account Reader Role</code>）やカスタムロールを使用して、Entra IDユーザーやサービスプリンシパルに、Cosmos DBアカウント、データベース、コンテナーへの適切な権限を割り当てます。</p></li> <li><p><strong>マネージドID</strong>: Azureサービス（例: Azure Functions, Azure Web Apps）からCosmos DBへのアクセスには、マネージドIDを利用し、接続文字列やキーの直接管理を避けます。</p></li> <li><p><strong>条件付きアクセス (CA)</strong>: Entra IDの条件付きアクセスポリシーを適用し、特定の条件（デバイス、場所など）を満たした場合のみCosmos DB管理へのアクセスを許可します。</p></li> <li><p><strong>Azure Defender for Cloud</strong>: Cosmos DBに対する潜在的な脅威（異常なアクセス、データ流出の試みなど）を検出し、アラートを発します。これにより、セキュリティ侵害によるコストやデータ損失のリスクを軽減します。</p></li> <li><p><strong>ネットワークセキュリティ</strong>: VNet統合とプライベートエンドポイントを使用して、Cosmos DBへのアクセスをプライベートネットワークに限定し、インターネットからのアクセスをブロックします。IPファイアウォールも併用し、信頼できるIPアドレス範囲のみからのアクセスを許可します。</p></li> </ul> <h2 class="wp-block-heading">コスト最適化</h2> <p>コスト最適化は、Azure Cosmos DBのライフサイクル全体にわたって継続的に取り組むべきテーマです。</p> <ul class="wp-block-list"> <li><p><strong>ワークロードに適したスループットモデルの選択</strong>:</p> <ul> <li><p><strong>サーバーレス</strong>: 突発的で予測不可能なワークロードや、低頻度・低利用率のアプリケーションに最適です。利用したRUとストレージに対してのみ課金されるため、アイドルコストが発生しません。</p></li> <li><p><strong>プロビジョンドスループット</strong>: 予測可能で安定した高スループットが求められるワークロードに適しています。</p></li> </ul></li> <li><p><strong>自動スケーリングの活用</strong>: プロビジョンドスループットモデルを選択した場合でも、自動スケーリングを有効にすることで、ワークロードのピークに合わせてRU/sが自動的に増減し、アイドル時の過剰なプロビジョニングを避けてコストを削減します。最小RU/s設定はワークロードのベースラインに合わせて適切に調整します。</p></li> <li><p><strong>リザーブドキャパシティの検討</strong>: 長期間にわたって安定したRU/sが必要な場合、1年または3年のリザーブドキャパシティを購入することで、大幅な割引が適用されます。計画的なワークロードに非常に有効です。</p></li> <li><p><strong>Time-to-Live (TTL) の設定</strong>: 古いデータが不要になった際に自動的に削除されるようにTTLを設定することで、ストレージコストを削減します。</p></li> <li><p><strong>インデックスポリシーの最適化</strong>: デフォルトのインデックスポリシーはすべてのプロパティをインデックス化しますが、実際にクエリに使用されるプロパティのみをインデックス化するようにポリシーを調整することで、ストレージと書き込み操作（RU消費）を削減できます。</p></li> <li><p><strong>適切なパーティションキーの設計</strong>: ホットパーティション（特定のパーティションにアクセスが集中し、RU消費が偏る状態）を避けるために、データが均等に分散され、クエリが効率的に実行されるパーティションキーを選択します。ホットパーティションは、RU消費を不必要に増加させる主要な原因の一つです。</p></li> <li><p><strong>データモデルの最適化</strong>: データの冗長性を減らし、埋め込みドキュメントを適切に利用することで、必要なドキュメント数を削減し、ストレージとRU消費を最適化します。</p></li> <li><p><strong>マルチリージョン構成の見直し</strong>: 地域冗長性や低レイテンシのために複数リージョンを有効にするとコストが増加します。ビジネス要件に照らし合わせ、本当に必要なリージョンのみを設定します。</p></li> <li><p><strong>無料枠の活用</strong>: 小規模な開発/テスト環境では、Azure Cosmos DBの無料枠（最初の1000 RU/sと25 GBストレージ）を活用することでコストを大幅に抑制できます。</p></li> </ul> <h2 class="wp-block-heading">落とし穴</h2> <p>コスト最適化を阻害する一般的な「落とし穴」を理解し、回避することが重要です。</p> <ul class="wp-block-list"> <li><p><strong>不適切なパーティションキー</strong>: ホットパーティションを引き起こし、スロットリングエラーやRU消費の不均衡を招き、結果的に全体のRU/sを不必要に高くプロビジョニングせざるを得なくなります。</p></li> <li><p><strong>過剰なRU/sプロビジョニング</strong>: ワークロードの実際の需要を上回るRU/sを手動で設定し続けると、無駄なコストが発生します。</p></li> <li><p><strong>サーバーレスでの予期せぬ高トラフィック</strong>: サーバーレスモデルは低利用率に適していますが、突発的に高トラフィックが発生すると、その分だけコストが急増する可能性があります。ワークロードの特性を正確に理解することが重要です。</p></li> <li><p><strong>デフォルトインデックスポリシーの放置</strong>: すべてのフィールドにインデックスが作成されることで、ストレージ消費と書き込み時のRU消費が増加します。</p></li> <li><p><strong>TTLの未適用</strong>: 履歴データやログデータが永続的に蓄積され、ストレージコストが増大します。</p></li> <li><p><strong>不要な地域レプリケーション</strong>: 高可用性や低レイテンシが必須でないアプリケーションに対して、複数リージョンを有効にすると、コストが倍増します。</p></li> </ul> <h2 class="wp-block-heading">まとめ</h2> <p>Azure Cosmos DBのコスト最適化は、単なる設定変更に留まらず、アーキテクチャ設計、運用監視、セキュリティ考慮事項を含む包括的なアプローチが求められます。ワークロードの特性を正確に理解し、サーバーレスとプロビジョンドスループットの適切な選択、自動スケーリング、リザーブドキャパシティ、TTL、インデックスポリシー、そしてパーティションキーの最適化を組み合わせることで、コストパフォーマンスの高いデータ基盤を実現できます。継続的な監視と定期的な見直しを通じて、常に最適な状態を維持することが、クラウドアーキテクトとしての重要な役割です。</p>

flowchart TD
    A["Cosmos DB コスト最適化"] --> B{"ワークロードタイプは？"}
    B --|予測可能・高スループット| --> C["プロビジョンドスループットモデル"]
    B --|突発的・低利用率| --> D["サーバーレスモデル"]

    C --> E{"DBまたはコンテナーのスループット割り当て？"}
    E --|データベースレベルで共有| --> F["共有スループットデータベース"]
    E --|コンテナーレベルで個別| --> G["専用スループットコンテナー"]

    F --> H{"特定のコンテナーが高負荷？"}
    H --|はい| --> I["高負荷コンテナーを専用スループットに分離検討"]
    H --|いいえ| --> J["データベースレベルのRU/sを最適化"]

    G --> K{"自動スケーリングは有効？"}
    K --|はい| --> L["最大RU/sと最小RU/s設定の最適化"]
    K --|いいえ| --> M["手動スループットの適切な設定"]

    D --> N["利用量に基づく課金"]
    N --> O["ストレージと利用リクエストの監視"]

    L --> P["リザーブドキャパシティの検討"]
    M --> P
    J --> P
    I --> P

    O --> Q["データモデルの最適化|ストレージ削減"]
    Q --> R["インデックスポリシー調整|RU消費削減"]
    R --> S["TTL設定による古いデータの自動削除"]

    P --> T["継続的な監視と調整"]
    S --> T

# 事前準備: リソースグループとCosmos DBアカウントの作成

RESOURCE_GROUP_NAME="myCosmosDbResourceGroup"
LOCATION="eastus"
ACCOUNT_NAME="mycostoptimizedcosmosdb$(date +%s)" # ユニークなアカウント名

az group create --name $RESOURCE_GROUP_NAME --location $LOCATION

az cosmosdb create \
    --name $ACCOUNT_NAME \
    --resource-group $RESOURCE_GROUP_NAME \
    --default-consistency-level Session \
    --locations regionName=$LOCATION failoverPriority=0

# データベースの作成

DATABASE_NAME="myAutoScaledDatabase"
az cosmosdb sql database create \
    --account-name $ACCOUNT_NAME \
    --resource-group $RESOURCE_GROUP_NAME \
    --name $DATABASE_NAME

# 自動スケーリング（Autoscale）が有効なコンテナーの作成


# --max-throughput は最大RU/sを指定し、最小は最大RU/sの10%に自動設定される

CONTAINER_NAME="myAutoScaledContainer"
PARTITION_KEY_PATH="/category"
MAX_THROUGHPUT=4000 # 最大4000 RU/s。最小は400 RU/s

az cosmosdb sql container create \
    --account-name $ACCOUNT_NAME \
    --resource-group $RESOURCE_GROUP_NAME \
    --database-name $DATABASE_NAME \
    --name $CONTAINER_NAME \
    --partition-key-path $PARTITION_KEY_PATH \
    --max-throughput $MAX_THROUGHPUT \
    --idx-policy '{"indexingMode":"consistent","automatic":true,"includedPaths":[{"path":"/*"}],"excludedPaths":[{"path":"/\"_etag\"/?"}]}'

echo "自動スケーリングが有効なコンテナー '$CONTAINER_NAME' が作成されました。"

# 既存のコンテナーのTTLを有効にする例


# TTLを秒単位で指定 (例: 86400秒 = 24時間)

CONTAINER_NAME="myAutoScaledContainer" # 上記で作成したコンテナー名を使用
TTL_SECONDS=86400 # 24時間後にアイテムを自動削除

az cosmosdb sql container update \
    --account-name $ACCOUNT_NAME \
    --resource-group $RESOURCE_GROUP_NAME \
    --database-name $DATABASE_NAME \
    --name $CONTAINER_NAME \
    --default-ttl $TTL_SECONDS

echo "コンテナー '$CONTAINER_NAME' のデフォルトTTLが '$TTL_SECONDS' 秒に設定されました。"