マスメディアを創るということ
西尾亮太氏（以下、西尾）：みなさまこんにちは。長瀬に続きまして私から、AbemaTVの技術的な側面における戦略性やこれまでのAbemaTVの取り組みについて紹介できたらと思います。私はAbemaTVで現在CTOを任されております西尾と申します。
2011年に株式会社サイバーエージェントに入社しまして、大きな案件プロジェクトをいくつかこなしたのち、2016年にAbemaTVの立ち上げに参画して、現在CTOをやっております。
今回のDeveloper Conferenceのテーマであります「PAST→FUTURE」というところで、AbemaTVのこれまでの流れや、これから先の話について振り返っていきたいと思っています。
AbemaTVは2016年4月に開局されたものですけれども、実際には開発が本格化したのが2015年11月ぐらいになります。
そこから開発を経て開局に繋がっていったんですけれども、開局同年度に主要なテレビデバイスへの展開が完了し、先ほど紹介がありましたとおりAbemaビデオのリリースが入りました。
主だった放送としましては、『亀田興毅に勝ったら1000万円』や、初の取り組みである72時間の連続生放送『72時間ホンネテレビ』という番組、最近ですと『安室奈美恵MV総選挙＆伝説のライブ生放送』といった番組を放送しております。
今回の私の話ですが、これらの約3年間の開発の流れのなかで、Phaseを3つに分けてお話ししたいと思います。
1つ目は「サービスの立ち上げと確立」と題しまして、AbemaTVの開発の初期がどのようなかたちで進んでいったか、またどのようなことを考えながら開発が進んでいったかといったことをお話しします。
Phase2に関しましては、AbemaTV開局から1周年後ぐらいからの流れですけれども、「配信の安定化」という少し技術的な力点が発生したポイントについてお話ししていきます。
Phase3としまして、「マスメディアの実現に向けて」というキーワードで、今年の1月ぐらいから取り組んでいる技術的な展望とかビジョンに対して、我々が行っていることについてお話ししていきます。
サービスの立ち上げと確立
Phase1、「サービスの立ち上げと確立」についてお話ししていきます。
AbemaTVの初期開発はだいたい4ヶ月ぐらいで完了しています。
モックアップやデザインの調整に関しては100回ぐらい繰り返されたとうかがっておりますが、そこからだいたい4ヶ月ぐらいを経て開局に繋げるという怒涛の開発を実践しました。
当時の立ち上げの開発フローがどうだったかという話なんですけれども、主だったものとし
iOSエンジニアであったりAndroidエンジニア、Webエンジニアといったエンジニアリングの職種によるトピックを分割し、それに対して優先度だけが定義されたチケットが無限にディレクターからプッシュされていく。それに対してそれぞれの領域のエンジニアがやれるだけやるという開発スタイルでした。
この時開発を支えたものは、チームプレイとかマネジメントとかでは決してなくて、各個人個人のスタンドプレイを最大化していくというかたちで開発を進めていったと考えております。
当時の開発の速度を支えたものに「Google Cloud Platform」の存在は欠かせません。
開発において、サービスの機能自体の開発ではない部分に関して、Google Cloud Platformが提供するさまざまなコンポーネントが大変役に立ちました。
時間を使いがちなロギングやバランシング/ルーティング、コンテナマネジメントといった側面において、Google Cloud Platformのコンポーネントを多様に利用して、我々が機能開発自体にフルコミットするという状況を形成できました。
また、動画の配信事業を支えるシステムをつくる上で、CDNの存在は本当に欠かせないものです。
CDNの領域におきましては、Akamaiを採用しました。
Akamaiは動画配信に最適化されたCDNでして、信頼性の高さや高度に分散されたキャッシュのネットワーク、また動画配信ソリューションに対する多機能な一面を持っていまして、動画配信に対して最適なCDNであろうと当時判断し、高速で安全なメディア配信を実現しています。
テレビデバイスの対応と、Abemaビデオの提供開始
開局を迎えまして、2016年4月から同年度中に主要テレビデバイスへの対応を完了しています。
当時のデバイス戦略の始動であり、AbemaTVのサービスに親和性の高いデバイスから優先的に対応していくといったかたちをとっていました。
また、テクノロジーにおいてはマルチDRMの対応というのが欠かせないものになります。
現在AbemaTVはFairPlay、Widevine、PlayReadyといったDRMテクノロジーに対応し、HLSとかMPEG-DASHといった配信方式を組み合わせることで、マルチDRMの対応を完了しています。
マルチDRMの対応というのは、コンテンツ配信を行う事業者からすると大変重要な意味を持っていまして。コンテンツの調達に対して大きな意味を持ちます。より多くの、より良質なコンテンツを調達し、またそれを配信できるために、マルチDRMを対応していくことには非常に意味がありました。
また、機能的な面では、Abemaビデオの提供も1周年あたりで対応されています。
それまでのAbemaTVはリニアTVとタイムシフトTVといった視聴形態をメインに機能を提供しておりました。
これは、従来のラテ欄やリモコンといった操作によって映像コンテンツを見ていくという視聴習慣を支えるものでした。
そこに対して、カタログをベースにするビデオの概念を導入しまして、TVとVODを融合して、異なる視聴習慣を融合していくといったことを、このタイミングで実践しております。
まとめになりますけれども、Phase1に関しては初期構想の機能の大半をこの時に完遂するといったベクトルで技術の開発が行われていました。
安定した配信環境を作るために
続きまして、Phase2「配信の安定化」というトピックになります。
このトピックをお話しするにあたって、どうしても欠かせない番組があります。それは、『亀田興毅に勝ったら1000万円』という番組です。
この番組はネット記事にもたくさん取り上げられた話なんですけれども、2017年5月7日に放送されました。
印象深い事項としましては、亀田興毅選手の開始のゴングと同時にAbemaTVのシステムのすべてがダウンしました。
この時、我々は現在のシステムアーキテクチャにいくつかの課題があるのではないか、伝送/配信の安定性というところにもう少し腰を据えてチャレンジしていかなければならないのではないかという課題の気付きになったと思っております。
このタイミングで配信構成の見直しが始まりました。
まず最初は伝送・配信の安定性向上です。
この局面において、Phase2のタイミングではおおよそ2点の観点で配信の安定性の向上を図っています。
1つはEncoderから配信システムに対してインジェストされる経路の安定性の確保です。
映像を配信するためには、現場からカメラで撮った映像をインターネットのネットワークに上げていって、そこから初めて処理が開始されるかたちなんですけれども、実は開局当時のAbemaTVの配信システムは、GCPの台湾リージョンで構成されていまして、ネットワークに物理的な距離もあったり、パケットロスや遅延がけっこう発生するといった環境下で配信を行っておりました。
一部導入していたZixiというプロトコルを定常運用化することによって、インジェストの経路の安定を図ることに成功しています。
もう1点は逆の方面ですが、配信システムに対してCDNから展開されているOriginリクエストを、Cloud Interconnectを導入することによって、CDN/Origin間の帯域と安定性の確保を行っております。
56
これによって、配信システムが生成した映像ソースを、確実にCDNにキャッシングする。そういったところに対して取り組みを行い、安定性の向上を実現しています。
配信システムの分離
もう1点、当時大きなアーキテクチャの変革が始まりました。配信システムの分離にあたります。
当時のシステムは、配信システムを構成するコンポーネントのいくつかが、それ以外のシステムと結合度が高い状態にありました。
これは簡易な図なので「簡単な話だな」と思われてしまうかもしれないんですけれども、本当に複雑怪奇なシステムのがんじがらめの絡み合わせに対して、配信システムを分離していくという作業を進めていくことは労力のかかる作業だったんです。
実際空間的に分離されたリソースを用いてシステムを構成していくことによって、配信システムと言われる映像を視聴するという機能と、ユーザー機能に当たる部分を切り分けていくと。
ユーザーの来訪と視聴というトラヒックをそれぞれ別にさばくことによって、配信システム自体の安定を図っていくといったアプローチになります。
当時はスケールアウトの戦略が終焉を迎えます。
AbemaTVは当初、機能開発に全力を注いでおりました。ユーザーやサービスの規模が拡大するにあたって、システムは基本的には水平スケールすればいいかなといったスタンスでアプローチをしておりました。
ですので、スケールアウトすればユーザーの規模の拡大に耐えれると当時は考えていたんですけれども、『72時間ホンネテレビ』に対して事業側が期待値として来訪数を試算した時に、システムが実際どれぐらいスケールアウトしないといけないかという計算をしました。
その時に、我々は実は物理的なComputingResourceと、物理的なNetworkResourceの限界をつくということに気付いてしまいした。
当たり前のことですが、物理的なリソースの拡張には期間と投資が必要です。放送まで実際1ヶ月とか2ヶ月しかなかったので、我々には期間と投資はできない状況にありました。
そこで、我々はリソースのパズルを開始しました。
無限ではないリソースに対して、リソースをどのように使っていくのか、そして割いたリソースに対して見合う価値を提供できているのかといった観点です。
また、最悪の場合、リソースが底をついてしまった場合、どのリソースを割いている機能を落とすか、または提供レベルを下げるかといったリソースのパズルを積極的に進めていきました。
これらの取り組みを合わせていったことで、2017年5月～2017年12月にかけて、システムのキャパシティを約5倍に拡大することに成功しました。配信の安定化を実現したPhaseであると私は考えております。
ネット発のマスメディアを作るために
最後のPhaseとなりまして、今年の頭からの我々の動きになりますけれども、「マスメディアの実現に向けて」というキーワードでお話ししていきます。
ネット発のマスメディアをつくるというのは、AbemaTVのビジョンであり野心であり目的でもあります。
このなかで我々は「マスメディアを目指す事業」というものを、技術でいかに支えられるかということを考えていっています。
代表的なマスメディアにテレビが挙げられます。AbemaTVと同じような形態ですので、そのテレビと比較した場合に、テレビ放送に迫るような信頼性で映像を視聴することができるのかといった疑問や、テレビ放送のような均一な映像を提供できるのか、そして従来のテレビにはできない価値を提供できるのか、そういった疑問に対して技術でアプローチをしかけていこうと考えています。
私が2018年前後にCTOを任されまして、最初にやったことは技術ドメインの抽出とチーム化です。
当時の開発チームの構成は本当にシンプルなものでして、Androidチーム、iOSチーム、Webチーム、サーバーサイドチーム、インフラチームとか、そのような技術的なレイヤーだけで分割されたチーム構成となっておりました。
これを動画インターネット配信をする事業にとって重要な技術ドメインを抽出して、チームに変えています。ここの右手にあるようなかたちでチーム化を図っていました。
これらのチーム化を行うことの意味をお伝えする前に、何を説明すればいいかなと思ったんですけれども、AbemaTVのような「インターネットで動画を配信してユーザーに届ける」ところの視聴ステップというものが、どのように構成されているかというお話です。
映像を届けるためにはまず素材ありきになります。それはライブソースとかファイルソースをベースに起点が始まります。
それをインターネット上に上げていかないといけないので、まず最初はEncoderに対するインジェストが走り、そこで実際ABR（アダプティブ・ビットレート）に変換がかかりまして、二次素材の生成が始まります。
Packagerは多様なデバイスでの再生形式に対応するために、HLSとかMPEG-DASHのような形態にマニフェストを構成していきます。
それらがCDNにキャッシュされ、最終的にPlayerにたどりつくまで、ラストマイルと言われるキャリア網やNTTのNGN網とか、そういった部分の伝送がかかった上で、Playerに届き、Playerがそれらを解釈し再生すると。最終的にそれで初めて視聴というものが生まれるといった流れになっております。
ドメインごとの重視していること
例えば、コンテンツ配信というドメインに対して、コンテンツ配信はインジェストからラストマイルの映像伝送と処理に対して責任を負います。
ここを切り出してコンテンツ配信といったところが、新しい技術に対して計画を立てていくと。
コンテンツエンジニアリングといった側面では素材に注目しています。
オリジナル、放送元となる素材自体や届ける上での工程において変換がかけられる素材の品質といったものに対して、ユーザーの目に届けるにあたって重要な品質を担保できているかといったことを考えていきます。
ストリーミングクライアントの部分は最終的に映像伝送がPlayerまで確実に行われたとして、実際そのPlayerが正しくバッファリングし、映像を滞りなく繋げて再生することができているかといったところに対して責務を負い、技術的な挑戦をしていきます。
コンテンツ配信が伝送/配信品質を担保して、コンテンツエンジニアリングはコンテンツ品質を負う、そしてストリーミングクライアントが再生品質を負うと。このような品質の組み合わせによって、初めて高い視聴品質をつくることができると考えています。
技術領域の自然な進化を促す
今回軽く紹介になってしまうんですけれども、「技術ドメインへの取り組み」と題して、抽出したドメインが何をやっているかというところの表になります。
基盤開発の部分はFeature Flag Management Systemを開発していまして、こちらはプロダクト開発に対して軽快さとクリティカルさを生み出そうとしています。
コンテンツエンジニアリングの領域は、メディアアセットマネジメントシステム（MAM）というコンテンツ管理の仕組みや、コンテンツの品質統制、映像品質をどのようにどれぐらいの品質まで担保していくかといったことに取り組んでいます。
コンテンツ配信の側面では、低遅延化とCDN以降の話、CDNから実際ユーザーの端末に届くまでのラストマイルと言われるネットワークに対して不備がないか、今後のキャパシティに耐えられるかといったところに対して、中長期の戦略を立てていっています。
ストリーミングクライアントにおいては、再生品質の計測と改善ということをようやく取り組み始めることができまして、現在再生品質を計測して、改善ポイントを探しています。
データマネジメントの領域は、3年間の開発を経て煩雑になってしまったデータのフローやデータの見方みたいなところに再統制をかけて、二次利用としてデータをどのように分析して、どのようなレポーティング、どのような経営判断を行うかといったところを支援していこうとしています。
新設したSREは、サービスの信頼性指標を定め、オンコール対応を担うことです。プロダクト開発側が開発自体に集中できるような取り組みを続けていこうと思っております。
これらのアプローチをもちまして、技術領域の自然な進化を促すといったかたちをとっています。
課題とかチャンスの発見や中長期戦略の策定、技術的挑戦、開発、ソリューションの導入といったところを、それぞれの技術ドメインにおいてそれぞれが考え、それぞれが実践していくといった流れをつくることで、ありとあらゆる技術的な側面の骨子を完成させると。
そういったアプローチで現在開発を進めております。
2018年1月から未来に向かってということで、Phase3は「マスメディアにふさわしいシステムを創る」というビジョンで開発を進めていっております。
私のセッションはここまでなんですけれども、今回のAbemaTVのセッションは、私が触れていった部分に関して、いろいろな技術的な知見とか挑戦といったものを表現しております。
ぜひ気になったセッションに耳を傾けていただき、AbemaTVの技術の挑戦と進化を感じていただければと思います。
以上をもちまして、私のセッションを終わりたいと思います。ご視聴ありがとうございました。
（会場拍手）
