y.takky てくめも

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

AbemaTV Developer CONFERENCE 2018

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

AbemaTV Developer Conference 2018

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

ytacky.hatenablog.com

ytacky.hatenablog.com

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

あとはメモなので

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

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

求められる3つの開発力

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

組織論について

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

  • Management -- 組織成果を最大化する -- TechLead15人に対してエンジニア51人。 TechLead育成を勧めている

  • チーム全員でひねり出して案を出す

バイス戦略

技術的戦略

  • AbemaTVの初期開発はだいたい4ヶ月ぐらい
  • チケット駆動開発で職種でトピックを分離、優先度定義されたチケットが降りてきてやれるだけやる
  • スタンドプレイの最大化になっている

  • GCPを有効活用した。ロギング,LB,コンテナマネジメント

  • 機能開発にフルコミットするように
  • CDNAkamai 動画配信に最適化

  • 配信構成の見直しをしなくちゃなーと思うように(亀田興毅事件)

  • Encoder->配信システムの遅延やパケットロス zixiを定常運用化

  • 技術ドメインを抽出してチーム化した。

  • どこに責務を負うかという観点で。

  • プロダクト開発に集中できるようにオンコール対応などを受ける。

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

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

キックオフに向けて

対策内容

CDNでのキャッシュ

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

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

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

別系のシステムへ

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

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

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

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

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

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

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

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

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

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

Future

  • インターネットは多くの人が見れば見るほど混雑する
  • ISPCDNなどの制約も 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から取得する
       - 編成途中の番組表がユーザに表示されるのを防ぐ
      - バージョン管理しとくことで実機確認ができる

仮開局〜本開局

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

広告

  • abemaTVの広告局が用意したAdサーバと連携
  • 予めトランスコードされた動画セグメントをGCSから取得して配信
  • ターゲティング広告
    • CMをパースなライズできる設計だった

本開局後

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

  • 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周年〜現在

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

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

2018年4月に転職してました

2014年に新卒でエンジニアとして入社した会社を 2018年3月末で退職し 2018年4月からいわゆる Saasビジネスを行っている会社にWebエンジニアとして転職してました。

何をやってたの?

ハンドルネームでググると前職のテックブログの記事が出てくると思います。 主に、Webエンジニアとして2-3年間 新規メディア開発したり改修案件してました。

後半の1年ではSREとして主にGCP/GKE周りの導入をしたりしてました。 特にGCP関係では、 コミュニティであるGCPUGのSlackに入り浸ったり勉強会に参加してました。 GCP/GKE周りでも1-2回発表ができたのである程度コミュニティへの還元ができたんじゃないかなと思ってます。 それでも、早い段階からGCP/GKE周りを触っていた割にはあまり還元できてなかったのかなと思ってたりするのでもう少しやってればよかったなと思います。

なんでやめたの?

理由はいろいろありすぎるので私を知っている方は飲みにでも行きましょう。

主には、自社メディアなのに受託開発案件がちょくちょくはいってきてあれ?ってなったのと、
あまり戦略もなく新規メディア構築してその後放置しているみたいなのが結構増えてきてあれ?ってなったのがメインですね。
やっぱり自分が作ったものが使われないと悲しい。

なんでこのタイミングで書いたの

なんだかんだ言っても前職のエンジニアの人たちはリスペクトしていて、流石にすぐ書くのはなぁと思っていたからです。
特に新卒の頃からのメンターの方にはいつもお世話になっていて彼がいなければ今の私のエンジニアとしての生き方はなかったなと思っています。 あと台風で暇だったから。

転職活動どうしてたの?

転職ドラフトでお声がけ頂いた会社を何社か受けたり、エージェント経由で応募したりって感じでした。
10月末に活動を初めて12月中には決まってた感じですね。

今何しているの?

また webエンジニアに戻りました。 Sass系のWebアプリケーション開発をしています。 go書いたり Vue+nuxt.jsでフロントエンド周りちょっと書いたりしています。

例のあれ

偉い人がこういう記事には貼れって言ってたやつ

Amazon.co.jp

GDG DevFest Tokyo 2018 メモ

