CodeIQ MAGAZINECodeIQ MAGAZINE

人類はインターネットでテレビができるのか?──大規模トラフィックを支えるAbemaTVの裏側とは

2017.11.16 Category:勉強会・イベント Tag: , , , ,

  • 23
  • このエントリーをはてなブックマークに追加

AbemaTVは伝達手段をインターネット回線としたテレビ局だ。そのため、様々な要因で低速化する可能性を秘めている。
このようなベストエフォート型のインフラ上で大規模トラフィックを迎え撃つため、AbemaTVのインフラエンジニアは何をしてきたのか。
インフラエンジニアとして活躍するサイバーエージェント岡田翔乃介さんが、その対策と技術について紹介した。
by 馬場美由紀 (CodeIQ中の人)

AbemaTVの負荷対策とは

10月21日に開催されたAbemaTVの取り組みや技術的知見を披露するイベント「AbemaTV Developer Conference 2017」。その最後のセッションに登壇したのが、サイバーエージェント技術本部のService Reliability Group(SRG)という横断的組織の岡田翔乃介さんだ。

岡田さんは2015年4月に新卒で同社に入社し、AmebaブログやOwnd、CROSS MEなどに携わった後、2016年12月よりAbemaTVのインフラエンジニアとして活躍している。セッションタイトルは「AbemaTVの裏側- 大規模トラフィックを支える技術と負荷対策の話」。その概要を紹介する。

AbemaTVのアーキテクチャーは膨大である。GKEについて知りたい方は、昨年のDEVELOPER CONFERENCE(DevCon)で話しているので、こちらも見てほしい。

また「Google Cloud Next ’17 in Tokyo」では、Googleの「世界規模のクラウドネットワークの負荷分散、最適化、セキュリティ確保」についての講演内で、AbemaTVのネットワークについても紹介されており、こちらはYouTubeで公開しているので、ぜひチェックしてほしいとのこと。

まずはAbemaTVの負荷試験について。昨年のDevConから今日まで、年末年始のイベントから始まり、「劇場版魔法少女まどか☆マギカ[新編]反逆の物語」、「亀田興毅に勝ったら1000万円」、「モンスターストライク 十二支再競争」、「第30期竜王戦決勝トーナメント」など、いくつものヒット企画や番組が誕生した。

喜ばしいことだが、インフラエンジニアからすると試練の連続だった。そんな試練を乗り越えるための対策の代表例が負荷試験である。負荷試験ではLocustとwrkという2種類のツールを使用している。

大規模な負荷試験にはLocustを採用

LocustとはPython製の分散型ユーザー負荷テストツール。特徴はgeventを使用した完全なイベントベース機構であること。

ちなみにgevent自体はコルーチンベースで、複数のtaskをこなす非同期IOライブラリである。Greenletという軽量型のコルーチンが実体で、OSプロセス内では実行されるが、協調的にスケジューリングされるというものだ。

なので、OSがスケジューリングして本当に並列に動くPOSIXスレッドを利用した並列機構とは、少々毛色が違う。

IO待ちになったらon_eventが発火し、別のタスク(シナリオ)が実行される。そのため、シナリオファイルを単独で実行していると、CPUが一コアだけしか使用されていないように見えるかもしれない。そうではなく、コアを十分に使用したい場合は、distributed mode機能を使用する。

AbemaTVでは、GKE上で大量のdistributed mode workerを配置してシナリオファイルを回し、high-throughputを実現している

Locustクラスタの詳細は次の通り。シナリオの用途別によりクラスタを切り分けている。


複合シナリオで負荷試験を実施する場合のみだが、トータルで9984コアのメガクラスタで負荷試験を実施することもある。この規模の負荷試験を基本的には、1~2人のインフラエンジニアが短期間で実施している。

Locustを使うメリットは複数ある。第一にWeb UIからリアルタイムで各pathのreq/secやexeptionを観測することができること。リアルタイムで描画されるため、何か問題があった場合には、すぐに対応できるのだ。

第二にScaleに強く、GKE×Locustのの組み合わせは相性が良いこと。第三はかゆいところに手が届くこと。例えばpush受け取り時、CM入り、videoの視聴時など、ユーザーの綿密なシナリオもLocustで表現ができる。

デメリットはPythonで何でも書けるので、自由度が高い分、秘伝のタレ化しやすいこと。現状、先人が書いたコードを継ぎ足したり削ったりして使用している。そのためまだまだ改善の余地はある。

綺麗にしたら9984コアも要らない説もあるので、こちらに関してはデメリットというより、どちらかというと今後の課題に近いとのこと。

今後の展望は、負荷試験環境の起動や停止、シナリオの実行、レポートの集計まではChatOps化したい。シナリオの作成のみ手動で、残りは全て自動化したいと考えている。

また、boomerを使用した全シナリオのリプレース、パフォーマンス検証も実施したい。

この背景にはAbemaTVのサーバーサイドはgolangを採用しており、誰でも管理できるよう手に馴染みやすい言語でシナリオを用意したいという意味が含まれている。

限界性能試験ではwrkを使用

