Local SSD

解決する課題

ネットワーク越しの Persistent Disk では届かない、物理ディスク直結レベルの IOPS と低レイテンシを必要とするワークロードを支えます。

• DB やキャッシュで極めて高い IOPS・低レイテンシが欲しい
• 学習データの前処理や解析のスクラッチ（一時作業）領域を高速化したい
• 失われても再生成できる一時データ・中間ファイルを安価かつ高速に置きたい
• 分散DB やキャッシュ層でノードローカルの高速ストレージを前提にしたい

主要概念と用語

• Local SSD: VM をホストする物理サーバーに直結したブロックストレージ。ネットワークを介さないため最高クラスの性能だが揮発性
• 揮発性（ephemeral）: VM の停止・削除、ライブマイグレーションの失敗、ホスト障害でデータが消失する。永続性の保証はない
• 接続インターフェース: 世代により NVMe や SCSI でアタッチされる。第3〜4世代のマシンシリーズでは NVMe ベースの Local SSD が前提
• Persistent Disk / Hyperdisk: 対照的にネットワーク越しの永続ブロックストレージ。VM を止めてもデータは残る
• スクラッチ領域: 計算の途中結果や一時ファイルを置く、消えても困らない作業用ストレージ
• RAID / ソフトウェアストライピング: 複数の Local SSD を OS 側でまとめ、容量とスループットを束ねる構成

仕様・制限・クォータ

• 揮発性: VM 停止・削除・ホスト障害でデータは失われる。永続データを置いてはいけない
• アタッチのタイミング: 多くのマシンシリーズで VM 作成時にのみ追加でき、後から本数を増やせない（マシンシリーズにより付与単位・本数の制約が異なる）
• 本数とマシンシリーズ依存: 利用可否・最大本数・1本あたり容量はマシンシリーズと vCPU 数に依存する。最新世代では容量が大きい単位で割り当てられる場合がある
• リサイズ不可: Local SSD 単体の容量は固定。容量を増やすには本数を増やすか、より大きい構成の VM を選ぶ
• ライブマイグレーション: Local SSD 付き VM の挙動はマシンシリーズで異なり、メンテナンス時にデータ保持の扱いが変わる場合がある（再起動でデータが消える前提で設計する）
• クォータ: プロジェクト/リージョンごとに Local SSD の総容量に上限があり、引き上げ申請が可能

内部の仕組み

Local SSD は、VM が動く物理ホストのローカルデバイスを直接 VM に見せる仕組みです。Persistent Disk のように内部で複数デバイスへ分散・冗長化されるネットワークストレージとは異なり、冗長化されず、ホストの寿命と運命を共有します。これが最高クラスの性能と引き換えの揮発性の理由です。

• データは物理ホストに直結。ネットワークホップが無いため低レイテンシ・高 IOPS
• 冗長化はされないため、ホスト障害＝データ消失。耐久性は持たない
• 複数本の Local SSD を OS の RAID/ストライピングで束ね、スループットと容量を拡大できる
• 永続性が必要なデータは別途 Persistent Disk / Hyperdisk / Cloud Storage へ書き出す前提

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

• 用途はキャッシュ・一時ファイル・スクラッチ・分散システムのローカル層に限定する
• 分散DB（Cassandra など）や検索エンジンのように、アプリ側がレプリケーションで冗長性を担保する構成と組み合わせる
• 高スループットが要るときは複数本を RAID 0 でストライピングし、必要なら起動時に自動マウントする
• 消えても困らないよう、重要な成果物は処理の節目で Cloud Storage / Persistent Disk へ書き戻す
• 本番DB の単独データストアには使わない。永続が要るなら Persistent Disk / Hyperdisk を選ぶ

運用・監視

• Cloud Monitoring でディスク I/O メトリクス（read/write の IOPS・スループット・レイテンシ）を監視し、上限への張り付きを確認
• VM 起動時に Local SSD をフォーマットしてマウントする初期化処理（起動スクリプト等）を用意する
• ライブマイグレーションやメンテナンス後にデータが消える前提で、再生成・再同期の手順を運用に組み込む
• 本数は基本的に作成時に決まるため、性能・容量の見積もりを事前に行う

コスト

• **アタッチした Local SSD の容量（GB/月）**に課金。スナップショットのような追加バックアップ課金は対象外
• 揮発性のためバックアップ保管コストは発生しないが、永続が要るデータは別ストレージのコストがかかる
• 一部マシンシリーズでは Spot/Preempt 可能 VM と組み合わせてコストを抑えつつスクラッチ用途に使える
• 不要に多くの本数を付けると割高。必要な性能・容量に絞るのが基本

セキュリティ

• 保存データは Google 管理鍵で既定で暗号化される（Local SSD は揮発性のため鍵運用は PD/Hyperdisk と扱いが異なる）
• 揮発性ゆえ VM の寿命とともにデータは消えるが、機微データの一時保管でも暗号化前提で扱う
• IAM で Local SSD 付き VM の作成権限を最小化し、想定外の高コスト構成を防ぐ
• 認証情報や機密の正本を Local SSD に置かず、Secret Manager とサービスアカウントを使う

関連サービス・比較

ハンズオン / CLI例

# 1) Local SSD（NVMe）を1本付けてVMを作成（作成時に指定する）
gcloud compute instances create my-fast-vm \
  --zone=asia-northeast1-a \
  --machine-type=n2-standard-8 \
  --local-ssd=interface=NVME

# 2) 複数本を付けてスループットを束ねる前提の構成
gcloud compute instances create my-scratch-vm \
  --zone=asia-northeast1-a \
  --machine-type=n2-standard-16 \
  --local-ssd=interface=NVME \
  --local-ssd=interface=NVME

# 3) VM内でデバイスを確認しRAID0でストライピング後にマウント（OS側作業の例）
#    lsblk でデバイスを確認し、mdadm でストライプ、フォーマットしてマウントする
sudo lsblk
sudo mdadm --create /dev/md0 --level=0 --raid-devices=2 \
  /dev/nvme0n1 /dev/nvme0n2
sudo mkfs.ext4 /dev/md0
sudo mkdir -p /mnt/scratch
sudo mount /dev/md0 /mnt/scratch