WebAssemblyはコンテナの次の進化ステップかもしれない：ミュンヘンのInfoQ DevSummitでFermyonが語る

原文リンク

InfoQ Dev Summit Munichの初回開催におけるプレゼンテーションの中で、Fermyonのプリンシパル・ソフトウェア・エンジニアであるDanielle Lancashire氏は、WebAssemblyコンテナについて、より環境に優しい代替手段であり、現在のコンテナ化されたアプローチからサーバーレス・コンピューティングへと進化する可能性を示唆した。

Lancashire氏は、グリーンソフトウェア財団のソフトウェア炭素強度（SCI）を参照しながら、ソフトウェアの炭素効率について話し始めた。この標準的な指標は、あらゆるソフトウェアのカーボンフットプリントを計算できる式に基づいている。実行に必要なエネルギー、基礎となる計算能力を維持するために必要なリソース、実行するコンポーネント（CPUやGPUなど）の開発に必要な鉱物など、潜在的な炭素源をすべて集約している。

グリーン・ソフトウェア財団（Green Software Foundation）が定義した計算式は複雑に見えるが、次のようになる。

SCI = ((E * I) + M) per R

• E = ソフトウェアが消費するエネルギー kWh

• I = エネルギー1kWhあたりに排出される炭素、gCO2/kWh

• M = ソフトウェアが動作するハードウェアを通じて排出される炭素

• R = Functional Unit（機能単位）。これは、たとえばユーザーやデバイスごとに、ソフトウェアがどのようにスケールするかということである。

彼女は、過度に単純化した言い方をすれば、SCIは「もしそうなら、その有用性を上回る計算量」に過ぎないと指摘した。

SCI指数がゼロになることはありえないが、可能な限り低くあるべきであり、それを達成するためには次のようなルートがある。

• 同じ仕事量をこなしながら、使用する電力を少なくする。

• 同じ作業量をこなしながら、物理リソースの使用量を減らす。

• 時間的制約のないコンピューティングは、よりクリーンなエネルギー源が利用できる時間帯にスケジューリングする。

Lancashire氏は、非常に効率的なプログラミング言語を使うこと（「すべてをRustやCで書き換えても、期待しているような効果は得られない！」）だけでは「全体像がつかめない」と指摘した。「CPUを最大に使うアプリケーションはほとんどないからだ。」

それ以上に、「ほとんどのサーバーは、アイドル時に最大電力の30～60％を使用している」。コンテナ化されたアプリケーションでは（主にオーバープロビジョニングが原因で）CPUの約70％が未使用であるため、Kubernetesを使用しても不十分である。彼女は、コンピューティング密度の向上は、単一のアプリケーションの効率よりも重要であることが多いことを示唆した。

見かけの進化（ベアメタルから仮想マシン、そして現在のコンテナ）にかかわらず、Lancashire氏は「まだ最悪だ」と述べ、改善の余地があるとした。ブラウザのFlashを安全な方法で置き換えるというWasmの当初の目標は、運用面でも関心を呼び、WebAssembly System Interfaceの実装により、サーバー側でもWasmをデプロイ可能なユニットとして使用できるようになった。Wasiの追加により、Wasmは基礎となるコンピュータ（ネットワーク、ポート処理、ファイルシステムなど）に安全にアクセスできるようになった。つまり、WebAssemblyのデプロイ可能なユニットは小さく（コードのバイナリより少し大きい程度）、ポータブルで、起動と停止が速く、非常に分離されているため安全なのだ。

Lancashire氏は、WebAssemblyユニットの上にサーバーレスを採用することで、組織は（財政的にも炭素関連でも）より高速で安価なインフラを持つことができると考えている。つまり、Wasmのデプロイ可能なものは、コンテナから進化する可能性があるということだ。