サービスを選ぶ

ストレージとデータベースの選び方

データの形 (オブジェクト、ファイル、ブロック、テーブル、ドキュメント、キーと値) で候補を絞り、規模と一貫性の要件で 1 つに決めます。リレーショナルなら Cloud SQL から始め、性能が足りなければ AlloyDB、グローバルに強い一貫性が要るなら Spanner へ進みます。

置き場は、まずデータの形で候補を 2〜3 個に絞り、次に規模と一貫性で 1 つに決めます。問題文の「グローバルに強い整合性」「時系列を毎秒数百万件」「SQL で分析」のような語が答えを示します。

ファイルを丸ごと共有ファイルVM のディスクSQL で分析リレーショナルドキュメントキーと値NFS数 TB規模で用途でCloud StorageFilestorePersistent Disk / HyperdiskBigQueryCloud SQL → AlloyDB → SpannerFirestoreBigtable / Memorystore
左の形が決まれば候補は 1〜3 個に減ります。リレーショナルとキーと値だけは、規模と使い方でさらに分かれます。

判断の順序

  1. 画像、動画、ログ、バックアップのように、ファイルを丸ごと置いて丸ごと取り出すか。はいなら Cloud Storage。
  2. 複数の VM から NFS で同じファイルを共有するか。はいなら Filestore。1 台の VM のディスクなら Persistent Disk か Hyperdisk。
  3. 大量のデータを SQL で集計、分析するか。はいなら BigQuery。
  4. トランザクションと SQL が要るアプリのデータか。はいなら Cloud SQL。PostgreSQL で性能や分析の速さが足りなければ AlloyDB。複数リージョンにまたがる書き込みや、1 台に収まらない規模なら Spanner。
  5. スキーマが柔軟なドキュメントを、モバイルや Web のアプリから直接読み書きするか。はいなら Firestore。
  6. 時系列や IoT のように、キーで引く大量のデータを高いスループットで書き込むか。はいなら Bigtable。
  7. ミリ秒未満で返したいキャッシュやセッションの置き場か。はいなら Memorystore。

試す置き場を絞り、Cloud Storage のクラスを比べる

データの形
規模と使い方
一貫性と規模

Cloud Storage のクラス比較

1,000 GiB
取り出しの頻度 (全量を読む回数)
置いてから消すまで

選ばれた置き場

Cloud SQL

  • AlloyDBCloud SQL で性能が足りなくなったときの次の候補。
  • Spannerグローバルも水平スケールも強い一貫性も要らないなら、費用が見合わない。
  • BigQuery分析用のデータウェアハウス。行単位で頻繁に更新するアプリの DB には使わない。

月額の目安 (東京リージョン、保管料と取り出し料だけ。操作とネットワークの料金は含めない)

  • Standard$23.00
  • Nearline$26.00
  • Coldline$26.00
  • Archive$52.50

棒の明るい部分が保管料、暗い部分が取り出し料。

1 つのリージョンで動く一般的なアプリの DB。既存の MySQL、PostgreSQL、SQL Server をほぼそのまま移せる。

取り出しが多いので、取り出し料のかからない Standard が最も安い。Nearline は保管料がさらに安いが、1 GiB あたり $0.01 の取り出し料で逆転する。

SLA はストックホルムのリージョンを除いた値です。

サービス向く要件SLA の例
Cloud Storage画像、動画、バックアップ、データレイクStandard でリージョン 99.9%、マルチリージョン 99.95%
Cloud SQL一般的な Web アプリの DBHA 構成で Enterprise Plus 99.99%、Enterprise 99.95%
AlloyDB高負荷の PostgreSQL、取引と分析の同居HA 構成で 99.99%
Spannerグローバルな取引、在庫、金融マルチリージョン 99.999%、リージョン 99.99%
Firestoreモバイル、Web アプリのデータマルチリージョン 99.999%、リージョン 99.99%
Bigtable時系列、IoT、広告、大量の書き込み構成により 99.9%〜99.999%

出典は Cloud Storage、Cloud SQL、AlloyDB、Spanner、Firestore、Bigtable です。

Cloud Storage のクラスは取り出す頻度で選ぶ

Cloud Storage はファイルをオブジェクトとしてバケットに置き、容量を事前に決めません。ストレージクラスはどれもミリ秒単位で読み出せ、違うのは料金の構造です。保管料が安いクラスほど最低保存期間と取り出し料があり、最低保存期間より前に消すと残りの期間分の保管料がかかります。

保管料 ($/GiB/月、東京)取り出し ($/GiB)StandardNearlineColdlineArchive0.0230.0160.0060.0025なし0.010.020.05
Archive の保管料は Standard の約 1/9 ですが、取り出し料は 1 GiB あたり $0.05 です。読む回数が増えるほど、冷たいクラスの安さは消えます。
クラス最低保存期間公式の目安
Standardなし頻繁に読むデータ、配信するコンテンツ
Nearline30 日月に 1 回程度読むバックアップ
Coldline90 日四半期に 1 回程度読むデータ
Archive365 日年に 1 回も読まない法定保存、DR 用の写し

