分散 SQL: Spanner、CockroachDB、YugabyteDB はいつ使うべきか

分散 SQL とは

分散 SQL は、データとトランザクション処理を複数のマシンに分散しながら、アプリケーションには1つの論理 SQL データベースとして見せるリレーショナル・データベースの構成です。テーブル、結合、インデックス、制約、ACID トランザクションを維持したうえで、自動パーティショニング、レプリケーション、障害復旧を加えます。

一般に、次の性質を組み合わせるシステムがこの分類に入ります。

• リレーショナルなスキーマと SQL クエリインターフェース
• データベースノードをまたぐ水平スケール
• パーティションをまたぐトランザクション整合性
• 自動レプリケーションとフェイルオーバー
• 1つの論理データベースとして協調して動作すること

この定義が重要なのは、PostgreSQL や MySQL に読み取りレプリカを追加しただけでは分散 SQL にならないからです。プライマリとレプリカの構成では、書き込みは依然として1台の主サーバーを通ります。アプリケーション管理のシャーディングは書き込みを分散しますが、どこにレコードを置くか、シャード間の処理をどう扱うかをアプリケーションが決めなければなりません。分散 SQL は、その責任の多くをデータベースに移します。

従来の RDBMS と NoSQL の間にある位置づけ

分散 SQL は、従来の RDBMS が持つリレーショナルなプログラミングモデルと、分散データストアに見られるスケールアウト設計を組み合わせます。書き込み負荷をプライマリ1台で処理でき、リージョン障害時に別の場所で継続して書き込む必要がないなら、従来の PostgreSQL や MySQL の構成は十分に機能します。読み取りレプリカ、キャッシュ、コネクションプール、適切なインデックスにより、このモデルを何年も拡張できます。

多くの NoSQL データベースは、結合、トランザクション、一貫性保証を制限することで分散を簡単にしました。大規模なイベントストリーム、使い捨てのキャッシュ、複数行トランザクションにほとんど参加しないレコードには、今でも合理的な選択です。リレーショナルクラスタでは、データをノードに分けても制約とトランザクションが有効であることをアプリケーションが期待するため、より多くの調整を引き受けます。

実務上の違いは、複雑さを誰が担うかです。手動シャーディングでは、アプリケーションチームがルーティング、データ再配置、スキーマ変更の調整、複数シャードに触れる操作を実装します。分散 SQL ではデータベースがそれらを提供しますが、エンジニアは依然としてネットワーク化されたシステム向けにスキーマとクエリを設計する必要があります。

解決するために設計された課題

分散 SQL は、可用性、地理的配置、書き込みの成長が単一プライマリ構成を超えたアプリケーション向けです。たとえば、グローバル SaaS、売り越しが許されない予約システム、ノード障害後も不変条件を守る必要がある金融台帳です。

アプリケーションレベルのシャーディングを不要にし、1か所の書き込み拠点への依存を減らせます。データを利用者の近くや、承認済みの法域内に置くこともできます。その代わり、レプリカ、ネットワーク通信、調整が増え、1台のサーバーにはない障害モードが生まれます。

ワークロードが1リージョンに無理なく収まるなら、通常のマネージド・リレーショナルデータベースが標準的な選択です。独自のシャーディング、リージョン・フェイルオーバー、地理的なデータ制御が大きな独立した開発領域になりそうなとき、分散 SQL はコストに見合います。

分散 SQL の内部動作

分散 SQL は、データを複製されたパーティションに分け、合意形成と分散トランザクションのプロトコルで変更を調整します。SQL の背後に多くの仕組みを隠しますが、その動作はレイテンシー、スループット、スキーマ設計、障害対応を左右します。

パーティションがレコードの置き場所を決める

クラスタは論理テーブルを、ノード間で独立して移動できる小さな単位に分けます。Spanner では一般に split、CockroachDB では range、YugabyteDB では tablet と呼ばれます。各単位はテーブルまたはインデックスのキー空間の一部を担当します。

境界は範囲、ハッシュ、明示的な地理ルールに従うことがあります。顧客 ID の順に並ぶ範囲なら関連レコードを走査しやすい一方、単調増加する ID は新規書き込みを1つのパーティションに寄せます。ハッシュ分散は書き込みをより均等にしますが、順序付き走査やテナント配置を難しくします。本番スキーマでは、関連データにアクセスしやすくしつつ、すべての書き込みを1か所に集中させないため、テナント ID と別の値を組み合わせることがよくあります。

セカンダリインデックスにも分散ストレージが必要です。そのため1行の書き込みが、ベーステーブルと別パーティション上の複数のインデックス項目を更新することがあります。単一サーバーで安価だったインデックスが、クラスタでは合意形成とネットワーク通信を増やす場合があります。

レプリケーションと合意形成が各パーティションを守る

各パーティションには通常複数のレプリカがあり、合意グループが受け入れる変更順序を決めます。CockroachDB と YugabyteDB は Raft ベースのレプリケーションを使います。Spanner は、時間基盤と組み合わせた Paxos ベースのレプリケーションを使います。

リーダーまたはリースホルダーがレプリカグループの書き込みを調整します。十分な数のレプリカに変更を記録し、クォーラムを形成してからコミット済みと扱います。ノードが失われても、クォーラムが残れば生存メンバーは別の調整役を選出または指定できます。

クォーラムは数学的な要件であり、すべての障害が無害だという約束ではありません。3レプリカのグループは一般に1レプリカの停止に耐えられます。2台を失うと、残る1台は別の多数派がどこかで進行していないことを証明できず、安全に書き込みを受け付けられません。レプリカ数と同じくらい、障害ドメインをまたぐ配置が重要です。

