疎結合の非同期処理

このパターンは？

重い処理や急増するリクエストを、直接同期呼び出しせずにいったん「間にメッセージング基盤を挟んで」捌く構成。Google Cloud で疎結合を組むときの基本形です。

• スパイクを バッファ して取りこぼさない
• 失敗を リトライ／デッドレター で安全に退避
• 送信側（Producer）と処理側（Worker）を 独立にスケール

構成

[フロント/Producer]
   │ メッセージ発行
   ▼
Pub/Sub トピック ──► サブスクリプション ──► ワーカー(Cloud Run / Cloud Functions) ──► Firestore / Cloud Storage
   │ (1トピック→複数サブスクで同報)         │
   │                                        └─ 失敗 ─► デッドレタートピック(退避)
   ▼
別のサブスクリプション ──► 別ワーカー

別解: Eventarc (GCP イベントを CloudEvents で受けてルーティング) ──► 各ターゲット

コンポーネントの役割と使い分け

• Pub/Sub: バッファ兼ファンアウト。1トピック→1サブスクで SQS 的なキュー、1トピック→複数サブスクで SNS 的な同報を1サービスで両立。ack 期限とデッドレタートピックで確実に処理
• Eventarc: Cloud Storage の書き込みや Audit Log などの GCP イベントを CloudEvents 形式でルーティング。内部実装は Pub/Sub
• ワーカー: Cloud Run / Cloud Functions（コンテナ/関数でスケール to ゼロ）。push サブスクで HTTP 起動、pull サブスクで自前ポーリング
• 保存先: Firestore（サーバーレス NoSQL）/ Cloud Storage（大きな成果物）

設計の勘所

• 処理は 冪等 に（Pub/Sub の既定は at-least-once 配信＝重複し得る）。重複が困るなら exactly-once delivery を有効化したサブスクを使う
• 厳密な順序が要るなら ordering key を付けて発行（同一キー内で順序保証）。順序付きストリーム分析なら Pub/Sub + Dataflow
• ワーカーの自動増減は、push なら Cloud Run / Functions が リクエスト数で自動スケール、pull なら 未処理メッセージ数（バックログ） を見てスケールさせる
• 大きいペイロードは Cloud Storage に置き、メッセージには オブジェクト参照（gs:// パス） だけを入れる（Pub/Sub のメッセージ上限は 10MB）

Well-Architected の観点

• 信頼性: バッファ・リトライ・デッドレタートピックで取りこぼさない
• パフォーマンス効率: 発行側と処理側を独立スケール、スパイクを吸収
• コスト最適化: ワーカーは スケール to ゼロ。必要な時だけ処理し、スパイクに過剰投資しない

よくある落とし穴

選び方の早見表

AWS との対応（疎結合まわり）