PostgreSQL と CockroachDB：マルチリージョン可用性の比較

本当に解決したい問題は何ですか？

「マルチリージョン可用性」はいくつかの異なる目的で使われます。目的を混ぜると、間違ったデータベースを選んでしまう原因になります。

PostgreSQL と CockroachDB を比較する前に、(1) 生き残りたい具体的な障害と、(2) その障害が発生している間にユーザーがどう感じるべきかを書き出してください。

多くのチームが追いかけているのは次のような混合です：

• あるリージョンが落ちたときの稼働率を上げたい（フェイルオーバー）
• 主要リージョンから遠いユーザーの応答を速くしたい（レイテンシ低減）
• 地域ごとのデータルール（ローカリティや居住要件）
• ハッピーパスだけでなく負荷下での予測可能な振る舞い

共通の目標は単純です：別大陸の顧客でも速く正しい結果を受け取れること。

難しいのは、書き込みを地域にまたがって広げると「速さ」と「正しさ」が衝突する可能性があることです。強い整合性は通常、より多くのリージョン間調整を要求し、それがレイテンシを増やします。レイテンシを下げるには近くのコピーから読んだり非同期複製を使ったりしますが、その分古い読み取りや競合解決はアプリ側で扱う必要が出ます。

具体例：ドイツのユーザーが配送先住所を更新してすぐチェックアウトしたとします。チェックアウトが数秒遅れた米国のレプリカから読んでしまうと古い住所で注文される可能性があります。いくつかのプロダクトは UX とリトライでこれを許容できますが、決済や在庫、コンプライアンスを扱う場合は許されません。

万人向けの最適解はありません。何を絶対に間違えられないか、どこを少し遅くできるか、そして毎日の運用複雑さをどれだけ受け入れられるかで答えは変わります。

「複数リージョンで利用可能」に対する2つのアプローチ

PostgreSQL と CockroachDB を比較するとき、多くの場合はそもそも異なる設計を比べています。

PostgreSQL の最も一般的な構成はシングルプライマリです。書き込みは「ホーム」である一つのリージョンで行い、他リージョンはプライマリから変更をコピーする読み取りレプリカを走らせます。プライマリが落ちたらレプリカを昇格させてアプリを切り替えます。適切に運用すればこれで十分にうまく動きますが、システムは依然として一つの主要な書き込み場所と意図的なフェイルオーバープランの周りに組織されています。

CockroachDB のような分散 SQL システムは、データと責任を最初からリージョンにまたがって分散するよう設計されています。データは複数ノードにコピーされ、クラスタが書き込みの順序に合意します。特定のデータを地域ごとに近くに配置しつつ、ひとつの論理データベースとして動かすことができます。

アプリチームにとって変わるのは SQL 構文より期待値です：

• 書き込み：PostgreSQL の書き込みはプライマリの近くで最速です。CockroachDB の書き込みは複数のレプリカの合意を必要とすることがあり、リージョン間の確認を含むことがあります。
• 読み取り：PostgreSQL はレプリカからローカルに読み取れます（古さのトレードオフあり）。CockroachDB は一貫性のある読み取りを提供できますが、データ配置によっては調整コストが発生します。
• 障害時：PostgreSQL のフェイルオーバーは切り替えで管理します。CockroachDB はレプリケーションとクォーラムのルール内でいくつかの地域障害を乗り切るよう作られています。

隠れた要件は障害時の正しさです。短時間の古い読み取りやフェイルオーバー中の短い書き込み停止を許容できるなら、シングルプライマリの PostgreSQL は強力な選択になり得ます。リージョンが落ちている間もシステムを正しく書き込み可能に保ちたいなら、分散データベースの調整コストを受け入れることになります。

整合性保証：何を信頼できるか

整合性を平易に言えば、誰かがレコードを更新したら他の全員が同じ事実を見るべき、ということです。

PostgreSQL では、アプリが一つのプライマリに接続する場合に強い整合性が最も単純です。読み書きは一か所で行われるため、トランザクションは予測可能に振る舞います。他地域の読み取りを速くするためにレプリカを追加できますが、その場合どの程度の古さを許容するかを判断する必要があります。

CockroachDB や他の分散 SQL システムでも強い整合性は可能ですが、離れたリージョンにデータを広げるほどコストは高くなります。リージョン間で一貫性のある書き込みを行うにはノード間の調整が必要です。リージョンが遠いほど、その調整にかかる時間は長くなり、特に異なるリージョンに属する行にまたがるトランザクションでは書き込みやトランザクションの遅延を体感することが多いです。

