GCPでのインフラの理解

Firebase Hosting

ビルド済みの静的ファイル（HTML/CSS/JS/画像など）を Google のエッジに配って高速配信するグローバルCDNであり、静的オリジンです。

• 静的サイト/SPA の高速配信：グローバル CDN、無料自動 SSL、HTTP/2/3
• シンプルなデプロイ：firebase deploy、ゼロダウンタイム、即ロールバック
• カスタムドメイン：Apex/WWW を簡単接続
• リダイレクト/ヘッダー/キャッシュ制御：firebase.json で宣言的に管理
• バックエンド連携（リライト）：Cloud Functions / Cloud Run へ安全にプロキシ
• プレビュー運用：Preview Channels（PR ごと短期 URL）

Firebase App Hosting

ビルドからアプリのサーバーをマネージドで管理してくれるフルスタックのウェブアプリ用の環境を提供します。Cloud Build → Artifact Registry → Cloud Run（サーバ実行）→ Cloud Load Balancing＋Cloud CDNを自動で組んでくれる。

• Git 連携から本番まで一気通貫：リポ接続→ビルド→（必要なら）SSR 実行→CDN 配信
• サーバー実行が前提のアプリを想定：Node などのランタイムをマネージドで面倒を見る
• 画像最適化・SSR 等を“ホスティング側”で統合（対応フレームワークは順次拡大の前提）

Firebase HostingとFirebase App Hostingの使い方のまとめ

観点	Firebase Hosting	Firebase App Hosting
主目的	静的配信（CSR/SSG）中心	SSR/サーバー実行込みの一体運用
サーバーコード	実行しない（＝静的配信のみ）	実行する（ビルド→実行→配信まで管理）
動的機能の載せ方	Hosting →（rewrite）→ Functions / Run	App Hosting 自身が実行環境を提供
初期導入	CLI 初期化＋firebase.json 設定	リポ接続＋ビルド設定（GUI/宣言的）
得意領域	Jamstack、SPA、静的＋一部 API のハイブリッド	SSR 多用、画像最適化、フルスタック運用

Next.js の場合は

• CSR：クライアントで描画（初期 HTML は薄く、JS で描画）
• SSG：ビルド時に静的 HTML を生成して配信
• SSR：リクエストごとにサーバーで描画して返す
• ISR：公開後も静的ページを一定間隔で再生成（SSG の増分更新）

使い分け方

• CSR / SSG → Firebase Hosting 単体でOK
  • Next.js の output: "export"（next export）成果物を配信
  • SPA なら "**" → "/index.html" の rewrite を 1 本入れるだけ
• SSR / ISR → 選択肢は2つ
  1. Firebase Hosting +（rewrite）+ Functions/Cloud Run
     • 既存の GCP リソース（DB、VPC、秘密情報管理）と組み合わせやすい
     • ISR/画像最適化もサーバー側で実装可能
  2. Firebase App Hosting
     • Git 連携→ビルド→SSR 実行→配信までまとめて任せる運用

Firebase HostingとCloud Runの接続

A) 直結

[Firebase Hosting] –rewrite–> [Cloud Run (public)]
この場合、Cloud RunでAPIを実装した場合、APIは公開になる
この、rewriteとは、Firebase Hosting の設定ファイル（firebase.json）内で使うルーティング指定のことで、Cloud RunかCloud Functionsで使用できる

B) 入口で“物理的に”締める（WAF/IAP 必須のとき）

[Firebase Hosting] → [HTTPS LB + (Cloud Armor/IAP)] → [Serverless NEG] → [Cloud Run (private)]

• LB：httpsの終点、バックエンドルーティング、SSL証明書設定等
• Armor (WAF: Web Application Firewall)：LBにポリシーをアタッチし、アクセスを制限する
• IAP (Identity-Aware Proxy)：特定のチームやユーザーのみログイン可能にする
• Serverless NEG（Network Endpoint Group）: LBとサーバーレスサービス（Cloud Run・Cloud Functions・App Engine）を接続するオブジェクト

Cloud Load Balancing（LB）

HTTP(S) Load Balancer（External HTTPS LB） は、グローバルな Google フロントエンド（GFE） 上に存在します。つまりVPC の外側にあり、世界中のユーザーから直接 HTTPS リクエストを受け取ります。

