AbemaTV Developer Conference 2017 に行ってきたメモ #abematv_dev

はじめに

• GCPとかG SuiteとかあわせてGoogle Cloudっていってる
• それを日本で広めるための会社です
• AbematTVで使ってる概要を紹介
• GCPはこの5年間でサービスも増えた

AbemaTV on GCP

• クライアント <-> Akamai <-> GCP
• GCPの領域では最初にGCLBがいる
• 中はコンテナ、GKE上で動かしてる
  • App Engine
  • Container Engine(GKE) <- コレ
  • Compute Engine

GKE

• Google Kubernetes Engine
  • Dockerもk8sをネイティブサポート
  • 各種クラウドベンダーもだいたいk8sをサポート
  • コンテナやるならk8sな時代
• Google is your SRE
  • Site Reliability Engineer
  • コードも書けるし運用もできるエンジニア
• k8sのノードのアップデートとかも面倒みてくれる
• Kubernetes: Running MongoDB on Kubernetes with StatefulSets
  • 当時はk8s上では永続化層は設けないのがベストプラクティスだった
• k8sやるならGKEがオススメ
  • 歴史もあるし、なによりGoogleだし

GCLB

• 物理的に最も近いリージョンに振り分ける
• バックエンドに障害があっても、また違う最寄りのリージョンに振り分けてくれる
• Cloud CDNも、チェックボックスひとつで利用可能
• 世界中に存在するPOPや、ネットワーク（物理含め）があるからこそ成せる

FirestoreといいGCPキテますなー。

中継技術の進化

• FPU（マイクロ波）
  • 中継基地にいったん送って、それからスタジオへ
  • 1つの映像しか送れない
  • 現場から中継基地が見えるか（電波届くか）が問題
  • しかし費用が高い
• 衛生
  • 電波はどこでも使える
  • 遅延する
  • 天候に弱い
  • めっちゃ費用高い
  • ナミブ砂漠からの6分の中継に5000万
• これらは使えない・・・
• Skype
  • 不安定
  • PCベース
• SkypeTX
  • 720Pまで配信できる
  • 低遅延
  • やや不安定
• LiveU
  • ホーム
  • 各種通信キャリアを束ねて利用(SIMが刺さってるだけｗ)
  • 1本1通信じゃなくて、分散させて飛ばす
  • 圏外はどうしようもない
  • パケロス

将棋中継の仕組み

• 2ヶ月前から下見
• 1ヶ月前に回線工事
• 発電機の手配とかも
• キャリアの基地局の場所を把握
• 前々日に撮影機材の櫓をたて・・
• そこから本部まで150m回線を伸ばしたことも・・
• 1日の放送のためにこれだけ

想定外実話 Best3

• 3位: インターネットが黒電話だった
  • 150年の歴史がある旅館でございます
• 2位: 8階までクレーンであげる
  • 末端が隣の建物の地下、試合するのは別館の8F
• 1位: 国宝
  • 工事できません
  • ネットもつながりません！

めっちゃおもしろかった・・すごい話やった・・。

用語説明

• 解像度
  • フルHD: 1920x1080
  • 720P: 1280x720
  • 854x480
  • 640x360
  • 426x240
• CODEC
  • 映像・音声を圧縮
  • COder / DECorder
• コンテナ・拡張子

入稿素材

• h264がメジャー
• PRORES422
• mxfコンテナ

トランスコード

• DynamiDrivePoolに素材を
• メタデータを付与してトランスコーダーへ
• そこでHLSやDASHに
• 解像度を個別に出したりHDRとか
• 2回トランスコードする
• 中間ファイルはh264 10mbps フルhd

品質評価

• Quales / Vantageという品質評価のソフトを使ってる
• SSIMとPSNRという指標を見たり
• ビットレートを削った上で、主観でのチェックもしている
• Server Side Ad Insertionがキモ

ラウドネス

• 音量管理ルール
• 番組とcmの音量差とか
• チャンネル間の音量バランス
• エピソードごとにも
• 制作年代にもよるので注意して調整
• 劇場版は特に注意（ダイナミックレンジを潰さないように）

すっっっごい興味ある内容やったのに、Macbookがまた動作不良で鉄板と化してメモがあまり取れず本当に無念・・。

iOSアプリ

• チーム全体は50人くらい
• その中でiOSチームは10人
• iOSは1ヶ月で162PRがマージされてる
  • 8PR/dayくらいマージされてる
• tvOSはその半分くらい
• apiはそんなに多くない
• 頻繁にPRがマージされる環境

開発体制とかプロセスとか

