このガイドは、クラウド ワークロードのストレージ要件を評価し、 Google Cloudで使用可能なストレージ オプションを理解して、最適なビジネス価値を実現するストレージ戦略を設計する際に役立ちます。
主な設計の推奨事項の図解サマリーについては、ディシジョン ツリーの図をご覧ください。
AI / ML ワークロードのストレージ サービスの選択については、 Google Cloudで 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 クラスタと Google Kubernetes Engine クラスタ用の NFS ファイル サーバーを使用するファイルベースのストレージ。 ユースケースに適したサービスティア（ベーシック、ゾーン、リージョン）を選択できます。 |
| Google Cloud Managed Lustre |
AI、ハイ パフォーマンス コンピューティング（HPC）、データ集約型アプリケーション向けの低レイテンシの並列ファイル システム。 |
| NetApp Volumes | NFS または SMB を使用するファイルベースのストレージ。 ユースケースに適したサービスレベル（Flex、Standard、Premium、Extreme）を選択できます。 |
| その他のオプション | ファイル サーバー オプションの概要をご覧ください。 |
オブジェクト ストレージ
データは、「バケット」のフラットな階層に「オブジェクト」として保存されます。各オブジェクトにはグローバルに一意の ID が割り当てられます。オブジェクトには、システム割り当てとユーザー定義のメタデータがあり、データの整理や管理に役立ちます。アプリケーションは、REST API またはクライアント ライブラリを使用してオブジェクト ID を参照し、データにアクセスします。
Cloud Storage では、多様なデータタイプ向けに低コストで耐久性に優れた無制限のオブジェクト ストレージを用意しています。Cloud Storage に保存したデータには、 Google Cloud内外のどこからでもアクセスできます。複数のリージョンにわたる冗長性（オプション）によって、最大限の信頼性を実現できます。データの保持とアクセス頻度の要件に適したストレージ クラスを選択できます。
比較分析
次の表に、Google Cloudのストレージ サービスの主な機能を示します。
| Persistent Disk | Hyperdisk | ローカル SSD | Filestore | Managed Lustre | NetApp Volumes | Cloud Storage | |
|---|---|---|---|---|---|---|---|
| 容量 |
ディスクあたり 10 GiB～64 TiB VM あたり最大 257 TiB |
ディスクあたり 4 GiB～64 TiB VM あたり最大 512 TiB ストレージ プールあたり 10 TiB ～ 1 PiB |
ディスクあたり 375 GiB VM あたり最大 12 TiB Titanium SSD は、大容量のローカル SSD オプションです。 |
インスタンスあたり 1 ～ 100 TiB | 18 TiB ～ 8 PiB | ストレージ プールあたり 1 TiB ～ 10 PiB ボリュームあたり 1 GiB ～ 1 PiB |
下限値、上限値なし |
| スケーリング |
|
スケールアップ | スケーラビリティなし |
|
スケーラブル | スケールアップ / ダウン | 使用状況に応じて自動的にスケール |
| 共有 |
サポート対象 | サポート対象 | 共有不可 | 複数の Compute Engine VM、リモート クライアント、GKE クラスタにマウント可能 | 複数の Compute Engine VM と GKE クラスタにマウント可能。 | 複数の Compute Engine VM と GKE クラスタにマウント可能 |
|
| 暗号鍵のオプション |
|
|
Google-owned and Google-managed encryption keys |
|
Google-owned and Google-managed encryption keys |
|
|
| 永続性 |
ディスクの存続期間 | ディスクの存続期間 | エフェメラル（VM が停止または削除されるとデータは失われる） | Filestore インスタンスの存続期間 | Managed Lustre インスタンスの存続期間 | ボリュームの存続期間 | バケットの存続時間 |
| 可用性 |
|
|
ゾーン | ゾーン |
|
| |
| パフォーマンス |
ディスクサイズと CPU 数による線形スケーリング | 動的スケーリングの永続ストレージ | 高パフォーマンスのスクラッチ ストレージ |
|
プロビジョニングされた容量による線形スケーリングと複数のパフォーマンス ティア オプション | スケーラブルなパフォーマンス サービスレベルによって異なる |
|
| 管理 |
手動でのフォーマットとマウント | 手動でのフォーマットとマウント | 手動でのフォーマット、ストライプ、マウント | フルマネージド | フルマネージド | フルマネージド | フルマネージド |
次の表に、各 Google Cloudストレージ オプションが適しているワークロード タイプを示します。
| ストレージ オプション | ワークロードの種類 |
|---|---|
| Persistent Disk |
|
| Hyperdisk |
|
| ローカル SSD |
|
| Filestore |
|
| Managed Lustre |
|
| NetApp Volumes |
|
| Cloud Storage |
|
ストレージ オプションを選択する
ストレージ オプションの選択には、次の 2 つのステップがあります。
- 必要なストレージ サービスを決定する。
- 特定のサービスに必要な機能と設計オプションを選択する。
サービス固有の機能と設計オプションの例
Persistent Disk
- デプロイのリージョンとゾーン
- リージョン レプリケーション
- ディスクタイプ、サイズ、IOPS（エクストリーム Persistent Disk の場合）
- 暗号鍵: Google が所有し管理、顧客管理、または顧客指定
- スナップショット スケジュール
Hyperdisk
- デプロイゾーン
- ディスクタイプ、サイズ、スループット（Hyperdisk Throughput の場合）、IOPS（Hyperdisk Extreme の場合）
- 暗号鍵: Google が所有し管理、顧客管理、または顧客指定
- スナップショット スケジュール
Filestore
- デプロイのリージョンとゾーン
- インスタンスの階層
- 容量
- IP 範囲: 自動割り振りまたはカスタム
- アクセス制御
NetApp Volumes
- デプロイ リージョン
- ストレージ プールのサービスレベル
- プールとボリュームの容量
- ボリューム プロトコル
- ボリューム エクスポート ルール
Cloud Storage
- ロケーション: マルチリージョン、デュアルリージョン、シングル リージョン
- ストレージ クラス: Standard、Nearline、Coldline、Archive
- アクセス制御: 均一またはきめ細かい管理
- 暗号鍵: Google が所有し管理、顧客管理、または顧客指定
- 保持ポリシー
ストレージに関する推奨事項
作業の開始にあたり、以下の推奨事項を参考にして、要件を満たすストレージ サービスと機能を選択してください。AI ワークロードと ML ワークロードに固有のガイダンスについては、 Google Cloudで AI ワークロードと ML ワークロードのストレージを設計するをご覧ください。
一般的なストレージの推奨事項は、このドキュメントの後半でディシジョン ツリーとしても掲載しています。
並列ファイル システムが必要なアプリケーションには、Managed Lustre を使用します。
ファイルベースのアクセスが必要なアプリケーションの場合は、アクセス プロトコル、可用性、パフォーマンスの要件に基づいて適切なファイル ストレージ サービスを選択します。
アクセス プロトコル 推奨事項 NFS - リージョンの可用性と容量に応じてスケーリングする高いパフォーマンスが必要な場合は、Filestore Regional を使用します。
- ゾーンの可用性が十分であっても、容量に応じてスケーリングする高いパフォーマンスが必要な場合は、Filestore Zonal または NetApp Volumes Premium または Extreme を使用します。
- それ以外の場合は、Filestore Basic または NetApp Volumes を使用します。
Filestore のサービスティアの違いについては、 サービスティアをご覧ください。
SMB NetApp Volumes を使用します。 高パフォーマンスのプライマリ ストレージが必要なワークロードの場合は、要件に応じて Hyperdisk、ローカル SSD、または Persistent Disk を使用します。
要件 推奨事項 高速スクラッチ ディスクまたはキャッシュ ローカル SSD ディスク（エフェメラル）を使用します。 パフォーマンスと容量を個別にスケーリングできるブロック ストレージ Hyperdisk を使用します。要件に基づいて適切なディスクタイプを選択します。
- 汎用ワークロード:
hyperdisk-balanced - 高パフォーマンス データベースなどの高 I/O ワークロード:
hyperdisk-extreme - スケールアウト分析、費用重視のアプリ用のデータドライブ、コールド ストレージ:
hyperdisk-throughput - 読み取り専用モードで複数の VM に高いスループットを必要とする ML ワークロード: 読み取り専用モードの
hyperdisk-ml - 同じディスクへの書き込みアクセスが同時に行われるリージョン内の複数の VM: マルチライター モードの
hyperdisk-balanced-high-availability
詳細については、 Google Cloud Hyperdisk についてをご覧ください。
スケーラブルな容量を備えたブロック ストレージ Persistent Disk を使用します。要件に基づいて適切なディスクタイプを選択します。
- シーケンシャル IOPS:
pd-standard - IOPS 集約型のワークロード:
pd-extremeまたはpd-ssd - パフォーマンスとコストのバランス:
pd-balanced
詳細については、Persistent Disk についてをご覧ください。
- 冗長性の要件に応じて、ゾーンディスクまたはリージョン ディスクを選択します。
要件 推奨事項 リージョン内の単一ゾーンでの冗長性 Hyperdisk またはゾーン Persistent Disk を使用します。 リージョン内の複数のゾーンにまたがる冗長性 Hyperdisk High Availability またはリージョン Persistent Disk を使用します。
- 汎用ワークロード:
無制限のスケールでグローバルに利用可能なストレージが必要な場合は、Cloud Storage を使用します。
データアクセスの頻度と保存期間に応じて、適切な Cloud Storage クラスを選択してください。
要件 推奨> アクセス頻度が異なるか、データ保持期間が不明であるか、予測できません。 Autoclass 機能を使用すると、各オブジェクトのアクセス・パターンに基づいて、バケット内のオブジェクトを自動的に適切なストレージ クラスに移行できます。 高スループットの分析やデータレイク、ウェブサイト、ストリーミング動画、モバイルアプリなど、アクセス頻度の高いデータ用のストレージ。 Standard ストレージ クラスを使用します。
頻繁にアクセスされるデータをキャッシュに保存し、クライアントに近いロケーションから配信するには、Cloud CDN を使用します。
データの変更頻度が低く、読み取り頻度が高い読み取り負荷の高いワークロード（ML トレーニング、推論、分析など）では、Anywhere 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 コンソール、gcloud CLI、Cloud Storage API、またはクライアント ライブラリを使用して、Cloud Storage バケットにオンラインでデータをアップロードします。
データ転送方法を選択する際は、データサイズ、時間の制約、帯域幅の可用性、費用目標、セキュリティおよびコンプライアンス要件などの要素を考慮してください。 Google Cloudへのデータ転送の計画と実装については、 Google Cloudへの移行: 大規模なデータセットの転送をご覧ください。
ストレージ オプションのディシジョン ツリー
次のディシジョン ツリーの図では、前述の Google Cloudストレージの推奨事項について説明します。AI ワークロードと ML ワークロードに固有のガイダンスについては、 Google Cloudで AI / ML ワークロードのストレージを設計するをご覧ください。
次のステップ
- Google Cloud 料金計算ツールを使用してストレージ費用を見積もる。
- セキュリティ、復元力、費用、パフォーマンスが最適化されたクラウド トポロジを構築するためのベスト プラクティスについて確認する。
- HPC ワークロードに Lustre などの並列ファイル システムを使用するケースを確認する。
寄稿者
著者: Kumar Dhanagopal | クロスプロダクト ソリューション デベロッパー
その他の関係者:
- ソリューション アーキテクト | Brennan Doyle
- CTO オフィス テクニカル ディレクター | Dean Hildebrand
- グループ プロダクト マネージャー | Geoffrey Noer
- テクニカル ライター | Jack Zhou
- プロダクト マネジメント担当ディレクター | Jason Wu
- ソリューション アーキテクト | Jeff Allen
- Samantha He | テクニカル ライター
- Sean Derrington | ストレージ担当グループ プロダクト マネージャー