こんにちは！Cloud Spannerの世界へようこそ。
チーフアーキテクトの私だ。
今回は、Cloud Spannerの心臓部であり、データが世界中で安全に、かつ途切れることなく生き続けるための秘密である「レプリカ（Replica）」について話をしよう。
「データベースの複製って言われても、なんだか難しそう……」
「マスターとスレーブの違いとか、頭がごちゃ混ぜになるよ……」
そんな不安を抱えている君も安心してほしい。今回は専門用語を極力封印し、誰もが直感的にイメージできる「ある身近な例え」を使って、レプリカの本質を解き明かしていく。ここをクリアすれば、Cloud Spannerの基本はバッチリマスターできるよ。それじゃあ、いってみよう！
—
1. レプリカってなに？ —— 「超重要ノートの回覧係」に例えてみよう
いきなりだが、君が学校や職場で、絶対に無くしてはいけない、そしてみんなで最新情報を書き込み合わないといけない「超重要な一冊のノート」を管理していると想像してほしい。
もし、そのノートを1冊だけで、一つの机の引き出しにしまっておいたらどうなるだろう？
- その机の持ち主が休んだら、誰もノートを見られない（＝ダウンタイム）。
- うっかりコーヒーをこぼして汚してしまったら、情報が消えてしまう（＝データ消失）。
- みんなが一斉に「見せて！」と群がったら、大パニックになる（＝性能の限界）。
これを防ぐためにどうするか？
そう、「全く同じ内容が書かれたノートのコピーを、信頼できる仲間たち何人かで手分けして持っておく」よね。
この「コピーを保持するノートの分身たち」こそが、Cloud Spannerにおける「レプリカ」だ。
Cloud Spannerは、世界中のユーザーが同時にアクセスしてもビクともしない怪物級のデータベースだが、その裏側では、このレプリカたちがチームを組んでデータを守り抜いているんだ。
—
2. レプリカたちのチームワーク —— 「Paxos（パクソス）グループ」の秘密
Cloud Spannerでは、このレプリカたちがただバラバラに存在しているわけではない。通常、5つ（あるいはそれ以上）のレプリカが1つのチームを組んでいる。
このチームの名前を「Paxos（パクソス）グループ」と呼ぶ（名前は覚える必要はない！）。
このチームには、役割が綺麗に分かれている。
1. リーダーレプリカ（学級委員長・代表者）
- チームの司令塔。ユーザーからの「データを書き込んで！」「データを教えて！」というリクエストを最初にすべて受け付ける。
2. 参加者レプリカ（副委員長・書記たち）
- リーダーが「みんな、新しい書き込みがあったよ！ 同じようにノートを書き換えて！」と言ったとき、それに同意して自分のノートも書き換える仲間たち。
ここでCloud Spannerのめちゃくちゃクールなポイントを教えよう。
データを書き込むとき、リーダーは勝手にペンを走らせるわけじゃない。「チームの過半数（5人チームなら3人以上）が『OK、ウチのノートも書き換えたよ！』と返事をした瞬間」にだけ、書き込みが完了したとみなされるんだ。
だから、たとえリーダーが突然宇宙人に連れ去られても（サーバーが故障しても）、残された仲間たちが「最後に何が書き込まれたか」を完全に把握している。だから、データが消えることは絶対にない。これが、Cloud Spannerが止まらない理由の正体さ。
—
3. なぜCloud Spannerのレプリカは最強なのか？
世の中には色々なデータベースがあるけれど、Cloud Spannerのレプリカ構成が「世界最高峰」と言われるのには理由がある。
① 自動で地球規模の分散配置ができる
レプリカたちは、ただ同じ部屋の棚に並んでいるわけじゃない。東京と大阪、あるいはアメリカやヨーロッパといった、物理的に遠く離れた場所に散らばって配置されることが多い。
これにより、万が一東京で大規模な災害が起きてデータセンターが機能しなくなっても、別の地域のレプリカが瞬時に立ち上がり、「おっと、私がリーダーを引き継ぐよ」と何事もなかったかのようにサービスを継続できる（これを高可用性と呼ぶ）。
② 読み込み（参照）が爆速になる
「書き込み」はリーダーを通す必要があるけれど、「ちょっとデータを見せてよ（読み込み）」というリクエストであれば、近くにいる参加者レプリカが直接答えてもいいというルールがある。
世界中のユーザーが、自分の一番近くにいるレプリカから秒速でデータをゲットできる。だから、グローバル展開するサービスでも重くならないんだ。
—
4. 実務でのイメージ：コードや設定の裏側で何が起きているか？
Cloud Spannerを使うとき、僕たちは実際にSQLを書く。例えば、ユーザーのデータを取得するクエリはこんな感じだ。
— ユーザーテーブルから、IDが「user_001」の人の名前を取得するSQL
SELECT user_name
FROM users
WHERE user_id = ‘user_001’;
このたった1行の命令を君が投げたとき、Cloud Spannerの内部ではこんなドラマが起きている。
1. 最寄りのレプリカがリクエストを受け取る。
2. そのレプリカが最新のデータを持っているか確認し、スッと結果を返す。
3. もしデータを「更新」するクエリであれば、リーダーレプリカに話が通され、Paxosグループの仲間たちと「合意形成」の儀式がコンマ数秒で行われる。
僕たちエンジニアは、この複雑なレプリカの同期やリーダーの選挙の仕組みを、一切意識する必要がない。Cloud Spannerが全部裏側でやってくれる。これが、マネージドデータベースの最高に美しいところだ。
—
まとめ
どうだろう？ レプリカという言葉の裏にある「仲間たちとの信頼関係とチームワーク」がイメージできたかな？
- レプリカとは： 大切なデータを守るための「分身（コピー）」。
- Paxosグループ： レプリカたちが組むチーム。過半数の賛成がないと書き込みを認めない鉄壁のルールを持つ。
- メリット： サーバーが壊れても絶対に止まらない（高可用性）し、世界中のどこからでも高速にアクセスできる。
ここを理解していれば、Cloud Spannerのアーキテクチャの根幹はもうバッチリだ。自信を持って次のステップへ進んでほしい。
分からないことがあれば、いつでも僕のところへ聞きに来るといい。応援しているよ！
コメント