どちらのシステムもシリアライズ可能トランザクションをサポートできます（同時変更を一つずつ起きたかのように扱う）。違いはどこでその作業が行われるかです：PostgreSQL は主に一つのリージョン内でコストを負い、分散システムはリージョン間にコストを広げることが多いです。

トレードオフを具体化する質問はいくつかあります：

• ユーザーが数秒でも古い読み取りを見ることは許容できますか？
• 二つのリージョンが独立して書き込みを受け付ける必要がありますか、それともすべての書き込みがグローバルに合意されるべきですか？
• 二人が同じレコードを同時に編集したらどうなりますか？競合を許しますか？
• どの操作が常に正しくあるべきか（決済、権限）と、どれが「最終的に整合すればよい」か（分析など）を区別できますか？
• グローバルな一つの真実が必要ですか、それとも一部のデータは「ローカルな真実」でよいですか？

レイテンシ期待値：ユーザーが感じるもの

役に立つメンタルモデルはこうです：距離は時間を足し、調整はさらに時間を足す。距離は物理的な要素で、調整は他のノードが合意するのを待つということです。

単一リージョンの PostgreSQL では、ほとんどの処理が近くで行われます。読み書きは通常アプリからデータベースへの往復一回で完了します。他地域に読み取りレプリカを置けば読み取りはローカルで速くなりますが、書き込みは依然プライマリへ行き、レプリカは少なくともある程度遅れます。

CockroachDB のような分散システムでは、必要なデータが近くにあれば一部の読み取りは速く感じることがあります。しかし多くの書き込みは過半数のレプリカからの確認を必要とします。データが大陸間に複製されていると、単純な書き込みでもクロスリージョンの確認が必要になり得ます。

平均レイテンシだけで判断しないでください。p95 レイテンシ（最遅の5%）を見ることが重要です。ユーザーはその遅延を察知します。普段は 120 ms で読み込むページが日に数回 800 ms になると、平均が良く見えても信頼性が低く感じられます。

「速い」とはワークロードによって異なります。書き込みが多いアプリは調整コストをより強く感じます。読み取り中心のアプリは読み取りがローカルであればうまく機能します。大きなトランザクションや複数ステップのワークフロー、そして多くのユーザーが同じ行を更新する「ホット」な行はレイテンシを増幅します。

PostgreSQL と CockroachDB を評価するときは、トップのユーザーアクション（サインアップ、チェックアウト、検索、管理更新など）をどこにデータがあるか、各トランザクションで何リージョンが合意する必要があるかにマッピングしてください。これによりベンチマークよりも実際にユーザーが感じることを予測できます。

運用上のトレードオフ：日々何を運用するか

機能一覧よりも、夜中に何があなたを起こすか、チームが毎週何をしなければならないかが重要です。

PostgreSQL の運用は馴染みがあり予測可能です。マルチリージョンは通常、レプリカ、フェイルオーバーツール、あるいはアプリ側ルーティングを含む補助的な構成要素の運用が必要になります。作業は日常的なクエリチューニングというより、プランが機能することを実証する（フェイルオーバードリルやリストア演習）ことにあることが多いです。

CockroachDB はマルチリージョンの話をデータベース自体に押し込みます。これにより周辺コンポーネントは減るかもしれませんが、分散システムの理解（ノードヘルス、レプリケーション、リバランス、ストレス時のクラスタ挙動）が必要になります。

実務では、どちらの構成でも核心的な作業は同じように残ります：

• アップグレード計画とドライバ、監視、自動化の検証
• バックアップ取得とリストアテスト（存在確認だけでなく実際にリストアする）
• フェイルオーバーの練習と明確なランブックの作成
• 遅いクエリの調査と「悪いクエリ」と「クロスリージョン遅延」の切り分け
• ストレージ増加と長期的なコンパクション挙動の監視

故障モードの感触は異なります。PostgreSQL ではリージョン障害は意図的なフェイルオーバーを引き起こすことが多く、読み取り専用モードやレイテンシ増大、機能制限を受け入れることがあります。分散データベースではネットワーク分断が厄介で、クォーラムを守るために一部の書き込みを拒否するケースが厳しい場面です。

