Hyperdisk

解決する課題

従来の Persistent Disk は性能（IOPS・スループット）がディスク容量や VM の vCPU 数に比例していたため、性能を上げるためだけに不要な大容量や大きい VM を契約する無駄が生じがちでした。Hyperdisk は容量と性能を切り離して指定できるため、ワークロードに合わせて過不足なくリソースを割り当てられます。

• 容量はそれほど要らないが高い IOPS / スループットが欲しい（小容量・高性能の DB など）
• 性能のためだけに大容量や大型 VM を契約する無駄をなくしたい
• 稼働を止めずに性能（IOPS・スループット）を後から増減したい
• AI/ML の学習で同じデータセットを複数 VM へ高速に供給したい

主要概念と用語

• Hyperdisk Balanced: 汎用タイプ。容量・IOPS・スループットを独立指定でき、一般的な本番ワークロードやブートディスクの起点になる
• Hyperdisk Extreme: 最高クラスの IOPS・低レイテンシ。高負荷の RDBMS や SAP HANA など、要求の厳しいトランザクション系向け
• Hyperdisk Throughput: スループット重視・低コスト。ビッグデータ解析やログ処理などシーケンシャルな大量読み書き向け
• Hyperdisk ML: 読み取り最適化の共有ボリューム。学習済みモデルやデータセットを多数の VM から読み取り専用で同時マウントして AI 推論・学習に供給する
• Hyperdisk Balanced High Availability: 2ゾーンへ同期レプリケーションする高可用タイプ。ゾーン障害に耐える
• プロビジョンド IOPS / スループット: 容量とは別に契約する性能値。タイプごとに指定できる範囲が決まる
• 対応マシンシリーズ: Hyperdisk は**第3世代以降の VM（C3、M3、N4 など）**でのみアタッチでき、タイプにより対応シリーズが異なる
• マルチライター: 一部タイプでクラスタファイルシステム前提の読み書き共有に対応

仕様・制限・クォータ

• 容量・IOPS・スループットを独立してプロビジョニングできる。性能はディスクサイズや vCPU に直接縛られない（ただし VM 側のネットワーク帯域や最大性能が上限になる）
• 対応するマシンシリーズが限定される。タイプごとに使える VM シリーズや上限値が異なり、第2世代以前の VM では利用できない
• 稼働中に性能（IOPS・スループット）を変更できるが、変更には反映までの時間や一定の調整間隔（クールダウン）がある
• サイズ拡張は可、縮小は不可（縮小はスナップショットから小さいディスクへ復元）
• Hyperdisk Balanced HA は同一リージョン内の2ゾーンに同期レプリケートする
• Hyperdisk ML は読み取り専用で多数の VM へ同時アタッチできる
• プロジェクト/リージョンごとに容量・IOPS・スループットのクォータがあり、引き上げ申請が可能

内部の仕組み

Hyperdisk は Persistent Disk と同様、VM が載る物理ホストから独立したネットワーク接続の分散ブロックストレージです。データは内部で複数の物理デバイスに分散・冗長化されるため、インスタンスを止めてもデータは残ります。Persistent Disk との最大の違いは、性能（IOPS・スループット）を保存容量から切り離してプロビジョニングできる点にあります。

• ブロック I/O はネットワーク越しに分散ストレージへ送られ、複数デバイスに冗長化される
• 性能はディスク容量ではなく契約した IOPS・スループット値で決まるため、小容量でも高性能を引き出せる
• Hyperdisk Balanced HA は書き込みを2ゾーンへ同期レプリケーションし、片方のゾーン障害時にフェイルオーバーできる
• Hyperdisk ML は読み取りを多数の VM へ並列供給する設計で、AI/ML のデータ配信に適する

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

