microVMsのユースケースを考える.pdf

Transcript

1. J A W S U G T o k y oランチタイムL T会 Vol.37 microVMsのユースケースについて考えてみた 常駐SQSワーカーをMicroVMで作ってみて分かったこと 10 min · ·
2. X 0 1 — I NT R O DU C T IO N 自己紹介 GitHub 蛭田 聡司 Speake rdeck Kuberetes、マイクロサービス基盤構築。laCとしてAWS CDK 高トラフィックなコンテナ基盤設計、構築、運用 AWS Community Builder 2025- 主な登壇実績 AWS CDK Conference 2026 Cloud Native Days Winter 2025 5分LT JAWSUGコンテナ支部 0.5分
3. アジェンダ Lambda microVMsとは ポーリングアプリケーション microVMsの特徴 検証で見えてきたmicroVMsのユース ケース まとめ
4. Lambda microVMs とは 常駐できる VM suspend / resume 実行ロールで SDK イベント駆動の関数ではなく、最大8 アイドル時に自動サスペンドし、着 executionRoleArn で IAM ロールを引 時間動き続けるワーカーを起動でき 信で near-instant に再開できる（と き受け、内部コードから他の AWS る される） サービスを直接呼べる
5. ライフサイクル — Running / Suspend / Terminate Suspend は往復できる。Terminate は片道 — 状態は戻らない RUNNING idle 判定 / suspend-microvm SUSPENDED terminate-microvm TERMINATED run-microvm で起 ⇄ メモリ・ディスク → 状態は完全に消失 動 コンピュート課 resume-microvm / 着信 保持 コンピュート 8h 上限到達 resume 不可 金あり 何度でも往復可 課金なし near-instant resume 片道・復元不可 続けるなら run-microvm で 新規インスタンスを起動し フルスペックで処理中 （ スナップショットとして凍 最大 8 時間のカウント進行 結 （認証済みセッション ） 等も温存） 直す 注意: Running → Suspended は RUNNING からのみ。8h 上限では Suspend されず直接 Terminate（処理中でも容赦なし）
6. 余談 — Azure にも同じ形がある: ACA Sandboxes Azure Container Apps Sandboxes (preview) — snapshot / restore を持つ軽量 VM MicroVMs と似ている点 RUNNING autosuspend SUSPENDED prewarmed pool から sub- ⇄ 軽量 VM 分離 / suspend・resume でメモリごと凍結 / Memory / Disk モード選択 idle timeout ベースの autosuspend / エージェント・サ second 起動 resume 制 ンドボックス用途 ↓ snapshot（任意タイミング・複数可） SNAPSHOT 最大の違い — snapshot の独立性 メモリ + ディスク + プロセスの完全な状態を、sandbox 本体から独立して MicroVMs の suspend 状態はインスタンスに紐づく （ 永続化。元を削除しても restore / クローン / チーム配布が可能 terminate で消失）。ACA の snapshot は ライフサイク ルから独立した checkpoint — 別 sandbox として何度 でも復元できる
7. ユースケース案 同期・非同期で idle-suspend との相性が大きく変わる 同期（HTTP 型） 非同期（ワーカー型） バッチ・単発ジョブ API サーバー・Web アプリ SQS ポーリングワーカー 長時間処理の実行基盤 公開 HTTPS エンドポイントでリクエ キューを能動的にポーリングして処理 Lambda の 15 分制限を超える処理を ストを受ける構成。着信がそのまま する常駐ワーカー。今回のプロトタイ 最大 8 時間まで実行。終わったら idle 判定になるので、自動 suspend / プはこれ。suspend 判定と噛み合わず terminate する使い切り運用なら上限 resume が本来の設計どおり活きる 外部制御が必要 も問題にならない △ 工夫すれば使える（本 LT の主題） ◦ 8 時間以内なら候補 8hでTerminateされるので、起動させる仕組みが必要
8. vs AgentCore Browser / Code Interpreter 最大の差分は Suspend / Resume の有無 — AgentCore は「使い切り」モデル Lambda microVMs AgentCore Browser / Code Interp. Suspend / Resume でメモリ・ディスクを保持したま Start / Stop のみ。Ephemeral — 終了で状態消失・復 ま課金停止 元不可 稼働上限 最大 8 時間 最大 8 時間（デフォルト 15 分） マネージド性 全部自前（Chrome・CDP・監視・ランタイム構築） ライブビュー・レコーディング・Playwright/CDP・ 状態保持 pandas 等プリインストール 課金 Suspend 中はコンピュート課金なし 秒単位。メモリはセッション中継続課金 ※ AgentCore が Lambda MmcroVMs / Firecracker 基盤かは一次情報に明記なし（"dedicated microVM" の表現のみ）
9. 使い分けの指針 AgentCore が有利 生の MicroVMs が効く = 状態を跨いで使い回す 単発〜数十分の使い切りタスク 認証済みブラウザセッションを Suspend で凍結 → 数時 ライブビュー監視・レコーディングが欲しいブラウザ自 動化 プリインストール環境で足りるコード実行（集計→結果 だけ返す等） 間後に即 Resume（再ログイン不要） 数 GB 級データをロード済みの状態を複数ターン・複数 リクエストで再利用 独自バイナリ・特殊依存が必要なサンドボックス
10. アーキテクチャ全体像 S3 → SQS はネイティブ連携。検知から登録まで MicroVM だけで完結 Bedrock S3 messages/*.txt アッ プロード SQS → イベント通知 （ Haiku 4.5 で日本語解 説生成 MicroVM → Lambda 不要） 常駐ワーカーが ロングポー リング → DynamoDB 結果を登録 at-least-once 配信 → ETag ベースの冪等性キーで dedupe
11. リポジトリ構成 cdk/ microvm-worker/ S3・SQS・DynamoDB・IAM ロール・MicroVM イメージ Dockerfile + Python。SQS をロングポーリングし、 （CfnMicrovmImage）を TypeScript で宣言的に管理 Bedrock 呼び出しと DynamoDB 登録を行う ただし: MicroVM インスタンスの起動は CloudFormation リソースとして存在しない → デプロイ後に CLI で run-microvm を手動実行
12. CDK 構成（s3-microvm-async-stack.ts） イメージ定義までは宣言的に管理できる — インスタンス起動だけが管理外 イベント配管 IAM ロール ×2 CfnMicrovmImage S3（messages/ prefix）→ SQS 通知 + buildRole（/ready・/validate 用）と ベースイメージ al2023-1 / ARM_64 のみ DLQ（maxReceiveCount: 5）、結果用 executionRole（/run 以降 + ワーカー本体 対応 / 環境変数・フック・メモリを宣言 DynamoDB ）を分離 01 通常の Lambda ロールと違い sts:TagSession を AssumeRolePolicy に追加しないと起動できない 02 自前 VPC 不要 — AWS 管理の固定 ARN コネクタ INTERNET_EGRESS でパブリック経路を確 03 保 RunMicrovm（実行中インスタンス）は CloudFormation リソースが存在しない → デプロイ後に CLI / SDK で起動
13. 実装ハイライト — ライフサイクルフック連動 ポーリング開始を /run・/resume フックまで遅延させる（app.py） # クライアント生成はフック発火まで遅延 sqs = None # bedrock, table も def do_POST(self): elif path.endswith("/run") or \ path.endswith("/resume"): なぜ遅延させるか スナップショットは buildRole で取得される。import 時 に boto3 クライアントを作ると、 buildRole の認証情報 がメモリに焼き付いたまま resume され、実行時の API 呼び出しが権限エラーになる ensure_poller_started() # # init_clients() + poll_loop スレッド起動 その他の要点 フック専用ポート(9000)のみ待ち受け / GET /ready は生 存確認だけ（ビルド検証は権限なしロールで走るため）/ 冪等性は ETag キー + attribute_not_exists
14. ハマりどころ 01 idle-suspend が SQS ワーカーに効かない 仕様 帰結 idle 判定は 公開 HTTPS エンドポイントへの着信トラフィッ SQS へのアウトバウンドポーリングは活動と見なされない ク のみで計測。CPU やプロセスの活動は見ていない → 非同期ワーカーでは自動 suspend が実質機能しない "For asynchronous applications that do not actively send or receive traffic through the endpoint, disable automatic suspension or configure a suitable idle duration." — 公式ドキュメント
15. ハマりどころ 02 ドキュメントに書いていないことが多い リスナーポート アプリ本体のHTTPリスナーとMicroVM起動時の/readyフック用リスナーポートを別にする必要 /readyフック用ポートは8080を使用している
16. ハマりどころ 03 最大稼働 8 時間 — 超過は強制 terminate 8h maximumDurationInSeconds = 28,800 上限に達すると SUSPEND ではなく TERMINATE。処理中でも容赦なく落ちる 常駐ワーカーとして使うなら、8 時間ごとに run-microvm を呼び直す仕組み （ EventBridge Scheduler + 軽量 Lambda）が別途必要
17. 設計判断 — 自己 suspend の不採用 ◦ 案B: 外部からの制御（採用） 仲介 Lambda + EventBridge Scheduler が定期的にキュー 深度を確認し、外から suspend / resume を呼ぶ。レース 対策に suspend 前の深度再確認 ※ 方針決定済み・実装は未着手（2026-07-12 時点）
18. 未実装・今後の課題 01 8 時間ごとの自動再起動（ライフサイクル管理 Lambda + EventBridge Scheduler） 02 外部 suspend / resume 制御の実装（方針は決定済み） 03 CloudWatch Alarms による監視・アラート、DLQ 再処理フロー 04 冪等性キー（ETag ベース）の見直し — マルチパートアップロードでの ETag 仕様差に注意
19. まとめ 1. S3 → SQS → MicroVM 常駐ワーカー構成は Lambda なしで成立する 2. idle-suspend は HTTP 着信でしか判定されない — ポーリング型ワーカーには効かない 3. 8 時間上限・ARN・認証情報など、実機検証が前提の新機能 github.com/clouddev-code/microvm-sample
20. APPENDIX 補足資料 A-1 主要な API / CLI コマンド A-2 デプロイ・起動手順 A-3 制約・仕様一覧 / 参考リンク
21. APPENDIX A-1 主要な API / CLI コマンド # インスタンス操作（CloudFormation リソースなし・CLI / SDK のみ） aws lambda run-microvm --microvm-image-arn <image-arn> ... aws lambda suspend-microvm --microvm-arn <arn> aws lambda resume-microvm --microvm-arn <arn> aws lambda terminate-microvm --microvm-arn <arn> aws lambda list-microvms / get-microvm # イメージ管理（こちらは CDK / CloudFormation で宣言可能） AWS::Lambda::MicrovmImage（CfnMicrovmImage） ※ 自己 suspend は不可 — suspend / resume は必ず MicroVM の外から呼ぶ
22. APPENDIX A-2 デプロイ・起動手順 01 baseImageArn / networkConnector の ARN をリージョン実値に差し替え（プレースホルダーのまま厳禁） 02 cdk deploy — S3 / SQS / DynamoDB / IAM ロール×2 / MicroVM イメージを作成 03 run-microvm を CLI で実行 — /run フック着火でポーリング開始 04 S3 の messages/ に .txt を置いて稼働確認 → DynamoDB に解説文が入れば成功
23. APPENDIX A-3 制約・仕様一覧 最大稼働時間 8 時間（28,800 秒）— 超過は強制 terminate アーキテクチャ ARM_64 のみ（ベースイメージ al2023-1） idle 判定 公開 HTTPS エンドポイントへの着信のみ 自己 suspend 不可 — 外部から suspend-microvm を呼ぶ IAM AssumeRolePolicy に sts:TagSession が必要 ネットワーク AWS 管理コネクタ INTERNET_EGRESS（自前 VPC 不要） github.com/clouddev-code/microvm-sample docs.aws.amazon.com — Lambda MicroVMs（idle-suspend の仕様はここ）
24. APPENDIX A-4 参考リンク サンプル実装（本 LT の題材） github.com/clouddev-code/microvm-sample AWS Lambda MicroVMs — 公式ドキュメント docs.aws.amazon.com/lambda/latest/dg/microvms.html idle-suspend の判定仕様・自己 suspend 不可の記述はここ Amazon Bedrock AgentCore — Browser / Code Interpreter docs.aws.amazon.com/bedrock-agentcore/ Azure Container Apps Sandboxes (preview) learn.microsoft.com/azure/container-apps/sandboxes