今年もGDG DevFest Tokyoに参加してきた。 gdg-tokyo.connpass.com

2016から毎年行っているらしい。

ytacky.hatenablog.com ytacky.hatenablog.com

今年は新宿だったので、かなり行きやすかった。

DialogflowとCloudFunctionsで作るGoogleアシスタントアクション

@flatfish

t.co

Googleアシスタントアクションの話

  • コミュニティプログラムってのがあって、アクションをリリースするといろいろもらえたりする

開発する3つの方法

  • Actions SDK
  • Dialogflow
  • テンプレート
    • NonCodingで作れる。SpreadSheetを埋める感じ

Dialogflow

  • LineやSlackなどにも
  • アナリティクス機能
  • SDKが豊富

  • Dialogflowは聞き出すところまでできる

  • それ以降のバックエンドはできない。計算とか

Intent

  • 会話を開始する文(トリガー)を決める
  • 会話を成立させるための条件を決める
  • 作成したことのない謎の Intent
  • Default Fallback Intent
    • アクションが失敗したときのIntent
  • Welcome Intent
    • アクションが成功したときのIntent

      Entity

  • いわゆるメニュー1つ1つ。
  • Key-Value方式

Fulfillment

  • サーバにjsonを飛ばすことができる

acitons-on-google-nodejsライブラリ

  • DialogFlowではjsonを渡すのでよしなに処理してくれる

TIps

  • YoutubeのGoogleDevelopersチャネル
  • AoG公式Docs
  • Slack

Container

Kuma

  • コンテナ(物理)はなにがいいのか。
  • 統一規格なので何でも運べる

(ソフトウェアエンジニア的な)コンテナ

  • 統一された規格
  • どこでも動かすことができる
  • 環境が隔離されている

だいたいコンテナを使っている人は会場だと90%ぐらい?

Prod環境でコンテナを使う利点

  • 使い捨てが簡単
  • 増やすのも簡単
  • 減らすのも簡単

  • アプリケーションの依存性を内包できる

    • もしchefやansibleなどでマシン自体をスケールアウトしたらどちらが責任を持つか
    • コンテナの中と外で責任の分離ができる

注意点

  • 一度コンテナを作ったらそのコンテナの中をいじらない (immutable)
    • いわゆるコンテナにSSHしたら負けなやつ
  • コンテナの中にデータを保存しない (stateless)
    • ロードバランシングして画像がない方に振り分けられると見えない
  • コンテナの管理・運用
    • Monitoring,Orchestration などなど

InGCP

  • Kubernetes Engine
    • ちなみにkubernetesを使っている人は会場の中で10%以下ぐらい?
    • kubernetesの説明があったが割愛
      • コンテナのオーケストレーションツールで、水平スケールや自動ヒーリング、サービスディスカバリとロードバランシングなど。
      • Node-poolの提供 Nodeをまとめて管理する概念と、Nodeのスケール機能
      • GCPの連携
  • StackDriver
    • LoggingやTracing,profilling,Alertingなどモニタリングする際のツール
  • Container Registry
    • DockerHubみたいな
  • Cloud Build
    • コンテナのビルドとワークフローの指定管理を行うツール

GCPで作るデータ処理パイプライン

@orefon

t.co

  • バッチとストリーム処理の概要と問題

データ処理の分類

  • バッチ処理
    • 有限の範囲のデータを扱う
  • ストリーム処理
    • 処理対象となるデータの範囲が無限で時々集計する必要がある

機械学習の特徴量生成の場合

  • 時系列系の特徴量
    • リアルタイムレコメンド

GCP上ではプログラミングモデルとインフラを提供している

  • プログラミングモデル

    • ApacheBeam
    • Dataflow,Sparkなど
    • Javaが一番揃ってるけどPython,Goも
  • 分散実行インフラ

    • フルマネージドでオートスケール
    • GCP各種ストレージと連携できる
  • Cloud Dataflow+beam

    • データの処理と分析を担う
  • Cloud Dataprep -UI上でできる非プログラマ向け
  • Cloud Dataproc + Hadoop
    • Hadoopをそのまま移行する感じ

