どんな場面で検討するか
オブジェクト作成、メッセージ、HTTPなどのイベントに対し、関数のコードを配備して小さな連携処理を動かしたい場合。コンテナ管理を直接行うより関数単位で開発したいときに候補。
組織で使う条件
イベントIDによる冪等化、データ処理結果の記録、失敗の再処理を持つ。Eventarc側の配送状態と関数の処理成功を分けて監視する。
採用前に試すこと
- 世代とデプロイ経路を明記し、合成在庫20件・イベントID・検証用保存先を用意する。
- 正常、重複、形式不正のイベントを送信し、配達記録と処理結果を対照する。
- 一時的な保存失敗からの再試行を試し、実行/イベント/ビルドの課金要因を分けて記録する。
合格と判断する条件
- 在庫20件の期待値が一致し、重複で在庫が二重変化しない。失敗したイベントを識別して再処理できる。
- 世代に合った制約と料金体系を選定資料へ記録できる。
見落としたくない点
- 独自のコンテナ環境や複数処理をまとめたアプリが必要ならCloud Runサービス、複雑なジョブならJobs等と比較する。旧世代の課金・制約を現在世代へそのまま適用しない。
- 独自のコンテナ環境や複数処理をまとめたアプリが必要ならCloud Runサービス、複雑なジョブならJobs等と比較する。旧世代の課金・制約を現在世代へそのまま適用しない。