「ABEMA」がCDNの1つにAkamaiを選定した3つの理由　キャッシュ効率・可用性・オリジントラフィックへの貫通などが求められる環境におけるメリット

西尾氏の自己紹介と、本セッションのアジェンダ

西尾亮太氏：みなさまこんにちは。株式会社AbemaTV CTOの西尾と申します。会場が広くてだいぶ緊張しているんですが、本日はよろしくお願いします。会場が歩ける感じになっていますが、僕はここで突っ立ったまましゃべるので、スライドに集中して聞いてもらえればと思います。

本日は「ABEMAが描く『新しい未来のテレビ』がAkamaiに求めるもの」と題して、いつでもどこでもつながる社会インフラを目指している我々が、どのようにインフラストラクチャを構成しているのか。あとは、どのように大規模なライブ配信を成功させているのか。その過程の中でどのようにAkamaiを活用しているのかという話をできればと思います。

あらためまして、私の自己紹介になります。株式会社AbemaTV CTOの西尾と申します。サイバーエージェントに2011年に中途入社しています。

エンジニアのキャリアとしては、（これまでの）多くはバックエンドのエンジニアとして携わってきています。スマートフォン向けのプラットフォームの基盤の開発であったり、ゲーム向けのリアルタイム通信基盤の開発を担当してきています。

現在はAbemaTVのCTOというところで、サービスの成長だったり高品質化に向き合っている日々になります。

本日のアジェンダです。最初に「ABEMA」について軽く紹介させてください。次に、事業を支えるインフラストラクチャとして、我々がクラウドやCDN（Contents Delivery Network）をそれぞれどういうふうに選定していて、どのように活用しているのかという話をさせてください。

そのあと、ライブ配信構成とAkamaiとして、我々の映像配信、特にライブといったものでどうやってアーキテクチャを構成しているのかと、その過程の中でどうAkamaiを活用しているのかという話をさせてください。

ABEMAのサービスについて

最初はABEMAについてです。ABEMAはテレビのイノベーションを目指して、新しい未来のテレビとして展開する動画配信事業になります。登録は不要で、国内唯一の24時間編成のニュース専門チャンネルを始め、オリジナルのドラマや恋愛番組、アニメ、スポーツなど、多彩なジャンルの約25チャンネルを24時間365日配信しています。

我々のサービス規模ですが、2022年度は「FIFA ワールドカップ カタール 2022」を配信していましたが、期間中に過去最高の3,409万WAUを突破しています。2023年に関しても、5月と7月に2,000万WAUを突破しているかたちで、好調に推移してきています。

また、テレビやPCでの視聴者数が1年間で1.5倍に成長してきていて、コネクテッドTVやIPTVといった、大画面デバイスのユーザーさまが増えてきているところが我々サービスの特徴となっています。

我々がサービスとして目指すものですが、テレビの再発明になります。従来のテレビの提供価値である無料であることとか、あとは生中継、同時性、報道といったものを主軸に、利便性として時間と場所からの解放を提供しようとしているといったところです。

我々のサービスはテレビの放送とよく比較される配信サービスですが、何が違うかというと、稼働率はテレビ放送がほぼ100パーセントに近いのに対して、控えめにいうとスリーナイン以上ぐらいの稼働率になっています。実際はフォーナインとかファイブナイン近くの稼働率を取っているんですが、（控えめには）そういったかたちになっています。

インフラという側面で見た時に一番の大きな違いは、許容接続数があるという点です。電波を介した1対多の関係性で届けるテレビ放送は、接続数の増加に影響を受けません。一方でインターネット配信になると、1対1の関係性で届けるかたちになるので、接続数の増加に対してキャパシティをプランニングして制御していかなければならない側面があります。

配信遅延はテレビ放送が約2秒といったところです。昨今の技術ではインターネット配信も2秒付近を最速で狙える世界になってきているかなと思います。しかし実際は、インターネットを使って配信する上では品質と画質、あとは画面上で連続して再生できる安定性がトレードオフになりがちなので、我々も遅延を攻め過ぎない配信を心がけています。

解像度と走査方式は（テレビ放送が）1080iに対して、ABEMAは1080pで提供しています。インターネット配信なので可変します。1080以外の解像度も含め、お客さまのインターネット環境に合わせて解像度が選択されるかたちになります。

あと、視聴デバイスの違いも非常に大きいかなと思っています。インターネット配信ではさまざまなOS、さまざまな配信規格を駆使して提供する必要がありますが、映像を視聴することを前提としたデバイスを使っているとも限りません。そういったものにも合わせてインターネットで配信していくことに難易度があります。

