蚊帳の中の日記

ゆるく生きてます

AbemaTVDevelopersConf2018に参加してきた（殴り書き）

勉強会 インフラ diary 開発

追記： 2018/10/24
公式から講演資料の共有がありました

https://developer.abema.io/2018/#timetable

普段から日頃お世話になっている（特にスポーツとアニメ視聴）AbemaTVのインフラ構成とかどうなってるのかな〜って、すごい気になっていて、今回表題のカンファレンスに参加することができたので、ざっとレポートを書き残しておく（完全に自分用。多分、スライド資料とか公式から後日まとめが出そうだし、もっとクオリティ高いのは他の記事とかを参考にしていただければ幸い）

AbemaTVの組織構造と今後の技術課題について

  • アプリダウンロード3000万突破
  • サイバーエージェントの歴史を諸々説明
  • 新卒が20名以上がＡｂｅｍａＴＶで活躍しているらしい。多いな〜。
  • プロジェクト進行はOKRを採用している。最初は色々大変だったけど四半期ごとに改善していってやっと板についてきた感じ
  • また、中長期な品質向上に取り組むように心がけている。
  • S１〜S７までのグレードでエンジニアを評価している。
  • 最近までエクセルで目標設定してたけど、HRBrainっていうクラウド？を導入したらしい。
  • キャリブレーションも実施（.....キャリブレーションって何？笑）
  • 組織構造はプロジェクト横軸、職種縦軸で、縦串構造みたいな感じ。
  • AbemaTVのカルチャーにフィットした人を採用すことを心がけている
  • 褒める文化
  • エンジニア組織は80名程度いる。思ったより多かった。でもこれでもまだ色々人が足りてないんだろうな。Android,Iosが割合の多い、次がWEB、あとは諸々。TechLeaderみたいな立ち位置の方は15名程度いる。
  • 評価指標はNPSって指標を採用している
  • 総務省がだしたインターネットトラヒックを見ると年々爆発的に伸びていて、動画サービスのニーズも高まっている。
  • ５G、携帯料金値下げ、CDNなどの今後の通信インフラの変化にも色々準備や投資を進めているらしい。
    • モバイル回線での動画視聴が増えると睨んでいる
    • スマホ、テレビデバイスの需要が増えることも考えられる。
    • 映像クオリティも上がっていく。そのニーズも上がっている。
    • 既存コンテンツのネット配信も当たり前になってきている。
    • Amazonとかもこのあたりに非常に投資を行っている。
    • 映像配信・圧縮、４K、８Kなどの映像技術も色々見て頑張っている
  • リニア配信？、VOD？
  • 動画技術も色々と技術革新が進んでいるらしい。最後のセッションでどういった動画技術に注目しているのか話してくれるみたい。
  • AndroidTV => IPTV？？？（テレビに関するデバイス開発も考えている）

ここまでは組織の話↑

ここから技術的な話↓

  • アベマはチケット駆動開発で初期開発は4ヶ月程度で爆速開発！すげーーー！！！！！
  • GCPを色々活用してエンジニアは機能開発に注力できた
  • CDNはAkamaiを採用していた。動画最適化に強いらしい。（当時）
  • マルチDRM対応？？？
  • Abemaビデオ。TVとVODの融合、、、よくわからん。
  • 配信の安定化について
    • 亀田の番組障害以降、伝送・配信の安定性と配信システムのアーキテクチャに課題を感じた。
    • 2点の観点で改善
      • Zixi（？）ってサービスを定常運用化（カメラで撮った映像をネットにあげて、初めて色々な処理が走るが、GCPの台湾リージョンを使っていて、物理的な距離とか色々問題があって処理が追いつかないことがあったらしい）
      • Cloud Interconnect導入（確実にCDNに配信する伝送・配信を安定化）
    • システムアーキテクチャの改善について
      • 配信システムが他のシステムと非常に複雑に絡み合っていた。密結合。
      • 映像配信とユーザーが使う機能を分離した。
    • スケールアウト戦略が終焉を迎えた
      • 大規模配信のときはスケールアウトでいいじゃん？って思ってたけど。。。。
      • 次回の大規模配信に向けて、システムのスケールアウト計算をしたら、物理的なリソースとネットワーク的なリソースの限界を超えてしまったらしいwwwwやばいよwwwwそんなことあるんかい？！？！
      • なので、リソースパズルをやってみる（どのリソースを増やして、どのリソースを減らすかを検討する。取捨選択。）
      • 結果、システムキャパシティを5倍に拡大できたらしい。
  • マスメディアの実現に向けて（今後について）