Apache Beam

  • データの処理の流れを宣言的に記述する
  • 抽出データ(PCollection)を処理(PTransform)でつないでグラフを作る

Google Cloud Dataflow

  • Apache Beamの実行環境
  • オートスケール

まとめ

  • ApacheBeamはバッチ処理とストリーム閭里を簡易に記述するプログラミングモデル
  • Dataflow使うと早く安く処理できる

Firebase Realtime Database in Production

speakerdeck.com

AI メッセンジャー

B2Bのチャットサービスの提供、自然言語処理を含めて自社製 FIreBase:アプリケーションインフラの提供サービス WebSocketの管理をしたくなかった

なぜ書き込みをサーバからしか行わないか(直接クライアントから返さないか)

  • フィルターなどが弱い(RealTime Database)
  • BigTable等の別Storageから検索・フィルタリングできる。 ただし、データの分散や二重管理などが必要になるので、構成の吟味が必要

Filtering values

  • FireBaseは値のクエリが苦手
  • 設計時点でフィルタリングが必要なかったりしやすいように設計すべき

How to manage incidents

  • Lineともつなげていて、絶対落とせない。証券会社とかあるし。
  • FireBaseに障害が起きってるっぽいときには、Pollingに切り替えて Restでやるようにした。
  • データをロストすることもあり得るので、全データはStackDriverにログを出力しておく

Future works

  • 最終的にFireStoreかな。まだ検証はしてないけど
  • Double Write以上になりそう。

感想

  • AoG面白い個人的にやってきたい感じはあるんだけど、マネタイズのイメージがまだつかなくて企業導入はまだまだな感じ
  • コンテナ自体は使っているけどKubernetesを使ってる人はまだまだ多くないようだ。
  • CloudDataflowあたりはまだそんなに使ってるところ多くないのかな。セッションは人気だった。
  • FireBaseが結構本番での利用事例が出てきた感じ

MacでMarkdown+umlを書きたかった(VSCode)

まえがき

Markdown+umlを書く機会がローカル(Mac)であった。 というよりWebサービス上で書くとサービスの性質上 publicにしないと下書きにできなかったので...

今回はVSCode拡張機能をインストールして対応した。

拡張機能 Markdown Preview Enhancedの準備

今回はMarkdown Preview Enhancedを使用した。 marketplace.visualstudio.com

今回やりたいuml(plantuml)だけでなく、PDF出力やhtml出力もできるスグレモノ。

拡張機能は[表示]->[拡張機能]で拡張機能メニューを出してMarkdown Preview EnhancedをインストールすればOK

plantumlの準備

plantumlをインストールする前にjavaが必要なのでjavaをインストールしておく
brew cask install java

その後graphvizもインストールしておく brew install graphviz

plant umlのインストール

こちらもbrewを使ってインストールする

brew install plantuml

確認

vscodeで適当にmarkdownを作って以下のように書いてみる

# test

````plantuml
title test
class Class
````

そして.md形式で保存しておく。

その後 command+k -> vでpreviewを表示するとumlが表示される

f:id:ytacky:20180829232406p:plain

まとめ

ローカルでmarkdown+umlをかけると捗るようになる。 htmlやpdfでの出力もできるし便利に使いたい。

Abema TV DEVELOPER CONFERENCE 2017にいってきた

AbemaTV Developer Conference 2017

去年に引き続いて

ytacky.hatenablog.com

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
    • Googleが制御プレーンを管理する
    • Master側はGoogleが管理する。 99.5%SLA
  • ノードアップグレード
    • kubernetesのバージョン
    • nodeOS
  • Backendはマネジメント使えば
  • GLB
    • BackeEndで振り分けられる
  • グローバル負荷分散
    • 自分の近いところにアクセスが行く。
  • Cloud LB / CDN

まとめ

福田さん自体は結構いろんなカンファレンスで話聞くことがあって、GCP周りの話に関しては結構調べれば出てきそうな感じかな。 あとAbemaTVの事例は Google Cloud Nextでもあったのでそっちの動画はみないとなーと。

(たしかこれ会場にいってたのに障害対応してた気がする..)

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

