こんにちは。Cloud Spannerの世界へようこそ。
大規模なシステムを支える「最強のデータベース」という噂を聞いて、少し緊張しているかもしれませんね。でも大丈夫。Spannerは、あなたのシステムの頼もしい相棒になります。
今日は、Spannerを扱う上で避けては通れない、でも一番大切な「トランザクションの冪等性（べきとうせい）」についてお話しします。難しそうな言葉ですが、日常の例えを使えばとてもシンプルですよ。
—
「冪等性」って、結局なんなの？
一言でいうと、「何度同じことをしても、結果が同じであること」です。
たとえば、自動販売機でボタンを押してジュースを買う場面を想像してください。
ボタンを押したのに反応がない。不安になったあなたは、もう一度ボタンを押しました。
- ダメなパターン： 2回ボタンを押したせいで、ジュースが2本出てきて、お金も2回分引き落とされた。
- 良いパターン（冪等性がある）： 1回目にすでに処理が始まっていたら、2回目にボタンを押しても「ただの空打ち」として無視してくれる。結果、ジュースは1本、お金も1回分。
データベースの世界でも同じです。「通信がちょっと不安定だから、もう一回送っちゃえ！」という再試行が起きたとき、データが二重に書き込まれてしまったら大変ですよね。Spannerでは、この「二重事故」を未然に防ぐ設計が不可欠なのです。
—
なぜSpannerで「再試行」が起きるのか？
Spannerは世界中に散らばったサーバーを束ねて動いています。そのため、たまに「今、ネットワークが混んでるから、もう一回やり直してくれない？」と、システム側からお願いされることがあります。これを「アボート（中断）」と呼びます。
このとき、アプリ側で「あ、失敗したんだな。じゃあもう一回送ろう」と自動的にやり直す仕組みを作るのですが、その時に「さっき送ったデータ、本当に届いてなかったっけ？」と確認する工夫が必要になるのです。
—
二重更新を防ぐ「魔法の杖」：ユニークID
では、どうやって「これはさっきの処理のやり直しだ」と見分けるのでしょうか？
一番簡単な方法は、処理ごとに「一意なID（注文番号のようなもの）」を付けておくことです。
これを「べき等性キー」と呼びます。
実装のイメージ（概念的なコード）
— ユーザーの残高を更新する例
— 処理ID: ‘txn_2023_10_27_001’ をキーとして使います
— 1. まず、処理履歴テーブルにこのIDがあるか確認する
— もしあれば、それは「前回の再試行」なので何もしない
SELECT count() FROM processed_transactions WHERE txn_id = ‘txn_2023_10_27_001’;
— 2. なければ、新しい処理として実行する
— 更新と同時に、処理IDを履歴テーブルに書き込む（これで二重実行が防げる！）
INSERT INTO processed_transactions (txn_id) VALUES (‘txn_2023_10_27_001’);
UPDATE accounts SET balance = balance – 100 WHERE user_id = ‘user_a’;
このように、「データ更新」と「処理済みフラグの記録」をひとつのパッケージ（トランザクション）としてまとめてしまうのが、Spannerにおける鉄則です。
—
初学者が押さえておくべき3つのポイント
1. クライアントライブラリを信じる：
Googleが提供しているライブラリは、内部で自動的に再試行をしてくれます。なので、あなたのコードは「何度実行されても結果が変わらない（冪等である）」ように書くことだけを意識すればいいのです。
2. 「処理ID」をアプリで生成する：
リクエストが来るたびに、アプリ側で一意なID（UUIDなど）を発行し、それをデータベースの「処理済みテーブル」に記録するようにしましょう。
3. 完璧を求めすぎない：
最初は難しく感じるはずです。まずは「この処理は、失敗したらもう一度実行されても大丈夫かな？」と自問自答する癖をつけるだけで、あなたはもう一人前のSpannerエンジニアへの第一歩を踏み出しています。
—
まとめ
Cloud Spannerは、世界中のデータを安全に守る堅牢な金庫のようなものです。その金庫にアクセスするあなたのルール（冪等性）さえしっかりしていれば、どんなにシステムが巨大化しても、データが壊れることはありません。
「何度叩いても、正しい結果しか返さない」。
この美学こそが、エンジニアとしての信頼を築く鍵になります。
ここをクリアしたあなたは、もうSpannerの基本をしっかりとマスターできています。自信を持って、次のステップへ進んでくださいね！応援しています。
コメント