Cloud Spannerの「トランザクション」って何？ 2PCという名の「みんなで決める」仕組みを、お祭りに例えて解説！
やっほー！ Cloud Spanner の世界へようこそ！
今日は、Cloud Spanner の心臓部とも言える「トランザクション」について、とびっきり分かりやすく解説しちゃうよ！ 特に、たくさんのコンピューターが協力して「みんなで決める」ための、ちょっと特殊なルール、「2PC（ツーフェーズ・コミット）」っていう仕組みに焦点を当てるんだ。
「え、2PC？ なんか難しそう…」って思った？ 大丈夫、大丈夫！ 心配しないで！ 今日は、みんなが日常で経験する「お祭り」に例えながら、この2PC の仕組みを、まるで秘密基地の秘密会議みたいに、ワクワクしながら紐解いていこう！
ここをクリアすれば、Cloud Spanner の基本はバッチリマスターできるから、安心してついてきてね！
そもそも「トランザクション」って、なんで大事なの？
「トランザクション」って言葉、よく聞くかもしれないけど、一体何をしているんだろう？
例えるなら、お祭りの屋台で「焼きそば」を買う時を想像してみて。
1. 注文する （「焼きそば一つください！」）
2. 作る （お店の人が一生懸命焼いてくれる）
3. お金を払う （「はい、500円です」）
4. 受け取る （「はい、どうぞ！」）
この一連の流れ、全部うまくいくと、あなたは美味しい焼きそばをゲットできるよね？
もし、途中で何か問題が起きたらどうなる？
- お金を払ったのに、焼きそばが出てこない…
- 焼きそばは作ってもらったのに、お金を払うのを忘れちゃった…
こんなことになると、困っちゃうよね。
「トランザクション」っていうのは、こういう「一連の作業を、全部成功させるか、一つも成功させないか、どっちかにきっちり決める」ための仕組みなんだ。
つまり、データの整合性を保つための、とっても大事なルールなんだよ。
Cloud Spanner が「みんなで決める」理由：分散システムのお約束
Cloud Spanner は、世界中のたくさんのデータセンターにデータが分散されている、とっても賢いデータベースなんだ。
例えるなら、大きなお祭りを、たくさんの町で同時開催しているようなイメージかな。
- 東京の町で「焼きそば」を買いたい人もいる。
- 大阪の町で「たこ焼き」を買いたい人もいる。
しかも、この「焼きそば」と「たこ焼き」は、「セットで買う」と、ちょっとだけ割引になる、なんて特別なキャンペーンをやっていたとしよう！
この場合、
- 東京で焼きそばを買った人が、大阪でたこ焼きも買ったら、割引が適用される。
- 東京で焼きそばだけを買った人は、割引は適用されない。
こんな風に、複数の場所（町）で、同時に、かつ、正確に何かが行われる必要があるんだ。
Cloud Spanner も、たくさんのコンピューター（サーバー）が協力して動いているから、みんなで「よし、このデータはこう変更しよう！」って決める時に、「みんなの足並みを揃える」必要がある。
そのための、ちょっと特別なルールが「2PC（ツーフェーズ・コミット）」なんだ。
2PC（ツーフェーズ・コミット）って、どんな仕組み？：お祭りの「最終決定会議」
2PC は、文字通り「2つの段階（フェーズ）」で、みんなで合意形成をする方法なんだ。
例えるなら、お祭りの最終決定会議だと思ってくれると分かりやすいかも！
登場人物:
- トランザクションコーディネーター（調整役さん）: お祭りの責任者。みんなに指示を出して、最終的に「やるぞ！」「やらないぞ！」を決める人。Cloud Spanner の場合は、特定のサーバーがこの役割を担うんだ。
- 参加者（お店屋さんたち）: 実際に作業をする人たち。ここでは、データを変更するデータベースサーバーのこと。
会議の流れ（2PC の2つのフェーズ）
フェーズ1：「準備はいい？（Prepare Phase）」
1. 調整役さん、指示を出す！
「みんな、聞いて！ 今から、このデータ（例えば、お祭りのチケットの枚数）を更新したいんだけど、みんな準備はできてる？」
（Cloud Spanner では、トランザクションの実行を始める前に、参加するサーバーに「このトランザクションを実行できますか？」と問い合わせる。）
2. お店屋さんたち、返事をする！
- 「OK！ 準備できました！」 (Vote Yes)
「はい、調整役さん！ この変更なら、うちのデータ（お店の在庫）をちゃんと更新できますよ！ 準備万端です！」
（参加サーバーは、データ変更を実行する準備ができたことを調整役さんに伝える。）
- 「ちょっと待って…」 (Vote No)
「すみません、調整役さん！ 今、別の注文が殺到していて、この変更まで同時に行うのはちょっと難しいかもしれません…」
（参加サーバーは、何らかの理由でデータ変更ができない、またはリスクがあると判断した場合に、その旨を伝える。）
ここでのポイント！
- この段階では、まだ実際にデータは変更しないんだ。あくまで、「変更できるかどうか」の確認だけ。
- みんなが「OK！」って言ってくれたら、調整役さんは「よし、みんな準備できたみたいだ！」って安心する。
- もし一人でも「ちょっと待って…」って言ったら、調整役さんは「あ、じゃあ今回はこの話は中止だね！」って、みんなに伝えるんだ。
フェーズ2：「最終決定！（Commit Phase）」
全員が「OK！」って言った場合（フェーズ1で全員が Vote Yes だった場合）
1. 調整役さん、最終決定！
「みんな、ありがとう！ 全員準備OKとのこと！ よーし、じゃあ、みんなで一斉に、このデータ（チケットの枚数）を更新しちゃおう！ 実行（Commit）！」
（調整役さんは、参加サーバーに「トランザクションを実行しなさい！」という最終決定を通知する。）
2. お店屋さんたち、実行！
「了解！ チケットの枚数を更新します！」
（各参加サーバーは、受け取った指示に従って、実際にデータを更新する。）
3. みんな、完了報告！
「更新完了しました！」
（参加サーバーは、更新が完了したことを調整役さんに報告する。）
もし一人でも「ちょっと待って…」って言った場合（フェーズ1で誰かが Vote No だった場合）
1. 調整役さん、最終決定！
「みんな、残念！ 一人でも準備が難しそうなので、今回はこのトランザクションは中止（Abort）でお願いします！」
（調整役さんは、参加サーバーに「トランザクションを中止しなさい！」という指示を出す。）
2. お店屋さんたち、中止！
「了解！ 中止します！」
（各参加サーバーは、それまで準備していた変更を元に戻す、あるいは何もしなかった状態を維持する。）
ここでのポイント！
- 全員が「OK」なら、全員で実行（Commit）。
- 誰か一人でもNGなら、全員で中止（Abort）。
- この「全員で同じ結果になる」っていうのが、2PC の一番のキモなんだ！
障害発生！：会議中に電源が切れちゃったらどうなる？
「でも、調整役さんやお店屋さんが、途中で倒れちゃったらどうなるの？」って思った？
そう、これが分散システムで一番難しいところなんだ。
もし、会議の途中で…
- 調整役さんが倒れたら…
「え！ 調整役さんが、最終決定を言う前に倒れちゃった！ みんな、どうすればいいの？ 実行していいの？ それとも中止？」
（参加サーバーは、調整役さんからの最終決定を受け取れていない状態になる。）
- お店屋さんの一人が倒れたら…
「調整役さんは『実行！』って言ったのに、このお店屋さんだけ返事が来ないぞ？ 他のお店屋さんは実行しちゃっていいの？」
（一部の参加サーバーは、指示を受け取って実行できたが、他の参加サーバーは指示を受け取れていない、あるいは実行できていない状態になる。）
こんな風に、「みんなの足並みが揃わない」状況が発生してしまう可能性があるんだ。
障害発生時の「状態復旧」：記憶喪失からの復活！
Cloud Spanner は、こういう困った状況にならないように、とっても賢い仕組みを持っているんだ。
もし、調整役さんや参加サーバーが倒れても、「誰が、いつ、どんな状態だったか」を、「ログ」としてしっかり記録しているんだ。
例えるなら、会議の議事録みたいなものだね。
- 「調整役さんは、フェーズ1で全員から『OK』をもらった後、フェーズ2の『実行！』という指示を出す直前に倒れた。」
- 「参加者Aは、『OK』の返事をした後、『実行！』の指示を受けて、データを更新した。」
- 「参加者Bは、『OK』の返事をした後、調整役さんからの『実行！』の指示を受け取る前に倒れた。」
こういった情報が、しっかり記録されているんだ。
そして、倒れたサーバーが復活したら…
1. 「議事録」を確認！
「あれ？ 私、途中で倒れちゃったみたいだ… ちゃんと会議の続きを記録してるかな？」
（倒れたサーバーは、起動後に、自分が書き残したログや、他のサーバーが書き残したログを確認する。）
2. 「みんなの状況」を把握！
「なるほど、調整役さんは途中で倒れたけど、他の参加者は『実行』まで進んでたんだな。」
（ログを元に、トランザクションの全体の状態を把握する。）
3. 「正しい状態」に復帰！
- もし、全員が「実行（Commit）」できた状態なら、自分も「実行」を完了させる。
- もし、誰か一人でも「中止（Abort）」になっていた状態なら、自分も「中止」に戻して、それまでの変更を元に戻す。
こうやって、たとえ途中で誰かが倒れても、「みんなで同じ結果（実行したか、中止したか）にする」という、トランザクションの「約束」を守り通すんだ。
この「ログ」による記録と、復活後の「状態確認・復旧」の仕組みがあるおかげで、Cloud Spanner は、たくさんのコンピューターがバラバラに動いていても、データの整合性をしっかり保つことができるんだよ！
まとめ：Cloud Spanner の「2PC」は、みんなの「信頼」で成り立っている！
今日のまとめだよ！
- トランザクション は、一連の作業を「全部成功」か「全部失敗」にきっちり決める、データの安全を守る仕組み。
- Cloud Spanner のような分散データベースでは、たくさんのコンピューターが協力するので、「2PC（ツーフェーズ・コミット）」という、みんなで合意形成するルールが使われる。
- 2PC には、「準備はいい？（Prepare）」と「最終決定！（Commit）」の2つのフェーズがある。
- 全員が「OK」なら実行（Commit）、誰か一人でも「NG」なら中止（Abort）。これが大事！
- 障害が発生しても、ログによる記録と、復旧プロセスによって、データの整合性を保つ。
この2PC の仕組みは、一見複雑に見えるかもしれないけど、基本は「みんなで協力して、間違いなく決める！」っていう、すごく人間らしい考え方なんだ。
Cloud Spanner は、この「みんなで決める」という原理を、高度な技術で実現している、まさに「信頼できる」データベースなんだよ。
どうかな？ Cloud Spanner のトランザクションの基本、掴めたかな？
もし分からなかったら、何度でも読み返してみてね！ きっと、もっともっと Cloud Spanner が好きになるはずだよ！
これからも、一緒に Cloud Spanner の奥深い世界を探求していこうね！
コメント