ディズニー、Disney+の動画配信クライアントにWebAssemblyを採用。2019年春に開発開始

今回は「ディズニー、Disney+の動画配信クライアントにWebAssemblyを採用。2019年春に開発開始」についてご紹介します。

関連ワード （ブラウザ、メモリ、日付等） についても参考にしながら、ぜひ本記事について議論していってくださいね。

本記事は、Publickey様で掲載されている内容を参考にしておりますので、より詳しく内容を知りたい方は、ページ下の元記事リンクより参照ください。

Amazon.comがAmazon Prime Videoの配信アプリケーションでWebAssemblyを採用し、動画のフレームレートを向上したことは、2月1日に公開した記事「Amazon Prime Videoが動画再生にWebAssemblyを採用。再生デバイス上にWasm VMをデプロイ、高フレームレートなど実現」で紹介しました。

この記事では「これだけの規模の本番環境にWebAssemblyが投入されている事例は他にないはず」と書いたのですが、その後もWebAssemblyの事例や応用技術を調べていくうちに、このAmazon Prime Videoの取り組みよりも前に、本番環境で大規模にWebAssemblyを展開している企業がありました（ですので、この記事のこの表現はお詫びして訂正させていただきます。申し訳ありません）。

ディズニーです。

同社が提供している動画配信サービス「Disney＋」はAmazon Prime Videoと同様に、さまざまなスマートフォン、スマートテレビ、セットトップボックス、ゲーム機器などのデバイスに対してDisney＋の配信アプリケーションを展開し、利用者に動画を見てもらうサービスです。

同社はこの動画配信アプリケーションのクライアント部分にWebAssemblyを採用することで、柔軟かつクロスデバイス対応のアプリケーションを実現したと、2021年9月9日付けの記事「Introducing the Disney+ Application Development Kit (ADK) | by Mike Hanley | disney-streaming | Medium」で紹介していました。

同社はこの取り組みを2019年春に開始、18カ月でローンチしたとのことですので、2020年中にはWebAssemblyを利用した動画配信アプリケーションの展開を始めていたことになります。

この記事から、WebAssemblyがどう使われたのか、ポイントを紹介しましょう。

Disney+配信アプリケーションのアーキテクチャ

Disney+の動画配信アプリケーションはApplication Development Kit（ADK）が基盤となっています。

このADKは、Disney+の配信アプリケーションがサポートする性能もCPUアーキテクチャもメモリ容量も異なるさまざまなデバイス、iOSやAndroidなどのスマートフォンやタブレット、スマートテレビ、ゲーム、Apple TVやFireTV、Google Chromecastやセットトップボックス、そしてPCまでをカバーするアーキテクチャを備えていなければなりません。

そこでADKは、ハードウェアプラットフォームを抽象化するレイヤ（コード名：Steamboat）、C++で書かれたネイティブビデオエンジン（DSS-NVE）、そしてWebAssemblyランタイムを含むネイティブクライアントプラットフォームv2（コードネームM5）などから構成されるアーキテクチャを備えています。

「Introducing the Disney+ Application Development Kit (ADK)」から

そしてこの上で、Rust言語で書かれ、WebAssemblyにコンパイル済みのクライアントアプリケーションが、デバイスブート時にAWSからインターネット経由でダウンロードされ実行されるようになっています。

Disney+がWebアプリを選ばなかった理由

Disney+はWebブラウザにも対応しているため、Webブラウザ経由でも配信サービスを利用することができます。であれば、なぜディズニーはわざわざADKとWebAssemblyで動画配信アプリケーションを構築するのでしょうか。

その理由は複数挙げられています。

1つは各デバイスのWebブラウザやファームウェアのアップデートによって最新機能が提供されるのを待つことなく、ディズニー自身で低レイヤに至るまで動画配信アプリケーションのアップデートをコントロールできることで、よりよいユーザー体験をコントロールできること。

また、汎用プラットフォームであるWebブラウザよりも、特定の目的のために開発されたADKのほうがずっとコードとメモリ容量を小さくできる点も指摘されています。

さらに、WebAssemblyがポータブルであることによるクロスデバイスの対応、そしてHTMLやJavaScriptと比べるとWebAssemblyはバイナリフォーマットであり、コンパイルされたプログラミング言語とほぼ同じレベルで、ほかの処理に影響することなくタスクを実行できる点などです。

2019年春にADKの開発を開始

記事によると、同社は2019年春にこのコードネームM5となるADKの開発を開始し、18カ月以内にローンチできたと説明されています。

2019年春のWebAssemblyがどんな状況だったか少し振り返ってみましょう。

Webブラウザでアプリケーションを高速に実行するためのバイナリフォーマットとしてWebAssemblyが登場し、主要なWebブラウザで実装されたのが2017年11月のことです。

そこから約1年半後の2019年4月、FastlyがWebブラウザからWebAssemblyのランタイムを切り離し、単独でWebAssemblyを実行できる「Lucet」をオープンソースでリリースしたことで、WebAssemblyランタイムの存在が注目され始めます。

参考：WebAssemblyが50マイクロ秒以下で起動する「Lucet」。コンパイラとランタイムをFastlyがオープンソースで公開

そして2019年12月にはWebAssemblyがW3Cの勧告に到達。

参考：WebAssemblyがW3Cの勧告に到達。「WebAssembly Core Specification 」「WebAssembly Web API」「WebAssembly JavaScript Interface 」の3つ

つまり2019年春時点では、WebAssemblyランタイムをさまざまなデバイスに展開して動かすという方針は野心的なものだったのではないかと想像できます。そうした中でWebAssemblyランタイムを組み込んだ配信アプリケーションを構築し、グローバルな展開を実現することは、相当に先進的な取り組みだったことは間違いないでしょう。

関連記事

• Amazon Prime Videoが動画再生にWebAssemblyを採用。再生デバイス上にWasm VMをデプロイ、高フレームレートなど実現