Concepts
インフラ構成と IaC (Google Cloud + Terragrunt)
インフラ構成と IaC (Google Cloud + Terragrunt)
定義
カケトクのホスティング・ネットワーク・永続層・CI/CD を Google Cloud 上に構築し、Terraform + Terragrunt で IaC 管理する構成。dev / stg / prod の 3 環境を環境ファイルで差分管理する。
現在の理解
GCP サービス割付 (§5.4)
| コンポーネント | GCP サービス | 補足 |
|---|---|---|
| Backend API ホスティング | Cloud Run | REST + WebSocket (Frontend 向け) |
| Backend Media Streams 処理 | Cloud Run (別サービス) | WebSocket 対応、長時間接続設定、CPU バウンド分離 |
| Web Frontend | Cloud Run (Next.js) | App Router、SSR + Client |
| データベース | Cloud SQL for PostgreSQL (HA) | Private Service Connect |
| ファイル永続化 | Cloud Storage | 音声バックアップ・CSV 取込・Scribe 障害時 PCM バッファ |
| シークレット | Secret Manager | 全外部サービス API Key |
| キュー | Cloud Tasks | 架電ジョブ・Webhook 配信 |
| ジョブ実行 | Cloud Run Jobs | 架電キュー worker・構造化処理 |
| ロードバランサ | Cloud Load Balancing | HTTPS + WebSocket |
| DNS | Cloud DNS | — |
| ネットワーク | VPC + Serverless VPC Access + Private Service Connect | Cloud SQL Public IP 無し (NFR-SE-3) |
| 監視 (MVP) | Cloud Logging + Cloud Monitoring | デフォルトアラート |
| エラー追跡 | Sentry (Phase C で導入) | 段階的 |
| APM | Datadog (成熟後) | 必須ではない |
| CI/CD | Cloud Build + Artifact Registry | — |
| IaC | Terraform + Terragrunt | — |
Terragrunt 階層構成 (§5.4)
infra/
├── terragrunt.hcl # ルート設定 (state バックエンド等)
├── modules/ # 再利用可能モジュール
│ ├── cloud-run-service/
│ ├── cloud-run-websocket/ # WebSocket 最適化済みモジュール
│ ├── cloud-sql/
│ ├── vpc/
│ ├── secret-manager/
│ ├── cloud-tasks/
│ ├── storage/
│ └── monitoring/
└── environments/
├── dev/
│ ├── terragrunt.hcl
│ ├── backend-api/terragrunt.hcl
│ ├── backend-stream/terragrunt.hcl
│ ├── frontend/terragrunt.hcl
│ └── database/terragrunt.hcl
├── stg/
│ └── (同構成)
└── prod/
└── (同構成)設計上のポイント
Backend を 2 つの Cloud Run サービスに分離
- backend-api: REST + Frontend WebSocket。通常の HTTP トラフィック
- backend-stream: Twilio Media Streams WSS 受信専用。長時間接続 + CPU バウンド
理由 (§4.3 NFR-SC-6):
- 音声ストリーム処理は CPU バウンドで API と異なるスケール特性
- Media Streams の同時 WS 接続数は同時通話数の 2 倍想定 (caller + agent track を別 WS で捌く場合)
- 将来的に backend-stream だけ GKE / Compute Engine に分離できる設計余地を確保
Cloud Run の WebSocket 設定
- concurrency 設定: 単一インスタンスで複数 WS 接続を捌く必要あり。
- Session Affinity: WS セッションは単一インスタンスに固定
- 接続時間上限 60 分: 長時間通話で切断リスク (§11.1)。通常 60 分未満想定だが、超過見込み時は GKE / Compute Engine 分離オプション
cloud-run-websocket/モジュールで WebSocket 最適化を切り出し
Cloud SQL
- HA 構成 + 自動フェイルオーバー (NFR-AV-4)
- VPC 内からのみアクセス (Private Service Connect、Public IP 無し)
- 保存時暗号化 + バックアップ暗号化 (NFR-SE-4)
- 本番では read replica で参照系拡張 (NFR-SC-7)
- RLS 設定は migration 管理 (Drizzle ORM) → multi-tenant-rls
環境差分の例 (想像、要件には具体値なし)
| パラメータ | dev | stg | prod |
|---|---|---|---|
| Cloud Run min instances | 0 | 1 | 3+ |
| Cloud SQL tier | db-f1-micro | db-custom-2-4096 | db-custom-8-32768 (HA) |
| Cloud Run WebSocket concurrency | 低 | 中 | 高 |
| Sentry 有効 | × | ○ | ○ |
| 音声バックアップリテンション | 短 | 中 | 長 |
監視段階 (§9.1)
| フェーズ | 監視 |
|---|---|
| MVP (Phase B) | Cloud Logging + Cloud Monitoring (デフォルトアラート) |
| 初期本番 (Phase C/D) | Sentry 追加 |
| 成熟フェーズ | Datadog 追加 (APM / カスタム Metrics) |
方針: 「Cloud Logging だけで最低限の運用監視ができる状態を維持する」。Datadog は必須ではない。
論点
- backend-api と backend-stream の分離タイミング: Phase B (MVP) 時点で分けるか、単一サービスで開始し C で分けるか。IaC モジュール分離は最初から可能だが運用複雑度が増す
- Cloud Run WebSocket 60 分上限: 通常 60 分未満想定だが、法律相談の長時間通話リスクは顕在化する可能性。GKE 移行閾値の定義が必要
- Terragrunt の depends_on 設計: database → backend-api → frontend の依存順序。Apply 順序と state ロックの扱い
- Secret Manager のローテーション: Twilio / Anthropic / ElevenLabs 等の API Key ローテーション運用が未定義
- VPC Serverless Access の同時接続数: 大量 WS 接続時に NAT 疎通のボトルネックにならないか
- Cloud Run のマルチリージョン: NFR-AV-3 で「マルチリージョン or マルチインスタンス」と併記。MVP はマルチインスタンスで済ませる想定か
- コスト: min instances を引き上げるほど固定費増。Cloud Run の 0 → 1 コールドスタートと Media Streams 即応性のトレードオフ
根拠となる資料
関連する概念
関連する entity
- 該当なし (現時点)
未解決の問い
- Cloud Run WebSocket の本番稼働実績・既知のトラブル事例
- Terragrunt の共通変数管理方式 (
inputsの階層化パターン) - Cloud SQL HA のフェイルオーバー時間と Backend のリトライ秒数の整合
- Secret Manager のシークレットバージョン管理・ローテーション運用
- backend-stream を GKE へ移行する場合の閾値と移行プロセス
- マルチリージョン構成の必要性判断基準 (SLA 99.95% 達成可否と関連)
更新メモ
- 2026-04-19: v3.0 要件定義書から初版作成