title | emoji | type | topics | published | |
---|---|---|---|---|---|
【随時更新】2023年版 WebAssemblyの活用事例を調べてみた |
🔖 |
tech |
|
true |
2023年なので(?)、WebAssemblyの事例をインターネットの海からかき集めてみることにしました。 今後、新しい事例が見つかれば随時追加していこうと思います。
まずは、Disney+です。大手動画配信サービスです。 https://medium.com/disney-streaming/introducing-the-disney-application-development-kit-adk-ad85ca139073
実際にWebAssemblyが活用されているのはDisney+の動画視聴クライアントアプリケーションで、内部的に利用されているADK(Application Development Kit)と呼ばれる開発基盤を介してビルドされます。 ADKについてはざっくりと特徴をまとめると以下のようなものです。
- Disney+を視聴するクライアントアプリケーションを開発するための基盤
- iOSやAndroid、スマートテレビやFireTVなどPCも含めあらゆるデバイスのアーキテクチャに対応している
- Rustで記述されたクライアントアプリケーションがこの基盤を介してWebAssemblyにコンパイルされる
優れた可搬性(ポータビリティ)とリソース効率の高さ
Disney+のクライアントアプリケーションは、iOSやAndroid、スマートテレビやFireTVなども含め、その他CPUやメモリ容量も異なるあらゆるデバイス上で稼働できなければなりません。 このような性質を持つクライアントアプリケーションを実現するために、Disney+ではWebAssemblyの高い可搬性を活用しています。
単純に幅広いアーキテクチャに対応したクライアントアプリケーションを実装したい、という目的だけであれば、ぶっちゃけWebブラウザでも満たせそうな要件かもしれませんが、Disney+がADKとWebAssemblyという技術選定をしたのには以下のような理由があります。
Webブラウザに依存することで迅速にクロスプラットフォーム対応のアプリケーションを実装できる反面、デメリットも存在します。それはWebブラウザ自体がボトルネックになってしまうケースが存在しうることです。 もし仮にDisney+が求める機能にWebブラウザが対応していない場合、Webブラウザ自体のアップデートを待たなければならないかもしれません。 そこで、そういったWebブラウザでは痒いところに手が届かないレイヤにも対応しつつ、クロスプラットフォーム性も両立できる実行環境としてWebAssemblyを利用しているようです。
もう一つ指摘されているのが、リソース効率の側面です。 汎用的な実行環境としてのWebブラウザよりも、Disney+の動画視聴クライアントとして特化された実行環境であれば、必要なものだけを詰め込んでコードやメモリ量も削減できるかもしれません。 また、WebAssembly本来の目的であるネイティブ並みのパフォーマンスも維持しつつ、あらゆるデバイス上で稼働する稼働させることも可能になります。 こういったリソース効率の側面でも、WebAssemblyが一役買っているようです。
続いては、Amazon Prime Videoです。 Disney+に続き、こちらも言わずとしれた大手動画配信サービスです。 https://www.amazon.science/blog/how-prime-video-updates-its-app-for-more-than-8-000-device-types
こちらでも、主に利用されているのは動画視聴のためのクライアントアプリケーションです。
優れた可搬性と処理速度の向上
先述のDisney+同様、Amazon Prime Videoでもあらゆるデバイスに対応したクライアントアプリケーションが求められます。 その対応デバイス数はというと、なんと8000種類以上ものデバイスに対応しているとのことです。
当然これだけのデバイスに対応するとなると、それ相応の痛みも生じます。 それは、各デバイスに対応するコードのデプロイとパフォーマンスのトレードオフです。 具体的には、それぞれのデバイスで最高のパフォーマンスを発揮するためには、それぞれのアーキテクチャに対応したネイティブのコードをデプロイする必要がありますが、デバイスの数が増えれば増えるほど現実的ではなくなるでしょう。 これに対し、より汎用的なプラットフォーム・より少ないコードで多くのデバイスに対応すれば、あらゆるデバイスへ対応は現実的になりますが、パフォーマンスを犠牲にせざるを得ないことになります。
実際のところ、Amazon Prime VideoではJavaScriptが利用されておりあらゆるデバイスへのデプロイは容易に保たれていましたが、パフォーマンスの問題を抱えていました。 そこで、JavaScriptで実装されていた中でもパフォーマンスの懸念があった部分(レンダラやアニメーションなど)をRustから生成したWebAssemblyで置き換えたところ、なんと10 ~ 25倍もの処理速度向上が観測されたそうです。 このことから、膨大な種類のデバイスへの対応とパフォーマンスのトレードオフも問題点を解消できる技術としてWebAssemblyの採用に至ったとのことです。
続いては、Fastlyです。Fastlyはアメリカに拠点を置く企業で、強力なCDNやエッジコンピューティング環境を提供するクラウドサービスプロバイダです。 Fastlyについてよく知らないという方は、Cloudflareなどのようなサービス事業者と考えてあながち間違いではないでしょう。
https://www.fastly.com/press/press-releases/fastly-expands-webassembly-investment
FastlyがWebAssemblyを活用しているのは、同社が提供するCompute@Edge
と呼ばれるプロダクトです。
Fasltyの持つ強力かつ巨大なCDNを利用したエッジコンピューティングを提供するサービスで、この実行環境にWebAssemblyが活用されています。
こういったエッジコンピューティングの実行環境として活用しているケースは最近だとFastly以外にもいくつか見られ、前述で少し触れましたCloudflareやNext.jsの開発元であるVercelでも採用されているようです。
https://vercel.com/blog/edge-functions-generally-available
より汎用的なプラットフォームとランタイムの最適化
(まとめ中)
続いてはFigmaです。事例としては2017年と少し前なので、ご存知の方も多いかもしれません。
https://www.figma.com/blog/webassembly-cut-figmas-load-time-by-3x/
デザインツールとして有名の同社も、WebAssemblyを活用しています。
(まとめ中)
(まとめ中)
続いてはGoogle Earthです。こちらも2020年のものということで、少しだけ古めの事例にはなります。
(まとめ中)
(まとめ中)
ここまでいくつか活用事例を調査してみての個人的な雑感としては、ネイティブ並みのパフォーマンスが期待できることももちろんメリットでありながら、 それに加えてユニバーサルな実行環境としての側面がかなり大きな強みとして採用されているのが目立つな〜といったところでした。 最近もWasmerからkernel-wasmなるものも出てきたようで、カーネル内でWebAssemblyを実行できるようになってきていたりとますます実行環境の幅が広がってきているように感じます。 他にもいろんな可能性を秘めていそうで今後も展望が気になる技術ではあるので、興味深い事例が見つかり次第自分なりにまとめて追記していきたいと思います。