Azure Cosmos DB for PostgreSQL

解決する課題

• 単一サーバーの PostgreSQL では CPU・メモリ・ストレージが頭打ちになる → 複数ノードへ水平分散したい
• データ量やトラフィックが増え続け、1 台では捌けない書き込み・集計をスケールアウトしたい
• マルチテナント SaaS でテナントごとの負荷を複数ノードに分散したい
• リアルタイム分析や時系列で、並列実行により大量データの集計を高速化したい

純正 PostgreSQL のフルマネージドが欲しいだけなら Azure Database for PostgreSQL（Flexible Server）が適します。本サービスは Citus 拡張で「分散 PostgreSQL」を実現し、単一ノードの限界を超えてスケールアウトしたいときに選びます。名称に Cosmos DB を冠しますが中身は PostgreSQL であり、NoSQL の Cosmos DB とは別物です。

主要概念と用語

• コーディネーターノード: アプリの接続先となる司令塔。クエリを受け取り、どのシャードへ送るかを判断して各ワーカーへ分配し、結果を集約する
• ワーカーノード: 実データ（シャード）を保持して処理を実行するノード。台数を増やすほど計算・ストレージをスケールアウトできる
• 分散列（ディストリビューションカラム）: テーブルをどの値でシャードへ振り分けるかを決める列。設計の最重要要素で、テナント ID などを選ぶことが多い
• シャード: 分散テーブルを分割した断片。各ワーカーへ配置され、並列処理の単位になる
• 分散テーブル: 分散列でシャーディングし、複数ワーカーに分かれて置かれるテーブル
• 参照テーブル（リファレンステーブル）: 全ワーカーに複製して持たせる小さなテーブル。マスタやコードなど結合相手に使う
• ローカルテーブル: コーディネーターにのみ置く通常のテーブル。分散しないデータ向け
• コロケーション: 同じ分散列を持つテーブル同士のシャードを同じワーカーに揃える配置。ノードをまたがない結合や外部キーを可能にする
• シングルノード構成: ワーカーを使わずコーディネーターのみで動かす小規模・検証向けの形態。後からノードを追加できる

仕様・制限・クォータ

• ノード構成: コーディネーター 1 台＋ワーカー複数台のクラスター。各ノードの vCore・メモリ・ストレージを個別に指定でき、ワーカー台数も増減できる
• PostgreSQL 互換: ベースは純正 PostgreSQL で、複数のメジャーバージョンに対応。PostGIS などの拡張機能も利用できる
• Citus 拡張: シャーディング・並列クエリ・参照テーブルなどの分散機能は Citus 拡張が提供する
• 高可用性: 各ノードにスタンバイを設ける HA 構成を選択でき、障害時に自動フェイルオーバーする
• バックアップ / 復元: 自動バックアップとポイントインタイムリストア（PITR）に対応
• 暗号化: 保存時暗号化は既定で有効
• リージョン／サブスクリプションごとにノード数や vCore 数のクォータがあり、引き上げ申請が可能

具体的な最大ノード数・対応バージョン・保持日数は変動するため、最新値は公式ドキュメントで確認します。

内部の仕組み

• シャーディング: 分散テーブルの行は分散列の値（ハッシュ）に基づいてシャードへ割り当てられ、各シャードがワーカーへ分散配置される
• クエリの分散実行: コーディネーターは受け取った SQL を解析し、関係するシャードを持つワーカーへ部分クエリを送って並列実行させ、結果を集約して返す。分散列で絞れる問い合わせは少数のワーカーで完結し、絞れない問い合わせは全ワーカーへ展開される
• コロケーション: 同じ分散列・同じシャード数のテーブルは対応するシャードが同一ワーカーに揃うため、ノードをまたがない結合や外部キーが成立する
• 参照テーブル: 全ワーカーに複製されるため、分散テーブルとの結合でデータ移動が起きない
• スケールアウト: ワーカーを追加するとシャードを再配置して負荷を分散できる。コーディネーター／ワーカーのサイズ変更でスケールアップも可能

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