分散トランザクションは複数パーティションを調整する

1つのパーティションだけに触れるトランザクションは、比較的少ない調整で完了することがあります。複数パーティションに関わるトランザクションには、参加者全員が書き込みを適用するか中止するかをそろえる共通のコミット判断が必要です。

正確なプロトコルは製品ごとに異なりますが、通常は関連バージョンの読み取りやロック、並行変更の検証、intent または仮レコードの複製、コミットの確定を含みます。長いトランザクションほど競合の時間窓が広がります。大きなバッチは多数の合意グループに関わるため、個々の文が単純でもレイテンシーが跳ねることがあります。

そのため、ネットワークを意識したトランザクション設計が重要です。データベースが対応しているなら、関連行を相性のよいパーティション接頭辞にまとめます。トランザクションは短く保ち、開いたまま外部サービスを待たず、影響を測らずに無関係な数千レコードを1つの原子的な単位に入れないでください。

時刻と順序には明示的な仕組みが必要

分散ノードは完全に同期した物理時計を共有しないため、各製品にはトランザクションの順序を決める方法が必要です。Spanner は TrueTime の不確実性範囲とコミット待機を使い、外部一貫性を提供します。他のシステムでは、物理時計と論理要素、依存関係の追跡、トランザクションプロトコルを組み合わせます。

時計の調整は、直列化可能な実行、フォロワー読み取り、スナップショットに影響します。別々のアプリケーションサーバーが生成したタイムスタンプで信頼できる世界共通の順序を作れるとは考えず、データベースのトランザクション時刻を使うべきです。

ローカリティがネットワーク経路を決める

ローカリティ設定はレプリカの位置と、レコードの書き込みをどのリージョンで調整するかを決めます。適切なレプリカが呼び出し元の近くにあれば、読み取りは速くなります。強い順序付けが必要な書き込みは、クォーラムに必要なレプリカまで届く必要があり、レイテンシーは選択したトポロジーを反映します。

よい配置は会社の組織図ではなくワークロードに従います。EU テナントの書き込みの大半が欧州から来るなら、書き込み調整役を欧州に置けば、各トランザクションの最初に大陸間を往復せずに済みます。全リージョンが更新するカウンターのような共有レコードは、すべての書き込み元のローカルにはできず、競合点になり得ます。

分散 SQL が適した場面

地理的な耐障害性、水平の書き込み容量、パーティション間の正しさが、継続的な調整コストを正当化するほど重要なら、分散 SQL は適しています。大企業だから必要とは限らず、リージョンごとの厳格な可用性を約束する小規模な製品では必要になることがあります。

評価を正当化する条件

次の条件が複数当てはまるなら、本格的な評価が妥当です。

• ゾーンまたはリージョン障害中もサービスを継続する必要がある
• 書き込み需要が1台のプライマリの実用上の限界に近い
• 手動シャーディングにアプリケーション開発時間を大きく使う
• ノードや場所をまたいでもトランザクションを正しく保つ必要がある
• レコードに強制可能な地理的配置が必要

これらは数値で裏付けてください。必要な RTO、RPO、トランザクションレイテンシー、ピーク書き込み率、障害ドメインを定義します。「グローバルにスケールしたい」という曖昧な要求だけではアーキテクチャを選べません。

リージョンに利用者がいるだけでは決め手になりません。コンテンツ中心のアプリケーションなら、Web サーバーとキャッシュを利用者の近くに置き、データベースは1リージョンに残せます。多少古い結果を許容できれば、読み取りレプリカで地域ごとの閲覧を支えられます。複数の場所の利用者が関連データに低レイテンシーで書き込む必要があるとき、検討理由は強くなります。

より単純なデータベースが向く条件

トラフィックが中程度で、書き込み元が1リージョンにあり、計画的なデータベース昇格で復旧できるなら、通常のリレーショナルサービスが適しています。成熟したツール、幅広い拡張互換性、慣れたデバッグ、より小さなインフラ費用が得られます。

厳しいレイテンシー要件では、1リージョンのプライマリが有利な場合もあります。ローカルで永続化する書き込みは、遠いリージョンをまたぐクォーラム書き込みよりずっと速く完了できます。分析中心のシステムでは、同じクラスタが運用トランザクションと長時間スキャンの両方で優秀だと期待せず、通常は分けるべきです。

チームの余力も重要です。マネージドサービスはハードウェア、パッチ、コントロールプレーン運用の負担を減らしますが、スキーマ競合、トランザクションリトライ、クエリ計画、容量管理、アプリケーション側の障害対応はなくなりません。障害時の動作をテストする時間がないチームでは、分散データベースの導入がリスクを増やします。

代替案で判断するしきい値

最も強い根拠は、代替案がすでに複雑なときに現れます。テナントルーティング、シャードマップ、シャード間トランザクション規則、リージョン昇格手順、独自の移行ツールを作ろうとしているなら、それらを提供するデータベースは慎重に評価する価値があります。

代替案が読み取りレプリカとテスト済みバックアップを持つマネージド PostgreSQL 1台なら、移行には明確な根拠が必要です。まず既存システムをベンチマークしてください。CPU 飽和は、水平書き込みが必要なのではなく、非効率なクエリ、接続管理の問題、過剰なインデックス、キャッシュ不足かもしれません。

一貫性、可用性、レイテンシー

分散 SQL は通常、必要なクォーラムに到達できない操作を拒否することで、障害中もトランザクションの一貫性を守ります。コミット済み状態は保護されますが、ネットワーク分断中は一部のリクエストが失敗または待機します。

CAP が説明するのは障害時の動作