金額は料金ページの東京のリージョンの値です (2026 年 10 月 30 日確認)。実際の安さは保管料と取り出し料の合計で決まるので、シミュレーターで比べてください。頻度が読めないデータには、アクセスに応じてクラスを自動で切り替える Autoclass を使えます。

  • 「ログは 30 日後に Coldline へ、1 年後に削除」は、ライフサイクルルールで作成からの日数を条件にして、スクリプトなしで実現します。
  • 「改ざんできない形で 7 年保存」は、保持ポリシー (最長 100 年) をかけてロックします。ロックすると取り外すことも期間を短くすることもできません。オブジェクトごとに期間を決めるなら Object Retention Lock です。

VM のディスクと共有ファイル

Hyperdisk は容量とは別に IOPS とスループットを決められ、使用中に性能だけを変えられます。Balanced (汎用)、Extreme (最高の IOPS)、Throughput (帯域重視)、ML (多数の VM で読み取り共有) があります。Hyperdisk Balanced High Availability は 2 つのゾーンに同期で複製するので、ゾーン障害のときに別のゾーンの VM へ付け替えられます。

複数の VM や Pod で同じファイルを読み書きするなら Filestore です。Cloud Storage はファイルシステムではないので、ファイルの一部の書き換えやロックを前提にしたアプリには向きません。

リレーショナルは Cloud SQL から

Cloud SQL は MySQL、PostgreSQL、SQL Server のマネージドサービスでです。HA 構成では別のゾーンに待機のインスタンスが置かれ、単一ゾーンのインスタンスは SLA の対象外です。

AlloyDB for PostgreSQL は、コンピュートとストレージを分けてスケールさせる PostgreSQL 互換の DB です。カラム型エンジンにより、取引の DB に分析のクエリを投げても速く返ります。

Spanner は複数のリージョンにまたがって水平にスケールし、強い整合性のトランザクションを提供します。グローバル、水平スケール、強い整合性のどれも要件にないなら、費用が見合わないので Cloud SQL です。

NoSQL、キャッシュ、分析

Firestore は JSON に近いドキュメントを持つサーバーレスの DB で、モバイルや Web から SDK で直接読み書きし、変更をリアルタイムに受け取れます。MongoDB 互換の API も使えます。Bigtable は行キーで引くワイドカラム型で、メトリクスや電力メーターの記録のような時系列に向き、HBase の移行先にもなります。表をまたぐ結合には向きません。データを書くのがアプリのユーザーなら Firestore、機械が大量に書くなら Bigtable です。

Memorystore は Valkey、Redis、Redis Cluster のマネージドサービスで、DB の前のキャッシュやセッションの共有に使います。Memcached 版は非推奨です。BigQuery は SQL で分析するデータウェアハウスで、取引の DB には使いません。データの流し込み方はデータ処理と分析で扱います。

試してみる

Cloud Storage のバケットを作り、30 日後に Coldline へ移し、365 日後に削除するライフサイクルルールを設定します。バケット名は世界で一意にする必要があるので、末尾にプロジェクト ID を付けます。

export BUCKET=gs://lifecycle-demo-$(gcloud config get-value project)
gcloud storage buckets create $BUCKET --location=asia-northeast1

cat > lifecycle.json <<'EOF'
{
  "rule": [
    {"action": {"type": "SetStorageClass", "storageClass": "COLDLINE"}, "condition": {"age": 30}},
    {"action": {"type": "Delete"}, "condition": {"age": 365}}
  ]
}
EOF

gcloud storage buckets update $BUCKET --lifecycle-file=lifecycle.json
gcloud storage buckets describe $BUCKET --format='default(lifecycle_config)'

コンソールの「ライフサイクル」のタブに 2 つのルールが出ることを確かめたら、削除します。

gcloud storage rm --recursive $BUCKET
rm lifecycle.json

試験で問われる判断

以下は、このカリキュラム用に作った例です。

「世界中の店舗の在庫を 1 つの DB で管理し、どの店舗から見ても常に最新の在庫数を返したい」。答えは Spanner のマルチリージョン構成です。

「1 万台のセンサーの値を毎秒受け、機器 ID で引いて表示する」。答えは Bigtable です。「過去 3 年分を SQL で集計」が加わったら、BigQuery への取り込みを足します。

「監査ログを 7 年間、誰にも削除できない形で保存する。読むのは監査のときだけ」。答えは Archive クラスのバケットに保持ポリシーをかけ、ロックする構成です。

「PostgreSQL のアプリで、夜間の集計が取引の処理を遅くしている」。答えは AlloyDB です。

次のページでは、置き場のあいだでデータを動かし、加工します。

理解度チェック

答えを開く前に、自分で考えてください。結果はこのブラウザにだけ残り、間違えた問題は復習のページでまとめて解き直せます。

思い出す

Cloud Storage の Archive クラスは、保管料が Standard の約 1/9 です。それでもいつも最も安いとは限らないのはなぜですか。

状況で選ぶ

日本、米国、欧州に店舗を持つ小売の会社が、在庫を 1 つの DB で管理します。どの国の店舗から見ても常に最新の在庫数を返し、在庫の引き当ては各国の店舗から書き込みます。どれを選びますか。

説明する

PostgreSQL で動くアプリの DB を Google Cloud に移します。Cloud SQL、AlloyDB、Spanner のどれを選ぶかを、どんな条件で答えが変わるかとともに説明してください。