Google Cloud設計ガイド：データベース選定とコンピューティング使い分けの完全な論理構造
Meg
2026-01-26
システム設計におけるGoogle Cloudデータベース選定の意思決定ツリーと、GCE・GKE・Cloud Run等の計算資源の厳格な使い分けを解説します。また、Cloud Functionsを「サービス間の接着剤」と再定義し、API開発との役割分担やAI活用を含む最新のアーキテクチャ設計指針を提示します。
1. Google Cloud データベース選定の論理構造
システム設計におけるデータベース選定は、データの性質と用途に基づき、以下の分岐論理（意思決定ツリー）に従って行う。
| 選定基準 | 推奨サービス | 特徴・用途 |
|---|---|---|
| 非構造化（メディア等） | Cloud Storage | 動画や画像データの保存。 |
| 分析用（低遅延/高速） | Bigtable | 高速なレスポンスが求められる分析。 |
| 分析用（大規模/標準） | BigQuery | 大規模データの蓄積とクエリ分析。 |
| アプリ用（NoSQL/JSON） | Firestore | 柔軟なデータ構造、モバイル/Webアプリ向け。 |
| アプリ用（SQL/水平スケール） | Cloud Spanner | 世界規模の整合性と高可用性（例：対戦型ゲーム）。 |
| アプリ用（SQL/標準） | Cloud SQL | 一般的なリレーショナルデータベース。 |
用語の注意点： 「低レイテンシ（Low Latency）」は「遅延が低い＝高速」を意味する。試験等で頻出するため、正確な理解が必須である。
2. コンピューティングサービスの使い分けと事例
GCPの各計算資源サービスは、その目的によって厳格に使い分ける必要がある。
- Google Compute Engine (GCE) :
- 用途： リフト＆シフト（既存システムの移行）。
- 事例： 既存の医療系システム等、構成を変更せずにクラウド化する場合。
- Google Kubernetes Engine (GKE) :
- 用途： クラウドネイティブ開発、グローバル展開。
- 事例： 全世界で同時に稼働するオンラインゲーム。
- Cloud Run :
- 用途： モダンなWebアプリケーション開発、API開発。
- 事例： 新規に構築するスケーラブルなWebアプリ。
- Cloud Dataflow :
- 用途： データの収集・加工・分析パイプライン。
- 事例： IoT（トラクター等の大量データ収集）やヘリコプターのデータ分析。
3. Cloud Functions の本質的役割
Cloud Functionsについて、一般的なAPI開発用という誤解を解き、その真の目的を再定義した。
3.1 「トリガー」の概念
トリガーとは、もともとデータベース（RDBMS）の概念であり、データの挿入（Insert）、更新（Update）、削除（Delete）といった状態変化を感知してプログラムを実行する仕組みである。Google Cloudはこの概念をクラウド全体に拡張した。
3.2 サービス間の「接着剤」
Cloud Functionsの本来の目的は、Google Cloud 内部の各サービスを繋ぐことである。
- Firestore連携： ドキュメントの新規作成や削除を検知して後続処理を走らせる。
- Cloud Storage連携： 特定フォルダへのファイルアップロードを検知して処理を行う。
- APIとの違い： インターネットから直接アクセスされるAPI開発にはCloud Runが適しており、Cloud Functionsは内部的なイベント駆動処理に特化させるべきである。
4. 今後の技術的アプローチ
- AI駆動開発の推進： ドライブ上のファイルをAIに読み込ませ、コード変換や資料作成を効率化する手法を積極的に取り入れる。
- Firestore Extensionsの活用： 開発工数削減のため、Firestoreの拡張機能（Firebase Extensions）を利用した外部サービス連携を検討する。