• 役割：グローバルな HTTPS 終端、証明書、L7 ルーティング、Cloud CDN 連携、ログ/メトリクスの起点。
• いつ使う：
  • 複数バックエンド（Cloud Run、GKE、VM、マルチリージョン）への高度ルーティング。
  • Cloud Armor（WAF）やIAPを使いたい（＝LBが前提）。
  • 独自の TLS 設定、接続制御、地理ベースのルールなどを細かく運用したい。
• Firebase Hosting との関係：Hosting は“Google管理のCDN+LB相当”が内蔵。ユーザーが別途 LB を置くことは基本しない。

Cloud Armor（WAF / DDoS ルール）

• 役割：WAF ルール、IP 制限、Bot/レート制御、地理ブロック等。
• いつ使う：
  • 公開 API/SSR に対して細かいセキュリティ制御をしたい。
  • PCI/GDPR/社内ポリシーで WAF 必須。
• 前提：外部 HTTPS LB のバックエンドにアタッチ（Cloud Run はServerless NEG経由で LB 配下に置く）。
• Firebase Hosting との関係：Hosting 直下には付けられない。必要なら**「LB + Cloud Run」構成**に切り替える。

IAP（Identity-Aware Proxy）

• 役割：Google アカウント/SAML/OIDC 等でアプリに入る前に認証（ゼロトラスト風の境界）。
• いつ使う：
  • 社内ツール/管理画面を外部公開せずに守りたい。
  • OAuth/OIDC を自前実装したくないが“入口で強制ログイン”させたい。
• 前提：LB 経由 or 対応バックエンドに対して有効化。
• Firebase Hosting との関係：Hosting の静的配信に IAP は基本使わない。Cloud Run/GKE など“アプリ側入口”で使う。

NEG（Network Endpoint Group）

• 役割：LB とバックエンド（Cloud Run/GKE/VM）をつなぐハンドル。
  • Serverless NEG＝Cloud Run/Functions/App Engine を LB にぶら下げるための論理オブジェクト。
• いつ使う：LB から Cloud Run へトラフィックを出したいときは必須。
• Firebase Hosting との関係：Hosting を使う限り、ユーザーが NEG を作る場面はない（裏側はGoogle管理）。

Cloud Run

• 役割：コンテナのフルマネージド実行（API/SSR/バッチ）。認証（OIDC）、最小スケール、VPC 接続、地域指定など。
• いつ使う：
  • Next.js SSR/ISR、画像最適化、Webhook、バックエンド API。
  • ランタイムを自由にしたい（Node 以外もOK）。
• Firebase Hosting との関係：Hosting から rewrite で Cloud Run に“同一ドメインで”プロキシ可能。LB なしでOK。

Cloud RunとFirestoreの接続

Firestore（Cloud Firestore）へのアクセスは、すべて「Firestore API」経由 で行われます。Firestore API は「Public Endpoint」ですが、Cloud Run（同じプロジェクト内）から呼ぶとインターネットを経由せずにGoogle のバックボーン内で完結 します。外部公開されたAPIではなく、Google Cloud内のIAM制御で安全にアクセスできます。

Cloud RunとCloud SQLの接続

接続方法	必要な構成	特徴
Public IP 接続	VPC 不要 Cloud SQL Auth Proxy（または自動統合）	簡単・初期構築が速い。TLSで暗号化される。
Private IP 接続	Serverless VPC Connector が必要	よりセキュア。Cloud SQL が VPC 内にあり、Public IP を持たない。

Google内部VPCの理解

Google Cloud では、すべてのサービス（Cloud SQL, Firestore, Storage, Cloud Run など）がGoogle が管理するグローバルなバックボーンネットワーク上の内部VPC で動いています。
この「内部VPC」はユーザーが操作できない（= Googleの管理領域）にあります。
ただし、Peering（VPC Peering や Private Service Connect） を通じて、ユーザーのVPCと安全に接続できるようになっています。つまり、ユーザーの「VPC Network」＋「Google管理のVPC」が裏で連携している構造になっています。

AWSとの違い

比較項目	Google Cloud	AWS
サービスの物理的配置	Google内部VPC上（マネージド）	各サービスごとに独立（VPC外部扱い）
内部接続	VPC Peering / Private Service Connect	VPC Endpoint / PrivateLink
概念名	Google-managed VPC（内部VPC）	Service Network / PrivateLink Target
例	Cloud SQL, Firestore, Storage	RDS, S3, DynamoDB
統合感	Googleのバックボーン全体で統一	各サービスが独立した設計