• 新規ワークロードは Hyperdisk Balanced を起点に、超高 IOPS が要れば Hyperdisk Extreme、シーケンシャル大量転送なら Hyperdisk Throughput を選ぶ
• ゾーン障害に備える本番 DB は Hyperdisk Balanced High Availability で2ゾーン同期にし、加えて定期スナップショットで世代管理する
• AI/ML の学習・推論で同じデータセットを多数の VM へ配る場合は Hyperdisk ML を読み取り専用共有で使う
• VM は Hyperdisk に対応した第3世代以降のマシンシリーズを選ぶ。性能上限は VM 側のネットワーク帯域にも左右される点に注意する
• まず控えめな IOPS・スループットで開始し、監視結果を見て稼働中に性能を増やすことで過剰プロビジョニングを避ける

運用・監視

• Cloud Monitoring でディスクの IOPS・スループット・レイテンシを監視し、契約値への張り付き（飽和）を検知する
• 性能不足はプロビジョンド IOPS・スループットの引き上げで対応する。容量を増やさず性能だけを増やせる
• 性能変更には反映までの時間や調整間隔があるため、ピーク前に余裕をもって変更する
• ディスクは稼働中にサイズ拡張が可能。OS 側でファイルシステムの拡張（resize2fs 等）が別途必要になる
• スナップショットから別ゾーン/別リージョンへ復元してゾーン・リージョン障害に備える

コスト

• **プロビジョニングした容量（GB/月）**に加え、プロビジョニングした IOPS・スループットにも課金される（タイプにより課金対象が異なる）
• 性能のために容量を水増しする必要がないため、高性能・小容量のワークロードでは Persistent Disk より割安になりやすい
• 過剰な IOPS・スループットを契約しないよう、監視結果に基づいて性能値を実需に合わせて調整する
• スナップショットは増分の保存容量に課金される。古いスナップショットや不要ディスクの削除でコストを抑える

セキュリティ

• 保存データは既定で常に暗号化される（Google 管理鍵）。要件に応じて CMEK（Cloud KMS） や CSEK（顧客指定鍵） に切り替えられる
• スナップショットは元ディスクの暗号化を継承する（CMEK ディスクのスナップショットも同じ鍵で保護）
• IAM でディスク・スナップショットの作成/削除/アタッチ権限を最小化する（roles/compute.storageAdmin などを適切に付与）
• ディスクへの認証情報の埋め込みは避け、サービスアカウントと Secret Manager を使う

関連サービス・比較

Hyperdisk は Persistent Disk の後継となる第3世代ブロックストレージです。最大の違いは性能と容量を独立して指定できる点で、対応する VM シリーズも新しい世代に限られます。

ハンズオン / CLI例

# 1) Hyperdisk Balanced を作成（容量とは別に IOPS・スループットを指定）
gcloud compute disks create my-hd-disk \
  --zone=asia-northeast1-a \
  --size=100GB \
  --type=hyperdisk-balanced \
  --provisioned-iops=5000 \
  --provisioned-throughput=200

# 2) 対応マシンシリーズ（例: C3）の VM にアタッチ
gcloud compute instances attach-disk my-c3-instance \
  --disk=my-hd-disk \
  --zone=asia-northeast1-a

# 3) 稼働中に性能（IOPS・スループット）を引き上げ（容量は据え置き）
gcloud compute disks update my-hd-disk \
  --zone=asia-northeast1-a \
  --provisioned-iops=8000 \
  --provisioned-throughput=300

# 4) スナップショットでバックアップ
gcloud compute snapshots create my-hd-disk-snap \
  --source-disk=my-hd-disk \
  --source-disk-zone=asia-northeast1-a \
  --storage-location=asia-northeast1

# 5) ゾーン障害に備える Hyperdisk Balanced High Availability（2ゾーン同期）
gcloud compute disks create my-hd-ha-disk \
  --region=asia-northeast1 \
  --replica-zones=asia-northeast1-a,asia-northeast1-b \
  --size=200GB \
  --type=hyperdisk-balanced-high-availability