• 開発とQAが並走すると辛いので、1週間ごとに繰り返すように（あわせて2週間のスプリント）
• スプリントにしてはざっくりしたポイントで
  • 0.5, 1, 2 みたいな
• 5段階の優先度
• 使ってるツールは一般的
  • https://github.com/toshi0383/cmdshelf
  • バイナリコマンドをまとめられる内製ツール
• PRのマージルールとかも決まってる
• レビュー文化も活発
• コーディング規約もある
• テストは2000くらい
  • モデルとかロジックまわりのみ
• 週一で定例
• GitのブランチはGitHubFlow
• Bot通知とかも活用
  • 毎日同じ文言で遅刻連絡を自動化してる人がいる説

Beta配信

• Carshlytics
• iTunesConnect -> TestFlight

QA効率化

• ローカル通知のシミュレート
• ユーザー設定、キャッシュなどの削除
• UIアニメの調整
• 映像情報をオーバーレイしたり

事業スピードも品質も落とさず継続開発するって大変やと思うので、すごいなという。

デザイナー

• チーム全体でデザイナーは4人
• 3つのラインでデザイン改善
  • グロースライン
  • ビデオライン
  • UX改善ライン

アプリの改善例

• ボタンが増えるのを見越して情報整理
• AndroidにあるSnackBarをiOSでも
  • 端末が大きくなって指が上部に届かない
• フルスクリーンのモーダルを避ける
• マテリアルデザインのシステムとしての優秀さ
• Netflixのようにサムネ重視から、テキストベースに
  • ハリウッド映画に比べるとサムネの訴求力は弱い
• アプリのアイコン
  • AndroidのAdaptive Iconに対応

Web

• AbemaTVはモバイルWebで見れない
• アプリへの導線
• 番組紹介のLPの改善
  • 番組紹介であることを第一に
  • アプリ版とUIに遜色ないように
• Twitter流入からのDL率改善
  • 改善前は、パーマネントなリンクではなかった
  • 改善後は、放送後でも見れるページにした
• 全体でDL率が200％改善

まとめ

• UI変更に抵抗はない
• ユーザーもUI変更に追従する
• 改悪も確かにあるが、変化を恐れるほうが悪

アーキテクチャ

• GCP + k8sで動くMicroServices（gRPCでやり取り）
• StatefullなのはRedis / Mongo

モニタリングシステム

• すべてのレイヤーを監視したい
  • 昔はStackDriverで
• Prometheus + Grafanaでやり替え
  • AbemaTVにPrometheusというモニタリングシステムを導入した話
• Prometheus
  • k8sと親和性が高い
  • パフォーマンスよし = 10000target/1instance
  • クラスタ内に1つ
• Grafanaで複雑なクエリを書くと遅い
• 取りたいメトリクスが増えた
  • Nodeメトリクス
  • k8sのメトリクス
  • CCUメトリクス（同時接続数）
• 1つのPrometheusでは厳しくなってきた
  • メトリクスの種類で分ける
  • ターゲットで分ける
• HA Prometheus
  • メトリクスからMicroServicesを自動でスケーリングしたい
• Config書く運用が大変
• 設定かえたら再起動
• Prometheus Operator
  • Configの自動生成（代わりにservice-monitorを記述）
  • ホットリロード
• AlertManager
  • NodeのHighCPUUsageなどがあるとSlackに通知
• 割といい感じにモニタリングできてきた
• が、まだ問題はいろいろある
  • k8sのyaml重複
  • applyする順番
• Helm
  • https://github.com/kubernetes/helm
  • ロールバックとかも安心

トラフィックのリアルタイム可視化

• Prometheusのデータを可視化したい
• Promviz
  • https://github.com/nghialv/promviz
  • https://github.com/mjhd-devlion/promviz-front
• さっきOSSにしました <- ！！

ものすごい知見大放出な感じはわかったけど、ほとんど理解できなかった・・。にしても優秀さがにじみ出てた・・。

事の発端

• 亀田興毅の番組でWebが死
  • 復帰も遅かった
• 藤井4段のときも死
  • アプリが5分くらいで復活する中・・

それまでの構成

• Nginx x Node.js
  • Nginxはアセット、HTML
  • Nodeは他サービスからgRPCでタイトルなどの情報をもらって返す
• WebはSPAなので後はAPIを叩くだけ
• しかし死

なぜ死んだか

• SPAの初期表示に必要なAPIが返ってこないと、ずっと真っ白
• NodeでgRPCを叩いてるがタイムアウト機構がない（ずっとPromiseを待つ）
• Nginxが詰まる

対策

• エラー処理
• gRPCコールのタイムアウト
• サーバーに頼らずスケーリングしたい
  • CDN
  • 制約もあるがコスパはいい選択肢
