Azure Database for PostgreSQL

解決する課題

• PostgreSQL サーバーの OS パッチ・マイナーバージョン更新・バックアップが重い → 自動化したい
• DB が単一ノードだと障害で止まる → 組み込みの高可用性で可用性を上げたい
• 互換性を崩さずに使いたい → 改変のない純正 PostgreSQL をそのまま運用したい
• 開発・検証では夜間や休日に止めて節約したい → 停止/起動や従量に近い課金で費用を抑えたい

AWS でいう Amazon RDS for PostgreSQL に相当し、エンジン本体には手を入れず周辺の運用作業をマネージドサービスが肩代わりします。

主要概念と用語

• デプロイ オプション: 現行の推奨は Flexible Server。ゾーン配置・停止/起動・メンテナンス時間帯の制御など柔軟性が高い。旧来の Single Server は新規利用が縮小しているため、新規構築は Flexible Server を選ぶ
• サーバー: 接続エンドポイントと計算・ストレージ・設定の管理単位。1 つのサーバー上に複数のデータベースを作成できる
• 計算層（コンピューティング階層）: 用途に応じて選ぶ。小規模・バースト的負荷向けの Burstable、安定稼働向けの General Purpose、高メモリ要件向けの Memory Optimized
• ストレージ: 計算とは独立に容量を指定。多くの場合容量に応じて IOPS が決まるため、必要な性能から容量を見積もる
• 高可用性（HA）: スタンバイレプリカへの自動フェイルオーバー。ゾーン冗長 HA（別の可用性ゾーンに配置）と同一ゾーン HAを選べる
• 読み取りレプリカ: 読み取り負荷を分散する非同期レプリカ。参照系のスケールアウトに使う
• 拡張機能（Extension）: PostGIS や pg_stat_statements などの拡張に対応。利用するには許可リストへの追加が必要な場合がある
• 接続モード: アプリから直接続ぐほか、組み込みの接続プーリング（PgBouncer 相当） を有効化して大量接続を集約できる

仕様・制限・クォータ

• 自動バックアップ: 定期的なバックアップを自動取得し、ポイントインタイムリストア（PITR） に対応。保持期間は一定範囲で設定でき、別リージョンへの geo 冗長バックアップも選択可能
• 対応バージョン: 複数のメジャーバージョンに対応し、マイナー更新はメンテナンスで自動適用。メジャーアップグレードは計画的に実施する
• 接続数: 計算層・サイズに応じて最大接続数が決まる。多数接続が必要なら接続プーリングで集約する
• 拡張機能: 利用可能な拡張はサービス側で管理され、サーバーパラメーターの許可リストで有効化する方式のものがある
• 暗号化: 保存時暗号化は既定で有効。鍵は Microsoft 管理鍵、または Key Vault による顧客管理鍵（CMK）を選択できる
• リージョン／サブスクリプションごとにサーバー数や vCore 数のクォータがあり、引き上げ申請が可能

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

内部の仕組み

• 計算とストレージの分離: 計算ノードと永続ストレージを分離した構成。ノード障害時はストレージを保ったまま付け替える形で復旧する
• 高可用性のフェイルオーバー: HA を有効化するとスタンバイレプリカが待機し、プライマリ障害時に自動でフェイルオーバーする。アプリ側は接続の再試行（リトライ）ロジックを前提に実装する
• 読み取りレプリカ: プライマリから非同期レプリケーションでレプリカへ反映する。レプリカには遅延があり得るため、強い整合性が必要な参照はプライマリへ向ける
• メンテナンス: マイナーパッチ等は指定したメンテナンス時間帯に適用され、短時間の再起動を伴うことがある

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

• 本番は ゾーン冗長 HA を有効化し、可用性ゾーン間で冗長化する
• 参照負荷が高い構成は 読み取りレプリカで参照系をスケールアウトする
• アプリと DB の間に接続プーリングを挟み、コネクション枯渇とオーバーヘッドを避ける
• 接続は プライベート アクセス（VNet 統合） または プライベート エンドポイントでプライベート化し、パブリックアクセスは絞る
• 認証は Microsoft Entra ID 認証を優先し、パスワード管理の手間とリスクを減らす
• 開発・検証環境は夜間や休日に停止してコストを抑える

運用・監視

• Azure Monitor / メトリクスで CPU・メモリ・ストレージ・IOPS・接続数・レプリケーション遅延を監視する
• 重いクエリは pg_stat_statements や クエリ ストア相当の分析機能で特定し、インデックスやクエリを見直す
• 接続不可時はファイアウォール規則・VNet 統合/プライベートエンドポイント・最大接続数を確認する
• メジャーアップグレードや HA 化など影響の大きい操作は、メンテナンス時間帯やメンテナンスウィンドウを意識して計画する
• ストレージは使用率を監視し、自動拡張を有効化して枯渇を防ぐ

コスト

• 料金は主に 計算（vCore × 時間） ＋ ストレージ容量 ＋ バックアップストレージ ＋ 読み取りレプリカや HA の追加分で構成される
• Burstable 層は CPU クレジットで低コストに使えるが、継続的な高負荷には不向き
• 開発・検証は停止/起動で稼働時間を減らすと費用を大きく抑えられる
• 定常稼働の本番は 予約インスタンス（1〜3 年） の前払いコミットで割引を受けられる

セキュリティ

• 保存時暗号化は既定で有効。鍵は Key Vault による顧客管理鍵（CMK）も選択できる
• 転送時は TLS/SSL を強制し、最小 TLS バージョンを指定する
• Microsoft Entra ID 認証でアクセスを制御し、ネイティブの PostgreSQL ロールと組み合わせて最小権限を徹底する
• プライベート アクセス（VNet 統合）／プライベート エンドポイントでパブリック露出を排除し、ファイアウォール規則は最小化する
• Microsoft Defender for Cloud による脅威検知や脆弱性評価でセキュリティ状態を継続的に点検する

Well-Architected の観点

• 信頼性（Reliability）: ゾーン冗長 HA でゾーン障害に耐え、PITR と geo 冗長バックアップで復旧手段を確保する。アプリにリトライを実装し、フェイルオーバー時の瞬断に備える
• オペレーショナルエクセレンス（Operational Excellence）: パッチ・バックアップ・メンテナンスをサービスに任せ、メンテナンス時間帯を業務影響の小さい時間に設定する。IaC（Bicep/Terraform）でサーバー構成を再現可能にし、メトリクスとアラートで運用を自動化する

試験で問われるポイント

関連サービス・比較

ハンズオン / CLI例

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

# Flexible Server を作成（ゾーン冗長 HA、Burstable 計算層、プライベートアクセスは別途構成）
az postgres flexible-server create \
  --resource-group demo-rg \
  --name demo-pg-0614 \
  --location japaneast \
  --admin-user pgadmin \
  --admin-password 'StrongP@ssw0rd!' \
  --tier Burstable \
  --sku-name Standard_B1ms \
  --storage-size 32 \
  --version 16 \
  --high-availability ZoneRedundant \
  --public-access None

# データベースを作成
az postgres flexible-server db create \
  --resource-group demo-rg \
  --server-name demo-pg-0614 \
  --database-name appdb

# 読み取りレプリカを作成（参照系スケールアウト）
az postgres flexible-server replica create \
  --resource-group demo-rg \
  --replica-name demo-pg-0614-replica \
  --source-server demo-pg-0614

# 開発環境はサーバーを停止してコスト削減
az postgres flexible-server stop \
  --resource-group demo-rg \
  --name demo-pg-0614