こんにちは！Cloud Spannerの世界へようこそ。
チーフアーキテクトの私です。
「Googleが使っている世界規模のすごいデータベース」と聞くと、なんだか難しそう、自分にはまだ早いかな……なんて身構えていませんか？ 大丈夫、安心してください。今日は、Cloud Spannerの心臓部である「データレプリケーションとPaxos（パクソス）グループ」という、一見すると呪文のような仕組みを、驚くほど身近な例え話で解き明かしていきます。
ここさえクリアすれば、Cloud Spannerの「なぜ止まらないのか」「なぜデータが消えないのか」という本質が手に取るように分かりますよ。さあ、一緒に扉を開けてみましょう！
—
1. タブレットって何？（お引越しのダンボール箱の例え）
Cloud Spannerを語る上で欠かせないのが「タブレット」という言葉です。タブレット型端末（iPadなど）のことではありません。データベースの「データのかたまり」を指す言葉です。
想像してみてください。あなたは今、ものすごい量の荷物（データ）を持って大引っ越しをしようとしています。全部をひとつの大きなダンボールに詰め込もうとしたら……重すぎて持ち上がりませんよね？
だから、Cloud Spannerは、その巨大なデータを「使いやすい大きさに切り分けて、いくつものダンボール箱（タブレット）」に詰めて管理しています。
- ユーザーAのデータはこの箱
- ユーザーBのデータはあの箱
というふうに綺麗に小分けされているわけです。
—
2. Paxosグループって何？（みんなで合意を取る「お留守番チーム」の例え）
さて、このダンボール箱（タブレット）、ただ自分の足元に置いておくだけでは不安ですよね？ 火事になるかもしれないし、猫が引っ掻くかもしれない。
そこでCloud Spannerは、「ひとつのダンボール箱につき、世界中のあちこちにいる5人の仲間（サーバー）でチームを作って、みんなでお守りする」というルールを作りました。このチームのことを、専門用語で「Paxos（パクソス）グループ」と呼びます。
難しそうな名前ですが、やっていることはとてもシンプルです。この5人のチームには、こんなルールがあります。
1. リーダーを1人決める（リーダー選出）
2. みんなでノートを共有する（ログレプリケーション）
日常の例で考えてみましょう。
いま、仲良し5人組（A, B, C, D, Eさん）で、共同の「お小遣い帳（ノート）」を管理しています。誰かが「100円使いました」と書き込むとき、どうするべきでしょうか？
勝手に1人が書き換えたら「聞いてないよ！」って喧嘩になりますよね。だから、みんなで集まって、
「じゃあ今回はAくんがリーダーね！ Aくんがみんなの意見を聞いて、ノートに書き込む係をやろう！」
と決めます。これがリーダー選出です。
—
3. データの書き込みは、どうやって行われるの？（ログレプリケーションのフロー）
では、実際にユーザーから「データを保存して！」と言われたとき、このPaxosグループの裏側で何が起きているのか、その美しいフローを覗いてみましょう。
フロー1：リーダーへの依頼
ユーザーが「私の名前を『田中』に変更して！」とお願いを送ります。このお願いは、まずPaxosグループのリーダーに届きます。
フロー2：みんなへの相談（多数決の魔法）
リーダーは「田中さんに名前を変えるってさ！ みんな、この内容でノートに書いていい？」と、他のメンバー（フォロワー）たちに手紙を送ります。
ここで面白い（そして賢い）のが、「全員が返事をしなくてもいい」というルールです。5人中、過半数である3人以上が「OK！ その内容で進めよう！」と返事をすれば、それで決定になります。
たとえ遠く離れた場所にいる1人が電波の不具合で寝ていたとしても、チーム全体の仕事は止まりません。これが、Cloud Spannerが驚異的な「止まらない強さ」を持つ秘密です。
フロー3：ノートへの記録（コミット）
過半数から「OK！」をもらった瞬間、リーダーはみんなの共有ノートに「田中さんに変更」とペンでガッチリ書き込みます。この瞬間のことを「コミット（確定）」と呼びます。
これが、いわゆるログレプリケーションの正体です。みんなが同じノートのコピーを持っていて、リーダーの号令のもとで全く同じ順番に出来事を書き込んでいく。だから、どこかのサーバーが突然隕石に直撃されて跡形もなく消え去っても、残りのメンバーのノートを見れば、データは1ミリも失われていないというわけです。
—
4. もしリーダーが倒れたら？（緊急事態のイケメン采配）
「もし、その頼みの綱のリーダーが、ある日突然、電源がプチッと切れて倒れてしまったらどうなるの？」
そんな不安がよぎったあなた、鋭いですね！ チーフアーキテクトとして、その疑問に満点の笑顔でお答えしましょう。
リーダーが倒れると、残されたメンバー（4人）はこう言います。
「あれ？ リーダーからしばらく連絡がないぞ。大変だ、緊急事態だ！」
そこで彼らはすぐに集まって、「次のリーダー選挙」を始めます。
立候補したメンバーの中から、一番通信がスムーズで信頼できそうな人を、数秒（あるいはミリ秒の世界！）で新しいリーダーに選びます。
新リーダーが決まると、みんなのノートを見比べて、情報のズレがないかを一瞬でピシッと揃え、何食わぬ顔でサービスの継続を再開します。
ユーザーから見ると、「あれ？ ほんのちょっとだけ通信が待たされた気がするけど、エラーにはならずにちゃんと動いたな」という感覚。これが、Cloud Spannerの圧倒的なレジリエンス（復元力）です。
—
まとめ：ここをクリアすれば、もう怖くない！
お疲れ様でした！ いかがでしたでしょうか？
今日の話をギュッとまとめてみましょう。
1. タブレット ＝ データを小さく切り分けたダンボール箱
2. Paxosグループ ＝ その箱を5人一組でお守りする「チーム」
3. リーダー選出 ＝ チームのまとめ役を民主的に決める仕組み
4. ログレプリケーション ＝ メンバーみんなで同じノートに同じ順番で記録をつけ、データを絶対に失わないようにする仕組み
これさえ頭の片隅に置いておけば、Cloud Spannerが裏側でどれほどエレガントで、かつ泥臭く堅実にデータを守っているかがイメージできるはずです。
ここをクリアしたあなたなら、もうCloud Spannerの基本はバッチリマスターできていますよ！ 自信を持って次のステップへ進んでください。それではまた、次のアーキテクチャの旅でお会いしましょう！
コメント