CAP 定理は、クラスタの一部どうしの通信が途絶えたときに当てはまります。影響を受けたデータについて、線形化可能な一貫性と、分離された全側からの成功応答を同時には保証できません。一貫性を重視するデータベースでは、クォーラムを持つ側だけが継続し、他方の安全でない書き込みを拒否します。

CAP は正常時のレイテンシーを説明するものではありません。すべてのリンクが動いていても、レプリカ間の通信は必要です。設計判断には、分断時の動作と、健全時にアプリケーションが受け入れる調整量の両方が含まれます。

アプリケーションは利用不能な結果を明示的に扱う必要があります。タイムアウト、リトライ可能なトランザクションエラー、書き込みリージョンの一時喪失は、通常起こり得ます。残高や予約では、分離された両リージョンで成功を返すほうが悪く、後で整合させる自動的な答えがないかもしれません。

強い読み取りと意図的に古い読み取りは異なる

強い読み取りは、求める順序保証と整合するデータベース状態を観測します。一部の製品では、鮮度を少し犠牲にして、書き込み調整役の負荷とレイテンシーを下げるフォロワー読み取りや、許容遅延付き読み取りも提供します。

選択は読むフィールドに従うべきです。商品説明は少し古いレプリカでも問題ないことが多いでしょう。変更直後のパスワード、現在の残高、残在庫には、適切に強い、またはセッション整合性のある経路を使う必要があります。速度のためにすべての読み取りを古いものとして扱い、サービスコードで正しさを作り直してはいけません。

read-your-writes の動作は、実際のドライバーとルーティング層でテストしてください。更新後の次のリクエストは、別のアプリケーションサーバーやデータベースエンドポイントに届く可能性があります。利用者が受理された変更を見られるように、セッショントークン、トランザクション境界、強い読み取り設定が必要になることがあります。

分離レベルが並行実行の結果を決める

トランザクション分離は、並行トランザクションでどの異常が起き得るかを決めます。直列化可能分離は、データベースが並行実行していても、完了したトランザクションが1つずつ実行されたように見えることを目指します。

安全に順序付けできない並行操作があると、直列化可能な実行は参加者の1つを中止することがあります。これはデータベース破損ではなく、不正な結果からの保護です。アプリケーションは、書き込み判断に影響したすべての読み取りを含め、トランザクション全体を回数制限付きでリトライする必要があります。

データベース外のリトライは冪等でなければなりません。トランザクションのコミットが確定する前にメールを送ったり決済事業者を呼んだりすると、リトライで副作用が繰り返されます。データベーストランザクション内でアウトボックスイベントを記録してコミットし、別ワーカーが外部処理を配信します。

距離が書き込みレイテンシーの下限を作る

リージョンをまたぐトランザクションは、プロトコルが必要とするメッセージより速く完了できません。クォーラムメンバー間の往復が80ミリ秒なら、クエリ実行、インデックス保守、アプリケーション処理、キュー待ちの前に、その時間が実際に加わります。

高価になりやすいのは、1つの利用者操作で複数のトランザクションを順に実行するパターンです。チェックアウトで注文挿入、在庫予約、決済状態更新、監査書き込みを4回のブロッキングコミットにすると、ネットワークコストが積み重なります。1つの原子的な結果を共有するデータベース変更をまとめれば不要な往復を減らせますが、外部決済呼び出しは開いたトランザクションの外に置きます。

平均ではなくパーセンタイルのレイテンシーを測ってください。リーダー移動、競合、ストレージの停止、リトライはテールに現れます。通常の再配置中に p99 を満たせない設計は、中央値が目標を満たしていても利用者に見える失敗を生みます。

Spanner、CockroachDB、YugabyteDB の比較

Spanner、CockroachDB、YugabyteDB は似た分散の課題を解きますが、デプロイモデル、互換性、トランザクション実装、運用上の前提が異なります。共通の SQL というラベルだけで選ばず、アプリケーションの動作で選ぶ必要があります。

Spanner はマネージド Google Cloud 戦略に合う

Spanner は、マネージド Google Cloud データベースを使い、その方言、トポロジー、運用モデルに合わせて設計できる組織に向いています。TrueTime は外部一貫性のあるトランザクションを支え、文書化された意味論の範囲で、コミット済みトランザクションが実時間順序を尊重します。

PostgreSQL 方言は SQL 構文の差を減らせますが、完全な PostgreSQL 等価ではありません。拡張、管理関数、システムカタログ、データ型、ドライバー、ORM の前提は検証が必要です。既存アプリケーションを移植可能とみなす前に、すべてのデータベース依存関係を棚卸ししてください。

Google Cloud の ID、ネットワーク、可観測性、リージョン制御にすでに依存するシステムなら、Spanner は特に検討に値します。マネージドモデルはデータベースノードの管理をなくしますが、スキーマ設計、クエリチューニング、クォータ、コスト管理、アプリケーションの復旧は利用者の責任として残ります。

CockroachDB は PostgreSQL 指向の分散アプリケーションに合う

CockroachDB は、PostgreSQL 風のアプリケーションアクセスを求め、トランザクションデータを range に分散したいチームに合います。既定で直列化可能分離を使うため、競合や順序の衝突で拒否されたトランザクションをアプリケーションが正しくリトライする必要があります。

互換性は移行、ドライバー、ORM の層でテストしてください。PostgreSQL 拡張や特殊な動作がない、または異なることがあります。テーブルとインデックスを range に分けると、単一ノードの実行計画に依存するクエリも異なる振る舞いをします。

range の移動と自動再配置は容量変更を簡単にしますが、プライマリキーの選択が悪ければ hot range は生まれます。マルチリージョン抽象化はテーブルのローカリティを表す助けになりますが、どのレコードがリージョン固有か、どれがグローバルか、どこで書き込みを調整するかは開発者が決めます。