藤崎さん

既存の中継

FPU(マイクロ波) で送信

  • 専用線で秘匿性高いが免許必要だし高い。
  • アンテナ合わせ...

衛生

  • 遅延が多い。専用線だけど
  • 天候に左右される

SKYPE

  • 簡単で画質そこそこだけど不安定でPCベース

SkypeTx

  • 放送用Skype , 画質Max720p 遅延が少ないが相手先のネットワークに左右される

LiveU

  • イスラエルが作ったやつ
  • キャリアを束ねて分散して送信して受け元で戻すやつ。
  • クラウドで動いていて位置もわかる

  • AbemaTvはLiveUの保有2位

  • 簡単,フルHD、圏外問題はある

実際の将棋中継

  • 2ヶ月前から設定する。
  • 電気食うから発電機必要
  • リピータも借りている

まとめ

  • 放送1日でも実際は3-4日
  • 平均2時間のカメラ調整

AbemaTVの画質定義~ラウドネスマネージメント(録画放送)

  • 配信レゾリューション (配信サイズ) は多々。近々情報量節約モードが出る

技術用語

  • CODEC
    • 圧縮 , 符号化 / 復号化
  • container / 拡張子
    • 映像と音の入れ物のイメージ
      • コンテンツプロバイダーからの入稿規定がある。
    • mp4ならばH.264 / AAC-LCなどの圧縮系
    • masterデータの場合もある。 / Prores422HQ / リニアPCM
  • 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配信

  • GithubにPR / bitriseがjobをキック。 Crashlytics, Itunes ConncectでTestFlight配信

Slack通知

  • K.I.T.T -レビューがされていないPRを流す

QA効率化

デザインのBefore & After

  • アプリ内通知バー
    • AndroidのSnack Barと同じデザインにしたい
    • 指が届かない
  • モーダル

    • フルスクリーンのモーダルは避けられる傾向がある
    • 指がと説かない
    • AndoidのBottom Sheetと同じUX
  • ビデオページ

    • サムネイルのパワーが弱いので文字で訴求したい
    • 情報量のバランスを取るため
  • アプリアイコン

  • Web(モバイル)

    • モバイルページはアプリへの導線的な役割
    • 番組ってことをわかるようにサムネ大きくした
    • 放送中の番組のページだけダウンロード率が少し低かった
    • twitterからの流入のダウンロード率がちょっと低い
      - リンクを踏むとその時放送中の番組になっていた
      - 番組それぞれ持つIDに変更
      

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

  • API Requestが200を返さず、ErrorPageを出すか、不必要なまま出す
  • つまりランディングに必要なAPIが叩けないと死ぬ

ケース2

  • Node.jsにはタイムアウトの実装がなかった
  • GLBがtimeoutすると503帰ってくる

ケース3

  • API Requestが通らない
  • いわゆるnginxが詰まった。

対応策

  • エラー処理を実装した
  • gRPCコールしているところにデフォルトタイムアウトを実装する
  • Webのサーバリクエストをスケーリングさせる

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とは

  • Appleが提唱したHTTPストリーミング規格
  • 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対応するか

  • DRM対応コンテンツの配信が必要
  • 各デバイスごとに配信方式変えている

配信品質の監視

  • マスタールームで監視しているけど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

    • Cloud Dataflowを使用してテーブルを一連のHadoop シーケンスファイルとしてexport
    • Hbase -> BigTableインポートもOK
  • Metrics

    • StackDriverでの表示はGA
    • ただしDashboardからBigtable MetricsにアクセスするためにはWhitelist申請が必要

その他

  • Abema Bot

    • 負荷試験環境は本番とほぼ同じ、 使用するときしか起動しない運用
    • 検証のときでも使ってるが人力ではカバーしきれない
    • 定時のタイミングでBotを動かしてインスタンスの停止を通知する
  • Varnishを通しているendpointやcache可能なendpointはCDNを導入

DevFest Tokyo 2017 メモ

gdg-tokyo.connpass.com

1週間以上前だけどDevFest2017へいってきたのでメモを公開しておく。 天気が良くて会場がお台場っていうちょっと他に遊びに行きたい誘惑感はあった。

