AgentCoreのセッション分離と状態の永続化を別に設計する
AgentCore Runtimeのセッションが分離されていても、計算環境のメモリや一時ディスクが永続化されるとは限らない。同じruntimeSessionIdで再開する場合も、何が保存されるかを確認する。
用語
- microVM
- セッションの計算資源やメモリなどを分離する軽量な仮想マシン。
- runtimeSessionId
- AgentCore Runtimeへの関連する呼び出しを同じセッションへ結び付けるID。
- 永続ストレージ
- 計算環境が停止しても必要な状態を保持する保存先。
図と例
利用者とセッションを照合 → microVMで処理 → 必要な状態を永続保存 → 新しい計算環境で復元
仮定の例：審査待ちの情報をPythonの変数だけに残した。翌日に同じセッションIDを指定しても復元できるとは考えず、DBの審査状態と操作IDを読み込んで再開する。
実際のサービス・製品では
Amazon Bedrock AgentCore Runtime
AWSのセッション資料はmicroVMの一時的な状態、設定したセッションストレージ、利用者との対応をアプリ側で管理する責任を説明する。Instancesの保存方式と混同しない。
資料を読む
解説
会話ID・runtimeSessionId・業務の操作IDを対応付ける。計算環境の停止後に、承認待ちや外部操作の状態を復元できるかを試す。
ここではAgentCore RuntimeのmicroVMを対象とする。既定の計算環境は一時的で、メモリやディスク上の状態はその計算環境の存続中だけ保持される。停止後に同じruntimeSessionIdで呼び出すと、新しい計算環境で再開する場合がある。設定したセッションストレージは停止をまたいでファイルを保持できるが、プロセスのメモリまで保存するものではない。必要な実行状態は永続ストレージへ記録する。また、AgentCoreはセッションと利用者の対応を強制しないため、バックエンドで所有者を検証する。
トレードオフ
- microVMのメモリに一時値を置く
- 得るもの：同じ計算環境で処理中の値を使いやすい
- 払うもの：停止後の復旧に必要な値は別の保存先が要る
- 必要な状態を永続ストレージへ保存する
- 得るもの：計算環境を作り直しても状態を復元できる
- 払うもの：保存時点、整合性、削除とアクセス制御を設計する
さらに学ぶ
チェック
microVMが停止した後、同じruntimeSessionIdで審査待ちを再開したい。正しい設計は？
- セッションが分離されているので全変数も戻ると扱う
- セッションストレージが全プロセスメモリを復元すると扱う
- 永続保存した審査状態を読み、所有者を検証して再開する
解答と解説
永続保存した審査状態を読み、所有者を検証して再開する
セッション分離は永続化の保証ではない。ファイルの保持とプロセスメモリも別で、再開に必要な状態と所有者の対応をアプリで確認する。