（スライドを示して）これだけ見ると盤石なインフラとしてインターネットを使っていくハードルがすごくあるように感じますが、さまざまなユーザーの機能性を継続して追加していったり、技術の発展に対して更新を行っていくという意味では、やはりインターネット配信には大きな強みがあるかなと思っています。

じゃあ、実際に差分としてシステム設計上で何を考慮しているのかという話です。まず信頼性の面では、可用性やパフォーマンスなどを想定してもらえば良いんですが、Webサービスを提供していく上で、信頼性は高ければ高いほど良いわけではないといったところです。

高すぎる信頼性を目標にするとROI（費用対効果）が著しく低下したり、あとは開発速度が失われていきます。ですから、そのサービスがどれぐらいの稼働率を担保しないといけないかと、残るエラーバジェットをどうやって開発に活かしていくかを考えていく必要があります。

一方スケーラビリティもやはり重要で、接続数の最大数を見極めること自体がそもそも難しいですが、最大数に対して愚直に応えるインフラを構築してしまうと、コスト効率が非常に悪くなる。ふだんのトラフィックが1だとした時に「100来る可能性があるから」といって100レベルのインフラを作ってしまうと、99が何も使っていない状況になるので、これをどう制御していくかについてもやはりポイントがあるといったところです。

あとはマルチデバイス対応といったところで、視聴することに特化したデバイスだけではなく、さまざまな技術で構成されたデバイスに対して、テレビ放送と同じように安定したような視聴体験を与えられるかにチャレンジポイントがあるといったかたちです。

こういったことを考えながらアーキテクチャを設計して、サービスの成長を促進していくことが技術担当部門としての役割になっています。

ABEMAがバックエンドシステムとして最初に「Google Cloud」を選定した理由

具体的に事業を支えるインフラストラクチャについて話していこうかなと思います。現在、ABEMAのバックエンドシステムは「Google Cloud」と「Amazon Web Services」で展開されています。

サービスリリース当初、2016年当時はGoogle Cloudのみで構成していました。当時は日本にリージョンがない状況でした。東京リージョンがない状況から活用を開始しています。実際問題、弊社はそのタイミングではGoogle Cloudの実運用のナレッジがない状況でしたが、その上で選定しました。

その理由がなぜかという話ですが、代表的な理由は4点になります。

1つ目はマネージドKubernetes。Google Kubernetes Engine（GKE）の存在ですね。やはりサービス開発をしていく上で高度化であったり、多機能化が予想されていく中で、バックエンドをマイクロサービスで構成する上でのアドバンテージがあると考えました。これが1点目になります。

2つ目は高機能なL7ロードバランサです。Kubernetesで展開されるバックエンドシステムのルーティングを簡易化したり、あとはグローバルロードバランサとして、大量のトラフィックとか、急激なトラフィック変化の対応もクラウド側に一任してしまうという目的がありました。

3つ目は当時のAWSとかを覚えている人がいればわかると思いますが、ネットワーク帯域に対するコストの安さがあるかなと思っています。当時はAWS上でマシン間のトラフィック帯域を確保しようとすると、マシンスペックを上げる必要がありました。

ネットワークを多く消費しますが、コンピューティングはさほど必要がない処理だと、そのネットワーク帯域を確保するために高いマシンを立ち上げないといけないようなかたちになるので、ABEMAのサービス特性上、映像ファイルとか、マシン間で伝送することも多々あることが想定されたので、そういったところに無駄なコストが発生しないようにと考えました。

4つ目はCloud LoggingとBigQueryですね。当時でいうとStackdriver Loggingとかですが、そういったところのログ収集やデータ分析サービスの存在であったり、あとはアプリケーション上で発生するログとか、ユーザーの行動ログをどう記録するか、分析するかといった側面を強力にサポートする機能と判断して、こちらを頼りにしています。

（スライドを示して）ここで、4つ並べていますが、これらの要件に共通するコンセプトは何かという話です。我々は、サービスの開発において不要な技術的難易度を生み出さないことをモットーにしています。つまり、直接ユーザー価値であったり事業価値に還元される主題に集中していきたいという思いがあって、競争力であったり、顧客提供価値につながらない技術要素はできるだけマネージドのクラウド機能に寄せていくと考えています。

アプリケーションのログの回収とか、ロードバランサのスケール処理とか、ウォームアップとか、自前で実装すると技術リソースが食われますが、競争力にはなりえないといった要素です。

「Google Cloud」と「Amazon Web Services」の使い分け

