なぜ必要なのか

主に予定を読む祭りの案内サイトを作るとします。訪問者が時々催しを個人リストへ保存し、短い書き込み要求が発生します。

祭りの日程には時々保存要求が届く程度で、常時稼働のアプリは一日の大半を待機します。

どう解決するのか

記事の閲覧は処理器を呼び出します。祭りの日程の保存は別の実行で外部ストアに記録します。再保存しても例の読者・記事キーにより記録は1件です。次の保存を失敗させるとストアを変えず失敗を返します。処理器の再起動は実行状態だけを破棄し、記録を残します。リセット・再読み込みは仮想ストアを含むページメモリ全体を消します。

呼び出しの寿命と重複処理

概念シミュレーション

サーバーレス関数

公開記事を読み、祭りの日程を保存します。再送も美奈 / 祭りの日程を共有します。

01 · 管理型の実行

ブラウザー → 関数呼び出し → 記事HTML

02A · 保存の呼び出し

美奈 / 祭りの日程

02B · 再度の呼び出し

美奈 / 祭りの日程

実行世代: 1 · この世代の呼び出し: 0

↓ 同じキー → 1記録

待機

ストアもページメモリ上の模型です。再起動では残り、リセット・再読み込みで消えます。重複防止は独自のアプリ処理です。

実行境界
要求→管理された呼び出し→外部ストア。呼び出し間にインスタンスメモリが消えることがあります。
状態と責任
基盤はサーバーを管理し、アプリ担当は再試行・アクセス・監視・永続記録を管理します。

本文内の架空のデモです。リセット・再読み込みで初期状態に戻ります。

どんな考え方なのか

サーバーレス関数はイベントやリクエストに応じて管理された処理を実行します。基盤はサーバーを管理しますが、アプリの正しさは開発者の責任です。

重複処理と永続保存を設計し、前の実行環境が残ると仮定しないでください。

出典