どんな場面で検討するか
HTTP API、認証付き軽量処理、外部サービスの応答変換を、サーバー管理を抑えて実行したい場合。D1/R2等のbindingを組み合わせる構成も候補になる。
組織で使う条件
CPU超過とwall timeを分けて監視し、期限・再試行・排他・保留結果を記録する。 資産ファイルが動的エンドポイントを先に配信してしまわないよう、本番配信で応答と保存結果を照合する。
採用前に試すこと
- 合成API・静的資産・DB書込ルートを作り、通常応答と構造の異なる大きな応答を流す。
- 外部503/途中切断/CPU負荷を模擬し、streamingや分割で欠落なく再開できるか測る。
- 配信された実URLでJS/APIを取得し、DBの実行ID・終了・件数・内容SHA256と照合する。
合格と判断する条件
- 必要ライブラリが動き、通常のCPU/メモリ予算を満たす。
- 失敗を成功へ置換せず、前回成功値と今回の失敗日時が区別され、再開で欠落/重複がない。
- 実配信に動的保存結果が反映され、静的資産による横取りがなく、実行完了をDBで確認できる。
見落としたくない点
- 常駐プロセスやOSへの自由な操作、重い長時間CPU処理が前提ならVM/コンテナを比較する。 大きな応答を上限だけ増やして全量保持する設計は、streaming・分割・再開方式と比較する。
- 常駐プロセスやOSへの自由な操作、重い長時間CPU処理が前提ならVM/コンテナを比較する。
- 大きな応答を上限だけ増やして全量保持する設計は、streaming・分割・再開方式と比較する。