YugabyteDB は YSQL と混在 API の要件に合う

YugabyteDB は PostgreSQL 互換のリレーショナルインターフェースを重視し、別の Cassandra 互換 API からも恩恵を受けるアプリケーションに合います。YSQL はリレーショナルテーブルと分散トランザクションを提供します。YCQL は別のデータモデルに従うため、すべての YSQL 操作への別経路として扱うべきではありません。

ストレージ層は tablet を通じてデータを分散します。テーブル設計、tablet 分割、インデックス配置、トランザクションの範囲が、クラスタ全体への仕事の広がりを左右します。PostgreSQL アプリケーションでも、拡張、関数、ツール、プランナーの動作について互換性テストが必要です。

さまざまなデプロイ方法を選べることは、配置の管理を求めるインフラポリシーに適します。セルフマネージドでは、その管理は顧客の運用責任になります。アップグレード、修復手順、容量、可観測性、証明書、バックアップ、障害テストに担当者が必要です。

製品テストにはアプリケーションの根拠を使う

有用な比較では、実際に近い同じワークロードを、候補となる各製品で実行します。スキーマ作成、マイグレーション、ORM が生成する SQL、トランザクションリトライ、バックアップ復元、フェイルオーバー、スケールイベント、最大量のクエリをテストします。

ピーク時の毎秒トランザクション数だけを比べないでください。p50、p95、p99 のレイテンシー、競合・リトライ率、リージョン間転送バイト数、ストレージ増幅、復元時間、模擬障害中の運用負荷を記録します。正しさと復旧目標を、許容できるコストと運用負担で満たす製品が最適です。

リージョンごとに利用者がいるグローバル SaaS

グローバル SaaS は、テナントごとに地域でのデータ配置とトランザクションアクセスが必要で、地域ごとに別のデータベース群を運用したくない場合、分散 SQL の恩恵を受けます。テナントをスキーマで明確にし、ほとんどのトランザクションを1テナント内に留めると、設計は最もうまく機能します。

テナントのローカリティは契約とトラフィックに従わせる

テナント ID を配置に使えば、欧州のレコードを承認された欧州の場所に留め、他の顧客のレコードは契約した国やリージョンに留められます。1つの論理スキーマを保ちながら、物理ポリシーを顧客ごとに変えられます。

配置ルールはベーステーブルだけで終わりません。インデックス項目、変更ストリーム、一時データ、バックアップ、エクスポート済みレコードにも規制対象の情報が含まれることがあります。行を固定してもグローバルなセカンダリインデックスを別の場所に送れば、意図した境界を破る可能性があります。

テナント分離は性能にも影響します。大規模テナントが共有パーティションを圧迫したり、1ノードを占有したりします。そのテナント内でハッシュ化またはサブパーティショニングが必要になることがありますが、テナントスコープのトランザクションへ効率よくアクセスできなければなりません。

リージョン読み取りには明示的な鮮度ポリシーが必要

読み取り中心のダッシュボードは、少し遅れたデータを許容できるなら近いレプリカを使えます。アカウント変更、認可判断、トランザクション直後の確認画面には、より強い動作が必要です。全体で1つの設定を採用するのではなく、鮮度要件でクエリ経路を分類してください。

書き込み配置はテナントごとの通常の書き込み元に従わせます。顧客の担当者が主にシンガポールで働くのに、別の大陸で書き込みを調整すれば避けられるレイテンシーが生じます。テナント移行手順では、書き込みを失わず、データ所在地に違反せず、アプリケーションのキャッシュを古い場所に向けたままにせず、配置を更新する必要があります。

グローバルなアプリケーションコードは移動を許容する

リーダーは移動し、ノードは再起動し、メンテナンス中にルーティングは変わります。ドライバーには適切なタイムアウト、リトライ方針、接続更新、トランザクション再開ロジックが必要です。過負荷のクラスタに同時の再試行波を送らないよう、リトライにはジッターと上限を付けます。

監視では、利用者レイテンシーをリージョンとテナント種別ごとに分けてください。グローバル平均では、遠い顧客グループが何度も追加のネットワーク往復を負担していることを隠します。API span とデータベース文を結び付けるトレース ID があれば、ローカリティの誤りを見つけやすくなります。

金融ワークフローと台帳

金融ワークフローでは、データベースの制約とトランザクションが、障害や並行リクエストをまたいで台帳の不変条件を守るときに恩恵があります。分散するだけで会計が正しくなるわけではないため、破ってはいけない規則をスキーマに表現しなければなりません。

台帳は監査可能な仕訳列を保つべき

追記型の台帳は、履歴なしに残高値を繰り返し置き換えるのではなく、各移動を仕訳として記録します。すべての記帳には、安定したトランザクション ID、口座、金額、通貨、業務上のタイムスタンプ、作成メタデータが必要です。借方と貸方が記帳単位で一致することを、コミット前に確認します。

キャッシュされた残高は読み取りを速くしますが、仕訳と同じトランザクションで変更するか、派生データとして明確に扱う必要があります。照合ジョブでは派生合計と元の仕訳を比較し、履歴を黙って書き換えずに差異を報告します。

すべての口座に世界共通の順序が必要になることはまれです。1口座または送金ペアに関わるトランザクションには一貫した順序が必要ですが、無関係な口座は並行して進められます。この境界に沿って設計すれば、世界共通の連番や決済行を1つにするより競合を減らせます。

冪等性がリトライを安全にする

決済 API、キュー、Webhook はタイムアウト後にリトライするため、各業務操作には安定した冪等性キーが必要です。加盟店や口座といった適切な範囲で一意性を強制し、1つのデータベーストランザクションで決済レコードと台帳仕訳を作成します。

