DynamoDBを追加せず、CRMの項目だけで結果確認のPollerを回しました。受付後の進行情報をAWS側の別ストアに増やさず、履歴レコード上のJSONに載せます。確認用Lambdaに公開HTTPは付けません。
シリーズ「Zoho WidgetとLambdaの連携」の第5回です。シリーズの締めです。
前回: Zoho WidgetとLambdaの連携 第4回：外部送信の受付判定と自動retry抑止
この記事の内容
- ポーリングの定義と、ブラウザ終了後も継続する理由
- 最終結果の正本の場所
- DynamoDBを追加しなかった理由と、既知の制限一覧
構成要素
| 要素 | 役割 |
|---|---|
| Widget | 要求受付までを表示。最終完了とは表示しない |
| 履歴レコード | 最終成功／失敗／人手確認の正本。進行JSONも保持 |
| 確認用Lambda（Poller） | 受付済みを定期照会し、履歴を更新する |
| EventBridge Scheduler | 公開URLなしでPollerを定期起動する |
| 外部送信API | 結果照会先 |
ポーリング
ポーリングは、完了通知を待つ代わりに、クライアントまたはジョブ側から繰り返し状態照会する方式です。利用者のブラウザタブが閉じても、バックエンドの定期ジョブは継続します。
起動は公開HTTPSではなく、EventBridge SchedulerからIAMでInvokeします。間隔はおおよそ2分です。重要なのは秒数より、公開HTTPではなくScheduler起動という境界です。間隔とバッチサイズは、外部APIのレート制限を超過しない前提で環境ごとに決めます。
最終結果の見方
| 場所 | 見える内容 |
|---|---|
| Widget | 要求できたことまで。最終完了とは表示しない |
| CRMの履歴状態 | 最終成功／失敗／人手確認の正本 |
| 通知やWidget再表示 | 案件依存。本稿では固定しない |
運用は履歴を見る前提です。送信ボタン成功は受付成功であり、最終結果ではありません。
照会の終端は、最終成功、最終失敗、または期限切れ等による人手確認です。これが確認用Lambdaの役割です。状態遷移の詳細は第4回です。
確認用Lambdaを分けた理由
入口や副作用の公開HTTPに同居させると、定期ジョブまで公開攻撃面になります。同期の画面操作と非同期の継続処理も混ざります。そのため別Lambdaとし、Function URLは持たせず、SchedulerからのIAM Invokeのみにしました。
DynamoDBを追加する場合との比較
DynamoDBはAWSのマネージドNoSQLです。キーアクセス向けの別テーブルとして進行管理を置く設計もあります。
本稿の構成ではCRM側を選びました。進行用の正本を増やさないためです。
| CRMの項目に載せる | DynamoDB等を追加する | |
|---|---|---|
| 正本の数 | 増やさない | AWS側に追加される |
| 障害時の調査 | 履歴レコードを見る | 追加ストアも調査対象 |
| スキーマ変更 | CRM項目変更が必要 | テーブル設計が追加 |
| 競合制御 | CRMの楽観的ロックと同じ土台 | 同期・整合の論点が追加 |
確認用Lambda自体はほぼstatelessです。起動のたびにCRMを参照し、対象を取得し、外部を照会し、履歴を更新します。進行情報は履歴レコード上のJSONフィールドに載せます（実フィールド名は記載しません）。
JSONで見る主な項目は、次回照会時刻、試行回数、期限、最後のエラーです。無期限照会を避け、打ち切り後は人手確認へ遷移するためです。
自動確認の対象は、自動照会が必要な状態のみです。最終成功・失敗・人手確認は主対象から外し、自動では再進捗しません。競合（HTTP 412）では上書きせずskipします。
一覧は状態で絞ってバッチ取得します。未到期行が枠を占有すると取りこぼしがありえます。厳密なキューではありません。取りこぼしは、次回起動や期限打ち切りで運用から見える前提で回します。
全体の流れ
- Widgetで入力を保存する（入口、HMAC）
- プレビューGET後、確認したbytesを直送で履歴へ保存する（第3回）
- 履歴IDで外部送信を要求する。成功は受付まで。受付不明は人手確認へ遷移し、自動再送しない（第4回）
- ブラウザ終了後も、確認用Lambdaが進行JSONを更新しながら結果を追う（本稿）
- 最終成功、最終失敗、または人手確認で終了する
HMAC検証失敗時は着弾raw bodyを先に疑ってください（第2回）。入口・副作用・確認用の分割は維持した方がよいです（第1回）。
既知の制限とトレードオフ
シリーズ全体で意図的に受容している点、または運用依存の制限です。防衛方針はURL秘匿ではなく、検証できない要求を通さないことです。
| 制限 | 扱い |
|---|---|
Function URLが NONE で公開HTTPになる |
URL秘匿を防衛に数えない。HMAC／token／IAMで実効認可 |
| HMACの300秒以内replay台帳なし | 受容。更新系はidempotency・競合・状態ガード |
| プレビュー短命URLの漏洩 | 有効期限内のPDF読取リスク。業務POSTは閉じる |
| 直送tokenの横断one-time不完全 | warmコンテナ上のbest-effort。期限切れは再発行 |
| 画面改ざん＋hash一致 | 確認bytes＝保存bytesまで。画面自体の改ざんは別レイヤ |
| Poller一覧のバッチ取りこぼし | 厳密なキューではない前提で運用 |
| 鍵ローテーション手順 | 運用依存。片方遅れで全HMACが失敗する |