Bare Metal Solution

解決する課題

• Oracle Database のように仮想化やライセンスの制約でパブリッククラウドの仮想マシンに載せにくいワークロードを、物理サーバーのまま動かしたい
• オンプレミスの物理サーバーを使い続けているが、ハードウェアの調達・保守・データセンター運用から解放されたい
• レガシー基盤をいきなりリファクタリングせず、**まず「持ち上げてそのまま移す」**形でクラウドへ寄せたい
• 物理基盤を Google Cloud のマネージドサービスと低遅延で連携させ、段階的にモダナイズしていきたい
• 共有環境ではなく、占有された物理ハードウェアでのパフォーマンスと分離性が要件になっている

これらを引き受けるのが Bare Metal Solution です。Google Cloud のリージョンに隣接した施設に専用の物理サーバーを用意し、ハードウェアの調達と保守を Google が担いながら、低遅延の専用接続でクラウド側のサービスと結びます。

主要概念と用語

• ベアメタルサーバー: 仮想化レイヤーを介さない占有の物理サーバー。利用者が OS から上を管理する
• Bare Metal Solution 環境: Google Cloud のリージョンに隣接した施設に配置される、利用者専用の物理ラックとネットワークの集合
• リージョン拡張（リージョンへの隣接配置）: クラウドのリージョンと低遅延の専用接続で結ばれる立地。クラウド側サービスと近接して連携できる
• Interconnect / 専用接続: Bare Metal Solution 環境と利用者の VPC を結ぶネットワーク経路。クラウド側のリソースと通信する
• OS とミドルウェアの責任分界: 物理ハードウェアと施設は Google が運用し、OS・ミドルウェア・データベース・アプリケーションは利用者が管理する
• ストレージ・ボリューム: サーバーに割り当てられるブロックストレージ。スナップショットによる保護も構成できる
• プロビジョニング: 必要なサーバー構成を Google に手配し、専用ハードウェアとして用意してもらう流れ

仕様・制限・クォータ

• 提供は特定のリージョンに隣接した施設に限られ、すべてのリージョンで使えるわけではない。利用前に提供地域を確認する
• ハードウェア構成（CPU・メモリ・ストレージなど）は用意されたサーバー種別から選ぶ形で、任意の自作構成ではない
• 一般的な仮想マシンのような秒単位の即時起動・即時破棄ではなく、物理サーバーの手配が前提になる
• OS から上は利用者責任。OS のパッチ適用、ミドルウェアやデータベースの運用は利用者が行う
• ライセンス（とくに Oracle 系）は利用者側のライセンス条件・契約に従う。持ち込みや適用条件は事前に確認する
• 具体的な提供地域・サーバー種別・契約条件・数量は変動するため、本番設計時は公式ドキュメントと営業・サポート窓口で最新情報を確認する

内部の仕組み

Bare Metal Solution では、Google Cloud のリージョンに隣接した施設に利用者専用の物理サーバーが配置されます。サーバーは仮想化レイヤーを挟まない占有ハードウェアで、利用者は OS をインストールし、その上にデータベースやアプリケーションを構築します。物理ハードウェア・電源・空調・ラックといった施設とインフラの運用は Google が担当し、利用者はハードウェアの調達や保守から解放されます。

この施設はクラウドのリージョンと低遅延の専用接続で結ばれます。これにより、ベアメタル上のデータベースとクラウド側のアプリケーションやマネージドサービスを近接して連携させられ、レガシー基盤を残したまま周辺を段階的にクラウドへ寄せる構成が取りやすくなります。利用者の VPC とは Interconnect 系の専用経路を通じて接続し、クラウド側リソースと同じネットワーク設計の延長で扱えます。

ストレージはサーバーに割り当てられるブロックボリュームとして提供され、スナップショットによる保護やバックアップ運用を組み合わせます。物理基盤である以上、可用性は冗長構成・バックアップ・障害時の切り替え設計を利用者側でも作り込むことが前提になります。

設計パターン / ベストプラクティス

• リフト＆シフト起点: まずはレガシー基盤をそのまま移し、稼働後にクラウド側サービスとの連携で段階的にモダナイズする
• 低遅延連携を活かす: ベアメタル上の DB と、クラウド側のアプリケーション層やマネージドサービスを近接配置し、遅延に敏感な処理を成立させる
• 可用性は明示的に設計: 物理基盤なので、データベースの冗長構成・レプリケーション・バックアップ・障害切り替えを自前で設計する
• ネットワークは VPC 設計の延長で: 専用接続経由の到達範囲・経路・ファイアウォールをクラウド側の設計と一貫させる
• 運用の自動化: OS パッチやバックアップなど利用者責任の運用を自動化し、人手による取りこぼしを防ぐ

運用・監視

• OS・ミドルウェア・データベースの監視とログ収集は利用者責任。クラウド側のモニタリング基盤と連携させると一元管理しやすい
• ハードウェア障害や施設側の事象は Google が対応するが、OS から上の障害切り分けは利用者が行うため、責任分界を運用手順に落とし込む
• バックアップとスナップショットの取得・復旧手順を定め、定期的にリストア訓練を実施する
• パッチ適用やメンテナンス時の停止計画を、クラウド側の連携サービスへの影響まで含めて設計する
• 障害時はまずハードウェア/施設由来か、OS・DB・アプリ由来かを切り分け、適切な窓口へエスカレーションする

コスト

Bare Metal Solution は専用物理ハードウェアを一定期間占有して使う性質上、コストは契約に基づく占有リソースへの支払いが中心になります。手軽に増減する従量課金型の仮想マシンとは費用構造が異なり、長期で安定して使うレガシーワークロードに向きます。

セキュリティ

• 物理サーバーは利用者専用に占有され、他テナントと物理ハードウェアを共有しない分離性を持つ
• OS から上のセキュリティ（パッチ適用・アカウント管理・データベースの権限設計）は利用者責任。責任分界を明確にして運用する
• 専用接続のネットワーク到達範囲を最小化し、VPC・ファイアウォール・サブネット設計でアクセスを絞る
• 機密情報や認証情報は安全に管理し、クラウド側と連携する場合は IAM とサービスアカウントで権限を最小化する
• データの暗号化やバックアップの保護方針を、コンプライアンス要件に合わせて設計する

関連サービス・比較

Google Cloud 内での棲み分けは、汎用の仮想サーバーが欲しいなら Compute Engine、コンテナやマネージドな実行基盤なら Cloud Run や GKE、そして仮想化に載せにくい物理前提のレガシーワークロード（とくに Oracle 系）の移行先としては Bare Metal Solution、という整理になります。連携の起点としては VPC と Interconnect 系の専用接続が中心です。

ハンズオン / CLI例

# Bare Metal Solution のリソースは gcloud の bms コマンド群で操作する
# まず割り当てられている物理サーバーの一覧を確認する
gcloud bms instances list \
  --region=asia-northeast1

# 特定のサーバーの詳細（構成・状態・ネットワーク）を確認
gcloud bms instances describe my-bms-server \
  --region=asia-northeast1

# 割り当てられているストレージ・ボリュームの一覧を確認
gcloud bms volumes list \
  --region=asia-northeast1