CREATE TABLE payment_attempts (
    account_id UUID NOT NULL,
    idempotency_key TEXT NOT NULL,
    provider_reference TEXT,
    status TEXT NOT NULL,
    created_at TIMESTAMPTZ NOT NULL,
    PRIMARY KEY (account_id, idempotency_key)
);

2つのワーカーが同じ操作を送ると、一意制約がどちらの挿入を成功させるか決めます。失敗したワーカーは既存レコードを読み、その確立済みの結果を返します。データベーストランザクションがリトライされたからといって、決済事業者への請求を2回作ってはいけません。

外部呼び出しにはトランザクション境界が必要

データベースは、両者が特殊な調整プロトコルに参加しない限り、無関係な決済事業者と原子的にコミットできません。一般的な公開 API は参加しません。ネットワーク呼び出しをデータベーストランザクションの外に置き、pending、authorized、captured、failed、reversed のような明示的な状態でワークフローを表現します。

トランザクショナル・アウトボックスは、コミット済みの変更を下流ワーカーに公開できます。メッセージは複数回届くことがあるため、コンシューマーはイベント ID で重複を除く必要があります。これにより、すべてのサービスをまたぐ不可能な単一トランザクションを主張せずに、復旧可能な処理を実現できます。

ホットな口座にはワークロードに合う設計が必要

給与支払い、マーケットプレイスの決済、大規模加盟店は、1つの口座に書き込みを集中させることがあります。ノードを増やしても、競合する1行を分割できません。選択肢には、不変の仕訳パーティション、期間ごとの集計値、1口座向けのキューイング、慎重に定義したサブ口座の階層があります。

実際の偏りをテストしてください。一様な合成トラフィックではクラスタが準備できているように見えても、本番では1つの加盟店が直列化可能な競合を繰り返し起こすことがあります。正しさが最優先ですが、会計規則が許す範囲で安全な並行性をデータモデルに表すべきです。

在庫、予約、引当

在庫・予約システムでは、複数の利用者が同じ希少な品目を確保しようとするため、権威ある引当トランザクションが必要です。高速な在庫読み取りは閲覧を改善しますが、最終単位を誰に渡すか決められるのはコミット経路だけです。

条件付き書き込みで売り越しを防ぐ

条件付き更新では、十分な在庫が残る場合だけ確保できます。影響行数で、引当が成功したかをアプリケーションに伝えます。

UPDATE inventory
SET available = available - 1
WHERE sku = $1
  AND available > 0;

この文は予約レコードと同じトランザクションに入れるべきです。先に在庫を読み、後で減らすと、分離レベルと述語処理が判断を保護しない限り競合が生じます。別の安全層として、データベース制約で負の数量を拒否します。

指定席では、公演と座席 ID の一意制約により勝者が1つに決まります。ホテル在庫は、重なる滞在で同じ容量を取れないよう、客室泊または在庫プールの日付でモデル化することが多いです。競合の正しい単位は業務規則から導きます。

保留で引当と決済を分ける

一時保留は、決済または利用者の確認中に在庫を確保します。有効期限と状態を保存し、条件付きトランザクションで確定予約に変えます。確認と失効は競合し得るため、失効ワーカーはまだ有効な保留だけを解放すべきです。

時計上の遅延だけでは解放を保証できません。ワーカーが停止し、キューが遅れ、リージョンが障害を起こすことがあります。販売可能な在庫を計算するクエリは失効状態を一貫して扱い、修復ジョブが見逃した保留を回収します。

保留時間はプロダクトと容量の判断です。チェックアウトには10分の保留が妥当でも、混雑時には希少な在庫の大きな割合をロックします。設定前に離脱率と決済完了時間を測定してください。

極端な競合は線形にはスケールしない

1行をめぐって数千人の購入者が競う状態は、レプリカを増やしても並列化できません。成功する減算はすべて、他の減算に対して順序付ける必要があります。入場制御、キュー、在庫バケット、あらかじめ割り当てた地域クォータで、販売開始時のデータベースを守れます。

リージョン別クォータは調整を減らしますが、意味論を変えます。欧州に未使用の単位がある一方で別リージョンが売り切れた場合、安全にクォータを移す方法か、一時的な不均衡を受け入れる方法が必要です。業務側で地域容量の調整方法を定義できる場合だけ使ってください。

高可用性と災害復旧

分散 SQL は、レプリカ配置、余剰容量、アプリケーションの動作が明確なサービス目標に合っていれば、選定したインフラ障害中もサービスを維持できます。レプリケーションだけでその結果が得られるわけではありません。

SLO は障害ドメインを明記すべき

可用性目標には、ワークロードと障害シナリオが必要です。1ノード、1可用性ゾーン、リージョン全体のどれに耐える必要があるか定義します。復旧後だけでなく、障害中に許容できるエラー率とレイテンシーも示します。

1つの建物に置かれた3レプリカクラスタは、独立したゾーンに分けた3レプリカとはリスクが異なります。マルチリージョントポロジーはより広い障害から守りますが、クォーラム経路が長くなり、1か所が消えた後のトラフィックを吸収する十分な残存容量が必要です。

RTO はサービス復帰までに許される時間を定義します。RPO は失ってよいコミット済みデータ量を定義します。同期クォーラムレプリケーションは、対象となる障害でコミット済みデータを失わない目標を支えられますが、必要なレプリカとアプリケーション経路が設計どおりに動く間に限られます。

フェイルオーバーはアプリケーションに見えるイベントを作る

