やあ。Cloud Spannerという、地球規模でデータを扱う巨大なシステムの世界へようこそ。
多くのエンジニアが「Spannerは難しい」と身構えるけれど、実はその本質は非常にシンプルだ。今日はその中でも、特に現場で重宝される「悲観的ロック」という概念について話そう。
専門用語を並べるのは簡単だけど、今日は君が明日から自信を持って設計できるよう、日常の例え話を交えて紐解いていくよ。準備はいいかな？
—
1. なぜ「悲観的」なんて名前なのか？
想像してみてほしい。君が超人気の行列ができるパン屋さんの店長だとする。
もし、最後の1個のパンをめぐって、3人のお客さんが同時に「それ、ちょうだい！」と言い出したらどうなる？ 混乱するよね。
- 楽観的なやり方： 「とりあえず全員に注文させて、後で誰が一番早かったか確認しよう。重複したら一人は諦めてもらう」
- 悲観的なやり方： 「誰かがパンに触れる前に、まず『私が今から選ぶから、誰も触らないで！』とエリアを確保（ロック）してから、ゆっくり中身を確認する」
Cloud Spannerにおける「悲観的ロック」は、まさにこの後者だ。「競合が起きるかもしれない」と悲観的に予測して、あらかじめ権利を確保する。 これにより、トランザクションの失敗という悲劇を未然に防ぐんだ。
2. Cloud Spannerでの実装イメージ
Spannerでこれを行うには、SQLの文末に `THEN RETURN` や、読み込み時にロックを明示するヒントを添えるのが定石だ。今回は一番直感的な「読み込み時にロックをかける」方法をコードで見てみよう。
— 悲観的ロックをかけてデータを読み込むクエリ
— FORCE_LOCKを指定することで、このデータが読み込まれた瞬間、
— 他のトランザクションからの書き込みを「待機」させる権利を得る。
SELECT
balance
FROM
Accounts@{FORCE_LOCK=TRUE}
WHERE
account_id = ‘user_123’;
このクエリを投げた瞬間、君はデータベース上のその行を「予約席」として確保したことになる。他の誰かが同じ行を更新しようとしても、君が処理を終えて席を立つ（コミットする）まで、彼らは門前払いを食らうことになるんだ。
3. この技術を使うべき「タイミング」
「じゃあ、全部ロックすればいいじゃないか？」と思うかもしれないね。でも、それはNGだ。
想像してごらん。パン屋の入り口で君がずっと立ち止まっていたら、他のお客さんはパンを買えない。ロックは「強力な武器」だが、使いすぎるとシステム全体の流れを止めてしまう「足かせ」にもなるんだ。
こんな時に使うのがベストだ：
- 競合が確実に起きるとわかっている時： 在庫が少ない商品、最後の1枚のチケット販売など。
- 失敗のコストが極めて高い時： 銀行の残高計算など、一度のミスも許されない処理。
逆に、SNSの「いいね」ボタンのような、一瞬のズレが許容される場所には使わない。それが賢いエンジニアの判断基準だ。
4. 伝説のアーキテクトからのアドバイス
君がこの「悲観的ロック」をマスターすれば、Cloud Spannerのトランザクション管理という、最も難解で、最も面白いパズルの一部を解いたことになる。
最後に一つだけ覚えておいてほしい。
「ロックをかけたら、必ず速やかに処理を終わらせてロックを解放すること」。
システムは「誰が一番早く処理を終えてくれるか」を常に待っている。君が書くコードがスマートであればあるほど、システム全体が滑らかに動き出すんだ。
—
どうだい？ 「悲観的ロック」が単なる技術用語ではなく、システムを守るための「思いやり」のようなものだと感じられたかな。
ここをクリアした君なら、もうCloud Spannerの基本はバッチリマスターしたも同然だ。次に進む時は、ぜひ自信を持って挑んでほしい。また何かあればいつでも聞きに来てくれ。君の挑戦を応援しているよ。
コメント