サーバーレス API

このパターンは？

サーバーを1台も持たずにWeb/APIを構築する、Google Cloud で主流の構成。アイドル時はほぼ無料（リクエストが来た分だけ課金）、急なスパイクにも自動でスケールします。

AWS の「CloudFront＋S3＋API Gateway＋Lambda＋DynamoDB」をそのまま Google Cloud に置き換えると、Cloud CDN＋Cloud Storage＋API Gateway＋Cloud Run（または Cloud Functions）＋Firestore になります。

構成

[ユーザー]
   │ HTTPS
   ▼
外部 HTTP(S) ロードバランサ + Cloud CDN
   │
   ├──► Cloud Storage バケット (SPA/静的サイト: HTML/CSS/JS)
   │
   │ /api/*  （URL マップでパスルーティング）
   ▼
API Gateway (認証・レート制限・APIキー)
   │
   ▼
Cloud Run (ビジネスロジック / コンテナ)
   │
   ▼
Firestore (データ)    ※ファイルは Cloud Storage、認証は Identity Platform

各コンポーネントの役割

• Cloud CDN + Cloud Load Balancing + Cloud Storage: フロント（SPA/静的）をグローバルエッジでキャッシュ配信。外部 HTTP(S) ロードバランサのバックエンドバケットとして公開し、Google マネージド SSL 証明書で HTTPS 化
• API Gateway: APIの玄関。OpenAPI 定義で認証（JWT / Firebase / APIキー）・レート制限（quota）・ルーティングを集約
• Cloud Run: ロジックをコンテナで実行。ステートレス・リクエスト数に応じて0からN台へ自動スケール。軽量関数なら Cloud Functions でも可
• Firestore: ミリ秒応答・サーバーレスなドキュメント DB。プロビジョニング不要で自動スケール

設計の勘所

• 認証は Identity Platform（Firebase Authentication） で発行した JWT を、API Gateway 側で検証して玄関集約
• Firestore はアクセスパターン駆動でコレクション設計（詳細）。クエリは複合インデックス前提
• 非同期処理は Pub/Sub / Eventarc を挟み、Cloud Run をイベント駆動で起動
• フロントとバックを同一ロードバランサにまとめ、/ は Cloud Storage バケット、/api/* は API Gateway へ URL マップで振り分けると CORS や独自ドメイン管理が楽

サービス対応（AWS との比較）

Cloud Run と Cloud Functions の使い分け

Well-Architected の観点

• コスト最適化: リクエスト課金・アイドルは0台（Cloud Run）／読み書き従量（Firestore）でアイドルほぼ無料
• 運用上の優秀性: サーバー管理レス・Terraform / gcloud でデプロイを標準化
• パフォーマンス効率: Cloud CDN のグローバルエッジ配信＋Cloud Run の自動スケール
• 信頼性: マネージドサービスの冗長性（Firestore はマルチリージョン構成も選択可）を活用

よくある落とし穴

メトリクス/ログは Cloud Monitoring / Logging に自動集約され、権限は Cloud IAM のサービスアカウントで最小権限化します（Cloud Run → Firestore のアクセスはサービスアカウントの IAM ロールで制御）。