リーダー変更は、実行中のトランザクションを中断し、接続を閉じ、レイテンシーを高めます。アプリケーションは、リトライ可能なデータベース結果と恒久的な業務エラーを分ける必要があります。失敗したトランザクションは、最後の文だけを再実行せず、1つの単位として再開します。

コネクションプールは、障害後も死んだエンドポイントを保持することがあります。ヘルスチェック、DNS の動作、ロードバランサー、証明書検証、ドライバーのトポロジー検出をテスト計画に含めます。データベースが健全でも、アプリケーションが見つけられないことがあります。

障害後の容量は明示的に計算してください。通常3リージョンが70%近い利用率で動くなら、1リージョンを失った際にその仕事を収める余地がありません。余力の確保には費用がかかりますが、フェイルオーバー容量のないトポロジーは掲げた目標を満たしません。

ゲームデーで設計を検証する

障害演習では、1ノードの停止、ゾーンの分離、リージョン接続の中断、アプリケーションエンドポイントの削除を行います。エラー継続時間、トランザクションリトライ率、レイテンシーのパーセンタイル、キュー増加、運用者の対応を測定します。

重要なトポロジー、ドライバー、スキーマの変更後にこれらの演習を実行してください。前年のトラフィックで実証された手順が、データ量の倍増や1テナントの巨大化後に失敗することがあります。安全な部分を自動化し、年1回の手作業に証拠を依存させないようにします。

レプリケーションはバックアップではない

レプリカは、誤削除、欠陥のあるマイグレーション、有害なアプリケーション書き込みも忠実に複製します。バックアップとポイントインタイムリカバリは、レプリケーションでは検知できない論理的な損害から守ります。

復元訓練では、別のクリーンな環境を作り、チェックサムまたはアプリケーションの不変条件を確認し、総復旧時間を測定します。暗号鍵、アクセス方針、スキーマバージョン、依存設定も含めます。目標時間内に復元できないバックアップは、十分な復旧システムではありません。

データ所在地とコンプライアンス主導の設計

分散 SQL では、テナントやレコード群を承認済みリージョンに配置できます。ただしコンプライアンスは、すべてのコピー、アクセス経路、運用プロセスにかかっています。データベースのローカリティは、より広い取り組みの中の1つの制御です。

所在地ルールには正確な定義が必要

データを国に留めるという要件は、保存、処理、サポートアクセス、バックアップ、暗号鍵、またはそのすべてを指す場合があります。解釈が違えばトポロジーも変わります。法務担当と監査人は、規制と契約をテスト可能な技術的制御に翻訳すべきです。

チームには規制対象フィールドと派生データの棚卸しが必要です。ログ、トレース、検索インデックス、分析エクスポート、サポート添付、メッセージキューにも、主テーブルと同じ個人情報が含まれることがあります。データベースだけを制限し、生のペイロードを世界中に出力していては、意図したポリシーを満たせません。

データ最小化は設計を簡単にします。グローバルサービスに必要なのがアカウント ID と集計状態だけなら、機微な詳細は承認済みリージョンに留め、他の場所には許可された最小限の表現だけを公開します。

配置ポリシーにはライフサイクル操作も含める

ポリシーには、稼働中のレプリカ、一時レプリカ、バックアップ、スナップショット、変更レコード、復元環境をどこに置けるかを記します。再配置とメンテナンスも同じ境界に従わなければなりません。緊急手順で、便宜のため規制対象データを未承認リージョンにコピーしてはいけません。

アクセス制御には地理的・組織的な制限が必要です。サービス ID には必要なテーブルと操作だけを与えます。本番への人のアクセスは記録し、可能なら時間制限を設け、レビューします。リージョンにひも付く暗号鍵は制御を追加できますが、鍵の可用性と災害復旧には別の設計が必要です。

テナント移転には文書化されたフローが必要です。契約変更、顧客移行、企業再編で、法域間にレコードを動かすことがあります。古いコピーがいつ消えるか、バックアップがどう期限切れになるか、完了を示す証拠は何かを特定します。

グローバルレポートには派生データセットが必要な場合がある

グローバルダッシュボードは、地域をまたいで生の顧客データを走査すると、厳しい配置要件と衝突します。リージョンごとの処理で承認済みの集計値をローカルに計算し、機微でない結果を中央のレポートストアに公開できます。

集計規則は、制限対象レコードを復元できないようにすべきです。小さなグループ、自由記述フィールド、詳細な次元は、直接識別子を除いても個人情報を露出させることがあります。分析のガバナンスは、後のレポートプロジェクトではなく、アーキテクチャレビューに含めます。

運用と分析のワークロードは、多くの場合別システムにすべきです。トランザクションデータベースは現在のプロダクト状態を守り、リージョンスコープのパイプラインはレポート向けの管理されたデータセットを作ります。こうした分離により、長い分析スキャンをレイテンシーに敏感なトランザクションから遠ざけられます。

コストと性能の計画

分散 SQL は、冗長な容量を維持し、ネットワーク越しに処理を調整するため、基本的な単一リージョンデータベースより費用がかかります。高価なシャーディング作業を置き換えたり、運用上乗せ額を超える損失を防いだりできるなら、投資は正当化できます。

コンピュートとストレージにはレプリケーションの負荷が含まれる

論理サイズ 2 TB のデータセットを完全なレプリカ3つで持つと、セカンダリインデックス、一時コンパクション領域、バックアップ、メタデータの前に、複製データだけで約6 TB になります。実際の課金と圧縮率は製品ごとに違うため、見積もりには論理テーブルサイズだけでなく、計測した物理ストレージを使います。

コンピュートは通常処理、合意処理、再配置、バックアップ、障害時の余力を支える必要があります。1つのパーティションがホットなら、ノードは交換可能なスループット単位ではありません。容量追加が役立つのは、ワークロードを分散できる場合だけです。