FirebaseとReact Nativeでのモバイルアプリの作り方

@k2wanko

How to make mobile app with Firebase and React Native // Speaker Deck

Firebaseって何

  • mBaas / データ預けられたり

なぜFirebaseか

  • クライアントを作ることに集中したい。
  • サーバの管理が必要ない。
  • 無料枠でなんとかなる。

React Nativeって何

  • Reactでモバイルアプリが作れるやつ
  • JSX(HTMLのDOMできななんか)で返せる
  • WebViewでない。 JavaScriptCore
  • ただしブラウザの機能をサポートしている。 Fetch / WebSocket / setTimeoutなどなど
  • HotReloadできる (保存して更新したら反映される)
  • ネイティブモジュールでネイティブの機能にアクセスもできる
  • ロジック部分はjsでかけるからテストが楽
  • 全てをReactNativeにするひつようはない。

React Nativeでよく使われるライブラリ

  • NativeBase
  • react-navigation
  • Mobx
  • React Native Firebase
    • 公式のWebSDKでは使えないサービスもかける

Firebase Authentication

  • ユーザ認証を実装できるサービス
  • twitterやメール等々認証。カスタム認証もできる。

Realtime Database

  • オンラインでもオフラインでもデータが保存できてリアルタイム同期が可能なKVS
  • セキュリティールールで読み書き制限

Google Analytics for Firebase

Firebase Cloud Messaging

  • Push通知を送信するためのサービス
  • SDKを通してPush用のトークンを取得
  • Notification / onMessageとgetInitialNotificationで結果が異なったりPermissionを求める必要があるので、注意

Cloud Storage for Firebase

  • 大きめのファイルを保存するためのストレージ
  • セキュリティールールがあるので安心

Firebase Remote Config

  • アナリティクスをもとにユーザごとに設定を割り振れる

Firebase Crash Reporting

  • そのうちCrashlyticsがメインになるからそちらを使ったほうがいい

AdMob

  • アプリに広告を載せるためのサービス

Cloud Functions for Firebase

- イベント駆動でNode.jsを実行できる。 - 書き込みなどをトリガーに - いままでできなかったことを可能に

Cloud FireStore

  • ドキュメント指向のDB

初心者がFireBaseについて見ておくといい場所

gcpugを見ましょう

Firebaseが向いている人

  • サーバの開発運用を最小限にしたい人

React Nativeが向いてる人

Javascriptがかけてネイティブも少し分かる人

deeplearn.js入門

-teachable machineを題材に-

deeplearn.js入門 - Google スライド

  • jsで深層学習する

teachable machineを通して deeplearn.jsの基礎について学ぶ

  • Makegirls moe

WebDNNを使ったもの

  • Performance RNN

  • 深層学習をブラウザでやるメリット

  • 高スペックのマシンいらず
  • ネットワーク遅延なし
  • インストール不要
  • セキュルティ上の危険が少ない

  • ConvNet.JS ここ数年更新がない

  • Keras.js 深層学習のモデルをjs側で読み込む。 推論のみ対応

  • WebDNN

    • Keras/ Chainerのモデルをコンバート可能

deeplern.js

  • 学習も可能
  • WebGLによる高速な演算
  • TensorFlowのチェックポイントファイルの読み込み(学習済みモデルの読み込み)

環境構築

npm install deeplernか scriptにhttps://unpkg.com/deeplearn読み込む

基本概念

https://bl.ocks.org/ohtaman/raw/5b55dff399864f8bde1b073478450a79/ のコンソールから実行できる

teachble machineの処理フロー

  • ビデオからキャプチャ -> 特徴量の抽出 -> 保存 抽出は学習済みモデルでやる。 推定はKNNによる分類をする

  • SQueezeNetのモデルを使ってる。AlexNet並の精度でモデルのサイズが小さいやつ

  • KNN k近傍法 特徴量が何に似ているかで分類するシンプルなアルゴリズム。 特徴量を抽出する以外に学習をしないので高速に動作する。 全学習データと分類したいデータの内積をとってtop k件の学習データをとる。

  • 深層学習では誤差逆伝搬法で学習をする。 deeplearn.jsではGraphとTensorという概念を使って学習可能なネットワークが構築できる

