今年で第3回目の開催となった「AbemaTV Developer Conference 2018」。

これは年に1度、AbemaTVのエンジニアが集結し、開発で溜めた技術的知見を公開するテックカンファレンスです。

今回は「PAST→FUTURE」をテーマに、過去・現在・未来の3つの時間軸でAbemaTVが取り組んできたこと、未来構想などが、14セッションにわたり紹介されました。

Keynote「AbemaTVはネット発のマスメディアを創る」では、開発本部長の長瀬に続きCTOの西尾亮太が登壇し、これまでの技術戦略と今後の技術領域の進化について語りました。

西尾亮太（にしお りょうた）　AbemaTV CTO

2011年サイバーエージェント入社。入社後はAmeba Platformの基盤開発に携わり、2015年のAbemaTV立ち上げ〜現在まで開発に携わる。2017年にはAbemaTVのCTOに就任。

フェーズ1：初期は個人のスタンドプレー最大化

AbemaTVが本開局をしたのは2016年4月ですが、開発が本格開始したのは2015年の11月頃です。立ち上げから開発に携わる西尾は、この3年間を「サービスの立ち上げと確立」「配信の安定化」「マスメディアの実現に向けて」の3つのフェーズに分けてお話させていただきました。

まず、フェーズ1である「サービスの立ち上げと確立」についてです。AbemaTVの初期開発は約4ヶ月という怒涛のスケジュールだったため、当時の開発フローはチケット駆動が採用されていました。iOSエンジニア、Androidエンジニア、Webエンジニアなど、職種によってトピックを分割し、それに対して優先度だけが提示され、それぞれの領域のエンジニアがやれるだけやる、というスタイルだったといいます。

この時の開発を支えたものは、チームプレイやマネジメントではなく、個人のスタンドプレーの最大化に頼っている状況でした。また、とにかくスピードが求められるなか当時の開発速度を支えたものに、GCPの存在は欠かせません。機能開発ではない部分に関して、GCPが提供する様々なコンポーネントが大変役に経ちました。時間を使いがちな、ロギング・バランシング/ルーティング・コンテナマネジメントと行った側面においてGCPのコンポーネントを多様に利用して、我々が機能開発自体にフルコミットする状況を生み出せました（西尾）

また、動画の配信事業を支えるシステムを作る上でCDNの存在が欠かせなかったことについても触れました。AbemaTVではCDN領域においてAkamaiを採用しているのですが、その理由として、「信頼性の高さ」「高度に分散されたキャッシュのネットーワーク」「多機能な動画配信ソリューション」の3つを挙げ、当時Akamaiが動画配信において最適なCDNだと判断し、高速で安全なメディア配信を実現したと語りました。

より良質なコンテンツを多く調達するためのマルチDRM対応

テクノロジーにおいて、マルチDRM対応は欠かせないものでした。現在AbemaTVでは、FairPlay、Widevine、PlayReadyといったDRMテクノロジーに対応しHLS、MPEG-DASHといった配信方式を組み合わせることで、マルチDRMの対応をしています。

このマルチDRM対応は、コンテンツ配信を行う事業者にとっても重要な意味を持つので、良質なコンテンツを多く調達するためにも、大きな意味を持ちました。（西尾）

フェーズ2：伝送／配信の安定性向上とアーキテクチャの変革

続いてフェーズ2として、AbemaTV開局から約1年度の「配信の安定化」という技術的な力点が発生したポイントについてご紹介しました。

まず、フェーズ2の「配信の安定化」を語るのに欠かせない出来事があります。それが2017年5月に放送された「亀田興毅に買ったら1000万円」という番組です。アクセスが殺到し、試合開始のゴングと同時にAbemaTVの全てのシステムが一時ダウンしたのです。

この出来事をきっかけに、現在のシステムアーキテクチャに課題がある事、また伝送・配信の安定性にもっと腰を据えてチャレンジしなくてはいけない、ということに気付き、配信構成の見直しが始まりました。ここでは「伝送・配信の安定性向上」と「配信システムの分離」の2つに取り組みました。

「伝送・配信の安定性向上」については、2つの観点で見直しを行いました。

1つ目が、Encorderから配信システムに対してインジェストされる経路の安定性確保です。映像を配信するためには現場からカメラで撮った映像をインターネットのネットワークにあげて、そこから初めて処理が開始されるのですが、開局当初AbemaTVの配信システムはGCPの台湾リージョンで構成されており、物理的な距離ゆえ、パケットロスによる遅延が発生する環境下で配信を行っていました。そこで一部導入していたZixiというプロトコルを定常運用化する事でインジェスト経路の安定性を測る事に成功しました。

2つ目は配信システムに対して　CDNから展開されているOriginリクエストをCloud　Interconnectを導入することでCDN・Origin間の帯域と安定性の確保を行いました。これにより、配信システムが生成した映像ソースを確実にCDNにキャッシングすることで安定性の向上を実現しました。（西尾）

当時もう1つ大きなアーキテクチャの変革として「配信システムの分離」がはじまりました。当時のシステムは、配信システムを構成するコンポーネントのいくつかが、それ以外のシステムと結合度が高い状況にありました。この図はとても簡易なものですが、本当に複雑怪奇なシステムに対して、配信システムを分離するという、すごく労力のかかる作業を進めていきました。

