Firecracker – サーバーレスコンピューティングのための軽量な仮想化機能
Firecracker – サーバーレスコンピューティングのための軽量な仮想化機能:
私の好きなAmazonリーダーシッププリンシプルの1つはCustomer Obsessionです。 私たちがAWS Lambdaをローンチしたとき、私たちは開発者にセキュアなサーバーレス体験を提供し、インフラストラクチャの管理を避けることに重点を置いていました。 目的のレベルの分離を達成するために、我々は各顧客に専用のEC2インスタンスを使用しました。 このアプローチにより、私たちはセキュリティ目標を達成することができましたが、私たちがLambdaを裏で管理する方法に関していくつかのトレードオフを余儀なくされました。 また、新しいAWSサービスの場合と同様に、顧客がLambdaをどのように使用するのか、あるいはサーバーレスモデル全体をどのように考えているのかもわかりませんでした。 私たちの計画は、時間の経過とともにバックエンドをより効率的にすると同時に、優れたカスタマーエクスペリエンスを提供することに重点を置くことでした。
ちょうど4年後 (Lambdaはre:Invent 2014でローンチされました)、サーバーレスモデルがここに残っていることは明らかです。 現在Lambdaは毎月何十万人ものアクティブな顧客に対して数兆件の処理を実行しています。 昨年、我々はAWS Fargateのローンチによりサーバーレスの利点をコンテナにまで拡張し、毎週AWSの顧客に数千万のコンテナを提供しています。
私たちの顧客がサーバーレスでの採用を進める中で、効率の問題を再検討する時が来ました。 Invent and Simplifyの原則を念頭に置いて、今のコンテナやファンクションの世界のための設計として仮想マシンがどのように見えるのか自分自身に尋ねました。
Firecrackerについて知っておくべきことは次のとおりです:
セキュア – これは常に最優先事項です! Firecrackerは複数レベルの分離と保護を使用し、攻撃面は最小限に抑えられています。
ハイパフォーマンス – 今日時点でわずか125ミリ秒 (さらに2019年に高速化予定) でmicroVMを立ち上げることができ、一時的なものや短命のものを含む多くの種類のワークロードに最適です。
Battle-Tested – FirecrackerはBattle-Testedであり、既にAWS LambdaとAWS Fargateを含む複数のハイボリュームなAWSサービスに利用されています。
低オーバーヘッド – Firecrackerは、microVMあたり約5 MiBのメモリを消費します。 同じインスタンス上で、さまざまなvCPUとメモリ構成を持つ数千のセキュアなVMを実行できます。
オープンソース – Firecrackerはアクティブなオープンソースプロジェクトです。私たちはすでにpullリクエストを確認して受け入れる準備を完了しており、世界中の寄稿者とのコラボレーションを楽しみにしています。
Firecrackerは最小限主義の流儀で造られました。 私たちはオーバーヘッドを減らし安全なマルチテナンシーを可能にするために、crosvmからスタートし、最小限のデバイスモデルを設定しました。 FirecrackerはRustで書かれており、その最新のプログラミング言語はスレッドの安全性を保証し、セキュリティの脆弱性を引き起こす可能性があるさまざまなタイプのバッファオーバーランエラーを防止します。
Simple Guest Model – Firecrackerのゲストには、ネットワークデバイス、ブロックI / Oデバイス、プログラマブルインターバルタイマー、KVMクロック、シリアルコンソール、および部分キーボード(VMをリセットできるだけのもの)といった、攻撃面を最小限に抑えるための非常にシンプルな仮想化デバイスモデルが用意されています。
Process Jail – Firecrackerプロセスはcgroupsとseccomp BPFを使用して留置され、小さくて厳密にコントロールされたシステムコールのリストによってアクセスできます。
Static Linking –
私は1つのPuTTYセッションで
そして、2番目はゲストカーネルを設定します:
そして、3番目にはルートファイルシステムを設定します:
すべての設定が完了したら、ゲストマシンを起動できます:
そして、私の最初のVMで稼働しています:
実世界のシナリオでは、Firecrackerとのやりとりのすべてをスクリプト化したりプログラムしたりします、そしてネットワーキングと他のI/Oを設定するのにもっと時間を費やすでしょう。 しかし、re:Inventが待っていますし、もっとやりたいことがたくさんあるので、私はその部分をあなたのための練習として残します。
– Jeff;
この記事はSA小川が翻訳しました。原文はこちら
追記:FirecrackerについてはAWS Open Source Blogでも紹介されていますので、ぜひ併せて参照ください。
私の好きなAmazonリーダーシッププリンシプルの1つはCustomer Obsessionです。 私たちがAWS Lambdaをローンチしたとき、私たちは開発者にセキュアなサーバーレス体験を提供し、インフラストラクチャの管理を避けることに重点を置いていました。 目的のレベルの分離を達成するために、我々は各顧客に専用のEC2インスタンスを使用しました。 このアプローチにより、私たちはセキュリティ目標を達成することができましたが、私たちがLambdaを裏で管理する方法に関していくつかのトレードオフを余儀なくされました。 また、新しいAWSサービスの場合と同様に、顧客がLambdaをどのように使用するのか、あるいはサーバーレスモデル全体をどのように考えているのかもわかりませんでした。 私たちの計画は、時間の経過とともにバックエンドをより効率的にすると同時に、優れたカスタマーエクスペリエンスを提供することに重点を置くことでした。
ちょうど4年後 (Lambdaはre:Invent 2014でローンチされました)、サーバーレスモデルがここに残っていることは明らかです。 現在Lambdaは毎月何十万人ものアクティブな顧客に対して数兆件の処理を実行しています。 昨年、我々はAWS Fargateのローンチによりサーバーレスの利点をコンテナにまで拡張し、毎週AWSの顧客に数千万のコンテナを提供しています。
私たちの顧客がサーバーレスでの採用を進める中で、効率の問題を再検討する時が来ました。 Invent and Simplifyの原則を念頭に置いて、今のコンテナやファンクションの世界のための設計として仮想マシンがどのように見えるのか自分自身に尋ねました。
Firecrackerの紹介
本日、KVMを利用する新しい仮想化技術であるFirecrackerについてお話したいと思います。 仮想化されていない環境では、軽量のマイクロ仮想マシン(microVM)を数秒で起動することができ、従来のVMで提供されているセキュリティとワークロードの分離と、コンテナに伴うリソース効率性を向上しています。Firecrackerについて知っておくべきことは次のとおりです:
セキュア – これは常に最優先事項です! Firecrackerは複数レベルの分離と保護を使用し、攻撃面は最小限に抑えられています。
ハイパフォーマンス – 今日時点でわずか125ミリ秒 (さらに2019年に高速化予定) でmicroVMを立ち上げることができ、一時的なものや短命のものを含む多くの種類のワークロードに最適です。
Battle-Tested – FirecrackerはBattle-Testedであり、既にAWS LambdaとAWS Fargateを含む複数のハイボリュームなAWSサービスに利用されています。
低オーバーヘッド – Firecrackerは、microVMあたり約5 MiBのメモリを消費します。 同じインスタンス上で、さまざまなvCPUとメモリ構成を持つ数千のセキュアなVMを実行できます。
オープンソース – Firecrackerはアクティブなオープンソースプロジェクトです。私たちはすでにpullリクエストを確認して受け入れる準備を完了しており、世界中の寄稿者とのコラボレーションを楽しみにしています。
Firecrackerは最小限主義の流儀で造られました。 私たちはオーバーヘッドを減らし安全なマルチテナンシーを可能にするために、crosvmからスタートし、最小限のデバイスモデルを設定しました。 FirecrackerはRustで書かれており、その最新のプログラミング言語はスレッドの安全性を保証し、セキュリティの脆弱性を引き起こす可能性があるさまざまなタイプのバッファオーバーランエラーを防止します。
Firecrackerのセキュリティ
前述のように、Firecrackerには多数のセキュリティ機能が組み込まれています! ここに部分的なリストがあります:Simple Guest Model – Firecrackerのゲストには、ネットワークデバイス、ブロックI / Oデバイス、プログラマブルインターバルタイマー、KVMクロック、シリアルコンソール、および部分キーボード(VMをリセットできるだけのもの)といった、攻撃面を最小限に抑えるための非常にシンプルな仮想化デバイスモデルが用意されています。
Process Jail – Firecrackerプロセスはcgroupsとseccomp BPFを使用して留置され、小さくて厳密にコントロールされたシステムコールのリストによってアクセスできます。
Static Linking –
firecracker
プロセスは静的にリンクされており、ホスト環境ができるだけ安全でクリーンであることを確認するために、jailerから立ち上げることができます。Firecrackerのアクション
Firecrackerを体験するために、私はi3.metalインスタンスを起動し3つのファイル(firecracker
バイナリ、ルートファイルシステムイメージ、およびLinuxカーネル)をダウンロードします。/dev/kvm
にアクセスするための適切なアクセス許可を設定する必要があります。$ sudo setfacl -m u:${USER}:rw /dev/kvm
firecracker
を開始し、別のプロセスでコマンドを発行します(プロセスはUnixドメインソケットをリッスンし、REST APIを実装します)。 最初のコマンドは、最初のゲストマシンの設定を行います。$ curl --unix-socket /tmp/firecracker.sock -i \
-X PUT "http://localhost/machine-config" \
-H "accept: application/json" \
-H "Content-Type: application/json" \
-d "{
\"vcpu_count\": 1,
\"mem_size_mib\": 512
}"
$ curl --unix-socket /tmp/firecracker.sock -i \
-X PUT "http://localhost/boot-source" \
-H "accept: application/json" \
-H "Content-Type: application/json" \
-d "{
\"kernel_image_path\": \"./hello-vmlinux.bin\",
\"boot_args\": \"console=ttyS0 reboot=k panic=1 pci=off\"
}"
$ curl --unix-socket /tmp/firecracker.sock -i \
-X PUT "http://localhost/drives/rootfs" \
-H "accept: application/json" \
-H "Content-Type: application/json" \
-d "{
\"drive_id\": \"rootfs\",
\"path_on_host\": \"./hello-rootfs.ext4\",
\"is_root_device\": true,
\"is_read_only\": false
}"
# curl --unix-socket /tmp/firecracker.sock -i \
-X PUT "http://localhost/actions" \
-H "accept: application/json" \
-H "Content-Type: application/json" \
-d "{
\"action_type\": \"InstanceStart\"
}"
実世界のシナリオでは、Firecrackerとのやりとりのすべてをスクリプト化したりプログラムしたりします、そしてネットワーキングと他のI/Oを設定するのにもっと時間を費やすでしょう。 しかし、re:Inventが待っていますし、もっとやりたいことがたくさんあるので、私はその部分をあなたのための練習として残します。
私たちとコラボレーション
ご覧のとおりこれは大きな飛躍ですが、これは単なる第一歩です。 チームはあなたともっと話をして、あなたと協力して前進することを楽しみにしています。 repoに星を付け、コミュニティに参加し、コードを送信してください!– Jeff;
この記事はSA小川が翻訳しました。原文はこちら
追記:FirecrackerについてはAWS Open Source Blogでも紹介されていますので、ぜひ併せて参照ください。
コメント
コメントを投稿