【要約】【AWS】AgentCore Runtimeのフェールオーバーとリトライ設計について確認しました [Qiita_Trend] | Summary by TechDistill
> Source: Qiita_Trend
Execute Primary Source
// Problem
開発者がAgentCore Runtimeを本番環境へ導入する際、障害発生時の挙動が不明確であるという課題がある。検証により、以下の問題が明らかになった。
- ・Compute停止時は自動復旧するが、メモリ上の会話履歴が消失する。
- ・VPCモードでエグレス（通信経路）が断絶した場合、AgentCoreはVMを再作成せず、リクエストがハングし続ける。
- ・特定のAZに通信障害が発生しても、既存セッションは同じVMに固定されるため、単純なリトライでは復旧できない。
// Approach
検証結果に基づき、障害の種類に応じた適切なリカバリ戦略を提案している。具体的には以下の手法を組み合わせる。
- ・会話履歴の保持: AgentCore Memoryを利用し、VM再作成後も文脈を継続させる。
- ・ハング対策: boto3のタイムアウト値を明示的に短く設定し、VMのロックを防ぐ。
- ・AZ障害への対応: 一定回数のリトライ失敗後、StopRuntimeSessionを実行してVMを強制破棄し、AZの再抽選を促す。
// Result
検証により、エグレス障害が発生した環境下でも、適切なリカバリロジックの実装により、8本中7本のセッション救出に成功した。
- ・単純なリトライではなく「VMを捨てる」判断が、AZ障害からの脱出に不可欠であることを実証した。
- ・ただし、救出には40〜80秒を要する場合があり、同期リクエストにおける許容時間の検討が必要である。
Senior Engineer Insight
> AgentCoreの「セッション固定」は状態管理には有利だが、ネットワーク障害時には致命的な弱点となる。ALBのような動的なロードバランスを期待してはいけない。本番運用では、アプリ層での「VM破棄戦略」が必須である。また、VPCモード特有の通信経路リスクを考慮し、マルチAZ構成と適切なタイムアウト設計を組み合わせる必要がある。