インデックスは書き込み作業とストレージを増やします。各セカンダリインデックスを、クエリ価値、更新頻度、地理的配置で見直してください。使われないインデックスはディスクを浪費し、影響する書き込みをすべて高くします。

ネットワーク料金は無視できなくなることがある

レプリケーションはレプリカの場所どうしに書き込みを送ります。リージョン間クエリ、変更フィード、バックアップ、アプリケーショントラフィックがさらに転送を増やします。複数リージョンでアクティブにトラフィックを処理すると、単一リージョンのベンチマークでは見えない請求額になることがあります。

トランザクションあたりのバイト数、レプリケーション係数、書き込み率、インデックス増幅、転送方向を見積もります。その後、代表的な負荷試験でプロバイダーの請求データを使って確認します。リクエスト数だけでは、大きなペイロードとバックグラウンド移動を見落とします。

ローカリティの誤りはコストとレイテンシーをともに上げます。エンドポイント選択やテナント配置のため、1リージョンにデプロイしたサービスが別リージョンの調整役に繰り返し問い合わせることがあります。分散トレーシングとリージョン別のコスト内訳で、このパターンを明らかにできます。

利用者の操作で積み上がるレイテンシーを確認する

単独の文ではなく、利用者の操作全体をモデル化します。チェックアウトなら、順番に行うデータベースコミット、強い読み取り、外部 API 呼び出し、キューへの受け渡しをすべて数えます。計測したリージョン間往復時間とクエリ実行のパーセンタイルを、クリティカルパスに当てはめます。

たとえば、ある操作に順番のクォーラム書き込みが2回あり、各回にネットワーク調整で90ミリ秒かかるなら、アプリケーション処理の前に約180ミリ秒が加わります。1つの原子的な判断を共有する変更をまとめるとコミットを減らせ、独立した読み取りを並列化すると経路を短くできます。

負荷試験には現実的な競合とペイロードサイズを含めます。ランダム ID のベンチマークは完全に分散しても、本番では数件の人気テナントに書き込みが集中するかもしれません。リーダー変更と再配置も含め、テールレイテンシーが通常のクラスタ運用を反映するようにします。

現実的な代替案と総保有コストを比較する

比較すべきなのは、分散 SQL と運用コストのない架空のデータベースではありません。マネージド PostgreSQL、レプリカ、シャーディングサービス、リージョン復旧、アプリケーションルーティング、それらを維持するエンジニアという具体的な代替案と比べます。

移行作業、研修、可観測性、障害対応、サポートプラン、撤退コストを含めます。マネージド運用はインフラ作業を減らせますが、セルフマネジメントは深い人員体制を必要とする代わりに制御要件を満たす場合があります。

単純な財務モデルで、年間のプラットフォーム上乗せ額と、想定停止損失、遅れる開発作業、コンプライアンスのリスク、地域レイテンシーの影響を受ける売上を比べられます。不確実な入力には範囲を使い、どの前提が結論を変えるかを特定します。あり得ないほど大きな停止見積もりに結果が依存するなら、より単純なシステムが適切なままです。

スキーマとアプリケーションの設計パターン

分散 SQL のスキーマは、独立した作業を分散しつつ、関連するトランザクションを近くに保つアクセス経路を持つと性能を発揮します。単一ノード向けのスキーマをそのまま移すと、正しさは保ててもレイテンシーが悪化し、深刻な競合が生じることがあります。

プライマリキーが分散に影響する

単調増加するプライマリキーは、新しい行を1つの range の末尾に向けることがあります。ランダム ID は挿入を分散しますが、完全にランダムな分布ではテナント走査や地域配置にコストがかかります。複合キーでは、テナントまたはバケット ID を先頭にし、そのグループ内に並べ替え可能な値を残すことで、両方の目標を両立することがよくあります。

接頭辞はトランザクション境界に従って選びます。ほぼすべての操作がテナントスコープなら、テナントでまとめると分散処理を減らせます。非常に大きなテナントでは、複数パーティションが並行して書き込みを受けられるよう、その名前空間内にバケットが必要になることがあります。

テーブルが大きくなった後のプライマリキー変更には、大規模なデータ書き換えが必要になることがあります。移行前に現実的な偏りで候補のレイアウトをテストしてください。総スループットだけで判断せず、パーティションの熱、トランザクションのファンアウト、インデックスのローカリティ、走査の動作を確認します。

競合は容量追加より先に設計を見直す

グローバルカウンター、単一の設定行、1つの加盟店残高は、独立しているはずのリクエストを直列化します。すべてのトランザクションが同じ値を更新するという論理要件を、ノード追加で取り除くことはできません。

一時的な集計を許容できるなら、正確なグローバルカウンターを分割カウンターに置き換えます。高頻度で1行を更新する代わりに、設定はバージョン管理します。金銭状態では、正しさを弱めず、追記型の仕訳または独立したサブ口座に並行性を見いだします。

長い read-modify-write トランザクションは競合を悪化させます。必要最小限だけを読み、トランザクション内で利用者操作を待たず、速やかにコミットします。業務処理に数分かかるなら、複数の短いトランザクションにまたがる状態機械として表現します。

リトライ動作はアプリケーション契約に含める

ドライバーは個別の文をリトライすることもあれば、リトライ可能なエラーをアプリケーションに渡すこともあります。トランザクション全体の再実行をどの層が担うのかを理解してください。部分的な再実行では、古い判断を使ったり、先行する読み取りを漏らしたりします。

リトライループには最大試行回数、ランダム化したバックオフ、計測を用意します。競合タイプ、影響した操作、試行回数、最終結果を記録します。無制限のリトライは競合を見えないレイテンシーに変え、クラスタを過負荷にします。

