MicroVMs: 完全なライフサイクル制御を備えた隔離されたサンドボックスを実行する

完全なライフサイクル制御を備えた隔離されたサンドボックスを実行する: AWS LambdaがMicroVMsを導入 本日、AWS Lambda MicroVMsを発表します。これは、AWS Lambda内の新しいサーバーレスコンピューティングプリミティブであり、ユーザーまたはAIが生成したコードを隔離されたステートフルな実行環境で実行できます。仮想マシンレベルの分離、ほぼ瞬時の起動と再開、環境ライフサイクルと状態の直接制御を、インフラストラクチャの管理や複雑な仮想化技術の専門知識の構築なしで実現します。Lambda MicroVMsは、毎月15兆回以上のLambda関数呼び出しを支えてきたのと同じ軽量仮想化技術であるFirecrackerによって強化されています。 お客様がこれを必要とする理由 過去数年間で、各エンドユーザーに、アプリケーション開発者が記述していないコードを安全に実行するための専用実行環境を提供するという共通のニーズを持つ新しい種類のマルチテナントアプリケーションが出現しました。AIコーディングアシスタント、インタラクティブなコード環境、データ分析プラットフォーム、脆弱性スキャナー、およびユーザー提供スクリプトを実行するゲームサーバーはすべてこのパターンに適合します。今日のこの機能を構築するには、難しい選択を迫られます。仮想マシンは強力な分離を提供しますが、起動に数分かかります。コンテナは数秒で起動しますが、その共有カーネルアーキテクチャは、信頼できないコードを安全に隔離するために大幅なカスタム強化が必要です。Functions as a Serviceはイベント駆動型、リクエスト応答型のワークロードに最適化されていますが、ユーザーインタラクション間で環境状態を保持する必要がある長時間実行のインタラクティブセッション向けには設計されていません。これにより、開発者はパフォーマンスと分離のトレードオフを受け入れるか、エンドユーザーに低遅延のエクスペリエンスを提供しながら分離された実行を実現するために、独自の仮想化インフラストラクチャを構築および運用するために多大なエンジニアリングリソースを投資するかのいずれかになります。これは深い専門知識を必要とし、実際に構築しようとしている製品からエンジニアリングの時間を奪う努力を伴います。Lambda MicroVMsは、まさにこのギャップのために特別に構築されています。各MicroVMは、単一のエンドユーザーまたはセッションに独自の隔離された環境を提供し、迅速に起動し、セッション期間中はメモリとディスクの状態を保持し、ユーザーが離れると低アイドルコストで一時停止します。同じFirecracker技術がすでにAWS Lambda Functionsの基盤となっているため、このスタックを大規模に実行しているサービスの運用成熟度を継承します。 試してみましょう 開始するには、AWS Lambdaコンソールに移動し、左側のナビゲーションメニューにLambda MicroVMsが表示されています。まず、MicroVMイメージを作成する必要があります。私はFlaskウェブアプリとそのDockerfileをzipファイルにパッケージ化し、Amazon Simple Storage Service (Amazon S3) バケットにアップロードしました。私のFlask API – app.py ```python import logging from flask import Flask, jsonify app = Flask(__name__) logging.basicConfig(level=logging.INFO) @app.route("/") def hello(): app.logger.info("Received request to hello world endpoint") return jsonify(message="Hello, World!") if __name__ == "__main__": app.run(host="0.0.0.0", port=5000) ``` 私のDockerfile ```dockerfile FROM public.ecr.aws/lambda/microvms:al2023-minimal RUN dnf install -y python3 python3-pip && dnf clean all WORKDIR /app COPY requirements.txt . RUN pip install --no-cache-dir -r requirements.txt COPY app.py . EXPOSE 5000 CMD ["gunicorn", "--bind", "0.0.0.0:5000", "app:app"] ``` 次のコマンドを使用してMicroVMイメージを作成しました。 ```bash aws lambda-microvms create-microvm-image \ --code-artifact uri=<path/to/s3/artifact.zip> --name <VM_image_name> \ --base-image-arn arn:aws:lambda:us-east-1:aws:microvm-image:al2023-1 \ --build-role-arn <IAM role ARN> ``` 上の画像のように、AWSコンソールでMicroVMイメージを作成することもできます。コマンドを実行すると、Lambdaはzipを取得し、Dockerfileを実行し、アプリケーションを初期化し、実行中のディスクとメモリの状態のFirecrackerスナップショットを作成しました。ビルドログは/aws/lambda/microvms/<image-name>の下のAmazon CloudWatchにリアルタイムでストリーミングされ、イメージの準備が整うと、そのAmazon Resource Name (ARN)とバージョン番号とともにコンソールに表示されました。 ```bash aws lambda-microvms run-microvm \ --image-identifier arn:aws:lambda:<region>:<acct>:microvm-image:my-image \ --execution-role-arn arn:aws:iam::<acct>:role/MicroVMExecutionRole \ --idle-policy '{"maxIdleDurationSeconds":900,"suspendedDurationSeconds":300,"autoResumeEnabled":true}' ``` 起動はAWSコンソールまたはCLIからも可能です。イメージARNと、15分間の非アクティビティ後に自動サスペンドし、次の受信リクエストで自動再開するように設定されたアイドルポリシーを渡しました。ネットワーク設定は不要でした。LambdaはMicroVMに一意のIDを割り当て、専用のエンドポイントURLを返し、Flaskアプリがすでに実行されている新しいMicroVMを開始しました。これはスナップショットから再開されたためです。起動が完了した瞬間、私のFlaskアプリはすでに実行されていました。1つのAPI呼び出しで、完全に初期化され、ブートストラップされたコンピューティング環境を取得できます。トラフィックを送信するために、CLIで短寿命の認証トークンを生成し、X-aws-proxy-authヘッダーを使用してプレーンなHTTPSリクエストに添付しました。リクエストはすぐに私のFlaskアプリに着弾しました。その後、MicroVMをサスペンド閾値を超えてアイドル状態にさせると、MicroVMはサスペンドされ、そのメモリとディスクの状態はスナップショットとして保存されました。その後、別のリクエストを送信すると、アプリケーションの状態が完全に無傷で再開されました。クライアント側からは、一時停止は一度も起こらなかったように見えます。 仕組み 内部的には、Lambda MicroVMsは、今日までどの単一のAWSコンピューティングサービスもまとめて提供していなかった3つの機能を提供します。1つ目は、Firecrackerによる仮想マシンレベルの分離です。各セッションは、独自の専用MicroVMで実行され、共有カーネルやユーザー間の共有リソースはありません。これにより、あるユーザーによって提供された信頼できないコードは、他の環境や基盤となるシステムにアクセスすることなく、その実行環境内に隔離されます。2つ目は、高速な起動と再開です。モデルはイメージ作成後に起動する方式です。DockerfileとAmazon S3にzipアーティファクトとしてパッケージ化されたコードを提供することでMicroVMイメージを作成し、LambdaがDockerfileを実行し、アプリケーションを初期化し、実行中の環境のメモリとディスク状態のFirecrackerスナップショットを作成します。そのイメージから起動されるその後のすべてのMicroVMは、コールドブートするのではなく、事前初期化されたスナップショットから再開されるため、起動とアイドルからの再開の両方がほぼ瞬時の起動レイテンシを達成します。たとえ数ギガバイトのインタラクティブセッションであっても、エンドユーザーにレスポンスが感じられるほど迅速にオンラインに戻ります。3つ目は、ステートフルな実行です。実行中のMicroVMは、ユーザーのセッション全体でメモリ、ディスク、実行中のプロセスを保持します。アイドル期間中、MicroVMは（メモリとディスクの状態をそのままに）サスペンドされ、トラフィックが到着すると再開できます。インストールされたパッケージ、ロードされたモデル、作業中のファイルセットは、ユーザーがセッションを再開したときにすぐに利用できます。MicroVMsは最大8時間の総実行時間をサポートし、設定可能なアイドル期間後に自動的にサスペンドできるため、数分で完了するソフトウェア脆弱性スキャン、数時間実行されるデータ分析アプリケーション、および長時間のアイドル期間を持つインタラクティブなコーディングセッションなど、さまざまな製品を簡単に構築できます。Lambda MicroVMsは事前初期化されたスナップショットから起動されるため、初期化中にユニークなコンテンツを生成したり、ネットワーク接続を確立したり、一時的なデータをロードしたりするアプリケーションは、互換性のためにサービスが提供するフックと統合する必要がある場合があります。Lambda MicroVMsは、AWS Lambda内の新しいリソースであり、異なるAPIサーフェスを持っています。Lambda Functionsはイベント駆動型、リクエスト応答型のワークロードに依然として適切な選択肢であり、Lambda MicroVMsは、各エンドユーザーまたはセッションに、ユーザーまたはAIが生成したコードを実行するための独自の隔離された環境を提供するマルチテナントアプリケーションのために特別に構築されています。これら2つは互いに補完し合います。イベント駆動型バックボーンにLambda Functionsを使用するアプリケーションは、信頼できないコードを隔離して実行する必要があるステップでLambda MicroVMsを呼び出すことができます。