🧊

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

AbemaTV Developer Conference 2017 - connpass

dotsっていつの間に名前変わってたんや・・!

AbemaTVを支えるGoogle Cloud Platform by Google Platform Japan 福田潔様

はじめに

  • 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キテますなー。

AbemaTV将棋チャンネルの配信技術 〜全国完全生中継への挑戦〜 by 藤崎 智

お台場のテレビ局を経て、個人で局をやったりした経験が

中継技術の進化

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

将棋中継の仕組み

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

想定外実話 Best3

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

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

AbemaTVの画質定義~ラウドネスマネージメント by 御池 崇史

トランスコードエンジニアっていう肩書の人もいるのね!

用語説明

  • 解像度
    • フル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がまた動作不良で鉄板と化してメモがあまり取れず本当に無念・・。

AbemaTV モバイルアプリの開発体制と開発プロセスの話 by 波戸勇二

AbemaTV モバイルアプリの開発体制と開発プロセスの話

iOSアプリ

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

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

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

Beta配信

  • Carshlytics
  • iTunesConnect -> TestFlight

QA効率化

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

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

デザインのBefore & After by 松本 俊介(@ShunsukeM108) & 清水 康秀

AbemaTV デザインのBefore & After

前半はiOS / Androidのデザイナーさん、後半がWebのデザイナーさん。

デザイナー

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

アプリの改善例

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

Web

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

まとめ

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

AbemaTVにおけるモニタリング by Le Van Nghia(@nghialv2607)

アーキテクチャ

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

モニタリングシステム

  • すべてのレイヤーを監視したい
    • 昔はStackDriverで
  • Prometheus + Grafanaでやり替え
  • 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

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

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

Microservices下におけるWebの負荷対策 -SSR×SPA×PWAへ向けて- by 大泉 明日香(@asukaleido)

Microservices下におけるWebの負荷対策 / AbemaTV DEVELOPER CONFERENCE 2017 // Speaker Deck

事の発端

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

それまでの構成

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

なぜ死んだか

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

対策

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

Webでやりたいこと

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

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

AbemaTVを支えるアプリの優しさ by 小形 昌樹

abematv_devcon_2017 // Speaker Deck

優しさとは

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

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

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

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

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

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

MPEG-DASHによるリニア型配信 by みゆっき(@toriimiyukki)

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、やっぱり奥行きが半端ないよなー・・ってか、新卒の発表て!天才かよ・・

AbemaTVの裏側 - 大規模トラフィックを支える技術と負荷対策の話 by 岡田 翔乃介(@rm_rf_slant)

負荷試験

  • Locust と wrk を使ってる
  • Locust
    • https://github.com/locustio/locust
    • Pythonの分散型ユーザー負荷テストツール
    • WebUIからいろいろ見れる
    • スケールできる
    • GKEと相性がいい
    • 綿密なシナリオも定義できる
    • 大規模な試験には向いてる
  • wrk

試験用のデータ

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

その他

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

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

おわりに

お気づきの方もおおいでしょうが、専門外の分野すぎてメモの精度が微妙です。

専門外の分野の勉強会がこんなに消耗するもんだとは思わんかった・・けど、いろいろモチベーションも上がる会だったのでよかった。
やっぱフロントエンド以外のこともやってかないとダメよなー、はてさて・・。