このように大規模な負荷試験に最適なLocustだが、例えば1つのendpointに対してサクッと限界性能試験したい時には巨大過ぎる問題がある。

そんなときに使うのがwrkである。wrkはLuaでシナリオを記述可能なHTTPベンチマークツール。単一のマルチコアCPU上で実行すると大規模な負荷を発生させることもできる。

マルチスレッド設計だが、epollやkqueueなどのevent通知システムを組み合わせて実現している。使い方も簡単で、vegeta、Apache Bench、Siege、k6などのツールを触ったことがあるエンジニアであれば、すぐ手に馴染むと思われる。

wrkのメリットの第一は、レポート出力部分をカスタムできること。つまり実装次第で好きなものを解析することも可能だ。第二に高速、かつ、パワーも十分であること。

第三はBinaryを使用したrequestにももちろん対応していること。さらにちょっとしたシナリオも記述できることなどだ。

AbemaTVではレポート部分を次の様にカスタマイズしている

  • latencyのpercentile表示
  • threadの詳細情報表示(均等に負荷を与えられているかどうかを確認したり、theadとconnectionのバランスを可視化するため)
  • レポート解析時間の表示

デメリットはレポートの集計に弱いこと。例えばvegetaのreportコマンドみたいな機能は存在しない。集計部分は独自で作るしかないというわけだ。

昨年末以降、インフラエンジニアが見舞われたトラブルへの対応策

昨年のDevCon以降、我々は様々なトラブルやバグについて見舞われた。それをどう乗り越えたのか。AbemaTVでは次のようなGCPサービスを使用している。

MongoDBもその一つで、MongoDB Cloud Managerを使用している。従来はMongoDB Management Service(MMS)と呼ばれていたが、2015年6月ぐらいに現在の名称に改称された。現在、リストアにMongoDB Cloud Managerを使っている。

従来はmongodump(GCE)がdumpファイルを作成し、そのファイルはGCSに置く。そしてdumpファイルを元にmongosがリストアする仕組みとなっていた。

実行時間は毎朝5時で、90分かけて処理を行っていた。負荷試験中、しかもマイルストーン手前でリストアが失敗すると、90分間無力となり、絶望を感じていた。これでは不健全だと考え、Cloud ManagerのSnapshot機能を検証することになった。

その結果、実行時間90分を38分に短縮することができた。従来の方法だとshardやChunk情報は独自のスクリプトで整合性を保っていたが、Cloud ManagerだとshardやChunk情報はよしなに解決してくれる。

厳密に言うと、shard key rangeだけ反映してくれる仕組みになっているということ。なので、本番環境と全く同じSharded Clusterを38分未満でサクサク作ることが可能となった。尚、これはあくまでも当社のGCPプロジェクト上での実績なので、参考値程度で留めてほしい。

注意することもある。リストア時はwrite防止のため、意図的にCloud Managerがmongodを止めるので、オンラインでは使用不可となる。

あくまで新規作成時、あるいはSharded Cluster全体が破損した際などに使用することだ。しかし、負荷試験時や新規機能の検証時などに、本番環境と同等のSharded Clusterを簡単に用意できるので、かなり有用な手段だと言える。

だが、Webコンソールの使用はヒューマンエラーにつながるため極力避けたい。そこで独自にCLTを作成した。今実装できている機能は各プロジェクトの情報やSharded Clusterの詳細情報の参照、後はリストア機能だ。

現在は常に最新のSnapshotをベースにリストアする仕組みなので、ユーザーが任意のSnapshotを選択できるような機能の追加、さらにプロジェクトごとにアラートの設定を作成し、管理できる機能を追加していきたいと考えている。

Cloud BigtableへのバックアップもCLTを作って対応

続いてCloud Bigtableについては、バックアップとメトリクスに分けて解説するが、結論としては、Cloud Dataflow を使用してテーブルを一連の「Hadoopシーケンスファイル」としてexportするという方法しかない。

これに関してはユーティリティが用意されている。捕足だがHbaseからBigtableへの移行もサポートしている。

まずはバックアップ。「Point-in-time的なバックアップ方法はないのか」という疑問が出てくるが、現時点では存在しない。またSnapshotは対応してないのかという疑問もある。これについても現時点ではサポートされていない。

そこで私たちはCLTを作成。基本的にはバックアップしたいテーブルとcluster情報を引数として渡して実行するだけのツールである。Backup時に必要なGCS Bucketやjarファイルやcbt componentは、裏で自動的に用意してくれる仕組みとなっている。

将来的にはK8sのjob resourceで定期実行や世代管理を実施するほか、Snapshot APIが用意されれば、Go Client Libraryを使用して、既存CLTを書き換えたいと考えている。

次はメトリクスだが、Metrics自体は既にGA(Explorerで表示可能)となっている。ダッシュボードからBigtable Metricsにアクセスするには、Whitelist申請が別途必要となる。Alerting設定も同様だ。

しかし、Whitelist登録が完了しても、アクセス不可能なメトリクスが存在する。Error countなど、まだStackdriverからアクセスできないメトリクスでAlerting policyを設定すると、もれなく全policy一覧が参照不可能となる。

