Azure Cosmos DB

解決する課題

世界中のユーザーへ、容量計画やシャーディングの手間なしに、安定したミリ秒応答を届けます。

• アクセスが急増しても落ちない/遅くならないDBが欲しい
• DBの容量計画・シャーディングを自分でやりたくない
• ミリ秒の応答を安定して出したい（SLA で保証されたレイテンシ）
• 単一リージョンでは足りず、世界中に低遅延で配信したい

主要概念と用語

• API の選択: 作成時に API を選ぶ。API for NoSQL（ネイティブ・最も機能が豊富）/ MongoDB / Apache Cassandra / Apache Gremlin（グラフ）/ Table（DynamoDB の Table API 相当）
• アカウント → データベース → コンテナー → 項目（Item）: 階層構造。コンテナーが DynamoDB のテーブルに相当
• パーティションキー: データの物理分散を決める最重要キー（DynamoDB の PK に相当）
• RU/s（Request Unit per second）: スループットの統一通貨。読み書きやクエリのコストを RU で表し、毎秒の RU を確保する
• スループットモード: プロビジョンド（手動/自動スケール）/ サーバーレス
• 整合性レベル: 強固 / 有界整合性制約 / セッション（既定）/ 整合性プレフィックス / 結果整合性 の5段階
• 変更フィード（Change Feed）: 変更をイベント順に流す（DynamoDB Streams に相当。Azure Functions と連携）
• TTL / 統合キャッシュ: 項目の自動失効 / 専用ゲートウェイ上のキャッシュ（DAX に近い役割）

仕様・制限・クォータ

• 1項目（ドキュメント）の最大サイズは 2MB（DynamoDB の 400KB より大きい）
• 論理パーティション1つあたりのデータ上限は 20GB、スループット上限は 10,000 RU/s
• 5段階の整合性レベルを選べる（DynamoDB は「結果整合性 / 強い整合性」の2択）
• ターンキーのグローバル分散: ポータルから数クリックでリージョンを追加し、読み取り/書き込みを多リージョン化できる
• **マルチリージョン書き込み（マルチマスター）**に対応し、各リージョンでローカルに書き込める
• 可用性・スループット・レイテンシ（読み書き P99 で一桁ミリ秒）・整合性に 金銭的裏付けのある SLA

内部の仕組み

Cosmos DB はパーティションキーを ハッシュして「論理パーティション」へ振り分け、それを内部の「物理パーティション」に配置します。データ量やスループットが増えると、物理パーティションを自動で分割・再配置してスケールします。ゆえに パーティションキー設計＝性能設計 で、特定キーへ偏るとホットパーティションとなり、RU を使い切ってスロットル（HTTP 429）が発生します。

• データは各リージョン内で4レプリカに保持され、書き込みは局所多数へ複製される
• すべての項目フィールドが既定で自動インデックスされる（スキーマ/インデックス定義が原則不要）。不要なパスを除外して RU を節約できる

設計パターン / ベストプラクティス

• アクセスパターンを列挙し、分散が均等になるパーティションキーを選ぶ（合成キーも有効）
• スパイクが読めない/間欠的なら サーバーレス、定常負荷なら 自動スケール（Autoscale） か手動プロビジョンド
• 変更駆動の処理は 変更フィード → Azure Functions（Cosmos DB トリガー）
• 読み取りが激しく同一クエリが多いなら 専用ゲートウェイ + 統合キャッシュ でRUを削減
• クロスパーティションの全件スキャンを避け、パーティションキーを指定して絞る

運用・監視

• Azure Monitor / Metrics でメトリクスを監視。Total Request Units、Total Requests、ステータス 429（スロットル）の発生率を確認
• スロットル（429）が出たら、ホットパーティション or RU 不足を疑う。自動スケールで上限を引き上げるか、パーティションキーを見直す
• 診断ログ（Diagnostic Settings） を Log Analytics へ送り、DataPlaneRequests で高 RU クエリを特定
• クエリ実行時に返る RU チャージを計測し、コストの高いクエリを最適化する

コスト

スループットモードの使い分けがコスト最適化の肝です。課金は RU/s ＋ ストレージ（保存データ量） で決まります。

セキュリティ

• 保存時暗号化はデフォルト（Microsoft 管理キー。Key Vault のカスタマーマネージドキーも選択可）。通信は常に TLS で暗号化
• マネージド ID + Microsoft Entra ID（RBAC） でデータプレーン/コントロールプレーンの権限を制御し、キーのハードコードを避ける（AWS の IAM ロール相当）
• プライベートエンドポイント（Private Link） で VNet 内から到達させ、パブリックアクセスやファイアウォールで IP を最小化

関連サービス・比較（AWS との対応）

ハンズオン / CLI例

# リソースグループを作成
az group create --name demo-rg --location japaneast

# Cosmos DB アカウントを作成（API for NoSQL）
az cosmosdb create \
  --name demo-cosmos-acct \
  --resource-group demo-rg \
  --locations regionName=japaneast failoverPriority=0 isZoneRedundant=False \
  --default-consistency-level Session

# データベースを作成
az cosmosdb sql database create \
  --account-name demo-cosmos-acct \
  --resource-group demo-rg \
  --name AppDb

# コンテナーを作成（パーティションキー=/userId, 自動スケール上限 4000 RU/s）
az cosmosdb sql container create \
  --account-name demo-cosmos-acct \
  --resource-group demo-rg \
  --database-name AppDb \
  --name Orders \
  --partition-key-path "/userId" \
  --max-throughput 4000

# 別リージョンを追加して多リージョン化（読み取りを近くで）
az cosmosdb update \
  --name demo-cosmos-acct \
  --resource-group demo-rg \
  --locations regionName=japaneast failoverPriority=0 isZoneRedundant=False \
  --locations regionName=koreacentral failoverPriority=1 isZoneRedundant=False