Cloud Spanner：マルチステートメントトランザクションという名の「分散の深淵」
Cloud Spannerを単なる「強力なRDB」と呼ぶ者は、その真価を1％も理解していない。真のアーキテクトにとって、Spannerは「地球規模の分散システムにおける、同期の幻想を物理的に実現した奇跡」である。
今回は、ビジネスロジックの要である「マルチステートメントトランザクション」の深層にメスを入れる。一般的なドキュメントには書かれていない、この機能が内部でどのような物理的苦闘を経て整合性を担保しているのかを解説する。
—
1. トランザクションの「場所」を意識せよ
Cloud Spannerのマルチステートメントトランザクションにおいて、我々が発行するSQLは、物理的に離れた複数のSpannerノード（Split）を跨ぐ可能性がある。
ここで重要なのは、「トランザクションコーディネータ（TC）」の役割だ。
Spannerは、トランザクションが開始されたノードをコーディネータに指名する。このTCが、書き込み先のすべてのSplitに対して2相コミット（2PC）プロトコルを指揮する。
- 極限の知見: トランザクション内で触れるSplitが地理的に分散している場合、ネットワークレイテンシがそのままコミットレイテンシに直結する。特に、読み取り専用のクエリをトランザクションの最初に入れてしまうと、TCの選定やロック保持期間が肥大化し、システム全体の排他制御のボトルネックとなる。「必要な書き込みは最小のスコープに集約する」。これが分散DBにおける鉄則だ。
2. 内部メカニズム：Paxosとロックの相克
Spannerのトランザクションは、単なる2PCではない。各Splitにおいて、Paxosグループによるコンセンサスが裏で走っている。
1. ロックの獲得: トランザクション中のSQL実行時、各Splitのリーダーノードで排他ロックを確保する。
2. Paxosログへの書き込み: コミット時、変更は即座にデータベースに適用されるのではなく、まずはPaxosログとしてジャーナルされる。
3. レプリケーション: 多数決によりコミットが承認され、初めて状態が確定する。
このプロセスにおいて、開発者が無視しがちなのが「準備段階（Prepare）」の重みだ。マルチステートメントである以上、最後の`COMMIT`が呼ばれるまで、ロックは保持され続ける。もし、アプリケーション層で重い計算を挟んだ状態でトランザクションを開きっぱなしにすれば、そのSplitの書き込みスループットは瞬時に氷河期を迎える。
3. メモリ最適化と「アンチパターン」の排除
マルチステートメントトランザクションを扱う際、メモリを食いつぶす最悪の挙動がある。それは「巨大な中間結果セットの保持」だ。
— アーキテクトの警告：これは危険なパターン
BEGIN TRANSACTION;
— 数百万行をフェッチするクエリ
SELECT FROM massive_table WHERE status = ‘PENDING’;
— この後、複雑なビジネスロジックをアプリケーション側で回す
— …
UPDATE massive_table SET status = ‘PROCESSED’ WHERE id = …;
COMMIT;
このコードの問題は、SQLの実行結果をメモリに展開している間、当該行へのロックが「Shared Lock」から「Exclusive Lock」へ昇格するまでの間、ロック待ちのキューが爆発的に増えることだ。
最適化の解:
マルチステートメントを使うなら、「読み取りは極力シンプルに、更新はインデックスを活用したピンポイントなクエリに絞る」こと。メモリを浪費する巨大なクエリは、トランザクションの外側で処理し、トランザクション内では「IDの特定」と「最小限の更新」のみを行うのが、Spannerのパフォーマンスを引き出す作法だ。
4. 伝説のアーキテクトからの提言
Spannerにおけるトランザクションの設計とは、「同期のコストをどこで支払うか」というトレードオフの芸術である。
もしあなたが100ms以内のレスポンスを求めているなら、トランザクション内のステートメント数は「3つ以下」に抑えるべきだ。それ以上の複雑なロジックを要求されるのであれば、それはデータベース側で解決すべき問題ではなく、イベント駆動型のアーキテクチャや、補償トランザクション（Sagaパターン）への移行を検討すべきタイミングである。
まとめ
- TCの場所を意識せよ: 物理的に遠いSplitへのアクセスは、コミットコストを跳ね上げる。
- ロックの寿命を最短に: トランザクション内のSQLは、計算ではなく「更新」に特化させる。
- 計測せよ: `Cloud Monitoring`で `Spanner.googleapis.com/transaction/lock_wait_time` を監視し、自分の書いたコードがシステムにどれだけの「静寂」を強いているかを確認せよ。
Cloud Spannerは、魔法の箱ではない。我々エンジニアがその物理的な制約を理解し、敬意を払った時に初めて、その真の性能を解放してくれる。次回の開発では、ぜひこの「ロックの重み」を感じながらトランザクションを組んでみてほしい。
コメント