だいたい一ヶ月前だけど AbemaTV Developer CONFERENCE 2018にいってきた。

これも2016-2017と連続で参加していた。

今回の開場は渋谷に新しくできた渋谷ストリームグーグルの日本法人も六本木からここへ移転するみたい。

グーグルも入るんだっけ　たしか。
ホール自体は割と小さめで GCP NEXTの開場がここになることはなさそう
— y.takky (@y_takky2014) 2018年10月13日

あとはメモなので

【Keynote】 AbemaTVのエンジニア組織論と今後の技術的戦略

MAUがだいたい1,100万ぐらい
中途採用が2006, 新卒採用開始が2008年ぐらいから
エンジニア組織的には1000人ぐらい

求められる３つの開発力

product
quality : ザッピング時のUXのクオリティー
technology : テクノロジードリブンで開発していく

組織論について

施策自体は当たり前のものだけど組織のカルチャーや時流によって入れていくことが大事
全体のKRから分解していってOKRを導入した。
横軸でTechTeamをおいている
グレード制上位のエンジニアが評価する
目標設定: HRBrainを導入。目標のオープン化
同じグレードで目線合わせ、上位グレードへの目線上げ
キャリブレーション : 評価のすり合わせ
成長機会 : input/outputの後押しをしている
Management -- 組織成果を最大化する -- TechLead15人に対してエンジニア51人。 TechLead育成を勧めている
チーム全員でひねり出して案を出す

デバイス戦略

スマホからタブレットやPC / AndoirdTVが増えている。いわゆるWebベースのIPTVなども。

技術的戦略

AbemaTVの初期開発はだいたい4ヶ月ぐらい
チケット駆動開発で職種でトピックを分離、優先度定義されたチケットが降りてきてやれるだけやる
スタンドプレイの最大化になっている
GCPを有効活用した。ロギング,LB,コンテナマネジメント
機能開発にフルコミットするように
CDNはAkamai 動画配信に最適化
配信構成の見直しをしなくちゃなーと思うように(亀田興毅事件)
Encoder->配信システムの遅延やパケットロス zixiを定常運用化
技術ドメインを抽出してチーム化した。
どこに責務を負うかという観点で。
プロダクト開発に集中できるようにオンコール対応などを受ける。

A1「72時間ホンネテレビ」の負荷対策とその裏側

技術本部 : CAのメディア事業を社内横断的に見る人。
エンジニアブログ委員長など
Developer Blogであとから情報は公開する

キックオフに向けて

ドックフーディングしたり、ログ見たり

対策内容

優先度を決めた
- 72時間ホンネテレビとCMの配信

CDNでのキャッシュ

 - プレイリストをCDNキャッシュ
 - Web用をCloudCDNに対応させた
 - キャッシュヒット率を向上させた

リクエストのポーリング間隔調整

 - 視聴数やコメント数の部分

別系のシステムへ

 - スパイクしやすいトラッキング用のリクエスト
 - プライベートクラウドからAWSへ

負荷試験/サーバ台数の調整

 - 去年のDevConで発表あったやつ

負荷対策が間に合わない部分

エラーハンドリングの見直し
メンテナンスへ入れられるように
間に合わない機能を使ってもらわないように

リリースをしてもアップデートが

強制アップデートの仕組みがあったので..

カウントダウンするだけの直前番組

起動処理にはリクエストが多くて、負荷をさげるため
オフロード率99.8%だったのでCDNでほとんど返せた

エスカレーションのレベルとアクションを規定しておいた

Future

インターネットは多くの人が見れば見るほど混雑する
ISPやCDNなどの制約も TBps自体には必要となってくるう

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

仮開局まで

- 収録番組の配信がマスト

技術選定

 - オンプレはコスト以外のメリットがなかった
 - なぜGCPを選んだか
      - Googleが使っているのと同じようなL7LB 
      - GKE/k8s
      - ネットワーク帯域に対するコストの安さ
           - AWSはマシンのスペックに応じてネットワーク帯域が決まっている
           - GCPはその制約がなかった
      - StackDriver Logging / BQ
      - 台湾リージョンしかなかった
           - 日本<-->台湾間のインジェストの安定性が問題
           - 台湾<-->東京に移行する人的リソースが避けない

   - 言語 Java -> Node.JS -> Golangへ
   - 編成ツールを完成する必要がありMongoDBを愛用

アーキテクチャ

 - Microservices
 - コンテナ化でリソースの有効活用
 - gRPC+Protocol Buffers
 - Gateway系/Backend系に分けたGateway Pattern

番組表

 - スナップショットをGCSから取得する
       - 編成途中の番組表がユーザに表示されるのを防ぐ
      - バージョン管理しとくことで実機確認ができる

仮開局〜本開局

生番組/広告/コメントができることがマスト

本開局後

動画セグメントのキャッシュ

GCSがSPOF
GCSへの一時的なスループットの低下
Redisキャッシュつかった

ログ改善

fluentdを使っていたがGolandで使いにくい
GcloudPub/Sub + BQ

-- 各ゲートウェイでPub/Subにログを流してバッチサービスがBQにInsertする。 -- ログ解析チームがSubscribeすることが可能

メトリクスの可視化

Stackdriver Monitoringを使用
各リソースを可視化したい
Prometheus+Grafana

年末年始の対応

広告サーバからのレスポンスをキャッシュ
Redis Clusterをスケールアウト
1/1に検証して1/2にバージョンアップを実施 redis-trib.rb 3.06にバグがったので

1周年~2周年

配信の安定化

RTMPでCMキューを入れていたが切れるとCM入れられないのでHTTPで

障害時に何をしていたか

アラートのOnCallを受け取ったが根本原因をさぐるのに時間を用意した mongosが詰まっていたので再起動で解決した

データストアの分離

単一データストから各ドメインごとに分離した

24hホンネTV

エンジニアが出演情報を知ったのは、一般と同じ9月
CDNの利用。番組データ/番組表 CDN

2周年〜現在

ターゲティング広告を開始
ユーザをいくつかのセグメントに分けてセグメントごとにプレイリスト配信
安定稼働を取るように

とここで腰の痛みでリタイア。最近カンファレンス言っても腰痛くて早めに帰ってしまうのがあれなところ。年かな..

y.takky　てくめも

web技術について勉強会の参加メモだったり、本を読んだメモだったりを載せる予定

AbemaTV Developer CONFERENCE 2018