AWS・Google Cloud・AzureのDB比較：PostgreSQLの互換性・HA・読み取り拡張で選ぶ
RDS for PostgreSQL・Cloud SQL for PostgreSQL・Azure Database for PostgreSQLを、互換性、待機系と読み取りレプリカ、リージョン障害、接続数、総費用で比較。AuroraやSpannerへ選択を広げる条件も整理します。
RDS・Cloud SQL・Azure Database for PostgreSQLを同じ条件で比べる
既存PostgreSQLの受注DBをクラウドへ移すケースです。注文・在庫の更新をトランザクションで守り、単一リージョンを主な書き込み先とします。まずRDS for PostgreSQL、Cloud SQL for PostgreSQL、Azure Database for PostgreSQL flexible serverの対応する版・拡張・運用方式を調べます。
| 候補 | 最初に固定する構成 | 比較の要点 |
|---|---|---|
| AWS：RDS for PostgreSQL | DB instanceかDB clusterか、Single-AZかMulti-AZか | 同じMulti-AZという名前でも待機系と読み取りの構造が異なる |
| Google Cloud：Cloud SQL for PostgreSQL | エディション、ゾーン構成かリージョンHAか | HAの待機系、読み取りレプリカ、DRの役割を分ける |
| Azure：Database for PostgreSQL flexible server | 計算階層、HAなし・同一ゾーン・ゾーン冗長 | 同一ゾーンHAとゾーン障害への耐性を混同しない |
互換性は、SQL・拡張・接続・保守を実物で確かめる
「PostgreSQLが使える」だけでは、現在のアプリがそのまま動くとは限りません。利用中の拡張、管理者権限に依存する処理、照合順序、接続方式、メジャーバージョン、バックアップと復元の方法を一覧にします。代表SQLだけでなく、注文の同時更新とロック待ちも再現します。
- 必須の拡張と版を確認する。使えないものは代替実装とアプリ改修量まで見積もる。
- 本番相当の件数と偏りで、読み取り・更新・インデックス保守を測る。空のDBで接続できただけでは移行完了としない。
- 更新や保守による停止、接続の再確立、証明書と認証情報の更新を運用手順へ含める。
HAの待機系と、読み取りを増やすレプリカを区別する
| 構成 | 主な目的 | 読み取りとの関係 |
|---|---|---|
| RDS Multi-AZ DB instance | 別AZへの同期複製とフェイルオーバー | 待機系は読み取りに使えない。読み取りレプリカ等を別に検討 |
| RDS Multi-AZ DB cluster | 3つのAZにwriterと2つのreaderを配置 | readerは読み取りと切り替え先を兼ねる。Auroraとは別の構成 |
| Cloud SQLのリージョンHA | 同じリージョンの異なるゾーンで継続性を高める | HAの構成と読み取りレプリカの構成を分けて計画 |
| Azure PostgreSQLのゾーン冗長HA | 異なるゾーンの待機系へ切り替える | HAの待機系は読み取りに使えない |
読み取り用の非同期レプリカには遅れがあります。注文作成直後の確認を遅れたレプリカへ送ると、「注文がない」と見えることがあります。その画面は書き込み先で読むか、書き込み位置まで追いついたことを確かめてから読みます。レプリカを増やすだけで、この問題やwriterの更新競合は解消しません。
可用性・リージョンDR・誤削除への備えは別に決める
AZやゾーンの障害へ備えるHAと、リージョン全体を失った際の災害復旧（DR）は別の設計です。許容する復旧時間RTOと、失ってよいデータの時間幅RPOを先に決めます。非同期のリージョン間複製を使うなら、未反映の更新が残り得ます。平常時の遅れを、そのまま障害時のRPOの保証にはできません。
仮にRTOが30分で、検知4分、復旧判断3分、昇格8分、接続切り替え5分、業務確認4分とします。合計は24分で余裕は6分です。これは手順を分解する仮定で、製品の復旧速度ではありません。昇格だけ8分でも、全体の復旧が8分になるわけではありません。
- 検知: 4分
- 復旧判断: 3分
- 昇格: 8分
- 接続切り替え: 5分
- 業務確認: 4分
誤ったDELETEやアプリの不正な更新は、正常にレプリカへ伝わります。バックアップと時点復元を別に持ち、復元先の認証・接続変更、誤削除後に入った正しい更新の扱いまで試します。DRでは旧リージョンのwriterが戻っても競合して書き込まないようにし、新しい書き込み開始後に戻す条件も決めます。
接続と書き込みの限界を測ってから、別のDBへ広げる
アプリ30台、各台2プロセス、プール上限15なら、設定上は30 × 2 × 15 = 900接続です。読み取りレプリカを増やしても、writerへ向かうプールは残ります。DBへ割り当てる接続枠と、実際に許容できる同時実行クエリ数を別に測り、デプロイ時の増加も含めます。
RDS Proxyなどの接続集約も候補ですが、利用条件、セッションへの依存、待ち時間を確認します。接続できる数を増やしても、CPU、I/O、単一行への更新競合は残り得ます。まず実行計画と負荷の内訳を調べ、どこが上限なのかを明らかにします。
| 新しく分かった要件 | 比較を広げる方向 | 残る検証 |
|---|---|---|
| 既存のPostgreSQL互換性を保ちつつ別の構成を評価したい | Aurora PostgreSQL等も候補に加える | 対象の版・拡張・SQL、復旧、費用を再確認 |
| 測定上、1つのwriterでは必要な規模を満たさない | 分散SQL、シャーディング、データモデル変更を比較 | キーの偏り、トランザクション範囲、更新競合 |
| Spannerを候補にしたい | 分散トランザクションと配置要件に照らして試作 | PostgreSQLインターフェースはPostgreSQL本体ではなく、SQL・拡張・ドライバの対応を検証 |
総費用と復旧試験まで含めて採用する
費用にはwriterだけでなく、HA、reader、DR先、保存容量、I/O、バックアップ、通信、接続プロキシ、保守を含めます。同じvCPU数でも同じ性能とは限らないため、代表負荷で目標を満たした構成同士を比べます。互換性が低い候補では、移行と退出に必要な改修費も加えます。
- 必須のSQL・拡張・トランザクションを確認し、代表データでwriterとreaderを別々に測る。
- 書き込み直後の読み取り、接続急増、タイムアウト後の結果確認を試す。結果不明の注文を無条件に新規注文として再実行しない。
- HA切り替え、リージョンDR、誤削除からの復元を別々に訓練し、アプリの業務再開までの時間と失われた更新を測る。
- 採用理由を、互換性・通常負荷・障害時の目標・総費用の証拠で残す。複数writerや別リージョンの要件が変われば再評価する。
構成ごとの保証を確認する一次資料
- AWS — RDS Multi-AZ DB instance deployments
- AWS — RDS Multi-AZ DB cluster deployments
- Google Cloud — Cloud SQL for PostgreSQL HA
- Microsoft Learn — PostgreSQL flexible server HA
- Google Cloud — PostgreSQL interface for Spanner
- AWS — RDS Proxy
- Google Cloud — Cloud SQL for PostgreSQL disaster recovery
- Microsoft Learn — PostgreSQL backup and restore