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