では今、実際問題、Google Cloudと、AWS、2つのクラウドの使い分けをどうしているかという話ですが、我々は今は耐障害性のためにマルチクラウド化しているわけではありません。Google Cloudを起点に構築されたシステムのうち、メディアリソースであったり、メディアシステムに該当するものをAWSに活用を広げていっている段階です。

大きな理由は、AWSがメディアシステムとの親和性を継続的に高めていて、AWS Elemental Media Servicesに代表されるようなフルマネージドなコンテンツ配信システムが構築可能になりました。弊社のライブ配信の多くはこちらから配信されることが多くなっていて、Media Asset Managementシステムであったり、映像自体を保管しているストレージもAWSに展開されています。

一方で、ユーザー機能を構成するAPIやデータ基盤はGoogle Cloudを主力として展開しています。使い分けの考え方の根幹は、先ほど（話した）Google Cloudを採用した理由と近いんですが、事業に集中するために自前で設計・実装するメリットがなくなった。コモディティ化していった技術をできるだけフルマネージドの機能に寄せていっているかたちになります。

それぞれのクラウドで進化する機能の潮流とか自社サービスとの親和性も考えて、2つのクラウドを使い分けています。

ABEMAが活用している4つのCDN

次にCDNについてお話しをしたいんですが、ABEMAは4つのCDNを利用しています。こちらもクラウドと同様に、耐障害性のためのマルチCDNというよりかは、主にユースケースごとに使い分けているといったかたちです。

FastlyはWebサイト「abema.tv」を提供するために利用していて、細かい処理の追加だったり、設定変更が頻繁に発生しがちなWebサイトで運用しています。Webサイトの運用に対してIaC（Infrastructure as Code）という側面で非常に優れているということが理由になります。

「Google Cloud CDN」と「AWS CloudFront」は、それぞれのクラウドに展開されたAPIのキャッシュ、またはゲートウェイとして活用しています。シンプルにバックエンドサービスに連結しやすいCDNを利用しているといったところです。

「Akamai」は映像配信全般に活用していて、トラフィック全体量、CDNの全体トラフィックからして、99パーセント以上を占めています。

映像配信のCDN、厳密にはライブ配信や有事の際には、AWS CloudFrontも併用していて、特定のイベントなどではマルチCDNの配信構成を取っているかたちです。

CDNの選定条件ですが、最低限のキャッシュと、ゲートウェイとして必要となる可用性や処理性能があるか。つまり、提供する機能に求められるSLO（Service Level Objective）を満たせるかはもちろん見ています。

あとはオリジンからの横断的関心事に当たる要件。例えばプロトコル変換であったり、レート制御、サーキットブレイカーを適用できるかなどを考慮して選定しています。

CDNの1つにAkamaiを選定した3つの理由

今日はAkamaiのWorld Tourなので、Akamaiだけ特別に選定理由を詳しく話します。

まず1点目です。サービスリリース時点で超分散型エッジプラットフォームであったことが挙げられます。1対1の関係性で処理されるインターネット配信は、よりユーザーに近いネットワークにキャッシュされることがユーザー体験的にも良いし、インターネットの効率的な利用の観点でも優れています。

（スライドを示して）左から右へデータが流れていると思ってもらえたら良いんですが、右に近ければ近いほどお客さまの体験は良くなるし、キャッシュ効率が上がってインターネットというネットワークの中で流れるトラフィック量が減っていくかたちになります。

2点目は、Adaptive Media Deliveryに代表されるような、メディア配信にまつわる関心事に特化した機能を早期から提供しているところです。ライブ配信というのは1分どころか数秒落ちることは事業的には非常に痛いインパクトを生みます。

とり返しが基本的にはつかないというか、お客さまに提供できなかった映像をそのタイミングで失ってしまうので、そのあとに配信をしても、ライブで得られる体験とはまったく異なるものになるので非常に痛いです。なので、そこの可用性が非常に重要になってきます。

あとは接続規模の急激な上昇とかで、オリジンに処理が貫通すると映像ファイルを取り扱っているオリジンはダメージが非常に大きくなります。オリジントラフィックへの貫通を規定数に抑える明確な仕組みが必要になってくるので、こういったものの機能性も重要視しているといったところです。

あとはマニフェストやセグメントごとに配信地域に対するルーティングとか柔軟なキャッシュ戦略があると、メディアとしての取り回しは楽になります。

3点目は95パーセンタイルの価格モデルといったところで、非常にビジネス的なところです。ABEMAのサービスリリース時の基本的なグロース戦略は、1ヶ月に数回の話題化の企画によって認知を広げて、新規顧客をガッと獲得して、そのあと一定数の定着を狙うといったところだったので、月間あたり2、3本の超話題化コンテンツみたいなものを作るという戦略でした。

