【入門編】ストレージクォータの強制執行 – Cloud Spanner

こんにちは！いつも学びにきてくれてありがとうございます。

データベースを運用していると、避けては通れない大切なテーマがあります。それが「容量（ストレージ）の限界」です。

Google Cloudが提供する世界最高峰のデータベース「Cloud Spanner（以下、Spanner）」は、地球規模でデータを分散して保存できる、まさに夢のようなシステムです。しかし、そんなSpannerでも、あらかじめ設定した「最大容量（ストレージクォータ）」に達したときは、システムの安全を守るためにそれ以上の書き込みをピタッと拒否する必要があります。

「いっぱいになったら書けなくなるのは当たり前じゃない？」と思うかもしれません。
でも、世界中に何百台、何千台と散らばっているSpannerのサーバーたちが、「たった今、限界に達しました！全員、書き込みを止めてください！」という情報を、1ミリ秒でも遅れたら大混乱になる世界で、どうやって一瞬で共有しているのか。

今回は、この高度な「強制執行と状態の超高速伝播」の仕組みを、日常の出来事に例えて、どこよりも優しく解き明かしていきます。ここをクリアすれば、Spannerの基本と分散システムの真髄はバッチリマスターできますよ！

—

1. 日常の例え：世界展開する「超巨大クローク」の挑戦

想像してみてください。あなたは世界中に100店舗を持つ、超巨大な荷物預かりサービス（クローク）の総支配人です。

すべての店舗が預かれる荷物の合計は、安全のために「全体で10,000個まで」と法律で厳しく決まっています（これがストレージクォータです）。

ここで、以下のような大問題が発生します。

問題： ロンドン店で荷物が預かり限界（10,000個目）に達したその瞬間、東京店やニューヨーク店でも同時に「もう預かれません」と新規のお客さまを断らなければなりません。
もし伝達が遅れたら？ 東京店で「いいですよ！」と預かってしまい、後から「実は世界全体でもう満杯でした、法律違反です！」となってしまいます。

世界中に散らばる店舗（サーバー）に、「満杯になった」という状態を一瞬の遅延もなく伝えるには、どうすればいいでしょうか？

Spannerはこの難問を、驚くほどエレガントな方法で解決しています。

—

2. Spannerの裏側：瞬時に書き込みを拒否する3つのステップ

Spannerの内部では、データは「スプリット」と呼ばれる小さな引き出しに細かく分けて保管されています。そして、それぞれの引き出しには「リーダー（代表者）」となるサーバーがいます。

容量制限が限界に達したとき、Spannerは以下の3つのステップで、一瞬にして世界中の書き込みをシャットアウトします。

[ユーザーの書き込みリクエスト]
│
▼
┌─────────────────────────────────┐
│ 1. ゲートウェイ (受付カウンター) │ ◀─── (超高速で「満杯」の通知が届いている)
└─────────────────────────────────┘
│
├─ [まだ余裕がある場合] ──► データベースへ書き込み
│
└─ [限界に達している場合] ─► 門前払い！ (RESOURCE_EXHAUSTED)

ステップ①：受付カウンター（ゲートウェイ）での「プレフライトチェック」

お預かりの列に並んで、いざ荷物を渡す段階になってから「あ、やっぱり満杯でした」と言われたら嫌ですよね。
Spannerでは、データが書き込まれる一番手前の受付窓口（APIゲートウェイ）で、「今、容量に空きがあるか？」を事前にチェック（プレフライトチェック）します。これにより、無駄な書き込み処理がデータベースの奥深くまで入ってくるのを入り口で防ぎます。

ステップ②：限界の「悲鳴」を最優先で届ける（プロアクティブ通知）

容量を監視している「クォータ・マネージャー」という監視役がいます。この監視役は、容量が99.9%に達した瞬間に、世界中の受付カウンターに対して「もうすぐ満杯になるぞ！」「満杯になった！」という信号（シグナル）を、他のどんな通信よりも最優先で送りつけます。
これを「プロアクティブ（先回り）通知」と呼びます。

ステップ③：もしすり抜けても、最後の砦がシャットアウト

万が一、ネットワークのほんのわずかな一瞬の隙をついて、満杯直後に書き込みリクエストが受付をすり抜けてデータの保管庫（スプリットのリーダー）まで届いてしまったとします。
安心してください。保管庫のリーダーサーバーも常に最新の容量を把握しているため、「だめです、もう入りません！」と最後の砦として、その書き込みを厳しく拒否します。

この多重のチェック機構により、Spannerは「制限を超えたデータが書き込まれてしまう」という大事故を100%防いでいるのです。

—

3. もし制限に達したら？プログラムはどう動く？

実際にSpannerの容量制限に達したとき、皆さんが書くアプリケーションにはどのような結果が返ってくるのでしょうか。

Spannerは、これ以上書き込めない状態になると、`RESOURCE_EXHAUSTED`（リソース枯渇） というエラーを返します。

Javaのクライアントライブラリを使った時のイメージを、簡単なコードで見てみましょう。

import com.google.cloud.spanner.SpannerException;
import com.google.cloud.spanner.ErrorCode;

try {
// データベースにデータを書き込む処理
dbClient.write(mutations);
System.out.println(“データの書き込みに成功しました！”);
} catch (SpannerException e) {
// エラーの原因が「容量制限（RESOURCE_EXHAUSTED）」かどうかをチェックします
if (e.getErrorCode() == ErrorCode.RESOURCE_EXHAUSTED) {
// [先輩からのアドバイス]
// ここに達した場合、何度も再試行（リトライ）してはいけません。
// なぜなら、容量は自動的には空かないため、再試行するとシステムに無駄な負荷がかかるからです。
System.err.println(“【警告】Spannerの容量制限に達しました。管理者に連絡してください。”);
notifyAdministrator(e.getMessage());
} else {
// その他のエラー（ネットワークの一時的な瞬断など）は、リトライを検討します
handleOtherErrors(e);
}
}

このように、エラーコードを正しくキャッチして、システム管理者に通知する（または不要な書き込みを一時的に止める）ような設計にしておくことが、プロのエンジニアへの第一歩です。

—

4. まとめ：極限の分散システムを支える「優しさ」

Spannerが世界中で愛されているのは、ただ「大量のデータを保存できるから」だけではありません。

限界に達したという「都合の悪い真実」を、いかに早く、正確に、システムの隅々にまで伝えて、全体の安全を守るか。この「状態伝播遅延の最小化」に対する飽くなきこだわりがあるからこそ、世界中の大企業が安心して重要な決済データなどを任せられるのです。

今回のポイントを整理しましょう！

1. プレフライトチェック：入り口（ゲートウェイ）で瞬時に判定して、無駄な処理をさせない。
2. プロアクティブ通知：容量の危機を、世界中のサーバーへ最優先で伝達する。
3. RESOURCE_EXHAUSTED：限界に達した時のエラー。これが出たらリトライせず、すぐに容量を追加するか、古いデータを掃除する。

この仕組みを理解しておけば、Spannerのアーキテクチャの基本はバッチリマスターできていますよ！

これからも、一歩ずつ一緒に学んでいきましょう。何か分からないことがあれば、いつでも先輩を頼ってくださいね！