『72時間ホンネテレビ』の負荷対策とその裏側
柿島大貴氏：それでは、「72時間ホンネテレビ」の負荷対策とその裏側というタイトルで発表させていただきます。よろしくお願いいたします。
まずは自己紹介をさせてください。私は株式会社サイバーエージェントの技術本部で、インフラエンジニアをやっている柿島大貴といいます。
過去には共著で『HBase徹底入門』（翔泳社）を書いたりしました。
登壇としてはHBaseCon 2015においてサイバーエージェントにおけるHBaseの使い方を話したり、今年のAWS Summit TokyoではIAMの使い方とか、そういったところを共有させていただいております。
私の所属する技術本部というのは、サイバーエージェントのメディア事業を支援する、社内横断の技術組織となっていまして。社内には「AbemaTV」以外にも、「Ameba」とかそういった別のサービスもありまして、そういったところに対してクラウドですとか、開発環境とか、サポートをしている部署になります。
その他の活動としまして、私は2016年までエンジニアブログの委員長をしていたりとか、その後技術広報がついてくださってからは、サポートというかたちで広報にも関わっています。本日のレポートもCyberAgent Developers Blogで公開予定ですので、後日また確認してくださるとありがたいです。
ということで、宣伝はここまでとなります。
今回のカンファレンスのテーマが、「PAST→FUTURE」ということになってるんですけれども、私のメインのところはPASTの部分になります。
まず1つ目として、負荷対策プロジェクトの裏側を話させていただき、そして実際の負荷対策の内容を話させていただきます。そして最後に、今抱えている課題を発表させていただきます。
『72時間ホンネテレビ』の概要
まずはじめに発表を聞いていただく前に知っていただきたいこととして、1つ目として『72時間ホンネテレビ』とは何かというところです。
こちらは昨年の11月2日から11月5日にかけて、稲垣吾郎さん、草彅剛さん、香取慎吾さんが出演された、72時間の生配信番組となります。
公開されているデータとしては、このようなデータがあります。
例えば、総視聴数としては7,400万超え、Twitterの世界トレンドで1位を取ったり（注：#森くん）、スポーツ新聞に多数掲載されたり、Yahoo!ニューストピックスに5回掲載されたり、こういったデータがあります。いわゆるバズった番組です。
もう1つ知っておいていただきたいところとしては、「AbemaTV」のコンポーネントについてです。すごくざっくりとした構成なんですが、こちらです。
まずスタジオや中継先があって、そこからGCPにある「AbemaTV」の本体に届いて、それがCDNを通して動画のデータはクライアントに届くと。
それ以外に関しても、GCPにリクエストがいったり、広告などの連携システムなどは、AWSにあったりGCPにあったりプライベートクラウドにありますが、この間で叩いているというかたちです。
今日発表するのは、サーバーに届いたあとの話になります。
「72時間ホンネテレビ」は会社、グループ全体でも、みんなでやったプロジェクトでした。
今回は先ほどの赤く囲った部分が発表対象になるんですが、それ以外のサーバーに届くまでの部分も、中継回線を冗長化したり、それぞれの連携システムでも負荷対策が行われたりと、いろんな話があるのですが、こちらはまた別途お知らせできる機会があればなと思います。
負荷対策プロジェクトが始動
では負荷対策プロジェクトの裏側について話させていただきます。まずはこちら。西尾の発表にもありましたが、ここから話させていただきます。
2017年5月7日に「亀田興毅に勝ったら1,000万円」という番組で、「AbemaTV」はサーバーダウンをしてしまいます。
この障害を受けて、次の大きな目標を年末年始の番組に捉えて、サーバーサイド/インフラエンジニアを中心に、対策と検討を進めていました。
しかし……。6月・7月とクラウドの障害で視聴障害が発生してしまいます。
こうなってくると、社内の雰囲気としても、ここを対策しなければいけないんじゃないかという温度感も出てくるんですが、なかなか優先度が高いものが複数ある状態って難しくて、どちらも根本的にインフラのレイヤーを見直さなければいけなかったりするので、ここをどうしようかというところを、CTOの西尾とも話していました。
まず行ったこととしては、これが先ほどより詳しい図になります。
ちょっとモザイクかかってしまっていますが、どこでこれまでに障害が起こって、それがどのくらいの時間障害につながったかとか、「それは我々もう対策したんだっけか？」とか、そういったところを俯瞰できる図を作って、現在残っているリスクを考えました。
そのリスクを把握した上で、社長に「今年、クラウド障害対策と負荷対策、どちらに力を入れましょうか？」というジャッジをもらいにいきまして、「負荷対策だ」というジャッジをいただいたので、これで優先度の高いものは年末年始に向けた負荷対策だという方向性を取ることができました。
そして翌月、僕はクラウドのコストも担当しているんですが、「コストの報告に来ました～」と言ったところ、「負荷対策が進んでるか心配なんだよね」というお話いただいて、「負荷対策のプロマネやってよ」と言われたので、「やったことないけど、やってみまーす」というかたちで、負荷対策プロジェクトマネージャーになりました。
とはいっても、プロジェクトマネージャーというものはやったことなかったので、本屋さんに行って『童話でわかるプロジェクトマネジメント』という本を読んでみました。「プロジェクトマネジメントとは、『チームで成果を出す技術』でしかありません。」と書かれていたので、ガントチャートの書き方とか、勉強するとかではなくて、自分なりのやり方で対策をしていきました。
キックオフに向けて準備したこと
まずキックオフに向けてやったことはこちらです。
まず「AbemaTV」をひたすら使ってみるというところ。あとは過去のデータを、ログの調査をしたり、メトリクスを調査したり、ドキュメントを見たり、ヒアリングをしたり、そういったところから追っていきました。
また、アプリやブラウザのリクエストを、Charlesやブラウザの開発者ツールを使って実際にリクエストしながら、「このボタン押したらどんなリクエスト飛ぶんだろう……？」みたいなことを、ひたすらデバッガーのようにやっていました。
それで見えてきた問題はこんなかたちです。
当時サーバーまで届くリクエストが非常に多かったんですね。一部CDNで動画のセグメントファイルも配信していたんですけれども、それ以外のリクエストはほとんどGCPの本体に届いている状態でした。
あと、私Webサービスは担当したことあったんですけれども、動画サービスってあんまり担当したことがなかったので、傾向も調べていたんですけれども。
例えば配信中は、配信に必要なセグメントファイルだったりプレイリストだったりとかは、ずっと定期的にストリーミングのファイルを取得するわけですね。
あとはコメントだったりとか。そういったリクエストが、ユーザーが接続している間ずっと発生するというのが、なかなか珍しかったなと思いました。
視聴者推移の傾向
2つ目としては、我々は、先ほどの長瀬の説明にもあったように、1つにはリニア型の配信を取っています。
これは番組表の時刻に沿って配信なんですが、そうなるとみなさんが、22時だってなったら一気に視聴者が跳ね上がると。こういうトラフィックの上がり方も、普通のWebサービスとまた違ったかたちだなということを調査しました。
そして、同じようなタイミングでみんなが再生していると、同じようなタイミングでCMを迎えるわけなんですけれども、そのCM迎えたタイミングでトラッキングも走ります。
そうすると15秒のCM、30秒のCMというこの間隔で、どんどんリクエストがスパイクする。こういった特徴が見えてきました。
まとめると、全体的に言うとリクエスト全体を減らさなきゃいけない。そのリクエストに関しても、視聴者に応じてどんどん増えていくリクエストと、あるタイミングだけドカーンと上がる、スパイクするリクエストと、こういった2種類が存在します。
やらなきゃいけないことがわかってきたので、9月13日に年末年始の負荷対策プロジェクトがキックオフされます。プロジェクトメンバーと、年末年始のために、何のために、何をしなければならないのか。リクエストを減らさなきゃいけないと。ここでベクトルを合わせました。
しかし、9月24日に「72時間ホンネテレビ」（11月2日～11月5日配信）の情報が解禁されます。そうなるとこういう感じですね。
もともとのターゲットは年末年始だったんですけれども、一気に対策できる期間が変わってしまいました。
メンバーの数も、当初は15名だったんですけれども、発表されてからは開発本部ほぼ全員で対策するというかたちになっていきました。
負荷対策の舞台裏
ここまでがプロジェクト自体の裏側になります。ここから実際の対策内容を話させていただきます。
まずは、決めたこととして、何を守らなければいけないのかということを決めました。僕らが一番届けたいのは「72時間ホンネテレビ」とCMを配信すること。そこが一番優先度が高くて、ほかに関してはちょっと優先度を下げて対応することにしました。
具体的に配信を守るための方針としてはこのようなかたちで、1つずつ説明させていただきます。
まず1つ目の、CDNでキャッシュさせるに関しましては、先ほどの配信に必要なものの1つとして挙がっていたプレイリストに関しても、これまでは直接、CDNを介さずに提供していたんですけれども、そちらもCDNでキャッシュさせるようにしました。
また、Webブラウザ用の「 abema.tv」というサイトがあるんですけれども、このタイミングでGoogle Cloud CDNというGoogleのCDNに対応させました。
裏のセッションでは、さらにFastlyに対応させるという話が話されています。ほかにも、APIの一部のコメントだったりとか、そういった番組表だったりとか、そういったものもCDNでキャッシュさせるようにしています。
そして、ただCDNの設定をするだけではなくて、なるべくCDNからレスポンスが返ってもらえるように、キャッシュヒット率を上げるための策を練りました。
例えばリニアのような、番組表に沿って、みんなが同じタイミングで同じようなファイルを取得しに来るものと、VODのような、個人が好きなタイミングで好きなファイルを読むというのは、キャッシュの戦略が異なるので、このタイミングでドメインを分離して、設定の最適化を行いました。
また、これはデメリットもあったんですけれども、動画セグメントファイルのチャンクサイズを変更することで、プレイリストの取得間隔を長くして、TTLをより長く取ることができたりとか、そういったキャッシュヒット率を向上させる取り組みも行いました。
不要なリクエストを止める
ほかには、不要なリクエストを止めました。
例えば、いろんなトラッキングをリクエストしているわけなんですけど、導入当初は必要だったけれども今はいらなくなっているトラッキングのお掃除もこのタイミングで実施しました。
あとは、Androidチームのogaclejapanさんが発表してくれた資料もあるんですけれども、Androidで使っているGoogleのExoPlayerだけ、プレイリストの取得間隔が非常に多いという。先ほどのポチポチですね。ポチポチした結果多いということがわかって、「なんで多いんですかね」なんて話をしていたら、ExoPlayerのバグを見つけてくださって、Googleにプルリクを送ってくれました。
あとは、「AbemaTV」見ていただくと、こういった視聴数とかコメント数とか、そういった部分があるんですけれども、ここもかなりの頻度で定期的に取得していました。
ここも大規模な視聴になってくると、ちょっとの増え方はなかなかこの表示には現れないので、「そんなに頻繁に取る必要があるか？」みたいな話をみんなでして、このあたりも人数が多くなったらポーリングの間隔を変えるといったことを取り入れてます。
あとは、先ほどの「傾向」にもありましたけれども、CMのトラッキングみたいにスパイクするようなリクエストは、なかなかシステム側で受け取ると難しい部分です。こちらも過去の経緯から一度「AbemaTV」のサーバーを経由していました。
過去の経緯というのは、昔はサーバー側でデータを付与してからトラッキングのシステムに送る必要があったんですが、今はそれをする必要がなくなっていたので、本体を通らずに直接トラッキングのシステムに送るように変更しました。
そのトラッキング用のシステムも社内製のものなんですが、プライベートクラウドでは耐えきれないかもしれないというかたちで、急遽AWSで構築してもらうことになりました。
サーバーに届くリクエストを減らす
そして、いわゆる一般的な負荷試験とかサーバー台数の調整も行っています。負荷試験に関しては、昨年のAbema DevConでインフラ担当の方が発表されてますので、こちらもご覧ください。
ということで、負荷対策前の問題であった、サーバーまで届くリクエストが非常に多いというところです。
仮説のイメージとしては、そもそものリクエスト自体無駄なものを減らして、取得間隔を変えて、かつなるべくCDNをとおすようにして、CDNのキャッシュヒット率を上げることでオリジンのリクエストを減らすとか、トラッキングのように別のシステムに流すことで、ここを守ろうというかたちですね。
とはいっても、期間が限られているので、「対策間に合わないな……」という部分もありました。そういったところに関しては、ある種の諦めというかたちで、そこが落ちても配信は守れるようなエラーハンドリングを入れてもらったりとか。あとは部分的に「もう耐えられない！」となったら、そこだけメンテを入れるというような機能を入れてもらったりとか。
あとは技術的な話ではなくなってくるかもしれないんですけど、番組制作部門に「申しわけないですけどこの機能は当日使わないでください」というお願いをしたりとか、そういったかたちで一番守りたいものを守るための対策をしていきました。
押し寄せるテストの波
そして設計して、がんばって実装していただいたあとに待ってるものといったらテストです。
ですが、実質10月しか期間がないので、これが色分けの図なんですけれども、10月のWebとかアプリとかのテスト計画は、ほぼ毎日複数のテストが並列で走っていて、毎日のようにリリースが待っていました。
ここに関しても過去最大の人数でQAテストをしていただいたりします。もちろん自分たちでもミスがあっちゃいけないってことでテストをしました。
ただ、リリースをしてもまだ難しい問題があって、iOSとかAndroidのアプリって、リリースをしてもユーザーがアップデートをしてくれないと挙動が変わらないんですよね。ただここに関しても、過去にエンジニアが強制アップデートの仕組み、指定したバージョンよりも低かったら、画面を遷移できないようにブロックできる仕組みを入れておいてくれたので、10月30日にAndroid・iOS、11月1日にAmazon Fire TV・Android TVの強制アップデートを入れました。
そういったかたちで、これがプレイリストの秒間リクエスト数の推移なんですけれども、左側側が10月12日ごろで、先ほど強制アップデートしたのがこのあたりですね。
だいたい配信の2日前ぐらいに、想定していた、目指していた状態になることができました。
一気にトラフィックを増やさないための工夫
そして配信当日を迎えます。72.5時間の配信が始まります。
なぜ.5となっているかという部分なんですけれども、これにはカラクリがありまして。
直前の20:30から21:00の30分間、『超直前マル秘カウントダウン放送』というのがあったんですね。
これのマル秘は僕らも内容をまったく知らなかったんですけど、こんな感じです。
放送開始まであと59、58、57、本当に黒い画面にこういう感じだったんですけど。
思い出していただきたいのは、リニア型の配信の場合ユーザーは時刻に合わせてドカーンとやってくるという問題を抱えていたので、少しでも起動を緩やかにしたいなという希望がありました。
起動処理というのは、ユーザーのデータを取ってこなきゃいけなかったりとか、ちょっとリクエストが多くなるんですね。
なので、制作側に少しでも分散する方法がないかというかたちで打診したところ、ああいった番組が出てきました。
その30分間の黒い画面で、総視聴数50万を超えるというかたちだったので、少しは効果があったのかなと思っています。
そして、配信開始へ
そして本編が始まります。肝だった動画のプレイリストのCDN化なんですけど、番組開始直後のオフロード率としては99.8パーセントということで、ほとんどCDNで返すことができました。
気を抜いてはいけませんが、一安心したポイントでしたね。
そのほかの、例えばコメント数とか視聴数の取得とか、そういったリクエストに関しても、負荷対策前の平日のリクエストよりも、見ているユーザーは非常に多いんですが、比べても多くはないというか、むしろ少ないくらいの、サーバーへ届くリクエストとなりました。だいたい1接続あたりのサーバーへ届く秒間リクエストの数に関して言うと、「亀田興毅に勝ったら1,000万円」の時と比べると約10分の1ぐらいの大きさに変わっていました。
また、シフト勤務を組んでいたんですけれども、何かあったらすぐに判断ができる状態を作っておきました。生配信の場合、見てるユーザーのブラックアウトしてしまう時間が長くなるというのは非常に良くないと思うので。
なので先ほどの何を守るかというのと対応させて、「どういったことが起こったら何をする」というのを、あらかじめみんなで認識合わせをしておいて、すぐにアクションを取れるようにしておきました。
ただ、何事もなく配信は無事終わりました。
無事に配信を終えて
これは僕にとっては非常に感慨深い出来事だったんですけども、私の職業柄インフラエンジニアという、サーバーがダウンするとニュースになるのは当たり前なんですけど、サーバーがダウンしないことがニュースになるのは非常に珍しいことで、落ちなかったってニュースが出たのが非常に感慨深かったです。
ほかにも、エンジニアのみなさんはBプランも用意してくれていました。
例えば、もう耐えられないってなったら外部サイトへ誘導する。「メンテナンス画面です」とか、あとは帯域が足りなくなったら高い解像度を配信しなくするような解像度制限とか、既に見れている人を守るために機能を制限するとか、そういった仕組みも用意していたんですが、使わずに済みました。
そのほかの後日談としましては、クラウドへのリクエスト数やトラフィックが減った結果、クラウドのコスト削減にも成功しています。当初の目的だった年末年始の番組も大きな問題なく終了し、私は役割を果たしたのでSREへ役割を引き継ぎまして、技術本部に戻りました。
今回のプロジェクトでは、総力戦だったので、非常にさまざまなロールが活躍しました。
例えば、ディレクターの方々は各対策のリードとか調整をしてくださったりとか、先程のように「編成側にこういった機能を使わないでください」といった調整をしてくださったりとか。
あとはエンジニアたちは、高い技術力とコミット力で、とくにリーダー陣たちには非常に助けられました。
僕は動画配信については詳しくなかったんですけども、優しく厳しく専門知識を教えていただいたり、育てられましたね。
QAに関しても、リリース前のテストだけでもあのスケジュールのように忙しかったんですが、例えば「この機能だけ落としても画面真っ黒にならないよね」みたいな、障害を想定したテストも一緒にやってくださいました。
あまり負荷対策に関係がないと思われがちかもしれないですけど、デザイナーに関しても、例えば先ほどのBプランにあった制限の画面を作ってくださるとか、そういったところで関わってくれました。
そして、ロールではありませんが、入社直後の新卒の方とか中途の方々とかも、一切それを感じさせず、みんなが大活躍というかたちでしたね。
ここまでくると良いことばかりかなと聞こえるんですけど、僕はけっこう失敗もしています。
例えば、最初は「『Amazon Fire TV』は負荷対策しなくていいよ」みたいな話をしてたんですけど、途中で「やっぱりお願いします」と追加したりとか。あとは、システムへ新しい制約を途中で追加してしまったりとか、負荷対策に夢中で当日のシフトをギリギリまで組むのを忘れていたりとか。
あとは対策以外の部分で、他社との連携が漏れてしまって、ご迷惑をおかけしたりとか。あとこの資料作っている中で思い出したんですけど、負債を残してしまった可能性があるので、ここは後ほど調整します（登壇者注：登壇では負債という表現を使いましたが、暫定対応のままで、恒久対応としてはやり残した部分という意図で発言をしました。致命的なものではありません）。
選択と集中の大切さ
負荷対策に関してのまとめとしては、やはり選択と集中の大切さを感じました。
やらなきゃいけないことはたくさんあるんですけど、一番大事なことを決めて、それ以外はある程度割り切ることもたまには大事なのかもしれません。
あと、負荷対策に関しては、僕の経験でも過去サーバーサイド／インフラエンジニアだけでやることが多かったんですけれども、今回クライアントサイドエンジニアの方々とか、そういった方々も巻き込んでやることで、すごく大きな効果が出たのかなというところですね。
あとはメンバーがめちゃくちゃがんばってくださったところが一番大きいかと思います。
あとはお礼というところで、Google Cloud Japan様、アカマイ・テクノロジーズ様、Amazon Web Services Japan様というベンダーのみなさまには、非常に短いスケジュールの中でご協力をいただきまして、非常にありがたかったです。ありがとうございました。
インターネットの限界との戦い
そして「FUTURE」ですね。一般的な負荷対策の部分はSREに引き継いだんですけれども、一部まだ関わっているところがあります。それが「インターネットの限界との戦い」……と私は呼んでいるんですけれども。
一般的な地上波テレビであれば、私の知識が合っていれば、電波が届く範囲であれば多くの方が視聴可能だと思います。
それは、例えば年末の歌番組であったりとか、サッカーの代表戦であったりとか、たくさんの人が見ることができます。
でも一方で、インターネットって、多くの人が見れば見るほど混雑しやすいですよね。とくにIPユニキャストの場合。
トラフィックと呼ばれるぐらいので、道路の写真を載せてみたんですけど、ああいうかたちでたくさん使えば使うほど混雑すると。
「AbemaTV」のトラフィックってどんな感じなのかというところでいうと、動画セグメントファイルのCDNエッジトラフィックは、Tbpsの世界へ突入しています。
こう考えてきた時に、先ほどの長瀬の説明にもあったんですが、総務省の我が国のインターネットにおけるブロードバンド契約者の総ダウンロードトラフィックは、12.5Tbpsと推定されています。
日本の全総ダウンロードトラフィックと同じような単位のトラフィックを、考えなければいけなくなってきてしまいました。
そうなると、物理的な制約の存在が気になってくるわけです。
クラウドもCDNもISPも、裏側には物理的な機器とかネットワーク回線があるので、好きな時に好きなだけというのもなかなか難しいと。
そんな中でより多くのユーザーに番組を届けるために、我々はいま試行錯誤しています。一緒にインターネットの限界を超えてくれる人を探しています。
以上で発表を終わらせていただきます。ありがとうございました。