業務リクエストには安定した ID が必要です。クライアントへの応答が不確かでも安全に確認できます。データベースがコミットしたのに応答が失われた場合、クライアントは意味的に新しい操作を送るのではなく、確立済みの操作を問い合わせるべきです。

スキーマ変更は本番規模で事前検証する

分散スキーマ変更はメタデータをすばやく更新しても、バックフィルとインデックス作成はバックグラウンドで続くことがあります。これらのジョブはストレージ、ネットワーク、CPU を使い、本番の書き込みと影響し合います。

expand-and-contract マイグレーションを使います。まず互換性のあるフィールドやテーブルを追加し、両方の形で動けるコードをデプロイし、制御したバッチでバックフィルし、読み取りを切り替え、確認後に古い形を削除します。ロールバック計画では、新バージョンが書いたデータを考慮します。

本番に近い容量とリージョントポロジーで大規模移行をテストしてください。小さなステージングクラスタで短時間に終わる変更が、本番では数時間かかり顧客トラフィックと競合することがあります。開始前に、進捗、停止制御、ディスク余力、リトライ動作を監視します。

導入チェックリストと PoC

有用な PoC は、代表的な1つのワークロードを、明示した正しさ、レイテンシー、耐障害性、コスト目標に対してテストします。一般的なベンチマークでは、特定のスキーマとアプリケーションがよく動くかは判断できません。

実際の制約があるワークロードを選ぶ

希少な品目の予約、台帳振替の記帳、必須リージョンでのテナント作成などのワークフローを選びます。本番に近いスキーマ、クエリ、トランザクション境界、ペイロードサイズ、トラフィックの偏りを再利用します。

テスト実施前に成功条件を定義します。

• 並行実行とリトライ下で正しい結果が得られること
• リージョン別の p50、p95、p99 レイテンシー
• 障害時の余力を持つ持続的なピークスループット
• ノードおよびリージョン障害中の復旧動作
• 計測されたコンピュート、ストレージ、ネットワークコスト

安全余裕は任意の倍率ではなく、想定成長と障害時の容量から決めるべきです。1リージョンを失うことが対象なら、テスト中に残りの場所が振り向けられた負荷を扱えなければなりません。

現実的なアプリケーション面を作る

API と小さなユーザーインターフェースは、データベースだけのツールでは見逃すトランザクション順序、ドライバーの動作、利用者が感じるレイテンシーを明らかにします。Koder.ai は、チャットで React インターフェース、Go バックエンド、PostgreSQL のベースラインを作成できます。プランニングモードで生成前にワークフローを定義でき、ソースコードをエクスポートすれば、エンジニアは候補データベース向けにデータ層を調整できます。

生成したアプリケーションは、データベース互換性の証明ではなくテスト用の足場として使います。マイグレーションを実行し、生成された SQL を確認し、公式ドライバーを設定し、トランザクションリトライを意図して実装してください。Koder.ai のスナップショットとロールバックはアプリケーションの反復を守れますが、データベースバックアップや復元訓練の代わりにはなりません。

Koder.ai はデプロイとホスティングも支え、テスト用アプリケーションのインスタンスをデータベースリージョンの近くに置けます。これにより、すべてのベンチマークを1か所から送るのではなく、リクエスト経路全体を測れます。本番レコードに必要な制御が環境にない限り、テストデータは合成データにしてください。

通常運用と障害を試す

テストでは、安定したトラフィック、急増、ホットパーティション、長時間クエリ、スキーマ変更、バックアップ作業、ノード交換を扱います。その後、承認されたテスト環境で接続を中断し、障害ドメインを取り除きます。

トランザクション中止、リトライ回数、利用不能応答、リーダー移動、キュー深度、ディスク使用量、リージョン間転送を記録します。運用者が何をする必要があったかも記録してください。文書化されていない手作業が必要な自動復旧は、まだ本番対応ではありません。

バックアップを別環境に復元し、アプリケーションの不変条件を確認します。在庫では引当が在庫を超えないことを確認します。台帳では残高を再計算し、仕訳が均衡していることを確かめます。SaaS テナントでは、配置とアクセスポリシーが復元後も保たれたことを確認します。

移行前に互換性を検証する

データベース拡張、ストアドプロシージャ、トリガー、データ型、分離に関する前提、ORM 機能、レポートクエリ、バックアップツール、管理スクリプトを棚卸しします。各項目を、互換、置換可能、阻害要因に分類します。

本番規模のコピーまたは生成データセットで、代表的な移行を実行します。バックフィル時間、変更データキャプチャの遅延、二重稼働コスト、切り替え時間を測定します。二重書き込みを使うなら、差異の検出方法と、各段階でどちらのシステムを正とするかを定義します。

シャドー読み取りでは、本番状態を変えずに結果を比較できます。意図的に古いクエリやタイミング差を考慮し、予想される差を破損と誤判定しないようにします。トランザクションデータの説明できない差は、切り替え前に解決が必要です。

本番準備状況をレビューする

本番レビューでは、データベース運用、アプリケーションのリトライ、セキュリティ、所在地ポリシー、コスト、障害対応の担当者を割り当てます。ダッシュボード、アラート、ランブック、容量しきい値、復元の証拠、ロールバック判断点を含めます。

最終判断は PostgreSQL や MySQL に留まることでも構いません。PoC は、分散の選択肢が現在の要件を正当化できないほど高価だと示しても、信頼できる根拠を生めば成功です。要件が導入を支えるなら、段階的に移行し、各段階を測定し、新システムが実負荷で実証されるまでテスト済みの復帰経路を保ちます。