「Oracle のサポート費用がまた上がった」「SQL Server のライセンスを整理したいが基幹は止められない」——金融・製造・公共系を中心に、こうした基幹データベースの再評価相談が 2026 年に入って明らかに増えました。そこに新しい選択肢として登場したのが、Google Cloud がプレビュー公開した「Spanner Omni」です。これまでクラウド前提だった大規模分散 RDB Spanner を、オンプレや他社クラウドのローカルマシン上にもインストールできるようにしたもので、ハイブリッド構成や閉域系の基幹システムでも検討できる現実解になりました。
本記事では、Oracle / SQL Server からの段階的リプレース受託案件で、Spanner Omni を採用するときの設計指針とデータ移行のステップを整理します。
なぜ「オンプレで動く Spanner」が必要だったのか
Spanner はこれまで、Google Cloud 上でしか動作しない閉じたサービスでした。一方で、エンタープライズ受託の現場では次のようなブロッカーが繰り返し出てきます。
| 制約 | 背景 |
|---|---|
| データ持ち出し禁止 | 金融・医療・公共系の規制 |
| 既存データセンターの償却残 | ハードウェア投資の回収中 |
| 閉域ネットワーク前提 | プライベート接続のみ許可 |
| マルチクラウド戦略 | AWS / Azure 上でも同じ DB を使いたい |
これらの制約は「Spanner を使いたいが、クラウドだから採用できない」という結論を生んでいました。Spanner Omni はこの「クラウドだから使えない」を取り除くためのプロダクトです。Google Distributed Cloud（GDC）系列の延長線上に位置付けられ、オンプレや他社クラウドのインフラ上に Spanner クラスタを展開できます。
アーキテクチャ全体像 — 3 つの配置パターン
受託案件では、要件に応じて次の 3 パターンを使い分けます。
パターン A: 完全オンプレ配置
- 自社データセンターに Spanner Omni クラスタを構築
- データは外部に一切出ない
- 規制が強い金融・医療・公共系の基幹に適合
- 運用は自社（または受託側）が担当
パターン B: ハイブリッド構成
- 基幹データはオンプレの Spanner Omni、分析系は GCP の Spanner / BigQuery
- レプリケーション経由で「直近 N 日分」だけクラウドに転送
- 集計はクラウドの計算リソースを活用
パターン C: マルチクラウド配置
- AWS / Azure 上の VM に Spanner Omni をインストール
- 既存クラウド契約や Reserved Instance を活用しながら Spanner の機能を享受
- マルチクラウド戦略の中核 DB として機能
受託の初期ヒアリングでは、「データ持ち出し禁止」「直近データだけクラウド分析」「マルチクラウド戦略」のどれが本命の制約かを必ず切り分けます。これによって採用パターンと、続く移行設計が大きく変わります。
Oracle / SQL Server からの段階的移行ステップ
レガシー基幹のリプレースは、必ず段階的に進めます。Big Bang での切り替えは技術的にも組織的にもリスクが高すぎます。受託案件で標準的に採る 5 ステップは次の通りです。
Step 1: スキーマと SQL の棚卸し
- DDL を全件抽出し、Spanner で動かないものを分類（PL/SQL ストアド、トリガ、複雑な再帰 CTE など）
- アプリ側の SQL を静的解析し「Spanner の SQL 方言で動くか」を判定
- 「絶対残るストアドプロシージャ」は受託としてリライト計画を別途作成
Step 2: シャドウ書き込み（Dual Write）
- アプリは既存 DB に書き込みつつ、別途 Spanner Omni にも書き込む
- 整合性の差分は日次バッチで検出
- 1〜2 ヶ月かけてアプリ側のロジックバグを潰す
async function createOrder(order: Order) {
await tx(async () => {
await oracleRepo.insertOrder(order);
try {
await spannerRepo.insertOrder(order);
} catch (e) {
logger.warn({ err: e, order }, "shadow write failed");
}
});
}シャドウ書き込みは「Spanner 側がコケてもアプリが落ちない」設計が原則です。
Step 3: シャドウ読み出し（Shadow Read）
- アプリが両方から読み、結果を比較してログに残す
- 不一致があった場合のみアラート
- 実本番のクエリで Spanner 側の最適化を回す
Step 4: トラフィックカナリア
- 1% → 5% → 25% → 100% と Spanner 側を本系に切り替え
- 不具合発生時は即座に Oracle 側へフェイルバック
- カナリアは「機能単位」「テナント単位」「読み/書き別」の組み合わせで設計
Step 5: Oracle / SQL Server の停止
- 30 日間 Spanner 単独で問題なく稼働したのを確認後にライセンスを整理
- バックアップは別ストレージに残す（規制要件次第で 7 年保管）
弊社が 基幹システムの段階的リプレース指針 で整理した「業務継続を最優先にする」考え方は、データベースリプレースでも同様に有効です。
Spanner 特有の設計勘所 — 受託で必ず触れる 4 点
1. プライマリキー設計が「全体性能」を決める
Spanner は分散 RDB なので、プライマリキーがホットスポットを生むと全体スループットが落ちます。UUID v4 か 逆順タイムスタンプ + 連番 を採用するのが基本で、AUTO_INCREMENT 的な単調増加 ID は避けます。
2. インターリーブテーブルでJOIN を高速化
親子関係のあるテーブル（例: Orders → OrderItems）はインターリーブ設定にすることで、同一スプリット上に物理的に配置でき JOIN コストが激減します。Oracle のスキーマをそのまま移すと逃すポイントです。
3. グローバル整合性は「課金」と「レイテンシ」のトレードオフ
Spanner の TrueTime ベース整合性は強力ですが、マルチリージョン構成だと書き込みレイテンシがリージョン間 RTT に依存します。Omni の場合は配置パターンに応じて、整合性レベルとリージョン構成を案件ごとに設計します。
4. 監視は「ノードあたりの CPU 使用率 65%」を上限に置く
Spanner は CPU 使用率 65% を超えるとレイテンシが急上昇します。Omni でも同じ設計指針で、事前にスケールアウトの自動化（K8s カスタムオペレータ経由）を組み込みます。
既存ベンダーへの説明と契約整理
リプレース受託で意外と重いのが、既存ベンダー（Oracle / Microsoft / 既存 SIer）への説明です。受託先と一緒に整理する論点は次の通りです。
| 論点 | 整理の観点 |
|---|---|
| ライセンスの段階的減額 | 移行期は両方走らせるため、過渡期の費用が膨らむ |
| 既存サポート契約 | 切り替え後の問題対応をどこまで残すか |
| データ保持義務 | 規制要件で旧 DB を何年残すか |
| ナレッジ移管 | 既存 SIer から Spanner 運用ノウハウへの引き継ぎ |
Salesforce Headless 360 でのエンタープライズ受託案件設計指針 で触れた「既存ベンダーとの責任分界点」と同じ整理が、ここでも有効です。
まとめ
Spanner Omni は、これまで「クラウドだから採用できない」と諦めていたオンプレ・閉域・マルチクラウド構成の基幹システムに、グローバル分散 RDB の世界を開きます。受託で採用するときに押さえるのは次の 5 点です。
- 配置パターンを「完全オンプレ / ハイブリッド / マルチクラウド」で切り分ける
- シャドウ書き込み → シャドウ読み出し → カナリアの順で段階移行
- プライマリキー設計とインターリーブ設定で性能を担保
- CPU 65% を上限とした自動スケール運用
- 既存ベンダーとの責任分界点を契約初期で合意
弊社では Oracle / SQL Server からの基幹リプレース案件を、Spanner Omni を含めた候補で比較設計しています。「クラウド前提が嫌で Spanner を諦めていた」プロジェクトがあれば、お気軽にご相談ください。
