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

2022年3月8日

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+の配信アプリケーションを展開し、利用者に動画を見てもらうサービスです。

fig

同社はこの動画配信アプリケーションのクライアント部分に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)などから構成されるアーキテクチャを備えています。

そしてこの上で、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ランタイムを組み込んだ配信アプリケーションを構築し、グローバルな展開を実現することは、相当に先進的な取り組みだったことは間違いないでしょう。

関連記事

あわせて読みたい

WebAssembly Web技術




タグクラウド

クラウド
AWS / Azure / Google Cloud
クラウドネイティブ / サーバレス
クラウドのシェア / クラウドの障害

コンテナ型仮想化

プログラミング言語
JavaScript / Java / .NET
WebAssembly / Web標準
開発ツール / テスト・品質

アジャイル開発 / スクラム / DevOps

データベース / 機械学習・AI
RDB / NoSQL

ネットワーク / セキュリティ
HTTP / QUIC

OS / Windows / Linux / 仮想化
サーバ / ストレージ / ハードウェア

ITエンジニアの給与・年収 / 働き方

殿堂入り / おもしろ / 編集後記

全てのタグを見る

Blogger in Chief

photo of jniino

Junichi Niino(jniino)
IT系の雑誌編集者、オンラインメディア発行人を経て独立。2009年にPublickeyを開始しました。
詳しいプロフィール

Publickeyの新着情報をチェックしませんか?
Twitterで : @Publickey
Facebookで : Publickeyのページ
RSSリーダーで : Feed

最新記事10本