72時間ホンネTVの負荷対策と裏側

  • プロマネを担当した方の発表
  • 亀田の番組で障害が起きたので、次の大規模配信に向けて色々対策を行った。
  • まず、インフラ構成を書き出して、どこに障害が多くて、どこにリスクがあるのか見直す
  • ドッグフーディング？？
  • あとは、負荷対策キックオフのためにログ見たり、メトリクス見たり、色々調査し始める。動画配信の未経験だったのこと。すごい。。。
  • Charlesなどを使ってリクエストを見たりして調査しまくる。すると、サーバーへのリクエスト数に無駄があった。これはうちでもやってみると、学びや発見があって面白いかもと思った。真似してみたい。
  • 具体的な対策
    • できるだけCDNにキャッシュさせる。動画のプレイリスト、ウェブブラウザ用のサイト、APIの一部のコメントとか番組表も。
    • CDNのキャッシュヒット率を向上するようにする？？（リニア？VOD？）
    • 無駄なリクエストを減らす（googleのExoPlayerに不具合がありPRを出したとか）
    • リクエストのポーリング感覚（取得感覚）を調整したりする。（視聴数の数字更新機能とか）
    • またGCPだけでなく、プライベートインフラやAWSなどの別のサーバーに一部の処理を振り分けたりした。分担。
    • 負荷試験・サーバー台数の調整（@rm-rf-slantさんが書いた資料が参考になるらしい）
  • ホンネTVでは、亀田のときより、リクエスト数を１０分の１くらいに減らせた！コスト削減にもなった。その後の大規模配信も特に問題がなかったとのこと。すごい。。。（さっきからすごいしか言ってない。いやほんとに。）
  • 念の為、障害レベルも定義しておいて、どういったときにどういったアクションをするべきなのか？ということを皆で認識を合わせるために整理した（実際は使わなくて事なきだった）。これは真似しても良さそう。
  • 未来の話。インターネットの限界との戦い。インターネットの限界とは。。。。。
    • IPユニキャスト通信？？？
    • 地上波テレビと違って、インターネットは見る人が多ければ多いほど立て込んでくるので、パフォーマンスが悪くなる。
    • ＡｂｅｍａＴＶは12Tbpsの世界。。。通信量やばい。。。Tbpsとか、、、、。
    • 色々未来のために動いてる

AbemaTVのアーキテクチャの変遷

  • インターネットでリニア型？の動画配信開発は経験が浅かった。でも色々創意工夫。
  • なぜGCP？
    • 高機能L7ロードバランサを使える
    • GKE、Kubernectsが使える
    • ネットワーク帯域のコストが安いらしい（ネットワーク帯域増やすのにマシンのレベルもあげないといけないらしいのだが、GCPだとそのへんのコストカットしてくれる？？？GCP使ったことないからよくわからなかった）
    • StackDriverロギング、ビッククエリなどのログ収集などのサービスがある
  • （裏話）GCP台湾リージョンを選んでる
    • 日本と台湾間のインジェクトが不安定らしい
    • あとで日本リージョンもできたけど、移行に人的コストをあてられていないの現実。今も台湾リージョン（これに対する対策は後述）
  • Go言語。DBはMongoDB（GCPのデータストア使いたかったけど、編成ツール？の完成の関連でMongoにしたらしい。よくわかんないけど）、マイクロサービス。
  • （裏話）マイクロサービスの崩壊（ここ聞き逃した）
  • 番組表はスナップショットをGCSに保存している。（編成途中の番組表がユーザーに見えないようにするためらしい）
  • 配信サーバーHLS。なんかトランスコードして、メタデータとかはGCSに保存のみたいな感じっぽい。よくわからん。
  • 生配信は、HLSを配信して、インジェストサーバ（Watchman）を開発？？？わからん。

このあたり、自分がインフラ知識が弱いのもあり、進出単語多くて、動画系の単語も多かったから正直わからんことが多かった（泣）

  • 番組が生番組とか、収録番組とか、色々種類があるので、それによってインフラ構成が少し異なる。HLS（watchman）でトランスコーダされた動画データ（セグメント）？を取ってきて、MongoとGCPに保存して、MediaProxyでクライアントに配信するってことか？？？？
  • HLSが肝っぽいけど、、、うまく理解できなかった。。。
  • 動画セグメントをredisにも保存するように後々なったらしい。
  • Fluentdにログを貯めてたけど、Goだと相性悪かったらしくて、GatewayのあとにCloud pubsubを挟んだらしい。

