WebAssemblyはマイクロサービスアーキテクチャの救世主となるか：「WasmアプリケーションはRustアプリケーションより100倍高速」

マイクロサービスアーキテクチャの利用時に課題になる複雑さとコストの懸念を緩和する可能性があるのがWebAssemblyの実装だ。本稿では、WebAssemblyの機能と用途、マイクロサービスとの結び付きなどについて解説する。

LINE

Hatena

　マイクロサービスアーキテクチャの利用が広がっている。だが、その複雑さとコストが課題にもなっている。そうした懸念を緩和する可能性があるのがWebAssemblyの実装だ。

　ソフトウェア開発とクラウドコンピューティングの世界は絶えず進化している。今日起こったイノベーションも、より高速、軽量、高機能のものにやがて取って代わられていくことになるだろう。

　「Docker」は2013年のリリース当時、アプリケーションコードにもインフラにも画期的な一貫性、移植性、モジュール性をもたらした。マイクロサービスアーキテクチャの登場により、高い拡張性と柔軟性を備える独立したサービスのブロックとして、アプリケーションを構築できるようになった。

　現在は、「WebAssembly」によって、クライアント側とサーバ側の両方に高いパフォーマンス、モジュール性、移植性がもたらされ、コンテナ化の改善が見込まれるようになっている。

　本稿では、WebAssemblyの機能と用途を調べ、マイクロサービスとの結び付きを探る。さらに、マイクロサービスを管理するうえでの問題点の一部（複雑さや運用コストなど）について、WebAssemblyを使って対処する可能性についても考える。

WebAssemblyとは

　WebAssembly（以下、Wasm）とはオープン標準の一つで、これを使えば、開発者はネイティブアプリケーションに近いパフォーマンスを備える品質の高いWebエクスペリエンスを実現できる。Wasmにより、開発者はWeb上でバイナリコードを実行でき、Web開発に「C」「C++」「Rust」などのプログラミング言語を使用できるようになる。コード形式はアセンブリ（Assembly）に似ているため、開発者はプログラミング言語とブラウザを自由に選択できる。

　現時点では、Webブラウザでネイティブに実行できるプログラミング言語は「JavaScript」しかない。一方、WasmはWebアプリケーションにネイティブに近いパフォーマンスをもたらす。Wasmはブラウザに読み込まれる前に解析され、コンパイルされるため、マシン対応の命令によって、ブラウザでのプログラムの検証と実行が高速になる。

　Wasmは、高いレベルのパフォーマンスを必要とするWebサービスの構築に理想的な選択肢として浮上している。Googleが提供する「Google Earth」や「Figma」は、Wasmに移行し、これを活用することで、実行速度を向上し、読み込み時間を短縮している。

　Wasmモジュールを1つ用意すれば、「Linux」「Windows」「macOS」など、複数のOS間でRustプログラムを実行できる。また、異なるハードウェアプラットフォームにWasmモジュールをデプロイして、クラウドからエッジへのエクスペリエンスに一貫性を持たせることもできる。

　また、Wasmによってプログラムの独立性が向上し、サンドボックス環境によって攻撃対象領域が減少する。こうした対策により、システム上でホストされる機微な資産に悪意を持ったコードからアクセスするのが難しくなる。

　Wasmのもう1つの特徴はコードがバイナリ形式に変換されることにある。これにより、読み込みも実行も高速になる。その結果、効率とパフォーマンスが向上する。

WebAssemblyとRustを使うマイクロサービス

　マイクロサービスアーキテクチャでは、大規模アプリケーションを複数の小さなアプリケーション（通常は個別のHTTPエンドポイント）に分割し、その小さなアプリケーションに1つの機能だけを実行させることで、設計と実装を簡素化する。こうしたモジュール方式のアプローチは、開発者がソフトウェアを拡張するのに役立つ。だが、その管理は複雑になる。

　一方、WasmではWebブラウザでのアプリケーションのパフォーマンスが向上するだけでなく、他の環境でも複雑なアプリケーションを実行できる。この考え方の根底にあるのがCloud Native Computing Foundation（CNCF）のWasmプロジェクト「WasmEdge Runtime」だ。WasmEdge Runtimeにより、開発者は個別のHTTPサーバでマイクロアプリケーションを実行できる。この考え方は、エッジクラウドやサーバレス環境での動的なスケーリングを必要とするアプリケーションに特に適している。

　Wasmアプリケーションは、Rustアプリケーションに比べて100倍高速で、はるかに小型化できることが分かっている。Wasmアプリケーションのこの特性を生かすには、プログラムをRustでコンパイルしてWasmバイトコードに変換し、それをクラウドにデプロイする。その結果、事実上場所を問わず、セキュリティが確保される状態でRustプログラムを実行でき、攻撃対象領域が大幅に少なくなる。

WASIとは

　WebAssembly System Interface（WASI）とはモジュール形式のシステムインタフェースのセットで、これによってWebAssemblyコードの移植性が確保される。WASIは、入出力などの低レベルのインタフェースと、暗号化などの高度なインタフェースの両方から構成される。

　ブラウザ内部で使用する場合、OSへのアクセスはWasmが管理する。ただし、サーバでWasmアプリケーションを運用する場合は別のインタフェースが必要になる。

　WASIを使わないアプリケーションでは、OSへのアクセスを全てプロビジョニングしなければならない。そうすると、Wasmアプリケーションが特定のOSに結び付けられ、脆弱（ぜいじゃく）性が増す。

WasmとDocker

　Wasmは新しいテクノロジー標準だが、ソフトウェア業界にはその影響が既に広がっている。業界リーダーが自社のプラットフォームでWasmのサポートを保証していることは特に注目に値する。

　その一人がDockerの共同創設者であるソロモン・ハイクス氏だ。同氏は「X」（旧Twitter）に次のように記している。「もしもWasmとWASIが2008年に存在していたら、Dockerを作る必要はなかっただろう。それほど重要なことだ。サーバ上でのWasmの利用は、コンピューティングの未来を表す。そこに欠けていたのが標準化されたシステムインタフェースだ。この欠けていた部分をWASIが補うことを願っている」

　2022年、Dockerは「Docker＋Wasm」のテクニカルプレビューをリリースし、両テクノロジーがどのように相互補完するかを示した。

　こうした動きは、Wasmにとってはまだ初期段階だが、Wasmの今後は有望に思える。

WebAssemblyの今後の方向性

　マイクロサービスアーキテクチャは今後定着するだろう。マイクロサービスアーキテクチャは拡張性が高く、ユーザーはサービスごとに異なるテクノロジーを使用できる。ただし、マイクロサービスを使って独立するサービスの小さなブロックの数が増えれば、運用コストが上がり、その管理は複雑になる。

　こうしたマイクロサービス管理の課題に対する答えとなる可能性があるのがWebAssemblyだ。WebAssemblyは軽量で、プラットフォーム間での移植性をもたらし、ネイティブに近いコードの実行を実現する。開発者は、好みの言語を使用でき、さまざまなコンポーネントを統合して、より適切なソフトウェアを作成できる。WebAssemblyは、どこでも実行できる複雑なWebサービスを構築するための有望な選択肢になる。