AbemaTV Developer Conference 2016に参加してきたメモ。 途中でメモが吹っ飛んだので最初のほうがありません。

イマドキの Web サービス運営で突き当たるフロントエンド課題とつらみ

開発上の様々な依存のつらみと FRESH! by AbemaTV の話 // Speaker Deck

  • ahomuさんすごい！！！

リニア放送型動画サービスの Web フロントエンド

リニア放送型動画サービスの 
Web フロントエンド

  • 動画のストリーミング配信について

Flux with RxSwift

デザイナーとエンジニアの境界線

  • デザイン
  • 人の話
  • AbemaTC
  • 社長からの要望
    • すぐ再生
    • ザッピング再生
    • 受身的な再生
  • 最初のモック
    • 縦画面
    • pixate
    • モックを移して夕会で共有
    • テレビっぽくない
    • モックは250個
  • 結果
    • 16:9の横画面
    • 皆の意見が反映させているので納得感がある
  • モック見ながらの話
    • ステータスバーはwifi、バッテリーが気になるのであったほうがいい
    • 要素が多くて多くて分かりにくい
  • デザイン -> エンジニア
    • Sketchのファイルをエンジニアに渡す
    • エンジニアがsketchを開いてマージンとかを見る
  • アイコンの書き出し
    • Sketchからエクスポート
    • いい感じに最適化までやってくれるスクリプト
  • デザインガイドみたいのは用意しなかった
  • アニメーションはPixateで
    • アニメーションの種類
    • 秒数とかも共有できる
    • デザイナーが管理する

デザイナーがコードに触ってみて感じたこと

  • Atomic Design
  • コンポーネント管理
  • GitHubを使う

GKE at AbemaTV

  • GKEを選んだ理由
  • 設計
  • GKE is
    • Google Container Engine
    • Kubernetesをフルマネージメントサービス
  • Kubernetes is
    • Dockerのコンテナマネージメントツール
    • MasterとMinionのノードに別れる
  • AbemaTV on GKE
    • フルフルGoogleプラットフォーム
  • GKEを選んだ理由
    • GKEがGAに
    • 活発なアップデートなどが理由
    • マイクロサービスアーキテクチャとの親和性
  • RequestとLimits
    • RequestsはPod起動時に必要なリソース
    • LimitsはPodsのリソース制限
    • この2つの開きがあると高負荷時にリソースが枯渇する
    • Podスケール時にスケジュールしていた場合にLimitを超える場合もある
  • 1クラスタ × Nサービス AmebaTV
    • メリット
      • 追加機能でインフラの準備不要
      • 運用コストを低減
        • ローカルホストのポート指定で繋がる
    • デメリット
      • リソース消費の見極めが複雑化
      • Podの冗長化に難
  • Docker Image
    • Alpine Linux
      • Docker向きの軽量OS
    • デプロイ頻度が少ないとかパッケージが足りないのはUbuntu
  • lubectl
    • リソース作成
      • kubectrl create
    • 設定内容の更新
      • kubectrl apply
    • Roling-Update
      • 各Podをローリングでアップデートする
      • 途中で失敗すると、中途半端な状態なPodが残る
  • kubetool
  • 監視/ログ
    • 標準で取れるのはリソース状況のみ
    • Podの標準出力はLoggingに流れる => フィルターして監視
  • kube-ui
    • 各コンポーネントの情報一覧
    • 最近はリソースの編集とかもできる
  • Terraformとの別離
    • 編集するとすべて再作成される
    • 無停止でやりにくい
  • ServiceのIPに接続できない問題
    • v1.2.0でのバグ
  • Nodeアップグレード時に問題
    • 1台ずつアップグレードされるが、Podが先に落ちないためNodeに繋がらないとう問題がおきた
  • GKEの感想
    • Docker導入の敷居が低い
    • デプロイ簡単
    • リソース調整にはコツがある
    • DevOps

AbemaTVの開発スタイル

  • FRESHの立ち上げ
  • AbemaTVのリリース後の運用
  • インセプションデッキ
    • コンセプトイメージをまずつくった
  • スプリント
    • 2週間ぐらいを区切りにしてタイムボックスにいれてｒ
    • 朝回で確認
    • スプリントレビューで成果の確認
    • KPTを振り返り
  • チーム人数に適応する
    • そのままベースを使うわけじゃない
    • FRESH
      • 開発20人前後
    • AbemaTV
      • 開発30人以上
    • スクラムチームは15人ぐらいが限界
    • チームの分解が必要
  • チームの分解
    • クライアント、サーバ、iOS、Android、デザイン
    • 規模が大きくなるとヨコの連携が弱くなる
    • 機能毎にプロジェクトを作る人をアサインすることでヨコの連携を補強
  • FRESH 縦から横事件
    • リリース予定まで2スプリントだった
    • 残りの機能をリリーススコープから外して横対応にした
    • デザインスプリント(デザイン合宿)をして認識合わせをした
  • 人に適応する
    • 開発者個人でも課題が異なる
    • S1-S6の評価制度を意味づけを
    • 評価制度を使って役割を明確化
    • 自走できる人は権限を持つ
  • 自走
    • 自走できる人は勝手に課題を見つけて対応する
    • 計画する前に手を動いて追わせている場合がある
    • 管理しすぎるとパフォーマンスが落ちることがある
  • 属人化
    • 個人に依存するので属人化する
    • 開発速度 > 属人化

炎上プロジェクト立て直しの風景

  • 炎上プロジェクトの立て直しの事例
  • 権力者の介入がある風景
    • iOSとAndroidの仕様のズレがある
    • チーフプロデューサーが修正依頼がiOSのエンジニアのみに来る
    • => iOSとAndroidの仕様がずれる
    • やること
      • 仕様はプロヂューサーとチーフプロデューサーで決める
      • 直接エンジニアにはいかないはず
      • プロヂューサーを対話に同席させる
    • 学び
      • 意思決定と情報の集約は一元化する
      • 権力者とは上手く付きあう
  • 要件がいつの間にか進化する風景
    • ヒアリングしてると要件が変わってきてることに気づいた
    • クライアントのひらめきにより要件が変わった
    • => 在庫連動したレコメンドサービスになってしまった
    • 本来の目的に戻した
    • スコープは明確にすることが大事
  • 大規模プロモの直前なのにシステムが落ちまくっている風景
    • 1.5万キャパを100万同時接続にするという風景
    • SNS認証のバックアッププランがない
    • 特定機能の障害がひきずられて全体がダウンする
    • プロモが成功しても100万同時接続は行きそうになり
      • CM計画とアクセス傾向から
    • プロジェクトゴールの再設定
      • 過剰要件は落とす
  • 最悪の問題とは
    • ゴールがブレる、終わりが見えない
    • チームワークの崩壊
  • 炎上 = 祭り
  • Q. AbemaTVは祭りにならなかったとのことですが、どういう工夫が?
  • A. いややっぱり祭りでした。