【PCA認定試験】Cloud SQLとSpanner、BigtableとCAP定理と
はじめに
GCPのDBを勉強していると、「Cloud SQLやSpannerは一貫性を重視したCPシステム」という話をよく聞きますよ。初心者としては「可用性を優先したAPシステムは？」「CAシステムってないの？」という疑問が自然と湧いてくるはずです。
この記事では、そんな自然な問いについて調べてみました。PCA認定試験でも、特定の状況におけるDBを選定する問題はよくあるので、DB選定に制限を課すCAP定理という側面から問題を見ていこうと思います
最終的に、下記のような図の意味がわかるようになります。
CAP定理の簡単なおさらい
簡単なおさらいです。
-
C -
A -
P
すなわち、考えうるDBは
はじめに言及しますが、クラウドのような分散システムでは、ネットワーク分断（
CAP定理の証明
実際に[1]を読んで、該当の箇所を追ってみました。一部略してあります。
定理:
非同期ネットワークモデルにおいて、次の性質を保証するread/writeデータオブジェクトを実装することは不可能である。
- 可用性 (Availability)
- 原子一貫性 (Atomic consistency)
これは、メッセージが失われる場合を含む、すべての実行 (fair execution)においてである。
※現代的にはACID特性という言葉があるように、原子性と一貫性は分けて書くべきなのでしょうかね？ちなみに、
- 原子性(Atomicity):
トランザクション内のすべての操作が成功するか、または一つも実行されないかのどちらかであることを保証 - 一貫性(Consistency):
トランザクションの前後で、DBが整合性制約を満たしていることを保証 - 独立性(Isolation):
複数のトランザクションが同時に実行されても、互いに干渉しないように独立性を保証 - 永続性(Durability):
トランザクションが成功した場合、その結果がシステム障害などが発生しても失われないことを保証
であることをまとめておきます。下記も参考にしてください。
雑な証明:
基本的にCAP全てを満たすこと仮定して、矛盾を導く方針です。まず
設定
-
G_1, G_2 -
\alpha_1 v_0 v_1 -
\alpha_2
これを図解すると上記のようなイメージです。
このようにして
参考：
とここまでCAPについて説明してきましたが、現実問題、そこまで単純化もできないですし、調べたところ分散システムの設定にも不備があるという指摘もありました。そもそも
CAP定理をより詳細にしたものでPACELC定理という考え方があるそうです：
If a Partition occurs, choose between Availability and Consistency.
Else (in normal operation), choose between Latency and Consistency.
D. J. Abadi (2012)
分断時
最も参考にした論文です。全ては読めていませんが、このような分野もあるのだなと勉強になりました。
S. Gilbert and N. Lynch (2002)
もともとの
Geminiによる回答
「3つのうち2つを選ぶ」は誤解である
Brewerが最も伝えたかったことです。CAP定理は、システム設計を「
常にトレードオフが発生するわけではない: ネットワークが正常なとき（分断
分断は実はまれ: 現実の多くのシステム、特に同一データセンター内で完結するシステムでは、深刻なネットワーク分断はまれなイベントです。そのため、「100%の可用性」か「100%の一貫性」か、という極端な選択をする必要はほとんどありません。
トレードオフは「度合い（グラデーション）」の問題
遅延時間も考慮に入れる: 例えば、「50ミリ秒以内に応答がなければ、それは分断とみなして可用性を優先する」といった設計が可能です。これは、応答時間という「可用性（
全てか無かではない: 分断が起きた際も、システムの機能を全て停止する必要はありません。「在庫の確認はできる（読み取りはOK）が、購入はできない（書き込みはNG）」のように、操作によってCとAの扱いを変えることができます。
分断時の「計画的な復旧」が重要
分断はいつか必ず回復します。重要なのは、分断が起きたときにどう振る舞い、回復したときにどうやって矛盾を解消するかという計画です。
不変条件の管理: システムが絶対に守らなければならない条件（例えば、「銀行口座の残高はマイナスにならない」など）を定義し、分断時もその条件が破られないように操作を制限します。
矛盾の解消: 意図的に矛盾を許容した場合（例えば、飛行機のオーバーブッキングのように）、後でそれをどう解消するか（補償金を支払う、フライトを振り替えるなど）のビジネスロジックを準備しておくことが重要です。
CP (一貫性 > 可用性) の代表：Cloud SQL & Spanner
これは「データの正確さが何よりも大事！」という考え方のグループです。
-
Cloud SQL (HA: High Availability構成): リージョン内のゾーンが分断された場合、「矛盾したデータを返すくらいなら、数分間サービスを止めてでも、正しい状態に復旧する！」という選択をします。これがフェイルオーバーです。小規模ながらも、非常にわかりやすいCPシステムですね。
-
Cloud Spanner: 地球規模で「データの矛盾は絶対に許さない」という強い意志を持っています。その上で、独自の技術（原子時計とか）を駆使して、可用性を極限まで高めています。しかし、大規模な分断が起きてデータの合意形成（クォーラム）が取れない場合は、やはり一貫性を守るために書き込みをエラーにします。つまり、究極的に洗練されたCPシステムというわけです。
AP (可用性 > 一貫性) の代表：Cloud Bigtable
次に「どんな時でも、とにかくリクエストに応え続けるのが使命！」という考え方のグループです。GCPでは、Cloud Bigtableがその代表格です。
アーキテクチャとCAP定理の挙動
Bigtableは、IoTのセンサーデータや分析ログなど、超大量のデータを高速に書き込み・読み込みするために設計されたNoSQLです。
- 整合性モデル: Bigtableの整合性は、基本的に結果整合性 (Eventual Consistency) です。
-
AP的な挙動:
- あるクライアントがBigtableのあるノードに新しいデータを書き込みます。
- そのデータがクラスタ内の全ノードにコピーされるには、ほんのわずかな時間（ミリ秒単位）がかかります。
- もし、その瞬間に別のクライアントがまだコピーされていないノードにデータを読み取りに行くと、システムは古いデータを返します。
これは、一貫性
🔵 PCA試験における位置づけ:
大量の書き込みスループットが求められ、かつ、最新のデータがミリ秒単位で反映されなくても問題ないユースケース（例：IoTデータ収集、時系列分析、広告配信のバックエンドなど）で最適な選択肢となります。
CA (一貫性 & 可用性) について
「じゃあ、究極のCAシステムは？」という最後の疑問。
Brewerの指摘の通り、現実の分散システムにおいて、純粋なCAは存在しないと考えられています。
なぜなら、クラウド上で動くDBは、複数のサーバーやネットワーク機器から構成される分散システムであり、ネットワーク分断（P）の可能性をゼロにはできないからです。そして、CAP定理が示す通り、Pを許容した瞬間にCとAはトレードオフの関係になります。
理論上、ネットワークから完全に切り離された単一のマシンで動くDBだけがCAと言えますが、それはクラウドサービスが提供する価値（スケーラビリティや耐障害性）とは相容れません。
「Spannerは実質CAでは？」と聞かれることもありますが、前述の通り、Spannerはあくまで極限まで可用性を高めたCPシステムと理解するのが正確かなと思います。
まとめ：PCA試験に向けたDB選択フロー
CAP定理を理解すると、GCPのDBを以下の様なフローで考えられるようになります。
-
あなたのアプリは、データの強い一貫性が必要ですか？それとも可用性/スループットが最優先ですか？
-
A:「強い一貫性！」が最優先の場合 (CPを選択)
- アプリは単一リージョンで動きますか？ → Cloud SQL
- グローバル展開が必要で、世界中で一貫したデータが必要ですか？ → Cloud Spanner
-
B:「可用性/スループット！」が最優先で、結果整合性でOKな場合 (APを選択)
- 超大規模なデータ（テラ〜ペタバイト級）を扱いますか？ → Cloud Bigtable
-
このシンプルな判断軸こそ、PCA試験のシナリオ問題でDBを選択する際の強力な武器になります。それぞれのサービスが
最後に、CPA定理における、上記３サービス（Cloud SQL, Spanner, Bigtable）を（冒頭でも紹介したものですが）図として与えておきます！
Discussion