Sole-Tenant Nodes

解決する課題

• 同じ物理ホスト上に他テナントの VM を同居させたくない（物理レベルの分離が必要）
• 物理コア／物理ソケット単位でライセンスされたソフトウェアを持ち込み（BYOL）、専有ホストへ集約してコストを抑えたい
• 業界規制やセキュリティポリシーで、ハードウェアの専有が求められる
• レイテンシや性能ばらつきの観点で、ホストを共有しない構成を選びたい
• 特定のワークロードを意図した物理ホストへ配置・固定したい

Sole-Tenant Nodes は、これらを「専有の物理ホスト（ノード）」という単位で解決します。AWS で言えば Dedicated Hosts に相当します。

主要概念と用語

• ソールテナントノード: 1 つのプロジェクトの VM だけが載る、専有された物理サーバー。他テナントと同居しない
• ノードタイプ: ノードが提供する vCPU 数とメモリ量を定義するハードウェア仕様のテンプレート。マシンファミリーに対応する
• ノードテンプレート: ノードタイプや CPU オーバーコミット設定、アフィニティラベルなどをまとめた、ノードグループ作成のひな形
• ノードグループ: 同一テンプレートから作られたノードの集合。ゾーン単位で作成し、台数（サイズ）やオートスケールを設定する
• ノードアフィニティ / アンチアフィニティ: VM をどのノードグループ（ラベル）に載せる／載せないかを制御するスケジューリング条件
• CPU オーバーコミット: 物理コアに対して vCPU を多めに割り当て、ノードの集約率を高める設定（性能と引き換え）
• メンテナンスポリシー: 計画メンテナンス時にノード上の VM をどう扱うか（移動の挙動）を制御する設定

仕様・制限・クォータ

• ノードグループはゾーン単位で作成する。可用性のためには複数ゾーンへノードグループを分けて配置する
• ノード上の VM は通常の Compute Engine インスタンスであり、vCPU クォータやマシンタイプの制約が同様に適用される。加えてノード自体のクォータも消費する
• ノードタイプごとに搭載できる vCPU・メモリの総量が決まっており、その容量を超えて VM を載せることはできない
• 物理ホストを専有するため、ノードは VM の有無にかかわらず確保している間は課金対象になる
• 一部のマシン構成（特定のアクセラレーターやマシンファミリー）はソールテナント対応・非対応が分かれる。具体的な対応状況や上限値・クォータは変動しうるため、設計時に公式ドキュメントで最新値を確認すること

内部の仕組み

Sole-Tenant Nodes では、Compute Engine が専有された物理ホストを丸ごとプロジェクトに割り当て、その上にだけ対象 VM をスケジュールします。物理ホストを共有しないことが本質で、VM 自体の作り方は通常の Compute Engine と変わりません。

• 配置の制御はノードアフィニティで行う。VM 作成時にアフィニティラベルを指定し、合致するノードグループ上にスケジュールする。アンチアフィニティで特定グループを避けることもできる
• 集約率は CPU オーバーコミットで調整する。物理コアより多くの vCPU を割り当てれば 1 ノードあたりの VM 数を増やせるが、競合時の性能は落ちる
• 計画メンテナンス時はメンテナンスポリシーに従う。多くの構成ではライブマイグレーションで VM を別ホストへ移せるが、ライセンス要件で物理ホストを固定したい場合は移動の挙動を制御する必要がある

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

• ライセンス集約: 物理コア／ソケット単位でライセンスされる商用ソフト（一部の OS やデータベースなど）を専有ノードへ寄せ、ライセンス費用を最適化する
• アフィニティでワークロードを分離: 規制対象の VM 専用のノードグループを作り、アフィニティラベルで確実にそのグループへ載せる
• 集約率の設計: ノードタイプの容量に対し、VM のサイズと台数を見積もってノードの空きを最小化する。CPU オーバーコミットは性能影響を許容できる場合のみ使う
• 複数ゾーン配置: ゾーン障害に備え、ノードグループを複数ゾーンに分け、上位で冗長化する
• オートスケール: ノードグループのサイズを需要に追従させ、過剰なノード確保を避ける

運用・監視

• Cloud Monitoring / Cloud Logging でノードの使用率（ノードあたりの vCPU・メモリ充填率）と VM の配置状況を監視する
• ノードの空き容量が慢性的に多い場合は、ノードタイプや集約方針（VM サイズ・台数）の見直しを検討する
• 計画メンテナンスの通知とメンテナンスポリシーの挙動を把握し、ライセンス固定が必要な VM への影響を確認する
• ノードグループのオートスケールが意図どおりに増減しているか、サイズ変更イベントを追跡する

コスト

• 課金は専有する物理ノード単位で発生する。ノード上の VM に対する追加のソールテナント料金がかかるモデルで、空きノードでも確保中は課金される
• BYOL を集約することで、物理コア／ソケット単位のライセンス費用を抑えられる場合がある。これが専有の主要なコストメリットになりやすい
• 定常的に必要なノードには**確約利用割引（CUD）**を組み合わせ、単価を下げられる
• 集約率が低い（空きの多い）ノードを抱え続けると割高になるため、VM の詰め込みとノード台数の最適化が重要

セキュリティ

• 物理ホストを専有することで、他テナントとのハードウェア同居を排除できる。マルチテナント由来のリスクを避けたい要件に応える
• ノード上の VM には引き続き最小権限のサービスアカウントを割り当て、IAM で操作権限を制御する
• ディスクは既定で暗号化され、必要に応じて CMEK で自前鍵を使える。Shielded VM など通常の Compute Engine の防御策も併用できる
• ノードテンプレートやノードグループの作成・変更操作は IAM で管理し、誰が専有ノードを確保できるかを制御する

関連サービス・比較

通常の共有テナント（マルチテナント）の Compute Engine との違いを整理します。AWS の相当サービスは Dedicated Hosts です。

ハンズオン / CLI例

# 1. ノードテンプレートを作成（ノードタイプを指定）
gcloud compute sole-tenancy node-templates create my-node-tmpl \
  --region=asia-northeast1 \
  --node-type=n2-node-80-640

# 2. テンプレートからノードグループを作成（ゾーン単位・初期 1 ノード）
gcloud compute sole-tenancy node-groups create my-node-group \
  --zone=asia-northeast1-a \
  --node-template=my-node-tmpl \
  --target-size=1

# 3. ノードアフィニティを指定して専有ノード上に VM を作成
gcloud compute instances create demo-st-vm \
  --zone=asia-northeast1-a \
  --machine-type=n2-standard-4 \
  --image-family=debian-12 \
  --image-project=debian-cloud \
  --node-group=my-node-group

# 4. ノードグループの状態を確認
gcloud compute sole-tenancy node-groups describe my-node-group \
  --zone=asia-northeast1-a