これらを空間的に分離されたリソースを用いて、システムを構成する事により、配信システムという映像を視聴する機能とユーザー機能に当たる部分を切り分けたのです。これによって、ユーザーの視聴と来訪、それぞれ別に捌く事で配信システムの安定性に繋がりました。（西尾）

スケールアウト戦略終焉のその後

この頃、スケールアウトの戦略が終焉を迎えます。開局当初、AbemaTVは機能開発に全力を注いでいました。そのためユーザーやサービスの規模が拡大するにあたって、システムは水平スケールすれば良い、というスタンスでした。スケールアウトすればユーザー規模の拡大にも耐えられると当時は考えていたのですが「72時間ホンネテレビ」の放送にあたり、来訪数の試算と共にシステムがどれくらいスケールアウトしなくてはいけないか算出を行ったところ、ある気付きがありました。

これをきっかけに、私たちは物理的なコンピューティングリソースと物理的なネットワークのリソースの限界をつく事に気付きました。当たり前のことですが、物理的なリソースの拡張には期間と投資が必要で、放送まで1〜2ヶ月しかない状況で出来ることとして、リソースパズルを開始しました。有限リソースに対して、リソースをどのように使っていくのか。そしてその割いたリソースに対して見合う価値を提供できているのか？足りなくなった場合は何を落とすのか、または提供レベルを下げるか、このような考え方のもと改善を行なっていきました（西尾）

これらの取り組みを経ることで、2017年5月〜12月にかけ、AbemaTVではシステムのキャパシティを約5倍にまで広げ、「配信の安定化」を実現しました。その後フェーズ3である「マスメディアの実現に向けて」へと進むのです。

フェーズ3：ネット発のマスメディアを創るために

「ネット発のマスメディアを創る」というのは　AbemaTVのビジョンであり、野心であり、目的でもある。この中で開発チームがマスメディアを目指す事業をいかに技術で支えるか、を常に考えていると西尾は語ります。

「テレビ放送に迫る信頼性で映像を視聴できるか？」「テレビ放送のような均一な映像を提供できるか？」「テレビ放送にはできない価値を提供できるか？」といった疑問に対して技術でアプローチを仕掛けたいのだと。

（※左が当時のチーム構成。現在は重要な技術ドメインを抽出してチーム化している）

西尾がCTOを任されて最初にやった事は「技術ドメインの抽出とチーム化」でした。当時、上記の左図のように技術的なレイヤーだけで分割された極シンプルなチーム構成だったものを、動画インターネット配信をする事業にとって重要な技術ドメインを抽出して、上記の右手にあるようなかたちでチーム化を図っていったことを明かしました。そして、これらのチーム化を行うことの意味を伝えるにあたり、インターネットで動画を配信してユーザーに届けるところの視聴ステップがどのように構成されているかを説明しました。

映像を届けるためにはまず素材ありきになります。それはライブソースとかファイルソースをベースに起点が始まります。それをインターネット上に上げるために、まず最初はEncoderに対するインジェストが走り、そこで実際ABR（アダプティブ・ビットレート）に変換がかかり、二次素材の生成が始まります。

Packagerは多様なデバイスでの再生形式に対応するために、HLSやMPEG-DASHのような形態にマニフェストを構成していきます。

それらがCDNにキャッシュされ、最終的にPlayerにたどりつくまで、ラストマイルと言われるキャリア網やNTTのNGN網、そのような部分の伝送がかかった上で、Playerに届き、Playerがそれらを解釈し再生することで、初めて視聴が可能な状態に辿り着きます。（西尾）

高い視聴品質を創るためには、品質の組み合わせが必要

AbemaTVにおいて、高い視聴品質を創るためには、上記のような品質の組み合わせが必要だと、西尾はいいます。

例えば「コンテンツ配信」というドメインに対して、コンテンツ配信はインジェストからラストマイルの映像伝送と処理に対して責任を負います。ここを切り出してコンテンツ配信といった部分が、新しい技術に対して計画を立てていく。

「コンテンツエンジニアリング」といった側面では素材に注目しています。オリジナル、放送元となる素材自体や届ける上での工程において変換がかけられる素材の品質に対して、ユーザーが視聴するにあたって重要な品質を担保できているかを考えていきます。

「ストリーミングクライアント」の部分は、最終的に映像伝送がPlayerまで確実に行われたとして、実際そのPlayerが正しくバッファリングし、映像を滞りなく繋げて再生することができているかということに責務を負い、技術的な挑戦をしていきます。

「コンテンツ配信」が伝送・配信品質を担保して、「コンテンツエンジニアリング」はコンテンツ品質を追う、そして「ストリーミングクライアント」が再生品質を追う。このような品質の組み合わせによって、初めて高い視聴品質をつくることができると考えています。（西尾）

（その他の抽出した技術ドメインについても簡単に紹介しました）

マスメディアにふさわしいシステムを創るために

本セッションの締めくくりとして、これらの技術ドメインの抽出とチーム化によって、目指すものは「技術領域の自然な進化を促す」ことだと西尾は語りました。

課題やチャンスの発見、中長期戦略の策定、技術的な挑戦、開発やソリューションの導入という部分を、それぞれの技術ドメインにおいて、それぞれが考え実践する流れを作ることで、ありとあらゆる技術的な側面の骨子を完成させる、というアプローチで「マスメディアにふさわしいシステムを創る」ことに挑戦を続けています。（西尾）