【要約】Lambda MicroVMsで「再開可能なPython実行カーネル」を作る — fleet管理まで実装してLambdaの実行モデルを越える [Zenn_Python] | Summary by TechDistill
> Source: Zenn_Python
Execute Primary Source
// Problem
開発者が、計算リソースを一時停止しながらも、実行中のプロセスやメモリ上の変数を維持したいという課題に直面している。従来のサーバーレス環境では、以下の問題が存在する。
- ・通常のLambda関数は、呼び出しごとに実行環境がリセットされる。
- ・durable functionsは「チェックポイント＆リプレイ」方式であり、メモリ上の生きたプロセスや非決定的な状態を保持できない。
- ・状態を保持し続けるために常時起動させると、アイドル時も課金が発生し続ける。
// Approach
著者は、Lambda MicroVMsの「メモリ・ディスクの凍結/復元」機能を核とし、ステートフルな実行環境とステートレスな制御層を分離するアーキテクチャを採用した。
- ・MicroVMs：Pythonコードを実行し、変数やスレッドをメモリに保持するステートフルな本体。
- ・Orchestrator Lambda：API Gateway経由でMicroVMの起動・再開を制御するステートレスな層。
- ・DynamoDB：セッションIDとMicroVMの情報を紐付けるfleet台帳。
- ・Reaper Lambda：EventBridgeで定期実行し、期限切れセッションの削除と台帳の自己修復を行う。
- ・データプレーンの分離：クライアントがMicroVMの専用エンドポイントへ直接通信する設計により、低レイテンシを実現。
// Result
著者は、中断と再開を跨いで、メモリ上の変数、DataFrame、バックグラウンドスレッドの状態が完全に維持されることを実証した。
- ・中断中のvCPU・メモリ課金を停止しつつ、実行状態を保存可能にした。
- ・MicroVMの自動suspendによる台帳との不整合を、reaperによる自己修復で解決した。
- ・durable functionsでは不可能な、非決定的な状態（実行中のスレッド等）の継続を実現した。
Senior Engineer Insight
> コントロールプレーンとデータプレーンを分離した設計は、大規模トラフィックを捌く上で極めて合理的だ。MicroVMへの直接アクセスにより、プロキシ層のオーバーヘッドを排除している。ただし、イメージビルドに約160秒を要する点は、動的な環境払い出しにおいてボトルネックになり得る。実運用では、事前にウォームアップされたイメージをプールしておく等の戦略が必要だ。AIエージェントの実行基盤としては、コスト効率と状態保持のバランスが非常に優れた選択肢となる。