AbemaTV Developer Conference 2017
去年に引き続いて
Abema TV DEVELOPER CONFERENCEにいってきた。
今回の会場はTECH PLAY. dotsがTECH PLAYに変わってからははじめていったかも。
スライドとかはGoogleの福田さん以外のは順次公開されるはず...
AbemaTVを支えるGoogle Cloud Platform
福田潔さん (Googleの方)
- CDNはAamai(キャッシュできるコンテンツ)
- GCPではGLBで受けてバックエンドに流す。
- マイクロサービスとしてGKEを使ってる。
- GAEとGKEの違い
- GKEはkubernetesのマネジメントサービス
- GAEは制約が強いが動作環境自体のマネジメントはない。
- Kubernetesはデファクトスタンダードになった。
- Dockerもついにkubernetesをネイティブ Sawrmの併用も可能に
- SREはソフトウェアエンジニアとしての力も持っているし、運用もできるというのがGoogleのSRE
- GKE
- ノードアップグレード
- kubernetesのバージョン
- nodeOS
- Backendはマネジメント使えば
- GLB
- BackeEndで振り分けられる
- グローバル負荷分散
- 自分の近いところにアクセスが行く。
- Cloud LB / CDN
まとめ
福田さん自体は結構いろんなカンファレンスで話聞くことがあって、GCP周りの話に関しては結構調べれば出てきそうな感じかな。 あとAbemaTVの事例は Google Cloud Nextでもあったのでそっちの動画はみないとなーと。
#abematv_dev Google Cloud NextのAbemaTVの発表動画はこれかな https://t.co/N6fhjaHIIS
— y.takky (@y_takky2014) 2017年10月21日
(たしかこれ会場にいってたのに障害対応してた気がする..)
AbemaTV将棋チャンネルの配信技術 〜全国完全生中継への挑戦〜
藤崎さん
既存の中継
FPU(マイクロ波) で送信
- 専用線で秘匿性高いが免許必要だし高い。
- アンテナ合わせ...
衛生
- 遅延が多い。専用線だけど
- 天候に左右される
SKYPE
- 簡単で画質そこそこだけど不安定でPCベース
SkypeTx
- 放送用Skype , 画質Max720p 遅延が少ないが相手先のネットワークに左右される
LiveU
実際の将棋中継
- 2ヶ月前から設定する。
- 電気食うから発電機必要
- リピータも借りている
まとめ
- 放送1日でも実際は3-4日
- 平均2時間のカメラ調整
AbemaTVの画質定義～ラウドネスマネージメント（録画放送）
- 配信レゾリューション (配信サイズ) は多々。近々情報量節約モードが出る
技術用語
- CODEC
- 圧縮 , 符号化 / 復号化
- container / 拡張子
- TRASCODE
- 頂いたデータを配信用データに変換する
- 容量負荷の軽減と品質担保を保つ
中間ファイル作成
- DDP (ウォッチフォルダー運用)
配信トランスコード
- 速度と品質はトレードオフ。ユーザーファストで
ラウドネスマネジメント
- CMと本編の音量差を解消するために策定された。
- AbemaTVではこれを独自にモディファイ / 音量大きめで出力している
- 国際的議論があったり最適化をプロ(テレ朝）と話してる
- 将棋や麻雀のように喋っている部分が短いところは難しい。基準を変えて測定する
AbemaTV モバイルアプリの開発体制と開発プロセスの話
開発体制
- 開発局50人
- チームは別れている
- ビデオ/グロース/本質改善/テレビデバイスの4つに分けている。
repositories
-ios - tvos -api -protobuf-swift -script -その他 7~8 PR / 営業日
開発フロー
- スクラム開発
- 2週間スプリント
- 2wで修正
- 開発を2週間, QAを1週間でやってたけど、開発とQAの重複がつらい
- 開発1w,QA 1wにしてる。
タスク
- プロデューサー / プランナーが立案
実現されるための機能を上げる
エンジニアがコード品質やパフォーマンス化タスク化。
タスクの見積もり
- ストーリポイントは1人1人の
タスクの優先度
- ↑SAB/↓CD
- ↑ スプリント機関に開発完了 / テスト / リリース必須 定常リリース日に間に合わなければ遅らせる判断
- ↓ 後回しでもoK
会議体
- スプリント計画
- スプリントレビュー
- 案件会議
ツール
- Slack
- Jira
- Confluence
- esa
- Gtihub
- Bitrise
- Jenkins
- cmdshelf
開発スタイル
- CONTRIBUTING.md
- 3人以上からOK
- 軽微なら2人とか
- テストは極力書く
- UI周りは設計でカバーして、テストは書かない方針
ブランチ戦略
- 基本はGithub Flow
- 開発用のmasterとqa branch
Beta配信
Slack通知
- K.I.T.T -レビューがされていないPRを流す
QA効率化
- デバッグメニューを用意してあげている。
- アクティビティモニタ
- 通知周りエミューレート
デザインのBefore & After
- アプリ内通知バー
- AndroidのSnack Barと同じデザインにしたい
- 指が届かない
モーダル
- フルスクリーンのモーダルは避けられる傾向がある
- 指がと説かない
- AndoidのBottom Sheetと同じUX
ビデオページ
- サムネイルのパワーが弱いので文字で訴求したい
- 情報量のバランスを取るため
アプリアイコン
Web(モバイル)
AbemaTVにおけるモニタリング
- LE VAN NGHIA(ギアさん)
サービスから見る
- K8s Statelessなマイクロサービス -GCE Node (Stateful)
- その他GCPサービス
モニタリングサービス
- StackDriverのみ
- マシンメトリクス(CPU/Memory/Network)
全てのレイヤを監視したい
Prometheus + Grafana
- Kuebernetesと親和性が高い
- 性能が良い
Prometheusの導入
- クラスタ内に1つのPrometheus
- Grafana側で複雑なQueryを書くと待ち時間が長い
- PrometheusでRecording Rulesを追加して良くなった
- ただ問題と課題が上がってきた
時系列データの増加
- モニタリングターゲットの増加
- 新しいメトリクスが増えた
Node-exporter
- CPU / Memory ./ Disk / Network
- DaemonSetとして書くnodeに1つのpod
- GCEの場合Packer
k8sのメトリクス
- kube-dnsなど
CCUメトリクス
- 同時接続数にメトリクス
- アクセスログからリアルタイム計算
- HyperLogLogアルゴリズム
-Horizontal Pod Autoscalerで自動スケーリング
Prometheus sharding
- メトリクス首里でPrometheusを分ける
HA Prometheus
- 同じconfig / 同じターゲットリストで複数Prometheusを構築
- データの差分の吸収
Prometheus Operatorを導入した
- configの代わりに server-monitorを記述した
- ほっとリロード Sidecarコンテナでconfig/dashboard監視
問題
- k8sの必要なyamlファイルの重複
- DRY などに対応するのにHelmを導入した
Helm
- kubernetes package manager
- Helm Chartを作成してvalueに差分だけ与えればOkになった。
- Prometheusを使った分散トレーシングにPromvizを作った。
Microservices下におけるWebの負荷対策
- GLBで受けてGKEにmicroservicesが載っているという他と同じ構成
- Backend health / Timeout : 10s Internal 15s
- Nginxがassets系の配信をしている
- htmlのmeta情報はgrpc通してbackendから返している、
最初のランディングはabema.tv別ドメイン - フロントエンドエンジニアはUI/UXに専念したい。 APIGatewayは別ドメイン
障害原因
ケース1
ケース2
- Node.jsにはタイムアウトの実装がなかった
- GLBがtimeoutすると503帰ってくる
ケース3
- API Requestが通らない
- いわゆるnginxが詰まった。
対応策
CDNを通すようにする
- パフォーマンスと可用性
- 欠点は細かい振り分けができない
制約も多いがパフォーマンスにおける利点が多いが何より可用性が維持できる
新しい構成
- CloudCDNを頭につける
- UAごとの出し分けはやめる。
Webのパフォーマンス
- Service Worker有効時の First Meaningful Paintが遅い
対応策
- Server Side Rendering
- JSファイルの分割と動的インポート
まとめ
- 運用においての負荷対策は登竜門的なようなもの
AbemaTVを支えるアプリの優しさ
- バッテリーを使わないとかネットワークをあまり食わないとかはアプリとして大事
- システム的に見てもネットワーク帯域を使わない。というのも大事
現状の問題
- HLS(HTTP Live Streaming)
- playlistとりすぎ問題があった。
- 通常はMEDIA-SEQUENCEをインクリメントして次の.tsを取りに行く
- Playerのバグの問題(PR送った)
画面に最適なビットレート制御
- Andorid 7.0からは複数画面視聴もできるようになった。
- 端末や画面幅で切り替えた。
MPEG-DASHによるリニア型配信
- TECH PLAY TECH CONFERENCE 2017 の記事見るといい
HLSとは
MPEG-DASHとは
Dynamic Adaptive Streaming over HTTP - ISO/IECが企画したHTTPストリーミングを行う規格 - 各ベンダー(apple,adobeのHDSなど)が作った規格の統一のため
MPDとは
Media Presentation Description - メディア記述のXMLファイル
プロファイルが何故必要化
- 対応しているメディア形式を決めておいてプレイヤーがサポートする規格を制限できる
M4Sとは
- フラグメント(セグメント)化されたMP4ファイルのこと
AbemaTVのリニア配信
- リニア配信とは
- 予め番組表に従って行う配信
- 番組表に従って録画,生放送,CM,フィラーを配信する
なぜMPEG-DASH対応するか
配信品質の監視
- マスタールームで監視しているけど24h監視は辛い
- HTTPステータスコード監視入れるけどストリーミング監視には役立たない
監視ツールをつくった
- Procyon ー社内OSS的な
AbemaTVの裏側 - 大規模トラフィックを支える技術と負荷対策の話
負荷試験
- Locust & wrk
Locust
- Python製の分散型ユーザ負荷テストツール
- abemaTVでは GKE上で大量のdestibuted mode workerを配置してシナリオファイルを回して、high-throughputを実現している。
- machine Type n1-high-cpu-16, Node 104*3 , pod 5000
- Total 9984 Core
- GKE x Locustの相性が良い
- WebUIから各pathのreq/secやexptionを観測できる
- 自由度が高いゆえに秘伝のたれ化
- 9984コア要らない説
- 負荷試験環境の実行やレポートの週家まではChatOps化
- boomerを使用したシナリオreplace
- 1つのendpointに対しての限界性能試験ではちょっと...
wrk
- Lua製のHTTPベンチマークツール
- 単一のマルチコアCPU上で実行すると大規模な負荷与えられる
- レポート出力はカスタムできる
- Luaなので高速かつパワーも十分
- ちょっとしたシナリオも記述可能
- latencyのpercentile表示
- threadとconnectionのバランス表示
- レポートの集計には弱い
Bihind-thesceenes story
MongoDB
- MongoDB Cloud Manager
- Restore
- Cloud Managerのsnap shotを取るようにした
- 実行時間が1/2に
- Restore時はwrite防止の為mongoを止めるのでオンラインでは使用できない
Cloud Bigtable
Backup
Metrics