現在修正されているのかは定かではないが、救いなのは既存のAlerting policyに影響を及ぼすものではなく、あくまで参照にのみ影響するということだ。

Abema Botの作成やCloud CDNの導入も

その他の取り組みとしては、インフラエンジニア専用のAbema Botの作成がある。

AbemaTVでは負荷試験環境は本番環境とほぼ同じ構成で構築しており、コストが莫大になるため、負荷試験時にしか起動しない運用にしているのだ。

起動あるいは停止に関しては、別途用意したスクリプトを使用者に配布し、使用者が各々好きなタイミングで実行できることになっている。

だが、突発的な新技術の検証や障害ポイントの洗い出しで使用することも日常茶飯事にある。人力では起動状況はカバーしきれないので、定時のタイミングでBotから起動状況を通知する仕組みを作ったのである。

これによって任意の起動者にアナウンスをすることができる。ちょっとしたことだが、チーム全体の意識も変わり、止め忘れ防止対策になっている。将来的にはこのBotに負荷試験を任せる機能も実装したいと考えている。

もう一つはCloud CDNの導入。Varnishを通しているendpointや、cache可能なendpointに関しては、続々とCloud CDNを導入している。これはMongoDBのバースト負荷対策、起動時の負荷対策、Backend Trafficの抑制などのためである。

これは一例だが、Cloud CDNを導入したことで、ご覧のように劇的にrequestの改善に成功していることがわかる。

岡田さんは最後に「AbemaTVはユーザーもどんどん増えているので、それに正比例してトラフィックも大規模になっている。もはやAbemaTVはインターネットでテレビができるのか、ではなく、人類はインターネットでテレビができるのかというフェーズになっている」と言い切った。

今はまさにその挑戦が始まったところである。先日も72時間テレビなど、視聴数7400万を超えた際にもサーバーダウンせずに放送したことで話題となったAbemaTV。これからどのように成長していくのか、楽しみは尽きない。

発表資料:「AbemaTVの裏側- 大規模トラフィックを支える技術と負荷対策の話」

  • 23
  • このエントリーをはてなブックマークに追加

■関連記事

AbemaTVがリニア型配信で「MPEG-DASH」をサポートした理由と、その使い方とは?... HLSとMPEG-DASHの違い 「AbemaTV Developer Conference 2017」は開局から約1年半のインターネットテレビ放送の実績をもとに、現場で得られた技術的知見が公開されるイベントである。 配信現場からインジェスト・パッケージングを経て、多様なデバイスに快適な視聴体験...
IT業界の坂本竜馬こと若狭氏、アツく語る!─LINE BOT AWARDSの立役者たちに男泣き!... LINE BOT AWARDS GEEK賞&CodeIQ賞の「シャクレ」とは? CodeIQ賞のお祝いにインタビュー飲みしました CodeIQ馬場です(略してBBQ)。 LINE BOT AWARDSではCodeIQ賞として、若狭氏のイベントなどで映写されてるスライドやイベントでの...
聖夜のアイデアソン -Pepper Loves LINE BOT-... LINE BOT AWARDSとは 「LINE BOT AWARDS」とは、LINEのchatbot開発促進及びユーザーへの普及を目的に開催するAwards。個人・法人問わず誰でも参加可能なAwardsで、応募〆切は2月22日です。 ▲▲LINE株式会社 ビジネスプラットフォーム事業室 戦略企画...
グッドデザインには何が必要か?グッドデザイン賞受賞作品の開発プロセスに見るUX設計のポイント... 全員がUXデザイナーになる:AbemaTV立ち上げの舞台裏 リクルートホールディングスが開催した、グッドデザイン賞2016を受賞した4つのサービスをテーマにしたトークイベント「UX & Service Sketch グッドデザイン賞特集」イベント。 最初の登壇者はインターネットテレビ局「...
最高賞金1000万円!LINE・砂金信一郎氏に聞いた「LINE BOT AWARDS」の全容と狙い─... LINE・砂金信一郎氏がプロデュースするビッグイベント これまでサービスを提供する企業がユーザーと密接な関係を結ぶためには、スマホアプリを提供してユーザーに使ってもらうというのが一つの方法だった。 しかし、アプリ開発には手間がかかるだけでなく、一度はダウンロードしてみたユーザーも、毎日それを使う...
クラウドコンピューティングの未来を探る「OpenStack Summit Hong Kong 201... OpenStack Summitって何? 2013年11月5日~8日にかけて開催された「OpenStack Summit Hong Kong」に参加してきました。 OpenStackは、クラウドサービスを誰でも簡単に構築できる基盤ソフトウェア群の総称です。 OpenStackを使えば、アマゾン...

今週のPickUPレポート

新着記事

週間ランキング

CodeIQとは

CodeIQ(コードアイキュー)とは、自分の実力を知りたいITエンジニア向けの、実務スキル評価サービスです。

CodeIQご利用にあたって
関連サイト
codeiq

リクルートグループサイトへ