秋のカンファレンス参加 第二回目 今回はAbema TV DEVELOPER CONFERENCE 2016に参加してきました
AbemaTV Developer Conference 2016
ずっとRoomAにいました。発表資料とかは上のリンクにあります。
挨拶
abemaTV開発局局長の挨拶があった。
abemaTVの目指したところはインターネットの技術を利用してTVを再現する。
広告モデルはTVと同じことを実現
FRESH クローズド映像配信
ニコ生を意識して作った。
開設・利用費が0円とか高画質とかアーカイブ保存期限なしとか
AbemaTV の動画配信を支えるサーバーサイドシステム
AbemaTVはFireTVなどのデバイスにも対応する予定
TVのような体験とインターネット特有の体験
VODのような配信じゃなく受動型。
動画配信の基礎
1998年頃はUDP上のServer Push Steremingだったけど2006年ごろからHTTPによる動画サービス(Akamai CDN使ったりする)
プログレッシプダウンロード
メディアファイルのうちダウンロードできたところから再生している
ストリーミング
セグメント毎に分割して配信。生放送もできる。(セグメントつくったところから配信できる）
Adaptive Bitrate Streaming
シームレスに画質切り替えできる。
Http Adaptive Streaming
ファイルの集まりとしてHTTPで転送している。
HTTP関連のソリューションが使える
HLS(HTTP Live Streaming) Appleが作成。10分以上だとAppleのガイドライン的に使用が必須
M3U8(プレイリスト)と動画ファイルから(MPEG2-TS)
ストリーミングの裏側ではなにをしているか
入力 -> 映像処理 -> パッケージング -> 配信
AbemaTVの配信システム
入力のレイヤーは複数だけどパッケージング・配信は1つ
録画済み ->ドラマやアニメなど管理画面からストレージに上げておく
生放送->録画したものをlive encoderしてストレージにあげる。
Streaming-server
配信の切り替え・自前開発している。
番組毎にストレージサーバがあり適切なものを配信している。
広告挿入は自前のアドサーバから撮って挿入。
録画は前もって広告を入れておく。生放送はオペレータが入れている。
SEQUENCEの計算
in memoryだけだと同期取りにくいから、DBに書き込んで差分見てる
全体のアーキテクチャ
動画配信以外にも様々なものがある。
GCP上にある。
エンドポイントはGCE上にある。
ユーザからのアクセスを受けるEndpointはgatewayと streming-server
どちらもAkamaiキャッシュしてる。
gatewayは配信以外のサービスのエンドポイント
RPCで呼び出している。
Redis ClusterとかMongoはGCE
GCSにメディアコンテンツをあげてる。
生放送もVODで再生できるので、全部入れている。
AbemaTVの開発スピード
12月から3月の限定版リリースや4月の本開局まで4ヶ月ぐらい
1月はサーバ周り。1月はログがコンテンツ配信の開発。
3月にはAbemaNewsのみで生放送はFRESH経由していた。
できるだけ同じプログラムを使い回せるようにした。
並行して管理システムなども開発していた。
短期間で仕上げられた背景
GCPに助けられたこと
各種機能(loggingやmonitoringなど)
GKEよかった。
Q&A
Q.線形的にデータ増えてくと思うんだけどGCSだと課金額増えない？
A.大丈夫 。どちらかというとコンテンツ支払う方がお金かかってる。
Q.動画の切り替えのタイミングってどれもおなじ？
A.録画と生放送で違う。
Q.生放送で入れるとずれでユーザが意図したタイミングと異なった時間にはいらない？
A. ストリーミング2秒なので、そこまでずれはないというのと、最近慣れで大丈夫になってきた。
Q.RPCの形式は
A. GRPC / GKEがデフォルトでこれなので。
Q. GCPの選択理由
A. GCPの方がコスト安とか、LiveMigrationがされたりとか。
Q.FireBaseの使用理由とか
A.Push通知に使ってる。最初はLocal Pushだったけど。
Q.GCPのリージョン問題
A. 原因がリージョンが原因なのかわからないけど、そこまで問題なかった。
Q.Redis Clusterの罠なかったのか？
A.ちょっとまだ対策できてない。
インターネットにおける動画配信の仕組み
動画コンテントを提供するには
ダウンロード/プログレッシプダウンロード/Streaming/HTTP adaptive Streamingなどある。
幅広いデバイス向けならHTTP Adaptive Streamingが良さそう。CDNが活用できる。
HTTP上のStreamingは様々
HLSはItunesの審査で必須。 HDS:Adobe Smooth Streaming:MS MPEG-DASH: ISO/IEC 23009 多機能だがプレイヤーが対応してない。
配信形態
Linear TV
Linear TVでは映像ソースとアウトプットが多:1になる。
多:1で番組の移り変わりを実現するのに内製システムで実現している。
NewsだけAPCつかってる。
セグメントをどう作るか。
録画コンテンツ
納品データ -> 管理システム -> Job Queue -> Worker 配信可能形態
生放送
Encoder/Packagerを通してPollerでストリーミングに吐き出す。
APC使っている関係上別のメーカのEncoder/Packagerを使っている。
録画コンテンツ
フラグメンテーションはしてある1ファイル。
分割位置情報を持っているファイルも持っておく。
生放送もGCSにセグメント毎に格納しておく。
セグメント情報はMongoにいれてある。
Adaptive Bitrate Streaming
最初は低画質のものから再生して、どんどん画質良くしていってる。
サーバではビットレート毎にファイルを作成する必要がある。
壊れている場合は、自動検知できたら下の解像度からコピーしている。
やんちゃな HTTP Live Streaming (h264/aac) トラブルシューティング集
FRESH By Abema TV
DockerでAWS上に乗ってる。
なぜHLSを使うのか
部分ダウンロード即再生とCDNでキャッシュできる。
FRESHは全動画HLSで出力
こっちはS3に上げてる。
トラブル集
画質が悪い
配信元の解像度設定。
キャプチャツールの解像度が低い。
マニュアル化してる。
配信元のPC負荷
解像度設定が大きすぎる。
大きい解像度 -> 小さい解像度の変換が重い
Wowzaの負荷
切り分けが難しい。 HLS変換がかからないアーカイブデータ用意してそれで荒れてたら配信元原因。
みたいに切り分けた。
Wowzaの画質設定
ブロックノイズが出る。
帯域 / (解像度 *fps)が重要で Bits Per Pixel(BPP)のチューニングが必要
トライアンドエラー
画質戦略
2Passエンコードができない。
ジャンルがいろいろあってつらい
動きのある映像でも耐えられる設定をベースにしている。
ただ、TODOとしてジャンルによって変えて生きたい。
スマホ視聴がメインターゲット
メインユーザ層の使用帯域が限られているのがつらい。
結果
BPPは30fpsで0.15
圧縮効率のため解像度は16の倍数中心
1024*576 2655kbps
1時間で1Gぐらい。
遅延する
HLSは遅い
RTMP配信などに比べ遅延する。
TSファイルの長さを短くして改善
Apple推奨は10秒だけどFRESHでは2秒。
配信ツールでもKeyFrameIntervalをTSファイルより短くしてる。
遅延10秒ぐらいに抑えてる
アーカイブまだ？
WowzaはMP4で出力
配信終了したらMP4を結合して外部トランスコーダでHLS化してる。
時間かかる。
TSファイルを使いまわして、アーカイブ用のPlaylistファイルを錬成している。
アーカイブ再生できない
"#EXT-X-DISCONTINUITY"
ストリームの不連続をPlayerに伝えるタグ
つぎはぎするなら必須
問い合わせベースで修正してる
AES暗号化時のキー指定ミス。
Wozar落ちたらどうするの？
Playerの対応にばらつきでできない（まあ、最悪PR送ればいい)
配信トラブル要因になりがち
配信元の帯域を圧迫する。
安定した配信のためには
HLS芸の取得
Playlistはただのテキストファイルなので、手動でPlaylistをかけるように
配信主サポート
Slasskやメールベースでの密なコミュニケーション。
ログや設定ファイルをもらったり。
身内の配信に乗り込んで検証
Slaask Web面でのチャットとSlackを繋いでくれるツール
FFmpeg 動画・音声の編集ツール。
クラウドの違いは？
FRESHの方が先に開発始まってAWSを使った。
GKE@AbemaTV
GKE is
Kubernetesのフルマネージドサービス。 KubernetesのKをとってる。
Kubernetes(クーバネイティス)
Dockerのオーケストレーションツール
Kubernetesの構成
Minionノード コンテナが起動するノード Pod:コンテナのグループ RC : 起動するpod数や環境変数を管理(Deployments）に置き換わっていく。
Service: Pod群のエンドポイント Yamlのマニフェストファイルで管理
GKE@AbemaTV
Varnish/Nginx コンテナとして起動
選んだ理由
GKEがGAに
k8sがフルマネージドで使える。
microservicesとの親和性
設計
SPEC n1-highcpu-16 x 50ode 16vCPUs 14.4GB memory 33Services 216Pod default requests & limits cpu:400m,
Requests : podが起動に必要なリソース
Limits : 稼働でのリソース
Requests と Limitsに開きがあるとリソースが固結
kubectl describe node [node]でリソースの何%まで割り当てられているか確認出来る。
1Clustsr N Services
追加機能でインフラの準備不要
運用コスト低減
Service同士はlocalhostで接続
デメリットとしてはリソース消費の見極めが複雑になったりとかレプリカ数が少ないpodはタイミングによって同じノードに起動してしまうことがある。
Docker Image
Alpine Linux
リリースフロー
アプリケーションの場合 github -> circle ci でGCRにdocker pushする。
インフラ系は直接PUSHしている。
手元の開発環境からデプロイしている。
kubectk create -f xxx.yaml kubectl apply -f xxx.yml Roling-update kubectl rollig-update xxx -f xxx.yml kubectl scale rc xxx —replicas=10
kubectl rolling-updateの課題
v.120以降同じタグでRolling-updateができない。
Selectorが中途半端に残る
kubetool
kubectlをラップした補助ツール
良さそう。
監視
標準で取れるのはリソース状況
Podの標準はLoggingへ
kube-ui
運用時
Terafformとの別離
TerafformでInstance Templateを編集するとインスタンスが全台作成される。
無停止でスケールアップダウンする場合はテンプレートを手動で付け替える必要がある。
コード化できてない。
ServiceのIPに接続できない。
HTTP Load Balancerから繋がるけど、Podから接続できない。 v1.2.0
Nodeアップグレード時に断発生
1台ずつアップグレードされるが、Podが先に落ちないいので数秒断される。
まとめ
デプロイ簡単。
Q&A
Q. Alpine Linux不安定感ない？
A. 特になかった。
- GO使うならば App Engineって選択肢もあったとおもうけど
いろいろあったので続きは懇親会で。
Dockerfile Imageの運用方法は？
- Git Hubに上げてる。 開発/インフラどちらでも触ってる
AbemaTVの開発スタイル
アジャイルサムライにあるインセプションデッキを一通り話し合い。
スプリントはタイムボックス2週間で
計画ミーティングを実施してタスクの優先順位とか見積もりしてた。
Codecov /PRのカバレッジどうか
asana(ガントチャート)とか使ってる。
ベースをプロジェクトに適応する。
組織やルール・文化をみて適応する必要ある。
FRESH
開発:20人 開発以外10人前後
AbemaTV
開発30人 開発以外~100人
スクラムチームは多くても10-15人が限界で分解が必要。
FRESHの場合役割で分割した。
server/fromt/design/iOS/Android
各リーダとDir、責任者のまとめをboardとしてポートフォリオバックログを管理した。
Abema TVも役割で分割したけどプロジェクトを作って、横の連携をした。
FRESH縦から横事件
機能をリリーススコープから外して縦対応に注力。
デザインスプリントを行ってゴールの認識統一した。 (半日アプリ/デザインで認識合わせした)
チームの考えに適応する
課題から開発者で使用を落としこむか、 ディレクタープランナーが落としこんでから開発着手するか。
開発者目線で、KPIを単純にあげるのは難しい。
そこはPlanerの協力を得た。
人に適応する
チームメンバーに合わせるのはコストがかかる。
AbemaTVのグレード制度の意味づけをした。
自走できるエンジニア
S3.5
実現したいことに対して仕事詰めやスケジュール調整も含めて持ってける
自走できるならならば権限を持てる。
Slack依頼して、自走できれば チケットとかいらない。
自走できるエンジニアは、勝手に課題を見つけて対応できる。
管理しすぎると個人のパフォーマンスを出し切れない可能性があるときがある。
AbemaTVの文化
自走できる人たちを集めている。
管理できる人は最低限なので、リモートもできるようにしている。
各個人の最大化とマネジメントコストの削減をセットで進めていく。
デメリット
属人化する。属人化から走ってチームに共有する体制
炎上プロジェクトの立て直しの風景
炎上事例
権力者の介入
普段は仕様の決定とかがプロデュースがやっていて情報が一元化されているから問題ないけど
チーフプロデューサがIOSエンジニアに直接依頼して仕様のズレがあった。
仕様はチーフPの間
すべての修正依頼はPを通すように。
チーフプロデューサとエンジニアが直接対話する機会を設けた。
Pとチーフプロデューサとエンジニアが同席して仕様変更の決定を行えるようにした。
介入ができる場を限定した。
意思決定、情報の集約は一元化しよう。
権力者とはうまくつきあおう
要件進化
クライアントの思いつきで見積もりからずれていた。
プロジェクトゴールの再設定とやらないことの停止/第二期開発への引き継ぎ
目的が変わるようであれば仕切り直し or 別プロジェクトとしてスコープを明確にする。
ゴールが設定されている場合ゴールが最適か確認をする。
炎上しているときほど線引きを明確にする。
最悪な状態は
ゴールがブレる。終わりが見えない
チームワークが崩壊
まとめ
かなりいい感じのカンファレンスでした。配信もあったみたいですし、無限コーヒーあったり、スライドの公開が早かったりと。
abemaTVとしては初めてのカンファレンスで、不手際あるかも見たいなことを言っていましたが、そういうこともなかったです。
(一部スライドが切れてスライド調整するのに時間かかったりマイクが若干混戦したり、無限コーヒーが無限コーヒーじゃなくなった。（参加者が本気出しすぎて無くなり途中で補充入った））
無線LANも快適でカンファレンスとしてはかなりクオリティが高く発表の内容も素晴らしかったです。