この戦略でおおむね機能しましたが、逆を言ってしまうと、これが成功するということは、特定の期間だけ平時とはまったく比較にならないぐらいの大きなトラフィックが発生する流れになっていました。95パーセンタイルの価格モデルが、（月数回の話題作の配信にかかるコストを、無視される上位5%のトラフィックとして扱うので）この戦略によるコスト増加をすべて吸収して、ほぼタダで配信する感覚でとらえられる。

この、上位5パーセントに対する配信時間分のコストを気にせずチャレンジ可能にしてくれたことが、Akamaiを使っている大きな理由になりました。クラウドとCDNの選定や使い分け方については以上になります。

ライブ配信構成においてAkamaiをどう使っているか

あと、ライブ配信構成とAkamaiといったところで、ライブ配信をインジェストからユーザーの再生に至るまで、実際どのように構成しているかだったり、何を考慮して設計しているか、Akamaiをどう使っているかについて話します。

まず、ライブ配信全体の流れです。もしかすると釈迦に説法の方が会場にもいるかもしれませんが、あらためて説明します。

（スライドを示して）会場から最終的なユーザーに届ける映像を完成させる制作拠点が一番左ですね。そこから始まります。制作拠点からインジェストされた映像を、クラウドでクライアントに配信するための処理を行います。ABRエンコーディングであったり、パッケージング、マニフェストマニピュレーションなどです。広告挿入なども含まれます。

（その過程の後に）最終的にCDNを介してクライアントアプリケーション上のプレイヤーまで映像データを届ける流れになります。流れに沿って少しお話しします。

最初のポイントは制作拠点からインジェスト（まで）の話になります。制作拠点からパブリックのインターネットでインジェストすることは容易ですが、第三者の影響を非常に強く受けます。

プロバイダーを利用しているその他の利用者がトラフィックを流しすぎたり、そもそもインターネットってベストエフォートのインフラなので、さまざまな要因で不安定になっていく。じゃあこれに対してどう対策するかという話ですが、愚直にやると「各スタジオと各クラウドに専用線をつなぎましょう」みたいな話になりますが、柔軟なスタジオの増減に対応できない課題にもつながりかねません。

なので、我々は各スタジオとデータセンターを専用線で結んで、データセンターとクラウドをプライベートピアで結ぶハブのような構成を取りました。また、プロトコルにZixiみたいなネットワーク上の遅延、データ欠損対策に適したものを適用し、それらを合わせてインジェストの安定化を図っています。

次のポイントはインジェストされた後のクラウド上での処理ですが、エンコードとパッケージング、マニピュレーションを実行していきます。これらのクラウド上での処理の考慮点というのは、まず2つのアベイラビリティゾーンを最低の前提として、パイプラインを構築しています。必要に応じて2つのリージョンを用いて冗長化を図っています。

この時点で、机上の計算上でファイブナインクラス、99.999パーセントクラスの可用性を期待できるアーキテクチャを構成することを考えています。なお、マルチリージョンレベルの冗長化を行うかどうかはイベントごとに考慮可能になっていて、設定に基づいてどちらの構成でも構築できるようにしています。

絶対に落ちちゃいけないようなところはマルチリージョンになっているし、「少し落ちても問題ないでしょう」「何秒間や何パーセントは落ちてもいいでしょう」というところはシングルリージョンで配信されているかたちです。

次に大事なのが、オリジンの保護という観点になります。接続するユーザー規模が10、100、1,000、1万、10万、100万と桁レベルで変わっていくライブ配信において、そのオリジンをどう守るかが非常に重要になります。

オフロード率が1パーセント変わるだけでもオリジンの負荷は計り知れなくなるので、同一リクエストを有限数で統制する仕組みが重要になってきます。ABEMAでは、Akamaiの「Cloud Wrapper」を活用してこれらを統制して、接続規模の変化を完全に吸収しているかたちになります。

次はCDNからクライアントのパートで広義な面から話すと、インターネットに対して何を考慮していくかという話です。確実なキャパシティと配信品質の確保が重要になります。CDNやISPとのキャパシティプランニングでは大規模な配信量が重要になりますが、いずれにせよ無限ではないんですよね。

プランニングもしてキャパシティも取るんですが、ABEMAではFeature Flagによってデバイスのプランニング、主にそのデバイスの画面サイズのバリエーションと組み合わせて、解像度の制御を機能として実装しています。おおむね数分レベルで制御可能なものなので、高い解像度帯を制限することで、視聴数と画質によるユーザー体験の総和のバランスを取っています。