観測性も変わります。単一プライマリでは「なぜこのクエリが遅いのか？」が主な問いです。分散クラスタでは「このデータはどこに配置されていて、なぜクエリがリージョンを跨いだのか？」という問いが加わります。

コストは明白な形でも、そうでない形でも上がります。二つ目のリージョンを追加するとノード数や監視、インシデントの複雑さ、プロダクトチームに対するレイテンシと障害挙動の説明にかかる時間が増えます。

分散環境でのスキーマ変更とマイグレーション

スキーマ変更とは、データの形を変えるあらゆる更新です：新しいカラムの追加、フィールド名の変更、型の変更（int から string へ）、インデックス追加、新しいテーブルの導入など。

PostgreSQL ではマイグレーションは速いことがありますが、リスクはロック時間と書き込みのブロックです。ある変更はテーブル全体を書き換えたり、予想より長くロックを保持したりして、ピークトラフィック中の通常デプロイをインシデントに変えることがあります。

分散データベースではリスクが変わります。オンラインスキーマ変更がサポートされていても、その変更はノード間の合意とリージョン間の複製を必要とします。"簡単" な変更でもロールアウトと検証に時間がかかり、デプロイ後もラグやホットスポット、各リージョンでのクエリプランの乱れを監視する必要があるかもしれません。

マイグレーションを退屈に保つための習慣：

• まずは追加型の変更を優先する（新しいカラム、新しいテーブル）。次に読み書きを切り替え、最後に古いフィールドを削除する。
• ロールバックが迅速にできるよう、各マイグレーションを小さく保つ。
• 可能なら型変更はその場で行わず、新しいカラムにバックフィルする。
• インデックスは素早い調整ではなく機能ロールアウトとして扱う。
• 実データサイズでマイグレーションを練習する。空のテスト DB での検証だけに頼らない。

例：EU ユーザー向けに preferred_language を追加する場合、まずカラムを追加し、あるリリースで旧フィールドと新フィールドの両方を書き、UI を新フィールドで読むよう更新してから最後に古いフィールドを消す。マルチリージョンではリージョンごとの追いつき具合が異なるため段階的リリースが驚きを減らします。

早期に分散化することの実際のコスト

早い段階で PostgreSQL と CockroachDB のどちらかを選ぶことは単なるデータベースの決定ではありません。それは機能投入の速さ、運用上の驚きの頻度、チームがシステムを安定させるために割く時間を左右します。

主要な要件が単一プライマリ領域で満たせるなら、シンプルにしておくことが多くの場合勝ちます。可動部品が少なく故障原因が明確で、デバッグも速い。採用も容易で、ローカル開発や CI もシンプルです。

多くのチームは中央集権型で始めることで素早い反復、シンプルなロールバック、より予測可能なパフォーマンスを得ています。オンコールも可動部品が少ない方が楽です。

それでも早期に分散化するのが正しい選択となることはあります：地域ごとの厳しい稼働率目標、法的なデータ居住要件、あるいはレイテンシが直接収益に影響するグローバルなユーザーベースなど、要件が現実的かつ非交渉的な場合です。

複雑さの税は小さな形で現れて積み重なります：機能開発が遅くなる（マルチリージョン挙動を考慮する必要があるため）、テストはより多くの障害モードをカバーする必要があり、インシデントの原因分析はタイミングや複製、コンセンサスに起因することが多くなります。基本的なスキーマ変更でさえより慎重さが求められます。

役立つ目安：まず需要を検証し、痛みが数値化できるようになってから分散化する。一般的なトリガーは、ある地域での SLO 未達、レイテンシによる一貫したユーザー離脱、あるいは契約を阻むコンプライアンス要件などです。

AppMaster のようなツールで開発しているなら、最初はシンプルなデプロイでワークフローとデータモデルを洗練し、本番に近いテストでマルチリージョン書き込みが本当に必要かを確かめてから移行するのが楽です。

どちらを選ぶかのステップバイステップ

「マルチリージョン」をいくつかの数値とユーザーフローに落とし込むと判断が明確になります。

ステップバイステップ

