このガイドは、クラウド ワークロードのストレージ要件を評価し、 Google Cloudで使用可能なストレージ オプションを理解して、最適な技術的価値とビジネス価値を実現するストレージ戦略を設計する際に役立ちます。
AI / ML ワークロードのストレージ サービスの選択については、AI Hypercomputer の AI / ML ワークロードのストレージ サービスの概要をご覧ください。
設計プロセスの概要
クラウド アーキテクトとして、クラウド ワークロードのストレージを計画する場合は、まずワークロードの機能的特性、セキュリティの制約、復元力に関する要件、パフォーマンスの期待値、コスト目標を検討する必要があります。次に、Google Cloudで利用可能なストレージ サービスと機能を確認する必要があります。その後、要件と使用可能なオプションに基づいて、必要なストレージ サービスと機能を選択します。次の図は、この 3 フェーズで構成される設計プロセスを示しています。
要件を定義する
このセクションのアンケートを使用して、 Google Cloudにデプロイするワークロードの重要なストレージ要件を定義します。
ストレージ要件を定義するためのガイドライン
アンケートに回答する際は、次のガイドラインを考慮してください。
要件を細かく定義する
たとえば、アプリケーションにネットワーク ファイル システム（NFS）ベースのファイル ストレージが必要な場合は、必要な NFS のバージョンを特定します。
将来の要件を検討する
たとえば、現在のデプロイ環境はアジアの国々のユーザーにサービスを提供していますが、他の大陸にも事業を拡大する可能性があるとします。この場合は、新しい事業地域のストレージ関連の規制要件を考慮する必要があります。
クラウド固有の機会と要件を検討する
クラウド固有の機会を活用してください。
たとえば、Cloud Storage に格納されたデータのストレージ費用を最適化するには、データ保持ポリシーとライフサイクル構成を使用して保存期間を制御できます。
クラウド固有の要件を検討します。
たとえば、オンプレミス データが単一のデータセンターに存在し、冗長性を確保するために、移行後のデータを 2 つのGoogle Cloud ロケーションに複製する必要があるとします。
アンケート
以下のアンケートは計画に関する完全なチェックリストではありません。これらを出発点として使用し、 Google Cloudにデプロイするワークロードのすべてのストレージ要件を体系的に分析します。
ワークロードの特性を評価する
保存する必要があるデータの種類
例
- 静的ウェブサイトのコンテンツ
- 障害復旧のためのバックアップとアーカイブ
- コンプライアンスに関する監査ログ
- ユーザーが直接ダウンロードする大規模なデータ オブジェクト
- 取引データ
- 構造化されていない異種データ
必要な容量はどのくらいか。現在および将来の要件を検討します。
使用率に応じて容量を自動的にスケーリングする必要があるのか。
アクセス要件。たとえば、 Google Cloudの外部からデータにアクセスする必要があるかどうか。
想定している読み取り / 書き込みパターン。
例
- 頻繁に書き込みと読み取りを行う
- 頻繁に書き込みを行うが、時折読み取りを行う
- 書き込みと読み取りを時折行う
- 書き込みを時折行い、読み取りを頻繁に行う
NFS を使用するなど、ワークロードでファイルベースのアクセスが必要か。
複数のクライアントで同時にデータの読み取りや書き込みを行える必要があるか。
セキュリティの制約を特定する
データ暗号化の要件は何か。たとえば、管理する鍵を使用する必要があるか。
データ所在地の要件があるか。
データ復元に関する要件を定義する
- ワークロードで低レイテンシのキャッシュ保存またはスクラッチ領域が必要か
- 冗長性を確保するために、クラウドにデータを複製する必要があるか
- 複製されたデータセットに対する厳密な読み取り / 書き込みの整合性が必要か。
パフォーマンスの予測値を設定する
必要な I/O レートはどのくらいか。
アプリケーションでどの程度の読み取りと書き込みのスループットが必要か。
どのような環境でストレージが必要か。特定のワークロードで、本番環境用に高パフォーマンスのストレージが必要になる場合がありますが、本番環境以外では低パフォーマンスのオプションを選択できます。
ストレージ オプションを確認する
Google Cloud は、すべての主要なストレージ形式（ブロック、ファイル、オブジェクト）のストレージ サービスを提供します。各ストレージ形式で使用できるサービスの機能、設計オプション、相対的な利点を確認して評価します。
概要
ブロック ストレージ
ブロック ストレージに保存するデータはチャンクに分割されます。各ブロックは、一意のアドレスを持つ個別のブロックとして格納されます。アプリケーションは、適切なブロック アドレスを参照することでデータにアクセスします。ブロック ストレージは、トランザクション処理などの高 IOPS ワークロード用に最適化されています。これは、オンプレミスのストレージ エリア ネットワーク（SAN）や直接接続ストレージ（DAS）システムに似ています。
Google Cloud のブロック ストレージ オプションは、Compute Engine サービスの一部です。
| オプション | 概要 |
|---|---|
| Persistent Disk | Compute Engine VM と Google Kubernetes Engine（GKE）クラスタにデプロイされたエンタープライズ アプリケーションとデータベース アプリケーション専用のハードディスク ドライブ（HDD）とソリッド ステート ドライブ（SSD）。 |
| Google Cloud Hyperdisk | Compute Engine VM と GKE クラスタのための高速で冗長なネットワーク ストレージ。容量を動的に増やし、パフォーマンスを構成できます。 |
| ローカル SSD | 高パフォーマンス アプリケーション用にローカルで接続されるエフェメラル ブロック ストレージ。 |
ファイル ストレージ
データは、オンプレミス ネットワーク接続ストレージ（NAS）と同様に、ファイルの階層で整理され、フォルダに保存されます。ファイル システムは、NFS やサーバー メッセージ ブロック（SMB）などのプロトコルを使用してクライアントにマウントできます。アプリケーションは、関連するファイル名とディレクトリ パスを使用してデータにアクセスします。
Google Cloud には、ファイル ストレージ用のさまざまなフルマネージド ソリューションが用意されています。
| 解決策 | 概要 |
|---|---|
| Filestore |
Compute Engine VM クラスタと GKE クラスタ用の NFS ファイル サーバーを使用するファイルベースのストレージ。 |
| Google Cloud Managed Lustre |
AI、ハイ パフォーマンス コンピューティング（HPC）、データ集約型アプリケーション向けの低レイテンシの並列ファイル システム。 |
| Google Cloud NetApp Volumes | NFS、SMB、ブロック ストレージ プロトコルを使用するファイルベースのストレージ。 |
オブジェクト ストレージ
データは、「バケット」のフラットな階層に「オブジェクト」として保存されます。各オブジェクトにはグローバルに一意の ID が割り当てられます。オブジェクトには、システム割り当てとユーザー定義のメタデータがあり、データの整理や管理に役立ちます。アプリケーションは、REST API またはクライアント ライブラリを使用してオブジェクト ID を参照し、データにアクセスします。
Cloud Storage は、さまざまなデータ型に対応する低コストで耐久性とスケーラビリティに優れたオブジェクト ストレージを提供します。Cloud Storage に保存したデータには、 Google Cloud内外のどこからでもアクセスできます。複数のリージョンにわたる冗長性（オプション）によって、高可用性と信頼性を実現できます。データの保持とアクセス頻度の要件に適したストレージ クラスを選択できます。
比較分析
次の表に、Google Cloudのストレージ サービスの主な機能を示します。
| Persistent Disk | Hyperdisk | ローカル SSD | Filestore | Managed Lustre | NetApp Volumes | Cloud Storage | |
|---|---|---|---|---|---|---|---|
| 容量上限 |
ディスクあたり 64 TiB、VM あたり 257 TiB。 最新の仕様: Persistent Disk のドキュメント |
ディスクあたり 64 TiB、VM あたり 512 TiB、ストレージ プールあたり 5 PiB。 Exapools は、容量の大きい Hyperdisk プールです。 最新の仕様: Hyperdisk のドキュメント |
ディスクあたり 375 GiB、VM あたり 12,000 GiB。 Titanium SSD ディスクは、ディスクあたり最大 6 TiB、VM あたり最大 84,000 GiB をサポートします。 最新の仕様: ローカル SSD のドキュメント |
インスタンスあたり 100 TiB（サービスティアによって異なります）。 | インスタンスあたり 80.1 PiB（パフォーマンス ティアによって異なります）。 |
ストレージ プールあたり 20 PiB、ボリュームあたり 20 PiB。 最新の仕様: NetApp Volumes のドキュメント |
オブジェクトあたり 5 TiB。バケットあたりの上限はありません（Rapid Bucket を除く）。 最新の仕様: Cloud Storage ドキュメント |
| スケーリング |
|
|
スケーラビリティなし | スケールアップとスケールダウン（ゾーンティアとリージョン ティア） | スケールアップ | スケールアップ / ダウン | 使用状況に応じて自動的にスケール |
| 共有 |
サポート対象 | サポート対象 | 共有不可 | 複数の Compute Engine VM、リモート クライアント、GKE クラスタにマウント可能 | 複数の Compute Engine VM と GKE クラスタにマウント可能 | 複数の Compute Engine VM、リモート クライアント、GKE クラスタにマウント可能 |
|
| 暗号鍵のオプション |
|
|
Google-owned and Google-managed encryption keys |
|
|
|
|
| 永続性 |
ディスクの存続期間 | ディスクの存続期間 | エフェメラル（VM が停止または削除されるとデータは失われる） | Filestore インスタンスの存続期間 | Managed Lustre インスタンスの存続期間 | ボリュームの存続期間 | バケットの存続時間 |
| 可用性 |
|
|
ゾーン | ゾーン |
|
| |
| パフォーマンス |
ディスクサイズと CPU 数による線形スケーリング | 動的スケーリングの永続ストレージ | 高パフォーマンスのスクラッチ ストレージ | ゾーンとリージョン: カスタム パフォーマンス | 選択したパフォーマンス ティアに基づくスケーリング。 | スケーラブルなパフォーマンス サービスレベルによって異なる。 |
|
| 管理 |
手動でのフォーマットとマウント | 手動でのフォーマットとマウント | 手動でのフォーマット、ストライプ、マウント | フルマネージド | フルマネージド | フルマネージド | 完全管理 |
次の表に、各 Google Cloudストレージ オプションが適しているワークロード タイプを示します。
| ストレージ オプション | ワークロードの種類 |
|---|---|
| Hyperdisk または Persistent Disk |
|
| ローカル SSD |
|
| Filestore |
|
| Managed Lustre |
|
| NetApp Volumes |
|
| Cloud Storage |
|
ストレージ オプションを選択する
ストレージ オプションの選択には、次の 2 つのステップがあります。
- 必要なストレージ サービスを決定する。
- 特定のサービスに必要な機能と設計オプションを選択する。
サービス固有の機能と設計オプションの例
Persistent Disk
- デプロイのリージョンとゾーン
- リージョン レプリケーション
- ディスクタイプ、サイズ、IOPS（エクストリーム永続ディスクの場合）
- 暗号鍵: Google-owned and Google-managed encryption keys、または顧客管理
- スナップショット スケジュール
Hyperdisk
- デプロイのリージョンとゾーン
- ディスクタイプ、サイズ、プロビジョニングされた IOPS またはスループット
- 暗号鍵: Google-owned and Google-managed encryption keys、または顧客管理
- レプリケーション: 同期または非同期
- スナップショット スケジュール
Filestore
- デプロイのリージョンとゾーン
- インスタンスの階層
- 容量
- IP 範囲: 自動割り振りまたはカスタム
- アクセス制御
Managed Lustre
- デプロイゾーン
- 容量とパフォーマンスの階層
- 暗号鍵: Google-owned and Google-managed encryption keys、または顧客管理
NetApp Volumes
- デプロイ リージョン
- ストレージ プールのサービスレベル
- プールとボリュームの容量
- ボリューム プロトコル
- ボリューム エクスポート ルール
Cloud Storage
- ロケーション: マルチリージョン、デュアルリージョン、シングル リージョン、シングル ゾーン
- ストレージ クラス: Standard、Nearline、Coldline、Archive、Rapid
- アクセス制御: 均一またはきめ細かい管理
- 暗号鍵: Google-owned and Google-managed encryption keys、顧客管理、または顧客指定
- 保持ポリシー
ストレージに関する推奨事項
作業の開始にあたり、以下の推奨事項を参考にして、要件を満たすストレージ サービスと機能を選択してください。AI ワークロードと ML ワークロードに固有のガイダンスについては、AI Hypercomputer の AI ワークロードと ML ワークロードのストレージ サービスの概要をご覧ください。
並列ファイル システムが必要な AI、ML、HPC アプリケーションには、Managed Lustre を使用します。
ファイルベースのアクセスが必要なアプリケーションの場合は、アクセス プロトコル、可用性、パフォーマンスの要件に基づいて適切なファイル ストレージ サービスを選択します。
アクセス プロトコル 推奨事項 NFS - リージョンの可用性と構成可能な高いパフォーマンスが必要な場合は、Filestore Regional または NetApp Volumes Flex Unified を使用します。
- ゾーンの可用性で十分な場合:
- 容量とは別にパフォーマンスを構成するには、Filestore Zonal または NetApp Volumes Flex Unified を使用します。
- 容量に応じてスケーリングするパフォーマンスが必要な場合は、Filestore Zonal または NetApp Volumes Standard、Premium、Extreme を使用します。
詳細については、 Filestore のサービスティアと NetApp Volumes のサービスレベルをご覧ください。
SMB NetApp Volumes を使用します。 高パフォーマンスのプライマリ ストレージが必要なワークロードの場合は、要件に応じて Hyperdisk、ローカル SSD、または Persistent Disk を使用します。
要件 推奨事項 高速スクラッチ ディスクまたはキャッシュ ローカル SSD ディスク（エフェメラル）を使用します。 パフォーマンスと容量を個別にスケーリングできるブロック ストレージ Google が推奨する耐久性の高いブロック ストレージである Hyperdisk を使用します。これは、最新のマシンシリーズで必要です。要件に基づいて適切なディスクタイプを選択します。
- 汎用のワークロード:
hyperdisk-balanced - 高パフォーマンス データベースなどの高 I/O ワークロード:
hyperdisk-extreme - スケールアウト分析、費用重視のアプリ用のデータドライブ、コールド ストレージ:
hyperdisk-throughput - 読み取り専用モードで複数の VM に高いスループットを必要とする ML ワークロード: 読み取り専用モードの
hyperdisk-ml - 同じディスクへの書き込みアクセスが同時に行われる複数の VM: マルチライター モードの
hyperdisk-balanced-high-availability（リージョン内の 2 つのゾーン間）、hyperdisk-balanced、hyperdisk-extreme（単一ゾーン内）
詳細については、Hyperdisk についてをご覧ください。
以前の世代の VM 用のスケーラブルな容量を備えたブロック ストレージ Persistent Disk を使用します。要件に基づいて適切なディスクタイプを選択します。
- シーケンシャル IOPS:
pd-standard - IOPS 集約型のワークロード:
pd-extremeまたはpd-ssd - パフォーマンスとコストのバランス:
pd-balanced
詳細については、Persistent Disk についてをご覧ください。
- 冗長性の要件に応じて、ゾーンディスクまたはリージョン ディスクを選択します。
要件 推奨事項 リージョン内の単一ゾーンでの冗長性 Hyperdisk またはゾーン Persistent Disk を使用します。 リージョン内の複数のゾーンにまたがる冗長性 Hyperdisk Balanced High Availability またはリージョン Persistent Disk を使用します。
- 汎用のワークロード:
大規模でグローバルに利用可能なストレージが必要な場合は、Cloud Storage を使用します。
データアクセスの頻度と保存期間に応じて、適切な Cloud Storage クラスを選択してください。
要件 推奨事項 アクセス頻度が異なるか、データ保持期間が不明であるか、予測できません。 Autoclass 機能を使用すると、各オブジェクトのアクセス パターンに基づいて、バケット内のオブジェクトを自動的に適切なストレージ クラスに移行できます。 AI や ML のトレーニング、チェックポインティング、推論、分析など、ミリ秒未満のレイテンシと高スループットを必要とするワークロード用のゾーン ストレージ。 Rapid ストレージ クラスで Rapid バケットを使用します。 高スループットの分析やデータレイク、ウェブサイト、ストリーミング動画、モバイルアプリなど、アクセス頻度の高いデータ用のストレージ。 Standard ストレージ クラスを使用します。
頻繁にアクセスされるデータをキャッシュに保存し、クライアントに近いロケーションから配信するには、Cloud CDN を使用します。
データの変更頻度が低く、読み取り頻度が高い読み取り負荷の高いワークロード（ML トレーニング、推論、分析など）では、Rapid Cache を使用して読み取りパフォーマンスを向上させ、データ転送料金を削減できます。
アクセス頻度の低いデータ（少なくとも 30 日間保存できる）用の低コストのストレージ（バックアップやロングテールのマルチメディア コンテンツなど）。 Nearline ストレージ クラスを使用します。 アクセス頻度の低いデータ（障害復旧など）を少なくとも 90 日間保存できる低費用のストレージ。 Coldline ストレージ クラスを使用します。 アクセス頻度が低く、少なくとも 365 日間保存できるデータ（規制に関するアーカイブを含む）用の最小コストのストレージ。 Archive ストレージ クラスを使用します。 詳細な比較分析については、Cloud Storage のクラスをご覧ください。
データ転送オプション
適切な Google Cloud ストレージ サービスを選択した後、ワークロードをデプロイして実行するには、データを Google Cloudに転送する必要があります。転送する必要があるデータは、オンプレミスまたは他のクラウド プラットフォームに存在する可能性があります。
次の方法で Google Cloudにデータを転送できます。
- Storage Transfer Service を使用してオンラインでデータを転送: Cloud Storage、Amazon S3、Azure ストレージ サービス、オンプレミスのデータソースなどのオブジェクトおよびファイル ストレージ システム間の大量のデータの転送を自動化します。
- Transfer Appliance を使用してオフラインでデータを転送: ネットワーク接続と帯域幅が使用できない場合や制限されている場合、またはコストが高い場合に、大量のデータをオフラインで Google Cloud に転送して読み込みます。
- Cloud Storage にデータをアップロードする: Google Cloud コンソール、Google Cloud CLI、Cloud Storage API、またはクライアント ライブラリを使用して、Cloud Storage バケットにオンラインでデータをアップロードします。
データ転送方法を選択する際は、データサイズ、時間の制約、帯域幅の可用性、費用目標、セキュリティおよびコンプライアンス要件などの要素を考慮してください。 Google Cloudへのデータ転送の計画と実装については、データ転送オプションをご覧ください。
次のステップ
- Google Cloud 料金計算ツールを使用してストレージ費用を見積もる。
- セキュリティ、復元力、費用、パフォーマンスが最適化されたクラウド トポロジを構築するためのベスト プラクティスについて確認する。
- Cloud アーキテクチャ センターで、リファレンス アーキテクチャ、図、ベスト プラクティスを確認する。
協力者
著者: Kumar Dhanagopal | クロスプロダクト ソリューション デベロッパー
その他の関係者:
- ソリューション アーキテクト | Brennan Doyle
- CTO オフィス テクニカル ディレクター | Dean Hildebrand
- グループ プロダクト マネージャー | Geoffrey Noer
- テクニカル ライター | Jack Zhou
- プロダクト マネジメント担当ディレクター | Jason Wu
- Jeff Allen | ソリューション アーキテクト
- Samantha He | テクニカル ライター
- Sean Derrington | ストレージ担当グループ プロダクト マネージャー