ワークロードに適した Hyperdisk ブロック ストレージの選び方

※この投稿は米国時間 2025 年 6 月 12 日に、Google Cloud blog に投稿されたものの抄訳です。

Google Cloud の導入や最新の Compute Engine VM、Google Kubernetes Engine（GKE）への移行の際には、ワークロードに最適なブロック ストレージの選択が重要です。Hyperdisk は Google Cloud の最新 VM ファミリー（C4、N4、M4 など）向けに設計されており、ワークロードに最適化されたブロック ストレージです。高パフォーマンスかつコスト効率に優れ、大規模運用時の管理も容易な、エンタープライズ対応のストレージ ボリュームを提供します。この投稿では、Hyperdisk の基本知識と、環境に適した選び方をご提案します。

Hyperdisk ブロック ストレージの概要

Hyperdisk を使用すると、容量とパフォーマンスを個別に調整して、ブロック ストレージのリソースをワークロードに最適化できます。Hyperdisk にはいくつかの種類があります。

• Hyperdisk Balanced: ほとんどのワークロードに適合するよう設計されており、価格とパフォーマンスの最適な組み合わせとバランスを実現します。これは、コンピューティング インスタンスのブートディスクとしても使用できます。Hyperdisk Balanced を使用すると、各ボリュームの容量、スループット、IOPS を個別に構成でき、高可用性モードとマルチライター モードで利用可能です。

• Hyperdisk Extreme: Hyperdisk のサービスの中で最も高い IOPS を提供するため、パフォーマンスを重視するハイエンドなデータベースに最適です。Hyperdisk Extreme を使用すると、単一ボリュームで最大 35 万 IOPS を発揮できます。

• Hyperdisk Throughput: ディスクのセマンティクスを持ちながら、コールド オブジェクト ストレージ並みの低コストで容量を提供します。Hyperdisk Throughput は、低レイテンシを必要としない、帯域幅と容量を大量に消費するワークロードに対して、高スループットを実現します。また、コスト重視のワークロード（コールド ディスクなど）向けに費用対効果の高いディスクとしても利用できます。

• Hyperdisk ML: 静的データをコンピューティング クラスタに読み込むことに特化して設計されています。Hyperdisk ML では、モデルの重みやバイナリなどの固定データセットをディスクにハイドレートし、最大 2,500 のコンピューティング インスタンスを同じボリュームに接続できます。これにより、読み取り専用モードでは、競合するブロック ストレージと比べて、単一ボリュームで対応できるインスタンス数が 150 倍以上になります1。すべてのノードで非常に高い総スループットを発揮するため、推論の起動を高速化し、モデルのトレーニングを迅速に進め、貴重なコンピューティング リソースを最大限に利用できます。

また、Hyperdisk ストレージ プールを活用することで、容量とパフォーマンスの合計量を事前プロビジョニングできます。プール内のボリュームが動的にリソースを消費するため、TCO を削減し運用を簡素化できます。ワークロードに必要な合計容量とパフォーマンスを考慮してストレージ プールを作成し、そのストレージ プール内にディスクを作成します。その後、ディスクを VM にアタッチできます。ディスクの作成時には、必要以上に大きなサイズや、余裕を持たせたパフォーマンス上限でプロビジョニングすることも可能です。これにより、計画が簡素化され、ディスクのプロビジョニングされたサイズやパフォーマンスを変更することなく、将来的な拡張にも対応できます。

また、高可用性、クロスリージョン レプリケーションと復元、バックアップ、スナップショットなどの包括的なデータ保護機能を活用することで、ビジネス クリティカルなワークロードを保護することもできます。

機能、容量、マシンサポート、パフォーマンスに関する詳細については、ドキュメントをご覧ください。

一般的なワークロードに関する推奨事項

適切な Hyperdisk アーキテクチャを簡単に選べるように、よく見られる一般的なワークロードに対する推奨事項の概要を以下に示します。エンタープライズ環境では、Hyperdisk ポートフォリオを活用し、アプリケーションの各コンポーネントのニーズに応じて最適な Hyperdisk のタイプを組み合わせることで、3 層アプリケーション全体を最適化できます。

汎用データベースを含むエンタープライズ アプリケーション:

Hyperdisk Balanced とストレージ プールを組み合わせることで、一般的なデータベース ワークロードをはじめとした、幅広い汎用ワークロードに優れたソリューションを提供します。Hyperdisk Balanced は、Clickhouse、MySQL、PostgreSQL など、ほとんどのデータベースの IOPS とスループットのニーズを満たし、標準的な価格帯で利用できます。Hyperdisk Balanced は、1 ボリュームあたり 16 万 IOPS を発揮し、AWS EBS gp3 ボリュームの 10 倍のパフォーマンスを実現します2。ストレージ プールを使用することで、効率を高め、計画を大幅に簡素化できます。また、典型的なデータベース ワークロードにおいても、Hyperdisk Balanced ボリュームや AWS EBS gp3 ボリュームと比較して、ストレージの費用を約 20～40% 削減できます3。

「Sentry.io は迅速なデバッグと問題解決を支援するプラットフォームであり、全世界で 400 万人以上の開発者と 13 万のチームに利用されています。Google Cloud の Hyperdisk を採用したことで、当社のビジネスの中核を担うイベント分析プラットフォームに、次世代に向けた柔軟なアーキテクチャを構築できました。大容量かつ高性能な Hyperdisk ストレージ プールにより、数週間かかっていた計画サイクルを数分に短縮でき、永続ディスクと比較してストレージの費用を 37% 削減することにも成功しました。」- Sentry、最高技術責任者、Dave Rosenthal 氏

「Blackline にとって高可用性は不可欠です。当社では、グローバル規模でミッション クリティカルな財務決算管理システムを展開するにあたり、大規模なデータベース フェイルオーバー クラスタリングを運用しています。このような重要なワークロードを Google Cloud に移行でき、大変喜ばしく思います。Hyperdisk Balanced High Availability により、お客様が求めるパフォーマンス、容量、コスト効率、レジリエンスの要件を満たし、さらにはグローバル規模での金融規制への対応にも貢献しています。」- Blackline、SVP Cloud エンジニアリング＆オペレーション、Justin Brodley 氏

Tier-0 データベース

SAP HANA、SQL Server、Oracle データベースなどのハイエンドかつパフォーマンス重視のデータベースには、Hyperdisk Extreme が妥協のないパフォーマンスを提供します。Hyperdisk Extreme を使用すると、単一ボリュームで最大 35 万 IOPS と 10 GiB/秒のスループットを実現できます。

AI、分析、スケールアウト ワークロード

Hyperdisk は、最も要求の厳しい次世代の ML とハイ パフォーマンス コンピューティングのワークロードに対して、優れたソリューションを提供します。

動的にスケールする AI、分析ワークロード、および高性能ファイル システム

需要の変動が激しく、ピーク時のスループットや IOPS を必要とするワークロードには、Hyperdisk Balanced とストレージ プールが効果的です。これらのワークロードには、お客様が管理する並列ファイル システムや、アクセラレータ クラスタ向けのスクラッチ ディスクが含まれます。ストレージ プールの動的なリソース割り当てにより、ピーク時でもパフォーマンスを確保でき、手動調整の手間や非効率なオーバープロビジョニングを回避できます。さらに、ストレージ プールを設定することで、ディスク単位での計画が大幅に簡素化されます。注: フルマネージドのファイル システムをお求めの場合は、Managed Lustre をご検討ください。

「Hudson River Trading（HRT）では、定量取引に最先端の ML を活用しています。Google Cloud のアクセラレータ最適化マシン、Dynamic Workload Scheduler（DWS）、および Hyperdisk を導入したことで、最先端モデルの開発が大幅に加速しました。Hyperdisk ストレージ プールにより、通常の Hyperdisk と比較してストレージ費用を約 50% 削減でき、計画にかかる手間も最小限に抑えられました。」- Hudson River Trading、システム エンジニア、Ragnar Kjørstad 氏

AI / ML と HPC のデータ読み込みの高速化