• マルチテナント SaaS はテナント ID を全テーブルの分散列に統一し、コロケーションで結合をノード内に閉じる
• マスタ・コード値など小さく更新の少ないテーブルは参照テーブルにして結合相手に使う
• リアルタイム分析・時系列では、カーディナリティが高く均等に分散する列を分散列に選び、並列集計を効かせる
• 分散しないデータはローカルテーブルとしてコーディネーターに置く
• 小さく始める場合はシングルノード構成で開始し、必要になってからワーカーを追加する
• 接続はプライベートエンドポイントなどでプライベート化し、パブリック露出を絞る

運用・監視

• Azure Monitor / メトリクスで各ノードの CPU・メモリ・ストレージ・接続数を監視する。ワーカー間の偏りがないかを確認する
• 重いクエリは pg_stat_statements や Citus が提供する分散クエリ向けのビューで特定し、分散列・インデックス・クエリを見直す
• 特定ワーカーに負荷が集中する場合は**分散列の偏り（データスキュー）**を疑い、分散列やシャード配置を再検討する
• HA・ノード追加・サイズ変更など影響の大きい操作は、メンテナンス時間帯を意識して計画する
• ストレージ使用率を監視し、枯渇前にスケールアップやワーカー追加で容量を確保する

コスト

• 料金は主に コーディネーターとワーカーの計算（vCore × 時間） ＋ 各ノードのストレージ容量 ＋ HA を有効化した場合のスタンバイ分で構成される
• 小規模・検証ではシングルノード構成で始め、ワーカー分の費用を抑える
• 性能が必要になったら**ワーカー追加（スケールアウト）またはノードのサイズ変更（スケールアップ）**で段階的に増強する
• 長期に動かす本番は**予約容量（1〜3 年）**の前払いコミットで割引を受けられる

セキュリティ

• 保存時暗号化は既定で有効で、転送時は TLS/SSL で保護する
• ネイティブの PostgreSQL ロールと組み合わせて最小権限を徹底する
• プライベートエンドポイント／プライベートアクセスでパブリック露出を排除し、ファイアウォール規則は最小化する
• Microsoft Defender for Cloud による脅威検知や脆弱性評価でセキュリティ状態を継続的に点検する

関連サービス・比較

最も近い兄弟サービスは Azure Database for PostgreSQL（Flexible Server）です。単一ノードで足りるなら Flexible Server、水平スケールアウトが要るなら本サービスという使い分けになります。

ハンズオン / CLI例

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

# クラスターを作成（コーディネーター + ワーカー2台）
az cosmosdb postgres cluster create \
  --resource-group demo-rg \
  --cluster-name demo-citus \
  --location japaneast \
  --administrator-login-password 'StrongP@ssw0rd!' \
  --node-count 2 \
  --coordinator-v-cores 4 \
  --coordinator-storage 131072 \
  --node-v-cores 4 \
  --node-storage 131072 \
  --postgresql-version 16

# 作成したクラスターの情報を確認
az cosmosdb postgres cluster show \
  --resource-group demo-rg \
  --cluster-name demo-citus

# ワーカーを追加してスケールアウト（node-count を増やす）
az cosmosdb postgres cluster update \
  --resource-group demo-rg \
  --cluster-name demo-citus \
  --node-count 4

接続後、SQL 側でテーブルを分散させます。

# psql で接続し、分散テーブルと参照テーブルを定義する例
# create_distributed_table / create_reference_table は Citus が提供する関数
psql "host=c-demo-citus.<...>.postgres.cosmos.azure.com port=5432 dbname=citus user=citus sslmode=require" <<'SQL'
-- テナント単位で分散
SELECT create_distributed_table('orders', 'tenant_id');
-- マスタは全ワーカーに複製
SELECT create_reference_table('product_master');
SQL