Cloud Service
ストレージ
オブジェクト(Cloud Storage)・ブロック(Persistent Disk/Hyperdisk)・ファイル(Filestore)の使い分けと、ストレージクラス・ロケーション(冗長範囲)・ディスクタイプの選び方を即断する早見表。
3種類の使い分け
| タイプ | サービス | アクセス | 用途 |
|---|---|---|---|
| オブジェクト | Cloud Storage | HTTP(S) / API | 配信・バックアップ・データレイク |
| ブロック | Persistent Disk / Hyperdisk | 1 VM にアタッチ（読取専用は複数可） | OS（ブート）/ DB のディスク |
| ファイル | Filestore | 複数から同時マウント（NFSv3） | 共有フォルダ・GKE の ReadWriteMany |
迷ったら
- HTTP で取得・容量無制限・静的配信 → Cloud Storage（揮発でよい一時領域は VM の ローカル SSD）
- VM の高速ディスク（永続） → Persistent Disk / Hyperdisk（新規は容量と性能を独立指定できる Hyperdisk Balanced が起点）
- 複数サーバー / GKE Pod で同じファイルを共有 → Filestore（NFSv3）
オブジェクトは バケット（名前はグローバル一意・作成時にロケーションを決め後から変更不可）に入れます。一方 Persistent Disk / Filestore は VM とは独立した寿命を持つリソースで、インスタンスを停止・削除してもデータは残ります（PD のブートディスクは既定で VM 削除に連動する点だけ注意）。
オブジェクト: ストレージクラスの選び方
| アクセス頻度 | クラス | ポイント（最低保存期間） |
|---|---|---|
| 高頻度 | Standard | 最低保存期間なし・取得料金なし。標準・低レイテンシ |
| 低頻度（月1回程度） | Nearline | 保存安い／取得課金あり。即時アクセス可（最低30日） |
| まれ（四半期に1回程度） | Coldline | Nearline よりさらに保存安い／取得は高め。即時アクセス可（最低90日） |
| 長期保管（年1回未満） | Archive | 最安。即時に読めるが取得が最も高い（最低365日） |
アクセスパターンが読めなくても、バケットに Autoclass を有効化すれば、オブジェクトごとに最適なクラスへ自動で上げ下げします（AWS の S3 Intelligent-Tiering 相当）。あるいは オブジェクトライフサイクル管理で「N 日経過で Standard → Nearline → Coldline → Archive、その後削除」と自動移行も可能です。Glacier のリハイドレートのような待ち時間は無く、Archive でも即時に読める（ただし取得課金は高い）のが GCP の特徴。
オブジェクト: ロケーション（冗長範囲）の選び方
| 守りたい範囲 | ロケーションタイプ | ポイント |
|---|---|---|
| 低レイテンシ・データ所在を限定 | リージョン | 単一地域内の複数ゾーンへ冗長化。最安・データ所在を1地域に固定 |
| 地域災害に耐えつつ近接配置 | デュアルリージョン | 指定した2地域へ複製。可用性 SLA が高い |
| 大陸規模の高可用 | マルチリージョン | 大陸単位の複数地域へ複製。配信・高可用に最適 |
- イレブンナイン（99.999999999%）は耐久性（データを失わない確率）。可用性（アクセスできる割合）は別指標で、マルチ/デュアルリージョンの方が SLA 上は高い。
- バケットのロケーションは作成後に変更不可。移すには新バケットへコピーが必要なので、最初の選択が重要。
ブロック: ディスクタイプの選び方
| ディスクタイプ | 特性 / 課金の考え方 | 向いている用途 |
|---|---|---|
| pd-standard（標準HDD） | 最安・大容量・低IOPS（容量課金） | ログ / アーカイブ / シーケンシャル処理 |
| pd-balanced（バランスSSD） | 価格と性能のバランス（容量課金） | 一般的なブート / アプリ（既定の推奨） |
| pd-ssd（高性能SSD） | 高IOPS・低レイテンシ（容量課金） | DB / レイテンシ重視ワークロード |
| Hyperdisk Balanced / Extreme / Throughput | 容量・IOPS・スループットを個別にプロビジョニング | 性能を細かく最適化したい本番・高負荷DB / SAP HANA |
| ローカル SSD（Local SSD） | ホスト直結で最速だが揮発性（VM停止で消失） | 一時データ・キャッシュ・スクラッチ領域のみ |
- 複数同時マウント＝Filestore。PD は原則読み書き1 VM（複数からの読み取り専用マウントは可、
pd-ssd/Hyperdisk のマルチライターはクラスタFS前提の例外）。 - 旧世代 PD は性能がディスク容量と VM の vCPU 数に比例する。小容量だと IOPS/スループット上限が低い。Hyperdisk は容量と独立して性能を指定できる。
- ディスクは稼働中に拡張は可・縮小は不可（縮小はスナップショットから小さいディスクへ復元）。OS 側で
resize2fs等が別途必要。 - VM を停止してもデータは残るが、ディスク課金は継続する。
- 永続が必要なデータをローカル SSD に置くのは NG（VM 停止・ホスト障害で消失）。
ブロック: ゾーン障害への備え
| 守りたい範囲 | 選ぶもの | ポイント |
|---|---|---|
| 単一ゾーン（既定） | ゾーン PD | 作成ゾーン内のみ。別ゾーンへはスナップショット/クローン経由 |
| ゾーン障害（同期） | リージョン PD | リージョン内の2ゾーンへ同期レプリケーション。強制アタッチでフェイルオーバー |
| 世代バックアップ・別リージョン復元 | スナップショット | 増分で取得しリージョン/マルチリージョンに保存。別リージョンへ復元可 |
ゾーン障害に耐えたい本番 DB などは リージョン PD（2ゾーン同期）にし、加えてスナップショットスケジュールで定期バックアップと世代管理を自動化します。スナップショットは増分課金なので、保持期間で古い世代を整理するとコストを抑えられます。
ファイル: Filestore のティア選び
| ティア | 可用性 / 性能 | 向いている用途 |
|---|---|---|
| BASIC_HDD（旧 Standard） | 単一ゾーン・HDD・低単価 | 大容量で性能要件が低い共有・アーカイブ寄り |
| BASIC_SSD（旧 Premium） | 単一ゾーン・SSD・中性能 | 一般的なファイル共有・Web コンテンツ |
| ZONAL | 単一ゾーン・高スループット | HPC / レンダリング等の高性能な単発ワークロード |
| REGIONAL / ENTERPRISE | 複数ゾーン冗長・高可用 | 本番の重要データ・GKE のマルチシェア |
EFS のように「使った分だけ」ではなく、作成時に容量（GiB）を指定し、プロビジョニング済み容量に対して課金されます。不足したら手動でスケールアップが必要で、縮小はできません。BASIC/ZONAL はスループットが容量にほぼ比例するため、必要な性能から逆算して容量を決めるのがコツ。過剰だと無駄、不足だと性能も頭打ちになります。
セキュリティの鉄則（共通）
- バケットに
allUsersを付与して「全公開」で静的配信するのは NG。Cloud CDN + 外部 HTTP(S) ロードバランサ経由（必要なら署名付き URL/Cookie）で配信し、バケットは非公開のまま保つ。均一なバケットレベルのアクセスを有効化し、ACL ではなく IAM に権限を一本化するのが推奨。 - サービスアカウントの鍵ファイル（JSON）をコードや VM に埋め込むのは NG。VM/Cloud Run/Functions には接続済みサービスアカウントを割り当て、メタデータ経由で短命トークンを取得させる（AWS の IAM ロール相当）。
- Filestore は NFSv3 で通信の認証が弱い。ファイアウォールで NFS ポート（2049 等）を広く開けず、到達元を最小サブネットに限定し内部 IP からのみマウントさせる。
Cloud Storage / Persistent Disk / Filestore のいずれも保存時暗号化は既定で有効（Google 管理鍵）。要件に応じて CMEK（Cloud KMS の自前鍵） に切替でき、Cloud Storage / PD は CSEK（顧客指定鍵） も選べます。PD のスナップショットは元ディスクの暗号化（CMEK 鍵）を継承します。
クラウド間の対応（早見）
| 役割 | Google Cloud | AWS | Azure |
|---|---|---|---|
| オブジェクト | Cloud Storage | S3 | Blob Storage |
| ブロック（永続） | Persistent Disk / Hyperdisk | EBS | マネージドディスク |
| ファイル共有 | Filestore | EFS / FSx | Azure Files |
| 揮発性ストア | ローカル SSD | インスタンスストア | VM 一時ディスク |
| 自動階層化 | Autoclass | S3 Intelligent-Tiering | ライフサイクル管理 |
| アーカイブ | Archive クラス | Glacier / Deep Archive | Archive 層 |
| CDN 配信 | Cloud CDN + ロードバランサ | CloudFront | Front Door / CDN |
| 大容量転送 | Storage Transfer Service / Transfer Appliance | DataSync / Snowball | Azure Data Box |
関連: Cloud Storage / Persistent Disk / Filestore
Google Cloud Service
ストレージを実務で読む
TL;DRは入口です。実際に選ぶ・使う段階では、何を解決するか、何と比較するか、導入後にどこで詰まるかまで見る必要があります。
解決すること
cheatsheets
比較で見る軸
クラウド: Google Cloud / カテゴリ: cheatsheets / 難易度: basic
導入後に効く点
導入後の運用手順、権限、監視、更新方法まで含めて評価します。
先に潰すリスク
サービス単体ではなく、権限、ネットワーク、監視、課金、バックアップを含めて設計する必要がある。
- クラウド
- Google Cloud
- カテゴリ
- cheatsheets
- 難易度
- basic
- 関連資格
- —
- 設計柱
- —
判断チェックリスト
- 自社の用途が「cheatsheets」に近いか確認する。
- 注意点の「サービス単体ではなく、権限、ネットワーク、監視、課金、バックアップを含めて設計する必要がある。」を運用で吸収できるか確認する。
- 公開値や仕様値は、対象プラン・対象機種・対象リージョンまで確認する。
- 既存システム、ID、ネットワーク、監視、バックアップとの接続方法を先に洗い出す。
- 小さく試してから、本番移行、権限設計、障害時手順、コスト監視を決める。