本開局後に色々改善

  • 配信サーバーから広告サーバーへのレスポンスが詰まっていたので、広告サーバーからのレスポンスをキャッシュ
  • Redisでコメントとかのキャッシュをしてたらしいので、redisクラスターのスケールアウト。でもgem（？）にバグが有ったらしい。つらい。年始にすぐに対応したとのこと。すごい。年始も休まないアベマ。脱帽。
  • 日本と台湾間のインジェストが不安定なのは、伝送プロトコルをUDPベースのZixiで対応したらしい。プロトコル変更ってこと？うーん。わからん。
  • 亀田の障害はmongosのコネクションが詰まってたので、mongoDBを再起動して解決したらしい。また、後日ドメインとか色々分けないでごっちゃでredisとかmongoに保存していたので、色々ドメインごとに分離をした。（配信とそうでない部分で分けた）
  • オリジンの負荷軽減
  • 番組表とかはCloudCDNで、プレイリストはアカマイで、キャッシュも色々分ける。
  • ターゲティング広告はユーザーのセグメントを分けて、CDNから配信している。

AbemaTVのオリジン監視システム「Procyon」

  • プロキヨンって読む
  • 独自の配信監視サーバーをつくっておられる。すごい。。。
  • 作った背景として、配信独自の障害監視が必要だった（サーバーはちゃんとしてるけど、動画が再生されないとか）
  • 動画の配信って大変だな、、、。

Kubernetes Jobによるバッチシステムのリソース最適化

  • AbemaTVのトランスコーダー
  • 動画トランスコードをバッチ処理してる。動画トランスコードは非常に計算量がかかる
  • でも、コンテンツ運用者の都合で、実行時間を短くして、早く配信できるようにすることがたまにあるらしい。大変だ。
  • なので、Fan-Outパターンで並列トランスコードしてくれる。初めて聞いた。
    • キューにタスクが積まれて、複数workerがそれを取り出して、並列トランスコードをしてくれる。
    • Goからキュー（redis）にタスクを入れる。キューの詳細情報はmongoに入れる。workerはkubernetes Nodeを使っている。
    • このworker（kubernetes Node）にもリソースを切り替えられる。しかし、リソースの無駄とかがあったので、それの整理を行ったとのこと。すごすぎ。
  • Priority　Queueパターン
    • Fan outと違うのはキューが複数あるところ。良いところは、タスク割り当てるリソースを更に細かくできる。
    • でも、Fanoutよりしょっと複雑な構成になる。
  • Queuing Chainパターン？？？（聴き逃した）
    • Workflowエンジン？？例:digdag, …etc
  • 上記で色々パターン考えたけど、Kubernetes Jobを採用
    • Jobのリトライ回数を制御できる
    • 並列実行の仕組みもあって、指定すればその数分のポッドができて、並列ジッコしてくれる（ポッドごとに別の動きをすることはできない）。なので、自前でそういうの作った。Job MBR ほにゃららってやつを。すご。完了動機なども
    • また、ジョブの監視の仕組みも自前っぽい
    • kubenetesの公式でも言っているらしく、単一ジョブを複数PODで実行しようとするとちょっと複雑になるらしい。

世界の動画技術動向を見据えたアベマの向かう先

正直、動画技術とか何もわからないから、ポカーン状態だったけど、世界はもっとすごくて、色々な動画技術があるんだな！って小並感満載のかんそうだけど本当にそうおもった。

  • 動画エバンジェリスト！
  • 世界基準の動画技術動向を探しに行って、サービスの問題解決のヒントを探す人的
  • アメリカはコード・カッティングが進んでいる
  • Rokuってストリーミングデバイスもあるらしい
  • スイス政府は地上波放送廃止を決定したらしい。各国も流れに乗っているらしい
  • 動画ビジネスの敷居は結構低くなっているらしい
  • MAM（コンテンツ管理分野？？）
    • メタデータ、コンテンツん紐づけ、ワークフロー、コンテンツ品質などのドメインごとのい管理が対象をわけると要素分解できる。
  • 世界的に海賊行為の拡大がある
    • 一応対策って色々あるらしい
  • DRMは必須
  • watermaking技術ってのが最近の注目らしい。コンテンツの流通経路が検知できるらしい。悪いことできない。
  • 費用対効果の高いコンテンツを作ろうとしてて、なんか良さそうな配信技術使ったり、、、、。なんか色々しようとしている。
  • 高解像度、大規模配信、低遅延、これらをすべてマックスにするのは難しいし、トレードオフの要素である。
  • UHD
  • エンコーディング最適化も色々あるらしくて、netflixがなんかすごいのを2015年に発表して革新的だったらしい。
  • QoE分野

.......あと、わかんない 😇

感想

  • 他社のインフラ構成見ると面白いし、勉強になる。ただインフラ知識が弱いので進出単語多すぎて、わかんないことが多かった。
  • 動画圧縮とか配信とかエンコードとか、その辺の話がぽかーん状態。
  • 聞く限り開発サイクルがどれも早いし、技術的にもハードな内容で、とりあえずスゲーという言葉しか思いつかんかった。
  • 後日の資料配布に期待