デバイスがどの解像度をつかんでいるか、その比率などもリアルタイムで可視化されているので、計算によってトラフィックの最大量の制御を可能にしています。

次にオブザーバビリティといったところで、最終的にお客さまにどのような視聴体験を与えたか、視聴品質がどうだったかは、顧客満足度に強く影響を与えます。

視聴品質は、もともとの映像であったり、ABRエンコードされた映像自体の質である映像品質と、それらをインジェストからデバイスまで時間軸に合わせて安定的に届けることができたかという伝送品質、あとは届けられた映像がクライアントのアプリケーション上のプレイヤーで安定してバッファリングされずに再生開始できたか、描画されたかという再生品質で構成されています。

これらをRUM（Real User Monitoring）として観測して、再生プレイヤー上の不備とか、ネットワークの分析をABEMAでは可能にしています。「NPAW」がそれにあたります。

我々は2023年、夏の甲子園を配信しましたが、その甲子園の配信から（Akamaiが提供するログ可視化ツール）「TrafficPeak」を採用して、Akamaiエッジ上のアクセスログの解析を可能にしました。これまで「ユーザー（ABEMAのサービス利用者）のネットワーク環境の問題だったのか、CDN経路上の問題だったのか」といったブラックボックス化していた問題に対して、データからハック可能になってきたというかたちです。

まだ使い始めたばかりなので使いこなしているというわけではないんですが、これまでには得られなかった情報を分析・活用することで、高い視聴品質を作っていくことを目標としています。

僕はどの講演でもこの話を毎回しているんですが、経路側の話です。単純に映像配信だけでなく、サービスの高い可用性を実現する上で重要なことに、スパイクアクセスの制御があります。

世の中で「ライブ配信が落ちた」というニュースが出るたびに「明日は我が身だ」と内心穏やかではないんですが、いくつかのライブ配信事故を耳にする機会があります。多くはライブ配信システム自体の問題でなくて、配信以外の予想外の過負荷によって引き起こされているように思います。

弊社において、例えば緊急地震速報とかもそうですが、緊急ニュースや記者会見とかがあったり、あとは（スポーツライブ配信において、）SNSでものすごく著名な人が拡散して瞬間的にトラフィックが集まってくる時って、1秒あたりで数万というレベルの流入数が生まれるんですね。秒間あたり数万人がサービスに着地してくるみたいな。

これらって本当に瞬間的なスパイクなので、何も考えずに受け付けると、基本的にはスケールアウト処理が間に合わないかたちになります。

あとは過負荷によってエラーからのリトライで状況が悪化し続けることもあります。なので、ABEMAではそのアプリケーションの起動であったりとかサイト訪問時に、主要なAPIの負荷がかかってくる手前で、入場するユーザーの1秒あたりの許容流入数を制御しています。

この仕組みはAkamaiのAPI Gatewayのレートカウンタを活用しています。移動平均に基づいた1秒あたりのカウントによって、1秒あたりに流入してくるユーザー数を明確に制御しているかたちになります。

このアプローチに対して仮想待機室を設けるという案もありますが、仮想待機室はこういうレート制御とは仕組みが別で、構造が複雑になりがちなので、別の障害点を生みやすいという側面もあり、現状はこういった構成を取っています。

以上がライブ配信構成の全体と、その中での考慮ポイント、Akamaiの活用箇所に関する紹介となります。

競争力にならない技術をできるだけマネージドサービスに寄せる

まとめになります。前半の事業を支えるインフラストラクチャというパートでは、事業フェーズと用途に応じて、柔軟にインフラとか、CDN、クラウドを使い分けているという話をしました。

終始一貫して言っていることは、競争力にならない技術を、できるだけマネージドサービスに寄せるという考え方をしています。

ライブ配信構成とAkamaiに関しては、インジェストまわりのネットワークを信頼できる構成で構築することが重要です。あとは、クラウドの冗長化は求められる可用性に合わせて柔軟に構築しています。あとは、軽量ではない処理を伴うオリジンは、CDNからの保護機構が重要になります。あとは、オブザーバビリティの確保やスパイクアクセスの対策も同様に重要になるという話をしました。

今日はあまり時間がなかったのですごく端折って全体を概念的に話しましたが、細かいアーキテクチャであったり、我々がシステム全体上でどういうふうにものを考えて作っているかを2023年の「ABEMA Developer Conference 2023」で話しています。YouTubeチャンネルにアーカイブが残っているので、よければそちらを見てもらえればと思います。

本日の私からの話は以上になります。ご清聴ありがとうございました。