【入門編】トランザクションアボートの理由 – Cloud Spanner

やあ、よく来てくれました。Cloud Spannerの世界へようこそ。
私は長年、世界中の巨大なシステムをこのSpannerという「魔法のデータベース」で支えてきたアーキテクトです。

今日は、Spannerを使い始めたばかりの皆さんが必ず一度はぶつかる、そして少しだけ不安に思う「トランザクションのアボート（中断）」についてお話ししましょう。

「せっかく書いたプログラムが途中で止まってしまった！」と焦る必要はありません。実は、アボートはSpannerがあなたのデータを守るために一生懸命働いている「証」なのです。

この記事を読み終える頃には、あなたはアボートを恐れるどころか、「よしよし、Spannerがしっかり守ってくれているな」と微笑む余裕すら持てるようになっているはずですよ。

—

1. 「アボート」は失敗ではなく、究極の「優しさ」

まず、一番大切なことをお伝えします。
Spannerにおいて、トランザクションがアボートされるのは、「このまま進めると、データの整合性が壊れてしまう！」とSpannerが判断したからです。

例えるなら、Spannerは「超一流のレストランのホールマネージャー」です。
複数のお客さん（アプリケーション）から同時に注文が入ったとき、もし食材（データ）が最後の一つだったり、調理順序が狂って味が落ちそうになったりしたら、マネージャーは「申し訳ありません、もう一度最初から注文を伺い直してもよろしいでしょうか？」とスマートにお願いに来ます。

これがアボートです。無理やり料理を出して食中毒を起こす（データが壊れる）くらいなら、一度白紙に戻して、最高の結果を出し直す。これがSpannerの哲学なのです。

—

2. なぜアボートは起きるのか？ 3つの主な理由

アボートが起きる理由は、大きく分けて3つあります。日常の出来事に例えて見ていきましょう。

① データの取り合い（ロック競合）

これが最も多い理由です。
例えば、あなたと友人が「1冊しかない共有のノート」に同時に文字を書こうとしたと想像してください。

あなたが「今日の献立」を書こうとしている。
同時に、友人が「明日の予定」を同じ行に書こうとしている。

二人が同時にペンを動かしたら、文字が重なって読めなくなりますよね？
Spannerはこれを見つけると、どちらか一方に「ごめん、一旦ペンを置いて。相手が書き終わってからもう一度書いてね」と伝えます。これが競合によるアボートです。

② デッドロック（お互い譲れない状態）

これは少し複雑ですが、「2つの鍵と2つの宝箱」の話に例えられます。

Aさんは「銀の鍵」を持っていて、「金の宝箱」を開けたい。
Bさんは「金の鍵」を持っていて、「銀の宝箱」を開けたい。

お互いが「相手が鍵を貸してくれないと、私は宝箱を開けられないし、自分の鍵も渡さないぞ！」と意固地になっている状態です。このままでは永遠に時間が過ぎてしまいます。
Spannerはこれを見つけると、「このままだと日が暮れるので、一旦Aさん、あなたはお休みしてください」と強制的に中断させ、Bさんに道を通します。

③ ネットワークのまばたき（タイムアウトや一過性のエラー）

Spannerは世界中に分散したサーバーで動いています。
たまに、通信の途中で「あれ？返事が遅いな」ということが起きます。あまりに長く待ちすぎると全体の流れが止まってしまうので、「一旦リセットしてやり直しましょう」と判断することがあります。

—

3. 「アボート」が起きたらどうすればいい？

ここがSpannerの面白いところです。
実は、「アボートが起きたら、ただもう一度やり直す（リトライする）」。これだけで解決します。

Spannerのクライアントライブラリ（公式の道具箱）には、この「やり直し」を自動で行う機能が最初から備わっています。

Pythonでのイメージ例
from google.cloud import spanner

def update_data(transaction):
# ここにデータを読み書きする処理を書く
# もしここでアボートが起きても…
results = transaction.execute_sql(“SELECT …”)
transaction.execute_update(“UPDATE …”)

database.run_in_transaction という魔法の言葉を使うと、
Spannerが「アボートした？じゃあ自動でもう一回！」と
成功するまで（または限界まで）勝手にリトライしてくれます。
database.run_in_transaction(update_data)

エンジニアの皆さんは、「アボートは起こるもの。だから自動リトライに任せる」という心構えでいれば大丈夫です。

—

4. 診断のヒント：どうやって原因を見つける？

「最近、やけにリトライが多いな？」と感じたら、Google Cloudのコンソール（管理画面）を覗いてみましょう。

Query Stats（クエリ統計）: どの命令が時間を食っているか、犯人探しができます。
Lock Stats（ロック統計）: どのデータで「取り合い」が起きているか一目瞭然です。

もし特定の行にアクセスが集中しているなら、それは「人気すぎるレジ」のようなものです。レジを分散させる（データの設計を少し変える）だけで、アボートは劇的に減ります。

—

最後に：あなたへのメッセージ

Cloud Spannerのアボートは、システムが正常に、そして誠実に動いている証拠です。
「エラーが出た！」と落ち込むことはありません。それはSpannerが「私は絶対にデータを壊しませんよ」とあなたに約束してくれている声なのです。

1. アボートは「安全装置」である。
2. 公式ライブラリのリトライ機能に任せれば、怖くない。
3. あまりに多い時は、データの設計（取り合い）を見直す。

この3点を覚えたあなたは、もうSpannerの基本をマスターしたも同然です。
自信を持って、この最強のデータベースを使いこなしてください。もし迷ったら、いつでもまた聞きに来てくださいね。

さあ、素晴らしいアーキテクチャの旅を続けましょう！