Hyperdisk ML は、推論、トレーニング、HPC ワークロードのデータ読み込み時間の高速化に特化したストレージです。一般的な代替手段と比較してモデルの読み込み時間を 3～5 倍高速化します4。Hyperdisk ML は、Google Cloud の他のストレージ サービスと比べて、サービング タスクに特に優れた性能を発揮します。1 ボリュームあたり最大 1.2 TiB/秒の総スループットを実現し、多数の VM に対して同時に高い総スループットを提供します。これにより、競合製品と比較して 100 倍以上のパフォーマンスを達成します5。1 回の書き込みで最大 64 TiB のディスクを作成し、読み取り専用モードで複数の VM インスタンスを同じボリュームにアタッチできます。Hyperdisk ML を使用すると、GPU や TPU などの最も高価なコンピューティング リソースのデータ読み込み時間を短縮できます。詳細については、g.co/cloud/storage-design-ai をご覧ください。

「Resemble AI では、独自のディープ ラーニング モデルを活用して、テキスト読み上げや音声変換による高品質な AI 音声を生成しています。Google Cloud の A3 VM と NVIDIA H100 GPU、Hyperdisk ML を組み合わせることで、トレーニング ワークフローを大幅に改善できました。Hyperdisk ML によりデータローダのパフォーマンスが劇的に向上し、類似のソリューションに比べてエポック サイクルを 2 倍の速度で実行できるようになりました。この高速化により、エンジニアリング チームは柔軟に実験を重ねながら大規模なトレーニングを実施し、プロトタイプから本番環境へと迅速に移行できるようになりました。」- Resemble AI、CEO、Zohaib Ahmed 氏

「Abridge は、生成 AI を活用して患者と医療従事者の間の会話をリアルタイムで要約することで、臨床文書に革命をもたらしています。Hyperdisk ML を採用したことで、モデルの読み込み速度が最大 76% 向上し、Pod の初期化時間が短縮されました。」- Abridge、ソフトウェア エンジニア、Taruj Goyal 氏

大容量の分析ワークロード:

Hadoop や Kafka などの大規模なデータ分析ワークロードは、ディスク レイテンシの変動にあまり影響されません。そのため、Hyperdisk Throughput は高スループットかつ費用対効果の高いソリューションとなります。スループットを自由に構成できるうえ、1 GiB あたりのコストが低いため、TCO を抑えながら大量のデータを処理するのに最適です。

Hyperdisk のサイズ設定と設定方法

ワークロードに適した Hyperdisk ボリューム タイプを選択してサイズ設定する際には、以下の事項を確認してください。

• ストレージ管理。ワークロードのブロック ストレージをプール単位で管理するか、個別に管理するかを決定します。ワークロードの容量が単一のプロジェクトとゾーンで 10 TiB を超える場合は、Hyperdisk ストレージ プールを使用して TCO を削減し、計画を簡素化することを検討してください。ストレージ プールはディスクのパフォーマンスに影響しません。ただし、レプリケーションや高可用性など、一部のデータ保護機能はストレージ プールではサポートされていません。

• レイテンシ。SSD 並みのミリ秒未満のレイテンシが求められるワークロードには、Hyperdisk Balanced または Hyperdisk Extreme が適しています。

• IOPS またはスループット。単一ボリュームから 16 万 IOPS 未満または 2.4 GiB/秒未満のスループットが必要なアプリケーションには、Hyperdisk Balanced が最適です。それ以上の性能が必要な場合は、Hyperdisk Extreme を検討してください。

• パフォーマンスと容量のサイズ設定。Hyperdisk は容量とパフォーマンスを個別に設定できるため、必要なリソース分のみのお支払いで利用できます。この機能を活用して、ディスクのピーク IOPS、スループット、およびワークロードに必要な容量を把握することで、TCO を削減できます。具体的には、そのワークロードを処理するディスクに保存されるデータ量を、GiB または TiB 単位で見積もります。ワークロードがすでに Google Cloud 上で稼働している場合は、コンソールの Metrics Explorer でこれらの指標を確認できます。

