Spanner Omniの一般提供で、利用者が配置を選べる

Googleの公式リリースノートによると、Spanner Omniは2026年9月30日に一般提供となり、長期サポート版2026.r4-ltsが公開されました。InfoQの記事掲載日は10月7日です。製品のGA日と報道日が異なります。[1]

Omniは、自社設備（オンプレミス）やGoogle Cloud、AWSなどに配置できるSpannerです。インストールと保守を利用者が担う点は、公式概要にも記載されています。

Omniは、ノード（データベースを動かすサーバ）を追加して処理能力を広げる水平スケールを提供します。また、先に完了した取引（一連の処理をまとめて扱う単位）の結果を後続の取引に反映する外部整合性も提供します。[4]

注文の順序を保証し、業務ルールは取引に組み込む

注文Aの在庫更新を含む取引（一連の処理をまとめて扱う単位）が確定（コミット）した後に、注文Bを始める場面を本稿の設計例として扱います。コミットは、データベース内の取引を確定することです。外部整合性は、Aの完了後にBが始まった場合、BがAの効果を反映する順序を保証します。[2]

外部整合性が支えるのは取引の順序です。[2] 本稿の設計例として、在庫を負数にしない条件をアプリケーションが確認し、同じ読み書き取引（読み取りと書き込みを両方行う取引）に減算を含める方法を扱います。

データベース取引が一括確定するのは、データベース内の処理です。外部API（別システムに処理を依頼する窓口）の結果は、アプリケーション側で管理します。再試行によってAPIの副作用（外部システムに生じる変更）が重複する場合があります。[3] 重複排除（同じ要求を二重に処理しない設計）や冪等化（同じ要求を繰り返しても同じ状態になる設計）は、アプリケーション側で設計します。[3]

後輩順序がそろうなら、注文処理の整合性はDBに任せられますか。

先輩DBがそろえるのは、確定した取引どうしの順序だよ。

後輩在庫の条件や、決済APIの重複は別に考えるんですね。

先輩この設計例では在庫条件を取引内で確認し、外部APIの再試行にも備えるよ。

単一DB、読み取りレプリカ、managed Spannerの役割を比べる

書き込みを単一の主系（書き込みを受け付ける中心ノード）に集めた構成で、必要な取引順序や配置、負荷の要件を満たせるなら、その構成も選択肢です。読み取り負荷にはレプリカ（元データを複製して保持するノード）を使えますが、読み取りの分散と更新の反映タイミングは別の要件です。

PostgreSQLのhot standbyは、読み取り専用接続を受け付ける待機系です。主系の変更が届いて適用されるまでには遅延があり、ほぼ同時に問い合わせると、主系と異なる結果になる場合があります。コミット記録がstandbyで再生された後は、新しいスナップショット（読み取り時点のデータ状態）から更新が見えます。[5]

managed SpannerではGoogleがサービスを管理します。Omniでは利用者がインストール、パッチ、バックアップ、ハードウェアとソフトウェアの保守を担います。Omniには可用性に関するサービスレベル合意（SLA）がなく、可用性は利用者のインフラと構成に依存します。利用者は導入時に、契約上のサポートや実際の運用分担を確認します。[6]

利用者が水平スケール、自動シャーディング（データを複数の範囲に自動で分ける機能）、外部整合性を必要とし、配置先も選びたい場合は、Omniを検討できます。利用者は、単一主系で要件を満たせる場合、その構成を選べます。[4]

Paxosの合意とソフトウェアTrueTimeが順序を支える

シャーディングはデータを複数の範囲に分けること、複製は同じデータを複数ノードに保持することです。OmniはPaxosという合意形成の仕組みで複製間の更新をそろえ、自動シャーディングと組み合わせます。[4]

時計は別の役割を担います。クラスタ（複数のサーバを連携させた構成）では、データベースサーバ1台が基準時刻を配信するprimary time serverを担います。応答しなくなると、別のサーバが昇格します。各ホストのbackground clientは、定期的に時刻情報を取得します。[7]

ソフトウェアTrueTimeは、時刻を[earliest, latest]の区間として扱います。Omniの公式説明は、この区間からコミット時刻を割り当て、実時間順の外部整合性を提供すると説明しています。

GoogleによるSpannerの仕組みの解説では、コミット時刻を選び、区間の下限がその時刻を過ぎるまで待つcommit waitを示しています。Spannerは、コミット時刻が確実に過去になってから結果を返します。その完了後に始まる取引には、先の取引より後のコミット時刻を割り当てます。OmniはソフトウェアTrueTimeを使って同じ外部整合性を提供します。

ソフトウェアTrueTimeにもハードウェア条件があります。Linux x86では、ハードウェアのタイムスタンプカウンターであるTSCを使います。導入担当者は利用するホストの要件を確認します。[9]

複製間の合意はPaxosが担い、実時間順の保証は時計と待ち時間が支えます。TrueTimeの不確実性が大きいとコミット待ちが増えることがあります。一方、TrueTimeの不確実性がPaxosの往復遅延より小さい場合、公式文書はTrueTimeによる追加のコミット遅延はないと説明しています。この説明は、不確実性とPaxos遅延の条件に基づいています。[8]

導入条件を配置・ライセンス・運用に分けて確認する

実行環境とライブマイグレーション

仮想マシン（VM）は、仮想的な計算機上でオペレーティングシステム（OS）を動かす仕組みです。コンテナは、アプリの実行環境をまとめ、ホストOS上で動かす仕組みです。これらを稼働したまま別ホストへ移すライブマイグレーションの間は、原則としてTrueTimeがサポートされません。ライブマイグレーションには、認定されたマシン種別やAmazon Machine Image（AMI、仮想マシンの起動イメージ）などの例外があります。導入担当者はシステム要件を参照し、利用予定の構成を確認します。[10]

監視指標

監視では、true_time_is_availableがTrueTime APIの可用性を示します。true_time_interval_uncertaintyは、時刻区間の不確実性を示します。sla_tester_violation_countは、時計の問題やハードウェア条件違反の可能性を示す指標です。Omni自体の可用性SLAはありません。[11, 6]

ゾーン構成

構成最低条件と推奨条件可用性設計で見る点
single-zone（単一ゾーン）最低3台のサーバゾーン障害で停止する可能性があります。
regional multi-zone（同一リージョン内の複数ゾーン）最低3ゾーン、各ゾーン1台以上。各ゾーン3台を推奨最低条件と推奨条件を分けて構成します。

利用者がsingle-zoneにサーバを最低3台配置しても、ゾーン障害時に停止する可能性があります。regional multi-zoneでは、最低条件と推奨台数を区別し、必要な障害範囲に合わせます。[12]

ライセンス

Developer版は、公式概要で非本番・非商用向けとされています。Developer版は、ライセンスキーなしの単一サーバで仮想CPU（vCPU）が4基以下なら、無期限で利用でき、バックアップと復元にも対応します。

無期限Developer key（開発版を無期限で使うためのライセンスキー）を設定していない場合、複数サーバまたは4 vCPU超の構成では、環境の作成から90日後に書き込みが無効になります。読み取り処理は続けられます。無期限Developer keyを使う構成では、バックアップと復元を利用できません。[13]

本番・商用利用の対象は、有償のCommercial版です。導入担当者は契約内容と、バックアップ、更新、監視などの運用担当を確認します。利用者は必要なデータベース機能と、公式文書に記載された対応範囲を照合します。[14]