Chrome DevToolsの紹介

  • chrome標準搭載のデバッガー
  • 他より多機能

Elements

  • DOM構造の確認
  • CSSの編集
  • イベントリスナーでのブレーク

Sourcesパネル

  • 使用ファイルの確認
  • JSデバック

Networkパネル

  • 読み込まれるリソースのパフォーマンス
  • リクエスト元や画像サイズ接続詳細など
  • 3rdpartyのリソースにバッチつくようになった。

  • リソース上でshift押すとこの画像がどこから読み込まれたかわかる。

Performanceパネル

  • Chromeの内部処理
  • ネットワーク
  • パース、レイアウト
  • js実行
  • 描画、コンポジット

Applicationパネル

  • PWAの管理センター
  • App Manifest
  • Service Worker
  • Cache Storage
  • 他のストレージも

Auditsパネル

  • PWAのチェックツール
  • これをあげとけばいい

開発効率を上げる

ワークスペース

  • エディタとブラウザの行き来がだるい
  • Sourceパネルでローカルファイルとのマップができる

バイスモード

  • 読み込み速度やレスポンシブの確認

リモートデバッグ

  • 実機上のChromeで表示したコンテンツをPCのDevtoolsからデバックできる
  • ローカルのコンテンツを実機で表示できる

escで開いたメニューの中にRemote Devicesの中にDiscover USB Devicesがあるのでそこから開く

パフォーマンス計測

  • webサイトが遅いのはなぜか
  • 回線が遅い、サーバが遅い
  • HTMLの書き方、画像、Jsの読み込み方

devtoolsの情報

Go1.8 for Google App Engine

Go1.8 for Google App Engine

GAE

  • Googleが提供するPaas
  • スタンダートとフレキシブル環境がある。
  • Google App Engineを利用した新規Webサービスの立ち上げ方を見てください(KAURUの導入事例)

Goの対応状況

  • Go1.6 1.9なので離れてる
  • Go 1.8(β)
  • バグはなくなってきている

Go 1.6->1.8で新しくなったこ

  • 1.6->1.8
    • contextパッケージが標準になった
    • サブテスト
  • 1.7->1.8
    • sort.Sliceが導入されてソートするときに型を作る必要がない

Contextインターフェース

 - GCPの各APIを使うために必要
 - Goの標準としては ゴールーチンのキャンセル
 - コンテキストに値を持たせる
      - キャッシュを使わない。デバッグするためにつかったりとか
 - GAEとコンテキスト
      - Datastoreからの取得、 第一引数でコンテキストを指定している。

サブテスト

 - 子テストを実行する
 - サブテストを指定して実行できる。
 - 落ちたとこがわかりやすい

ソート

 - 1.7まではsort.Interfaceを実装する必要があった

Go 1.8対応

  • gcloudコマンドでアップデートしたりSDKを再DLしたり
  • 設定の変更
    • app.yamlを修正
    • contextをgolang.org/x/net/contextからcontextに変更する

app.yamlの書き換え

api_version: go1.8 に変更する。これでSDK内のgoappコマンドやGOROOTがスイッチされる

コンテキストの互換

  • インターフェースはメソッドが同じであれば互換である。 Aのinterfaceに String()メソッドを持っていてBのinterfaceにString()メソッドが持っていれば互換がある。

Request.WithContext問題

  • Request.Withcontextでリクエストが書き換えられる。
  • リクエストが書き換えられると対応するコンテキストが取れない(キーがヒットしなくなる)
  • gorilla/mux や lion v2などで問題が発生していた

コンテキストの置き換え

型の不一致問題

  • コンテキストを引数や戻り値に取るクロージャ
  • ラッパーを作る必要がある...

Go1.9にも期待できる。

  • エイリアス
  • t.Helper()
    • テストヘルパーで落ちたときにどこで落ちたかわかりやすくする。
  • sync.Map型
  • math/bitsパッケージ