• まだ導入できておらず、CDNはこれから
• SSRとかもしたいしBFF整備とかも・・

Webでやりたいこと

• 負荷対策 = パフォーマンス向上
• 他のCAサービスに比べると劇的に遅い
• SSR、js分割など
• パフォーマンス改善に命を燃やす！

なんかもうフロントエンドだけで完結できる話ではないし、やっぱ広い目で見ないといかんなーという気持ち。

優しさとは

• ユーザーへの優しさ
  • ネットワーク帯域
  • バッテリー消費
  • 親切なアニメーション
• 通信料をおさえること

プレイリスト取得しすぎ問題

• HLSのプレイリスト
  • Liveの場合、再取得の時にEXT-X-MEDIA-SEQUENCEが増える
• Adaptiveなのでマスターのプレイリストもある
• 各セグメントは2秒なのに、Androidは0.6秒間隔で取ってた
  • Androidで使ってるExoPlayerのバグだった
  • https://github.com/google/ExoPlayer

画面に最適なビットレートとは

• 横画面だけでなく縦画面にも対応
• Androidではマルチウィンドウにも対応
• ただフルHDの動画があっても、端末側が720Pなら無駄になる
• 回線だけでなく、OSや画面幅によっても最適なビットレートを
  • 古いAndroidは回線がよくても動画のデコードが弱かったりするし
  • maxBitrateとして持っておいて、ExoPlayerに伝える

こういうサービス作るならこれくらいやってて欲しいよね・・ってのをちゃんとやってて優しみ・・。

MPEG-DASHの基礎

• HLS
  • Apple産のHTTPベースのストリーミング方式
  • Adobe産のRTMPとかの対抗馬として登場
  • マスタープレイリストとメディアプレイリスト（`.m3u8`）
• DynamicAdaptiveStreaming over Http
  • 各種規格があって大変、統一しよう！
  • 統一するはいいがカバー範囲が広範囲
  • ABRだけでなくマルチストリーム、字幕、広告、DRM、etc...

MPDファイル解説

• `.mpd`のXMLファイル
• MPD
  • type: dynamic | static
  • minBufferTime
  • ISO Base media Profile
    • プロファイルにより、機能の実装を制限できる
• Period
  • 番組の枠
  • 本編、CMとか
• AdaptionSet
  • コンテンツの種類（映像・音声）
  • `mimeType`とか
• Segment
  • SegmentTemplate とかでも書ける
  • セグメントへのパス
  • SegmentTimeline
  • `timescale`で割って算出される
• Representation
  • `id`が画質レベル
  • さっきのTemplateにハマる変数
  • 帯域、コーデックの指定
  • 解像度別に
• M4S
  • `fmp4`
• HLSに比べると実装がすごく面倒くさい

リニア型配信

• 番組表に基づいて配信すること
• DRMに対応した配信が必要だった
  • しかもデバイスによって異なる
  • Apple / Google / Microsoft
  • HLSとDASHをどちら使うことで、全てのパターンをカバー
• fMP4とmpdを別軸で作ってる
  • 放送枠の時間が変わるから
  • 生放送の場合、TSからmp4にしてそこから動的にM4S

配信品質管理について

• HTTPのステータスコードだけ見てても、ストリーミング監視としては役立たない
• 全チャンネルのHLSプレイリスト、DASHマニフェストを取得して監視するツールを作った

DASH、やっぱり奥行きが半端ないよなー・・ってか、新卒の発表て！天才かよ・・

負荷試験

• Locust と wrk を使ってる
• Locust
  • https://github.com/locustio/locust
  • Pythonの分散型ユーザー負荷テストツール
  • WebUIからいろいろ見れる
  • スケールできる
  • GKEと相性がいい
  • 綿密なシナリオも定義できる
  • 大規模な試験には向いてる
• wrk
  • https://github.com/wg/wrk
  • LuaのHTTPベンチマークツール
  • パラメータとURL指定するだけ
  • レポートの集計まわりは自作が必要になる

試験用のデータ

• MongoDB Cloud Manager
  • 元 MongoDB Management Service
  • Snapshot
• Cloud Bigtable
  • Cloud DataflowからHadoopのシーケンスとしてエクスポートするしかない

その他

• AbemaBot
  • 負荷試験環境もコスト
  • 本番と同じ構成で試験する
  • なので使用する時しか使わないようにしたい
  • 定時に起動し忘れのLoad環境があればBotが通知
• Cloud CDN
  • これから

8割くらい理解できなかった・・けどきっとこれも知見大放出やったはず・・。