1. 平易な言葉で RPO と RTO を書き出す。例：「リージョンが死んだら最大1分分のデータは失ってよく、復旧は15分以内（RTO）」。コミット済みの書き込みの喪失を許容できないなら明確にしておきます。
2. ユーザーがどこにいるかをマップし、書き込みが重要なアクションをマークする。リージョンとトップアクション（サインアップ、チェックアウト、パスワードリセット、コメント投稿、フィード閲覧など）をリストアップ。すべての書き込みが同じ重要度ではありません。
3. 機能ごとに整合性要件を決める。決済、在庫、アカウント残高は厳密さが必要で、フィードや分析、「最終確認日時」は遅延を許容できることが多いです。
4. レイテンシ予算を決め、対象リージョンからテストする。重要な操作について「十分に速い」とは何か（例：キーアクションで200〜400 ms）を定め、ターゲット地域から RTT を測定します。
5. チームがサポートできる運用モデルを選ぶ。オンコールの負担、データベーススキル、複雑さへの耐性について正直に評価します。

簡単な例

ほとんどのユーザーが米国にいて EU は少数という場合、書き込みを一つのプライマリに置き、復旧ターゲットを強化し、EU では非重要画面の読み取り最適化を追加するのが現実的です。もし EU の書き込みが多く同じワークフローで改善が必要なら、そのときに整合性とレイテンシの要件に合うオプションを選びます。"グローバル" という言葉だけに惹かれないことが重要です。

例：同じプロダクトを使う米国と EU の顧客

B2B SaaS を想像してください。アカウントにはニューヨークとベルリンのチームメンバーがいて、同じチケット、請求、使用量上限を見ます。請求は共有されているので支払いイベントはすぐにアクセスに反映されるべきです。

PostgreSQL では一般的に米国にプライマリを置き、EU に読み取りレプリカを置く構成になります。米国ユーザーは読み書きが速いです。EU ユーザーはローカルで読み取れますが、今すぐ正確であるべき情報（現在のプラン、最新の権限、請求ステータス）はプライマリに取りに行く必要があることが多いです。EU がレプリカから読んでいると、ベルリンの管理者が請求を支払ってページを更新しても一時的に「期限切れ」のまま見えてしまうことがあります。

CockroachDB のようなマルチリージョン分散データベースなら、両地域に近い場所にデータを置きつつ論理的に一つのデータベースを保てます。代償は、多くの書き込みや一部の読み取りでリージョン間の調整が必要になり、その追加往復が通常パスの一部になります。特にアカウント設定や請求のような共有レコードでは顕著です。

実践的な段階的計画の例：

• まずは一つのリージョンと単一の PostgreSQL プライマリで始め、ユーザーと書き込みの実態を測る。
• レポーティングや非重要画面のために EU 読み取りレプリカを追加する。
• EU の書き込み重視フローが UX を損ねるなら、UI をレスポンシブにするための EU サービス層やキューを検討する。
• 中核テーブル（アカウント、請求、権限）でマルチリージョンの正確性が必要になったらデータベース選択を再検討する。

AppMaster を使えば、ビジュアルなビジネスプロセスでロジックを保つことで、後からデプロイ地域やデータベース戦略を変更する際の負担を軽くできます。

チームが犯しがちな一般的なミス

最大の誤りは「マルチリージョン＝全員に速い」と自動的に思い込むことです。分散データベースでも物理の壁は越えられません。トランザクションが二か所の確認を必要とするなら、その往復時間は必ず書き込みに現れます。

もう一つの罠は整合性への期待を無自覚に混ぜることです。チームが残高や在庫、権限の正確さを要求しながら、アプリの他部分を「十分近い」でよいと扱うと、画面間で異なる値が見えてしまいます。

注意すべきパターン：

• クロスリージョン確認が必要な書き込みを局所的に速くなると期待する
• 最終的整合性を UI の細部だけの問題だと考え、業務ルールを壊してしまう
• 初めてのインシデントで運用現実を知る（バックアップ、アップグレード、ノードヘルス、リージョン障害）
• ログやデータがリージョンに分散しているため遅いトランザクションのデバッグに時間がかかることを過小評価する
• 最初の決断を永久のものとみなして進化計画を立てない

マイグレーションは特に注意が必要です。プロダクトが最も成長するタイミングで起きることが多く、単一ノードでは簡単なスキーマ変更が多地域で整合性を保つときにはリスクになります。

最初のデータベース選択はステップと考え、運用や設計に進化の道筋を残してください。AppMaster を使えばワークフローとデータモデルを素早くプロトタイプし、実際のレイテンシと障害挙動を検証してから分散化に踏み切れます。