まとめ

  • Go1.8はβ
  • パフォーマンス改善やテストで使える

  • 本番利用は早そう

  • コンテキストの問題やライブラリの改修問題

Google HomeでツイートしたりIRKit経由で電気つけたりSlackに投稿したりする

Google Home 何?

f:id:ytacky:20171008175539j:plain いま結構バズワードになりつつあるスマートスピーカー。

Googleが出したもの。

store.google.com

AmazonAmazon Echoだしたり、LineがClova WAVEを出したりし始めつつある。

スマートスピーカーの共通の特徴として

  • AIアシスタント(主に音声認識周り等々)
  • IOT連携 (電気つけたり消したり)

などがあげられる

jp.techcrunch.com japan.cnet.com

GoogleHomeがデフォルトでできることは置いといて、エンジニアだったらほかサービスとの連携を試してみたくなる。

Google Homeの場合 IFTTT連携で他のサービスにつなぎこむのが基本的な使い方になる。

ツイートしてみる

ツイートの場合 IFTTTデフォルトレシピがあるのでそれを改良すればよい

IFTTTにログインして Search -> Google Assistantに Post a tweet using your voiceがあるのでそれを使う

f:id:ytacky:20171008165939p:plain

一旦Turn Onして Configurationする。

f:id:ytacky:20171008170220p:plain

コツとして What do you want to say? を

ツイート $ に

Language を Japaneseにする。

その人によるが発音的にtweetがどうしてもカタカナでツイートになってしまうので....

一回IFTTT連携した後うまく動かない場合はgoogle のmyactivityから何が発音されたか確認するといい。

myactivity.google.com

こんなかんじにツイートできる

f:id:ytacky:20171008172301p:plain 

IRkit経由で電気をつける

過去記事にDeviceID等の取得を書いたのでそれを参考に必要なDeviceID等をメモっておく

ytacky.hatenablog.com

My Applets -> New Appletから追加する。

f:id:ytacky:20171008173042p:plain

this(入力側)の方で google assistantを追加して

f:id:ytacky:20171008173212p:plain

f:id:ytacky:20171008173306p:plain

What do you want to say? -> 音声認識のコマンド。 電気オンとかにしておく

What do you want the Assistant to say in response? -> Google Homeからのレスポンス。 適当に Ok , 電気つけたよ とかにしておけばいい。

これで入力側が完了

Thatの方は Webhooksにしておく。 トリガーはMake a web request1つしかないので迷わないだろう

f:id:ytacky:20171008173702p:plain

以下のように埋めていく

  • URL : https://api.getirkit.com/1/messages
  • Method : POST
  • Content Type (optional) : application/x-www-form-urlencoded
  • Body (optional) : clientkey=YOUR_CLIENT_KEY&deviceid=YOUR_DEVICE_KEY&message={"format":"raw","freq":YOUR_FREQ,"data":[YOUR_IR_DATA]}

YOUR_CLIENT_KEY,YOUR_DEVICE_KEY,YOUR_FREQ,YOUR_IR_DATAは適宜変更する。

これで Saveすれば、 トリガーにした言葉で電気がつく。

IRKitと連携できたので赤外線データさえ取得できちゃえばどんなデバイスでも音声で操作できるようになる。

Slackに投稿する。

よく買い物メモをSlackに投げたりするので。 基本的にツイートのレシピの投げ先がslackになったものと考えればいい。

My Applets -> New Appletから追加して、 google assistantを選択。 Say a phrase with a text ingredient をトリガーとする。

What do you want to say? には メモ $とでもしておく。

$ が実際にSlackに投稿される内容になる。 レスポンスはお好みで。

That側はSlackを選択する。

f:id:ytacky:20171008174622p:plain

投げたいchannelを選択して、 Messageには適当に。

f:id:ytacky:20171008174956p:plain

こんな感じでSlackに投稿できる。

まとめ

Google Home + IFTTTの連携でわりといろいろなことができることがわかった。 まだ、Google Home + Crome Castの連携サービスが日本ではそんなにないのでまだ時期尚早かなー感はあるけど 面白いデバイスであるとは思う。