Compute EngineのVMからデータを保存しようとすると、Persistent Disk、Local SSD、Filestore、Cloud Storageという選択肢が出てきます。
これらは「VMの周辺にあるストレージ」としてまとめて登場するため区別が曖昧になりがちですが、実際にはブロック・ファイル・オブジェクトという別方式のストレージであり、アクセスの仕方も、データが残る条件も、共有できる範囲も違います。
この記事では、まずストレージ3方式の定義と違いを押さえたうえで、GCPの各サービスがどの方式に当たるか、要件のどのキーワードが出たらどれを選ぶかを整理します。
『GCPのストレージ・データベースはオブジェクトストレージ・アプリケーションDB・DWHの3分類で選ぶ』では、GCPの保存系サービス全体を3つに分類しました。本記事はその中の「ファイル・オブジェクトの置き場」を深掘りします。
ストレージはブロック・ファイル・オブジェクトの3方式に分かれる
3方式の違いは、保存したデータを利用者にどんな形で見せるかの違いです。ディスクとして見せるのか、共有フォルダとして見せるのか、APIで出し入れする置き場として見せるのか。この「見せ方」が違うため、共有できる範囲・向いている用途・料金の考え方まで変わります。
まず3方式それぞれの定義から押さえます。
ブロックストレージはOSに「1台のディスク」として見せる
ブロックストレージは、データを固定長の小さな区画（ブロック）の集まりとして保存し、OSからは生のディスク1台として見える方式です。PCの内蔵SSDや外付けディスクと同じ見え方だと考えてください。
- OSはこのディスクに自分でファイルシステム（ext4など）を作ってから使います
- 原則として1台のマシンが専有します。1台の物理ディスクを2台のPCに同時に挿せないのと同じです
- 「ディスクが繋がっていること」を前提とするソフトウェア、つまりOSの起動ディスクやDBのデータ領域に使います
ファイルストレージは「ネットワーク上の共有フォルダ」として見せる
ファイルストレージは、フォルダ階層とファイルの形のまま、ネットワーク越しの共有フォルダとして見せる方式です。会社のファイルサーバーやNASと同じ見え方です。
共有に使われる代表的なプロトコルがNFS（Network File System）です。ネットワーク越しにフォルダをマウントしてファイルを共有するための、Unix系で昔から使われている標準的な仕組みで、「共有フォルダを実現する通信規格」と押さえておけば十分です。
ブロックストレージとの決定的な違いは、複数のマシンから同じフォルダを同時にマウント（自分のマシンに繋いでフォルダとして使えるようにする操作）できることです。これが嬉しいのは、たとえば以下のようなシチュエーションです。
- Webサーバーが3台並んでいて、ユーザーがアップロードしたファイルをどのサーバーからも読みたい。共有できないと「サーバーAに上がったファイルがBには存在しない」状態になり、全台にコピーして同期する仕組みを自作するはめになります
- 機械学習やレンダリングのように、複数の計算ノードが同じデータセットを読み書きする
つまり「同じファイルを複数台で読み書きする必要が出た瞬間、1台専有のブロックストレージでは足りなくなる」というのが、ファイルストレージの存在理由です。
また、アプリからは普通のフォルダ・ファイルに見えるため、open・read・write・ファイルパス指定・権限設定といったLinuxの普通のファイル操作がそのまま使えます。この性質を指してPOSIX準拠と呼びます（POSIXはUnix系OSの標準仕様の名前で、ここでは「普通のファイル操作がそのまま効く」という意味だと読み替えて問題ありません）。
オブジェクトストレージは「APIで出し入れする置き場」として見せる
オブジェクトストレージは、ファイルをオブジェクトという単位にして、名前（キー）を付けて出し入れする方式です。ディスクとしてもフォルダとしても見せず、HTTPのAPI経由で「このキーで保存する」「このキーのものを取得する」とやり取りします。マウントという概念がそもそもありません。
- ディスクやフォルダの見え方を捨てたかわりに、容量は事実上無制限で、置いた分だけの課金になります
- フォルダ階層も実はなく、
uploads/2026/photo.jpgのようなキー文字列で管理されます（パス風の名前が付いているだけです） - オブジェクトは不変（イミュータブル）です。一部だけの書き換えや追記はできず、変更したければオブジェクト全体を置き換えることになります。つまり書き換わり続けるデータの置き場ではなく、書き終わった完成品を置く場所です
- 「ディスクとして見える必要も、複数台でマウントする必要もない、ただ置いておきたいファイル」の置き場です。バックアップ、画像・動画、ログ、分析前の生データなどが典型です
3方式の違いを一覧で比べる
| 観点 | ブロックストレージ | ファイルストレージ | オブジェクトストレージ |
|---|---|---|---|
| 見え方 | OSに繋がった1台のディスク | ネットワーク上の共有フォルダ | APIで出し入れする置き場 |
| 身近な例え | PCの内蔵SSD | 会社のファイルサーバー・NAS | クラウドのファイル置き場 |
| 共有 | 1台のマシンが専有 | 複数マシンから同時マウント | どこからでもAPIでアクセス |
| 書き換え | ブロック単位のランダム書き込みができる | ファイルの部分書き換えができる | できない（オブジェクト全体を置き換える） |
| 典型用途 | 起動ディスク、DBのデータ領域 | 複数サーバーでのファイル共有 | バックアップ、画像・動画、データレイク |
GCPのサービスを3方式に当てはめる
GCPのサービスをこの3方式に対応させると以下です。
| 方式 | GCPのサービス | アクセス方法 | 複数VMからの共有 |
|---|---|---|---|
| ブロックストレージ | Persistent Disk、Local SSD | VMにアタッチしてマウント | 基本は1VMが専有 |
| ファイルストレージ | Filestore | NFSでマウント | 複数VM・GKE Podで共有できる |
| オブジェクトストレージ | Cloud Storage | API / HTTP | どこからでもアクセスできる（マウントではない） |
以降、サービスごとに違いを見ていきます。
Persistent DiskはVMの基本のディスク
Persistent Diskは、VMにアタッチして使うブロックストレージです。VMを作ると必ず付いてくるブートディスクもPersistent Diskです。
物理的にVMのホストマシンに載っているのではなく、ネットワーク越しにアタッチされる仮想ディスクです。この構造から、以下の性質が出てきます。
- VMとディスクのライフサイクルが独立しています。VMを削除してもディスクを残せますし、ディスクを別のVMに付け替えられます
- スナップショットを取ってバックアップや複製ができます
- VM稼働中にサイズを拡張できます
性能はディスクタイプというオプションで選びます。HDDベースのpd-standardと、SSDベースのpd-balanced・pd-ssdがあり、SSDタイプにすると同じPersistent Diskのまま読み書きが速くなる、という関係です。
なお現在のGCPには、Persistent Diskの後継世代にあたるHyperdiskというブロックストレージもあり、新しいマシンシリーズではこちらが標準になりつつあります。「ブロックストレージ＝Persistent Diskだけではない」ことは押さえておくと、ドキュメントを読むときに迷いません。
ゾーンPDとリージョンPD
Persistent Diskには所属スコープが2種類あります。
- ゾーンPersistent Disk
- 1つのゾーンに存在する通常のディスクです
- ゾーン障害が起きると、そのディスクにはアクセスできなくなります
- リージョンPersistent Disk
- 同一リージョン内の2つのゾーンに同期レプリケーションされるディスクです
- ゾーン障害時に、もう片方のゾーンのVMにアタッチし直してフェイルオーバーできます
「ゾーン障害に耐えるデータディスク」という要件が出たら、リージョンPDの出番です。zonal / regionalというスコープの読み方は『GCPのzonal・regional・multi-region・global・cross-regionを整理する』で扱っています。
Local SSDは高速だが揮発する
Local SSDは、VMのホストマシンに物理的に接続されたSSDです。
ネットワーク越しのPersistent Diskと違い物理接続なので、非常に高いIOPS（1秒あたりに処理できる読み書きの回数）と低いレイテンシが出ます。そのかわり、決定的な制約があります。
- 揮発性です。VMを停止・削除するとデータは消えます。ホスト障害でも失われる可能性があります
- スナップショットのような永続化の仕組みはありません
- ディスク単体でサイズを自由に選ぶのではなく、固定サイズの単位でVMにアタッチします
つまりLocal SSDは「消えてもよい高速な作業領域」です。用途は一時ファイル・キャッシュ・処理の中間データのような、失われても再生成できるものに限られます。DBのデータ本体のような消えては困るものは置きません。
- 「SSD」はPersistent DiskのSSDタイプ（pd-ssd等）とLocal SSDのどちらも指しえます
- 永続化が必要な高速ディスクはpd-ssdです。Local SSDではありません
- Local SSDを選ぶのは「最高の性能が必要で、かつ消えてもよいデータ」のときだけです
2つを並べると以下です。
| 観点 | Persistent Disk（pd-ssd） | Local SSD |
|---|---|---|
| 接続 | ネットワーク越しにアタッチ | ホストマシンに物理接続 |
| 永続性 | 永続（VM停止・削除後も残る） | 揮発（VM停止・削除で消える） |
| スナップショット | 取れる | 取れない |
| 性能 | 高い | さらに高い（物理接続のため） |
| 用途 | DBデータ領域など永続かつ高速が必要なもの | スクラッチ・キャッシュなど消えてよいもの |
Filestoreは複数VMで共有できるマネージドNFS
Filestoreは、マネージドなNFSファイルサーバー、つまり先ほどのファイルストレージをGCPが運用込みで提供するサービスです。
Persistent Diskが基本的に1つのVMに専有される一方、Filestoreは複数のVMやGKEのPodから同じファイルシステムを同時にマウントできます。アプリケーションからは普通のディレクトリとして見え、POSIXのファイル操作（普通のopen・read・write）がそのまま使えます。
Filestoreを選ぶ目安になるキーワードは以下です。
- 複数のVMから同じファイルを読み書きしたい（前述のWebサーバー3台の例のような共有ストレージ）
- NFSを前提とした既存アプリケーションの移行
- POSIXファイルシステムが必要（アプリがファイルパスでの読み書きを前提にしている）
- GKEの複数Podから同じボリュームを読み書きしたい（ReadWriteMany）
逆に、共有が不要で1台のVMが使うだけならPersistent Diskで足ります。なおPersistent Diskにも複数VMにアタッチする構成はありますが、読み取り専用にするなどかなり限定的です。読み書きの共有が要件なら素直にFilestoreを選びます。また、POSIXやマウントがそもそも不要なら、次のCloud Storageのほうが安く柔軟です。
Cloud Storageはマウントしないオブジェクトストレージ
Cloud Storageは、バケットにオブジェクトを出し入れするオブジェクトストレージです。VMのディスクとは根本的に位置付けが違います。
- アクセスはAPIやHTTP経由です。VMにアタッチするものでも、NFSでマウントするものでもありません
- 容量の事前確保が不要で、置いた分だけ課金されます
- バケットのロケーションを
region/dual-region/multi-regionから選べ、耐久性・可用性をロケーション指定で確保できます - アクセス頻度に応じたストレージクラス（Standard / Nearline / Coldline / Archive）があり、アーカイブ用途ではコストを大きく下げられます
Cloud Storageを選ぶ目安になるキーワードは以下です。
- バックアップ・アーカイブ（スナップショットの保存先も実体はここです）
- 画像・動画・静的ファイルの保存と配信
- データレイク（分析前の生データ置き場）
- 「複数のサービス・リージョンからアクセスしたい」「容量が事前に見積もれない」
注意点として、gcsfuseというツールでCloud Storageをファイルシステム風にマウントすることもできますが、実体はオブジェクトストレージなので「マウントできる安いディスク」としては使えず、POSIXの完全な代替にはなりません。「マウントして使いたい」が本質要件ならFilestoreやPersistent Diskを選びます。
もう1つの注意点は、Cloud Storageが完成したファイルの最終置き場であって、書き込み中の作業領域ではないことです。たとえばDBバックアップでmysqldumpの出力先をgcsfuse経由のCloud Storageに直接向けると、逐次の書き込みがそのままAPI呼び出しのネットワーク往復になり、バックアップが過度に長引きます。dumpは速いローカルディスク（Persistent DiskやLocal SSD）で作り、完成品をgcloud storage cpでCloud Storageへ転送する、という「作る場所と置く場所を分ける」構成が定石です。
Cloud Storageのロケーション指定（multi-region / dual-region）が何を担保するかは『GCPのmulti-regionデータサービス: Firestore・Spanner・Cloud Storage・BigQueryの違い』で扱っています。
要件キーワードから引く保存先の早見表
ここまでの内容を、要件のキーワードから逆引きできる形にまとめます。
| 要件キーワード | 選ぶもの | 理由 |
|---|---|---|
| VMのブートディスク、永続化したいディスク | Persistent Disk | VMと独立したライフサイクルを持つ永続ディスク。高速にしたいならSSDタイプ（pd-ssd等）を選ぶ |
| 最高のIOPS・低レイテンシ、消えてもよい | Local SSD | 物理接続で最速だが揮発する |
| ゾーン障害に耐えるディスク | リージョンPersistent Disk | 2ゾーンに同期レプリケーション |
| 複数VMで共有、NFS、POSIX | Filestore | マネージドNFSで同時マウントできる |
| バックアップ、アーカイブ、画像・動画、データレイク | Cloud Storage | マウント不要ならオブジェクトストレージが最も安く柔軟 |
| 書き換わり続けるデータ（稼働中のDBのデータファイル等） | Persistent Disk | オブジェクトは不変で部分書き換えができないため、Cloud Storageは不向き |
| コスト最優先のアーカイブ | Cloud Storage（Coldline / Archiveクラス） | アクセス頻度に応じてストレージクラスを下げる |
まとめ
- VM周辺の保存先は、データをどんな形で見せるかでブロック・ファイル・オブジェクトの3方式に分かれ、そこにGCPのサービスが対応する
- OSにディスクとして見せるのがブロックストレージ。永続ならPersistent Disk（高速化はSSDタイプ、ゾーン障害耐性はリージョンPD）、最速・揮発でよいならLocal SSD
- 複数マシンの共有フォルダとして見せるのがファイルストレージ。GCPではFilestore
- APIで出し入れする置き場として見せるのがオブジェクトストレージ。GCPではCloud Storageで、マウント不要のファイル（バックアップ・アーカイブ・画像・データレイク）はここに置く