これはAWS Firecracker上で動いていますが、もちろん他の新興マイクロエンジンも同時に利用可能です。
FreeBSD カーネルのソートアルゴリズムを置き換えたところ、起動が 100 倍以上速くなりました。
過去5年間、マイクロバーチャルマシンは技術研究開発の分野で注目を集めてきました。その中核となる考え方は、1960年代にIBMがその誕生とともに発明した 再パッケージ化し、革新することです。つまり、別のオペレーティング・システム上のゲスト・システムとしてのみ動作するオペレーティング・システムを設計することです。つまり、オペレーティング・システムは、ハードウェアをエミュレートするのではなく、仮想マシン内で実行され、特定のハイパーバイザーによって提供されるリソースと相互作用するように特別に構築されなければなりません。
つまり、ゲストオペレーティングシステムは、ホストのハイパーバイザが提供する機能と直接対話できる VirtIO ドライバのみで、実際のハードウェアのサポートをほとんど必要としません。その結果、ハイパーバイザーは、エミュレートされた PCI バス、エミュレートされた電源管理、エミュレートされたグラフィック カード、エミュレートされた NIC などを提供する必要がなくなります。その結果、ハイパーバイザー自体がより小さくシンプルになります。
VMモニタとその内部で実行されるオペレーティング・システムを無慈悲に縮小することで、両端をより小さくすっきりさせることができます。つまり、VMはより少ないリソースで、より高速に起動することができます。
現在、ビジネスの目標は「」コンピューティング・パワーを提供することです。もちろん、現実世界のサーバーはまだどこかのデータセンターに存在しています。しかし、これは「サービスとしてのインフラ」モデルを提供することではなく、「サービスとしての機能」モデルを提供することと同じです。つまり、インフラについて何も知る必要がないのです。プログラムが別のプログラムを呼び出し、管理ツールが必要な特定のオペレーションを実行し、結果を返し、その計算を実行するために使われた仮想マシンを削除します。このプロセスがどこでどのように行われるかを知る必要はありません。
消費者にとって、この技術の利点はそのスピードと使いやすさです。また、サービス・プロバイダーにとっては、リソースのリサイクルと再利用がより迅速に行えるため、同じハードウェアでより多くの顧客にサービスを提供できるという大きなメリットがあります。
AWSは、難解な関数型プログラミング用語にちなんで名付けられたLambdaと呼ばれるサービスを通じてFaaSを提供しており、これはAmazon独自の Firecracker ハイパーバイザーを搭載しています。
FirecrackerはLinuxカーネルベースのKVMハイパーバイザーを内蔵しており、AWSの Xenハイパーバイザーベースの アプローチとは本質的に異なります。これは本質的にLinux-on-Linuxソリューションであることを意味します。これはFreeBSDのカーネル開発者であるColin Percivalにとっては挑戦のように聞こえますが、 1年前に報告されたように、彼はFirecracker上でFreeBSDを実行することに決めました。
今週初めの彼の Xenハイパーバイザーベースよると、彼の最新の性能最適化は非常に驚くべきもので、 置換ソートアルゴリズムは FreeBSD のカーネルブートプロセスを約 100 倍高速化し、 カーネルのロード時間をなんと 25 ミリ秒に短縮しました。言い換えれば、40 分の 1 秒です。
FreeBSD はもはや SYSINIT 上でバブルソートを行いません。現在では、より効率的で約 100 倍高速な マージソートが実行されています：
FreeBSD カーネルが Firecracker で起動するとき、その時間の約 7% を SYSINIT のバブルソートの実行に費やすようになりました。
何千ものエントリをソートする必要がある場合、O(N^2)の複雑さは大きな影響を及ぼします。したがって、バブリングソートをより効率的なアルゴリズムに置き換える時期に来ています。
この微調整は、2日後に彼が ツイート した一連の最適化の最新版にすぎません。これにはブートに必要な最初の変更が含まれます。Xen環境でのブートを想定した初期化ステップのいくつかを削除し、プロセッサのタイプと数をACPIに照会ます。FirecrackerはACPIを提供していないため、このステップには問題があり、Firecrackerがエミュレートする唯一のハードウェアであるシリアル・コンソールの初期化も失敗しました。
Firecrackerはデフォルトで128MBのメモリしかクライアントに割り当てないため、この前提を修正する必要がありました。Firecrackerはデフォルトではクライアントに128MBのメモリしか割り当てないため、この前提を修正する必要がありました。
特に技術に詳しくなくても、この記事を読むと面白いですよ。いくつかの手順は、専用ハードウェアでブートストラップするための賢明な選択を変更するもので、マシンがスポーンして作業を行い、数秒のうちに再び削除される仮想環境ではもはや適用できません。
とパーシヴァルは ：
同じ環境で Linux は 75-80ms で起動し、FreeBSD は 25ms で起動すると思います。
ブートプロセスの高速化に取り組み始めたころは、カーネルの起動に10秒ほどかかっていましたから、今では数年前に比べて約400倍も高速に起動するカーネルになっています。
現在、最適化されているシステムカーネルは、x86-64アーキテクチャで動作するFreeBSDバージョン14ですが、 64に適合させるための作業も進行中です。
canonicalの開発者であるChristian Erhardt氏は、Ubuntuでのこの技術の使用とオンラインコード開発について います。オンラインコード開発環境のプロバイダーであるHocus社は、最近FirecrackerからQEMUに相当するものに移行した 理由を説明 しました。
クラウドシナリオだけでなく、マイクロ仮想マシンの潜在的なユースケースは数多く考えられます。常に完全なシミュレーション環境を実行することなく、別のOS用に構築された1つのプログラムをまったく別のOS上で実行できることは、さまざまなシナリオで重宝されるでしょう。
コンテナは非常に便利なツールですが、コンテナではホストOSと同じバイナリしか実行できません。それ以外のもの、例えばmacOS上でDocker Linuxコンテナを実行するということは、スタックのどこかにエミュレーションとゲストOSが隠れているということです。そのVMが小さければ小さいほど、そして使用するリソースが少なければ少ないほど、コンテナにとってもマシン全体にとっても、全体的なパフォーマンスが向上します。
を経由して