もう一つの重要な考慮事項は、ワークロードに求められるビジネスの継続性とデータ保護のレベルです。ワークロードによって、目標復旧時点（RPO）と目標復旧時間（RTO）の要件が異なるため、それにかかる費用も変わってきます。データ保護の方針を決める際には、ワークロードの重要度を考慮しましょう。重要なアプリケーションやワークロードほど、データ損失やダウンタイムに対する許容度が低くなります。ビジネス オペレーションに不可欠なアプリケーションでは、RPO はゼロ、RTO は数秒程度であることが求められます。Hyperdisk のビジネスの継続性とデータ保護は、お客様が求めるパフォーマンス、容量、コスト効率、レジリエンスの要件を満たすとともに、世界中の金融規制への対応にも貢献します。

ワークロードに適した Hyperdisk の種類を選ぶ際に、考慮すべき事項をいくつか紹介します。

• 攻撃や悪意のある内部者からワークロードを保護するにはどうすればよいですか？Google Cloud Backup Vault を使用すると、バックアップの不変性や消去不能性、サイバー レジリエンスを確保でき、バックアップのレポート作成やコンプライアンス対応も管理できます。バックアップを自己管理する場合は、ワークロード向けの Hyperdisk 標準スナップショットも利用できます。

• ユーザーエラーや不具合のあるアップグレードによる影響から、低い RPO / RTO を保ちつつ、コスト効率よくデータを保護するにはどうすればよいですか？インスタント スナップショットによるポイントインタイム リカバリをご利用ください。この機能を使うと、非常に低い RPO と RTO で、ユーザーエラーや不具合のあるアップグレードによるデータ損失のリスクを最小限に抑えられます。チェックポイントの作成はほぼ瞬時に行えます。

• 複数のロケーションにわたってレジリエンスを確保しながら、重要なワークロード（MySQL など）を簡単にデプロイするにはどうすればよいですか？Hyperdisk HA をご利用ください。これは、フェイルオーバー クラスタリングを活用する SQL Server など、高可用性と高速フェイルオーバーが求められるシナリオに最適です。このようなワークロードでは、マルチライター サポートを備えた Hyperdisk Balanced High Availability の新しい機能を利用することもできます。これにより、2 つのゾーンで RPO=0 の同期レプリケーションを実現し、ワークロードに最適化されたストレージを利用したクラスタ化コンピューティングを実行できます。

• 障害が発生した場合、ワークロードを別の場所で迅速かつ確実に復元し、その復元プロセスを確認するための訓練を行うにはどうすればよいですか？Hyperdisk 非同期レプリケーションを使用した障害復旧機能をご利用ください。これにより、リージョン間の継続的なレプリケーションやリージョン障害からの復旧が可能になります。また、クローン作成による障害復旧訓練の迅速な検証もサポートしています。さらに、リージョン間でワークロードのフェイルオーバーが必要になった際にも、整合性グループポリシーにより複数のディスクに分散されたワークロード データを確実に復元できます。

つまり、Hyperdisk はワークロードに応じてブロック ストレージを最適化できる豊富な選択肢を備えています。さらに、適切な Hyperdisk を選択してストレージ プールなどの機能を活用することで、TCO を削減し、管理を簡素化できます。詳しくは、ウェブサイトをご覧ください。お客様に合わせた推奨事項については、Google Cloud アカウント チームにお問い合わせください。

^{1. 2025 年 3 月時点で公開されている Amazon EBS、Azure マネージド ディスクの情報}

^{2. 2025 年 5 月時点での Amazon EBS gp3 ボリュームの最大 IOPS（ボリュームあたり）との比較}

^{3. 2025 年 3 月時点の正規価格に基づき、容量 50～150 TiB、ピーク IOPS 25K～75K、圧縮率 25% の場合の Amazon EBS gp3 ボリュームとの比較}

^{4. 2025 年 3 月時点の Google 内部ベンチマークに基づき、大規模ノードサイズにおいて Rapid Storage、Anywhere Cache を利用した GCSFuse、Parallelstore、Lustre と比較した場合}

^{5. 2025 年 3 月時点で公開されている Microsoft Azure Ultra SSD および Amazon EBS io2 BlockExpress のパフォーマンスに基づく。}

^{このブログの執筆にご協力いただいた David Seidman 氏と Ruwen Hess 氏に、著者一同から感謝を申し上げたいと思います。}

-Google、グループ プロダクト マネージャー、Ben Gitenstein
-Google Cloud、プロダクト管理担当、Sai Gopalan