デプロイ方針
MVP: 単一サービスデプロイ
BFF と Backend は 同一 Cloud Run サービス としてデプロイする。
| 判断理由 | 説明 |
|---|---|
| in-process 参照 | Application 層を直接参照するため、同一プロセス内で動作する必要がある |
| 運用シンプルさ | 単一チーム・単一デプロイパイプラインで管理可能 |
| インフラコスト | Cloud Run インスタンス数を最小化 |
[Cloud Run Service: tashika-app]
├── BFF Endpoints (/employee/*, /admin/*, /agency/*, /system/*)
├── Backend API Endpoints (/api/v1/external/*)
├── Application Layer
├── Infrastructure Layer
└── Health Check (/health)ヘルスチェック
GET /health| 状態 | レスポンス | 条件 |
|---|---|---|
| Healthy | 200 OK | DB 接続正常 + セッションストア正常 |
| Degraded | 200 OK (body に degraded 表示) | 非必須サービス（ウイルススキャン等）が異常 |
| Unhealthy | 503 Service Unavailable | DB 接続不可 or シャットダウン中 |
- Graceful Shutdown 開始時に即座に Unhealthy に切替（→ operational-architecture.md）
- Cloud Run のヘルスチェック間隔: 10秒
将来のサービス分離
スケールアウトが必要になった場合、BFF と Backend を別サービスに分離可能:
- MediatR の
ISender.Send()を HTTP 呼び出しに差し替えるアダプターを実装 - BFF を独立した Cloud Run サービスとしてデプロイ
- Backend API のエンドポイントを Internal Service として構成
MediatR のインターフェースが抽象化層として機能するため、Application 層のコードは変更不要。
→ 満たす要件: AV-001 可用性