GCPで「データをどこに保存するか」を考えると、Cloud Storage、Cloud SQL、Spanner、Firestore、Bigtable、BigQuery、Memorystoreなど多くのサービスが候補に挙がります。
これらを個別に暗記して選ぼうとすると、似た選択肢を並べられたときに迷います。実際には、保存するデータの性質によって候補は最初から大きく3つに分類でき、比較が必要になるのは同じ分類の中だけです。
この記事では、まず3つの分類とその見分け方を示し、そのうえで分類ごとに所属サービスと使い分けを整理します。
- GCPの保存系サービスの3分類と、要件からの見分け方
- 各分類に所属するサービスと使い分けの要点
- 各分類の中でどの比較記事を読めばよいか
保存系サービスは3つに分類できる
GCPの保存系サービスは、保存するデータの性質と使い方によって以下の3つに分類できます。
- ファイル・オブジェクトの置き場
- 画像、動画、CSV、ログ、バックアップなど「ファイルそのもの」を置く
- アプリケーションDB（OLTP）
- アプリケーションが1件単位で読み書きする構造化データを扱う
- 分析基盤（OLAP / DWH）
- 蓄積したデータを集計・分析する
カッコ内のOLTP・OLAP・DWHは処理タイプの呼び名です。1件単位の読み書きがOLTP、大量データの集計・分析がOLAP、分析用にデータを蓄えておく基盤がDWH（データウェアハウス）です。
どの分類に当たるかは、サービス名からではなく要件から、2段階の分岐で決めます。
flowchart TB
q1{"ファイルそのものか<br/>構造化データか"}
q2{"1件単位の読み書きか<br/>大量データの集計か"}
file["ファイル・オブジェクトの置き場"]
oltp["アプリケーションDB（OLTP）"]
olap["分析基盤（OLAP / DWH）"]
q1 -->|"ファイル"| file
q1 -->|"構造化データ"| q2
q2 -->|"1件単位の読み書き"| oltp
q2 -->|"集計・分析"| olap
- 1段階目: ファイルか、構造化データか
- 画像や動画、CSVのように「ファイルとして出し入れする」ならファイル・オブジェクトの置き場です
- 注文レコードやユーザー情報のように「属性を持つレコードとしてクエリする」なら構造化データです
- 2段階目: トランザクション処理か、分析処理か
- 「この注文を1件更新する」「このユーザーの情報を取る」のような1件単位の読み書き（OLTP）ならアプリケーションDBです
- 「全注文を月別に集計する」のような大量データの集計（OLAP）なら分析基盤です
分類が決まれば、あとは同じ分類の中での比較になります。以降、分類ごとに所属サービスと使い分けを見ていきます。
ファイル・オブジェクトの置き場
ファイルを置く場所は、どこからどうアクセスするかで選びます。所属するサービスは Cloud Storage、Persistent Disk、Filestore の3つです。
- Cloud Storage
- オブジェクトストレージです。APIやHTTP経由でファイルを出し入れします
- 画像・動画・CSV・ログ・バックアップ・静的ファイル・データレイクなど、「VMにマウントする必要がないファイル」は基本的にここに置きます
- 容量は事前確保不要で、置いた分だけ課金されます
- Persistent Disk
- VMにアタッチするブロックストレージ（仮想ディスク）です。VMのブートディスクもこれです
- OSやミドルウェアから通常のディスクとして見える必要があるデータを置きます
- Filestore
- マネージドNFSです。NFSとは、ネットワーク越しに共有フォルダをマウントしてファイルを共有するための標準的な仕組みです
- 複数のVMやGKEのPodから同じファイルシステムを共有マウントしたい場合に使います
迷ったときの目安は「マウントが不要ならCloud Storage」です。ブロック・ファイル・オブジェクトの3方式の違いと、Persistent Diskのタイプ・Local SSDとの使い分けは『ブロック・ファイル・オブジェクトストレージの違いとGCPでの使い分け』で詳しく扱います。
アプリケーションDB（OLTP）
アプリケーションのメインDBは、データモデルとスケール要件で選びます。所属するサービスは Cloud SQL、Spanner、Firestore、Bigtable と、キャッシュとして併用する Memorystore です。
- Cloud SQL
- マネージドなMySQL / PostgreSQL / SQL Serverです
- 一般的なWebアプリのDBや既存RDBの移行先として、最初の候補になります
- Spanner
- リレーショナルなまま水平スケールとグローバル分散ができるDBです
- Cloud SQLの規模で足りるならCloud SQLを選び、足りない要件が明確なときに選びます
- Firestore
- サーバーレスなドキュメントDBです
- モバイル/Webアプリのバックエンドや、リアルタイム同期が必要な用途に向きます
- Bigtable
- ワイドカラム型のNoSQLです
- 時系列・IoTのような、巨大なデータ量に対する低レイテンシの読み書きに特化しています
- Memorystore
- マネージドなRedis / Memcachedで、DBの代替ではなく併用するキャッシュです
- DBの手前に置いて読み取りを高速化したり、セッション情報を持たせたりします
この4つ（＋Memorystore）の使い分けが、GCPのDB選定でいちばん迷いやすいところです。詳細は『Cloud SQL・Spanner・Firestore・Bigtableの違いと使い分け』で扱います。
分析基盤（OLAP / DWH）
蓄積したデータを集計・分析するならBigQueryです。
BigQueryはSQLでクエリできるためアプリケーションDBと混同されがちですが、1件単位の読み書きを高速に返すためのサービスではなく、大量データのスキャンと集計に特化した別物です。アプリのバックエンドDBとしてBigQueryを選ぶのはアンチパターンです。
Cloud SQLとの違い、業務データを分析に流す構成は『【GCP】BigQueryとCloud SQLの違いと使い分け』で扱います。
分類をまたぐ観点
ロケーションと可用性
どの分類でも、サービス選定とは別に「どのロケーションに置くか」という軸があります。Cloud Storage / Firestore / Spanner / BigQueryは、multi-regionやdual-regionといったロケーション指定でデータ層の可用性を高められます。この観点は『GCPのmulti-regionデータサービス: Firestore・Spanner・Cloud Storage・BigQueryの違い』で扱っています。
保存先は1つに決めるものではない
実際のシステムでは、3分類を組み合わせて使います。
- 画像本体はCloud Storageに、画像のメタデータはCloud SQLに保存する
- 業務データはCloud SQLで扱い、分析用にBigQueryへ連携する
- Cloud SQLの手前にMemorystoreを置いて読み取りをキャッシュする
「どれか1つを選ぶ」のではなく「データの性質ごとに置き場を分ける」のが基本です。組み合わせの実践例は『GCPで画像アップロード機能を設計するときのCloud Storageとデータベースの役割分担』で扱います。
誤解しやすい点
- BigQueryはSQLが使えるが、アプリケーションDBではない
- 1件単位の読み書きを低レイテンシで返す用途には向きません
- Cloud StorageはDBの代替にならない
- オブジェクトは中身を条件にクエリできません。検索・集計したい属性はDB側に持たせます
- MemorystoreはDBの代替ではない
- インメモリでデータを失う前提のキャッシュ層です。永続化が必要なデータの一次保存先にはしません
- NoSQLだからスケールする、とひとくくりにしない
- FirestoreとBigtableはデータモデルも得意分野も別物です
まとめ
GCPの保存系サービスは、個別に暗記するのではなく、まず3分類のどれに当たるかで絞り込みます。主要サービスを分類ごとに一覧にすると以下です。
| 分類 | サービス | データの形 | 代表用途 |
|---|---|---|---|
| ファイル・オブジェクトの置き場 | Cloud Storage | オブジェクト（ファイル） | 画像・動画・バックアップ・データレイク |
| Persistent Disk | ブロック（ディスク） | VMのブートディスク・データディスク | |
| Filestore | ファイル（NFS） | 複数VM・GKEで共有するファイルシステム | |
| アプリケーションDB（OLTP） | Cloud SQL | リレーショナル | 一般的なWebアプリのDB |
| Spanner | リレーショナル | グローバル分散・水平スケールが必要なDB | |
| Firestore | ドキュメント | モバイル/Webアプリ、リアルタイム同期 | |
| Bigtable | ワイドカラム | 時系列・IoTなど巨大な低レイテンシ読み書き | |
| Memorystore | キーバリュー（インメモリ） | キャッシュ・セッション管理（DBと併用） | |
| 分析基盤（OLAP / DWH） | BigQuery | 列指向（分析向けテーブル） | 集計・分析・ダッシュボード |
分類が決まれば、比較すべき相手は同じ分類の中のサービスだけになります。各分類の中での詳しい使い分けは、本シリーズの各記事で扱います。