ytakkyの技術系のブログだったりするもの

適当にいじったもののメモだったりを載せるかんじのもの

Abema TV DEVELOPER CONFERENCE 2016参加メモ

秋のカンファレンス参加 第二回目 今回は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. 特になかった。

  1. GO使うならば App Engineって選択肢もあったとおもうけど
  2. いろいろあったので続きは懇親会で。

  3. Dockerfile Imageの運用方法は?

  4. 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も快適でカンファレンスとしてはかなりクオリティが高く発表の内容も素晴らしかったです。

PSVR買ったので

運良く店頭体験→予約ができたのでPSVRを買いました。

セッティング

クイックマニュアルに従えば困ることは特になかった。 PSCameraつける端子をまよったことぐらいかな。 あと、PS4の構造上仕方ないけど裏側にもUSB端子が欲しいなと思った。

PSVRの接続上 PSVRプロセッサーユニットとPS4のUSB接続するときにフロント側のUSBしか端子ないので...

PS4 PROは背面にもUSB端子があるみたいなので、PROを買えということか...

ソフト

専用ソフトだとローンチ時は26本(体験版とかも含めて)やったものを載せておく

KITCHEN

BIOHAZARD VRのモック的な扱い。 プレイ時間が3分ぐらいしかないし、 個人的にはBIOHAZARD 7 TEASERの方が恐怖感があった。 あまりプレイアブルじゃないので、演出で見せてくるしかないよな。って感じ

Allumette

映像作品に近い感じ? あまりやってない

THE PLAYROOM VR

ミニゲームの詰め合わせみたいなもの。 マリオっぽいアクションゲーとかある。結構面白いけどVRにまだ慣れてない状態でやってたので結構酔った感じはある。

初音ミクVRフューチャーライブ DEMO

ちょっと見ただけ。 コントローラ振ってサイリウム振るのを再現するのは面白かったし、カメラ位置はデレステVRより良かった。

PlayStation VR Demo Disc

まだ全部やってないけど。体験版集。 DRIVECLUB VRやってみたけど、酔うね。 グランツーリスモとかも酔いそう。

Invasion

VR映像。 他のVR機器にも提供してるっぽくてある種のベンチマーク的に使えそうだなーと思った。

サマーレッスン:宮本ひかり

JKの家庭教師になって勉強を教えるVRゲー 体験会の時はADVに近いのかなと思ってたけど、育成シミュレーションの要素も若干入っている。 座ったままできて酔わないので、意外とVR体験としてはおすすめ

アイドルマスターシンデレラガールズビューイングレボリューション

デレステのVR版みたいな。 確かにライブに参加している感じがあるし、サイリウム振れるしコールもちゃんとあるしいい。

欠点はDLCが異様に高いのと、3曲2800円ってところと曲追加もDLCなんだろうなーってところ。 (いつものバンナムともいう)

とはいえ、デレステやってる人にはおすすめ。

弾丸ロンパ VR体験版

学級裁判のところをVR化した体験版。 そんなに長くない。 うーん。VR化する必要あるかなーと思うゲーム。 悪くはないんだけど

Until Dawn: Rush of Blood

ローンチ時のVRゲーの中では個人的に一番おすすめする。 ホラー + ジェットコースターに乗ってる感覚 + シューティングが一辺に味わえる。 ホラーも1面時点ではそこまで怖くはないけれど、若干怖い感じもある。というちょうどいい塩梅。 ホラーガチ勢はちょっと満足できないかも。

シューティング要素もあるしおすすめです。

シネマティックモード

VR非対応ゲームだったりメニューだったりはこの状態になる。 VR上に仮想の画面が出る感じ。 要はVRで体験する映画館的な。 画面サイズが小中大と選べる。

既存のゲームもこのモードで遊べるしTorneだったり、YoutubeだったりAmazonビデオだったりとPS4上で再生できるメディアならばなんでも再生できるからお手軽に映画館が再現できる。

ちょうどフリップフラップ2話みたけど、問題はなかった (ちょっと色彩つよくてきつい感じもあったけど)

サラウンドで音も再生されるしおまけの割には結構いいモードだった。 最悪VRゲーが合わなくてもこのモードで使い潰せそう。 余談だが、HDMIの入力をPS4以外にしてもVR上で再生される。

目疲れる?

やっぱりVRの中は蒸れるし疲れる感じはある。

めぐりズム 蒸気でホットアイマスク 無香料 14枚入

めぐりズム 蒸気でホットアイマスク 無香料 14枚入

めぐりズム 蒸気の温熱シート 16枚入

めぐりズム 蒸気の温熱シート 16枚入

この辺使って回復させたい。

あとめぐりズムは結構いいんだけど使い捨てだからコストが結構かかるので 普段の休憩用には繰り返し使えるこれをつかってる。

あずきのチカラ 目もと用

あずきのチカラ 目もと用

PSVR買い?

現時点ではゲームがそんなに出てないし、新しいもの好き以外は焦って買わなくてもいいかなー。 やりたいゲームのタイトルがでて運良く手に入れば..って感じに考えとけば良さそう。 シネマティックモードはかなり使えるので、PS4を持っていて1人で映像環境を整えようと思ってる人は買うのもあり。 あとは体験会とか友人とかに頼んで体験してみてVRあうかどうか確かめてからの方がいいと思う。

PSVRでデレステ (Andorid版の方)をする

※想定外の使用方法のため保証が受けられなくなったりしても責任は負いません。

 

発売初日でPSVRにパソコンを繋げたバカが私 | 家電のいろは

 

この記事を見て、HDMIを接続先を変えればシネマティックモードで映るなら

Andorid -> HDMIで出力できればPSVR出力先に出来るじゃん。

と思ったので、実際にやってみました。

 

MHL対応のAndoridスマホであれば専用のケーブルがあればMicroUSB端子->HDMIに出力を出せる。

 

ちょうど手元に

 

 

 

 があったのでつないでみた。

なお、スマホ

 

butterfly HTV31

butterfly HTV31

 

 

接続は

AndoridスマホのMicroUSB端子 -> MHLケーブル -> PSVRのプロセッサーユニットのPS4側入力

 

に入れる。

 

これだけでAndoridの画像がシネマティックモードでPSVRに表示される。

あとはやることといったら、デレステ立ち上げてMVモードで見るだけ。

 

ふみふみふみふみふみふみ

 

 

最高!

 

ただビューイングレボリューションとは方向性が違い

あくまでデレステの3Dキャラを PSVR画面上で大きく表示させてるだけなので注意。

ビューイングレボリューションもいい。

曲追加はよ。

 

 

 

 

devfest tokyo 2016に行ってきた。

gdg-tokyo.connpass.com

に行ってきたのでメモを。 GCP/機械学習関連について聞いてきた。

セッションタイムスケジュール DevFest Tokyo

アジェンダ詳細 DevFest Tokyo 2016 プログラム詳細

スライドは qiita.com とかにまとまっている。

GCE周りの変更点

Compute Engine

  • subnetがregion単位で切れるようになった
  • APIが変わってる
  • Developer ConsoleにSerial portでつなげるようになった
  • コスト削減とかのためにおすすめができるようになった (再起動する)
  • 起動中のインスタンスマシンサイズが変更できるようになった
  • scope(GCP関連の権限付与) の変更もできるようになった。
  • yumリポジトリとかがgoogle提供のものもできた

GCS

  • https load balancing with google cloud storage
  • 自前のドメインでやるときはSSLできなかったけど、LoadBalanceの後ろにGCSを指定できるようになった

StackDriver

  • 画面が変わった。統合監視ツールっぽい感じに
  • stack driver -agent がV3へ。APIの叩く量が増えた(3倍ぐらい)
  • stack driver logging google-fluentdがで取集
  • Error Reporting ->fluend で叩きつける感じ

CloudSQL 2nd Generaltion

  • 接続速度が向上
  • Endpoint IP か Clous SQL Proxyを使う。
  • Failover Replica と Read Replica

Failoverの仕様 - Failoverの後Failbackする。 そのあとSwitch overしない。 - Masterの障害後 Failover ReplicaとRead Replicaのみになる。 - Masterを復帰後 MasterのBackupを取得 - そのBackupからFailover Replica / Read ReplicaのRestoreで再起動 - Master復帰までProxy経由でもクエリ投げらんない。 (そもそも落ちない大丈夫)

Hasicorp Terraform

  • Terafformがおすすめ。
  • インスタンスの連番とかzoneの自動振り分けとか
  • Cloud DNSとかの設定もできる。

Q&A

CloudSQL グローバルIPからしか繋げないのキツイよね ってのが世界中からきてるから そのうち直りそう

GCPのネットワーク構成について

  • 一から学べるGoogle Cloud Networking リファレンスガイド っていうのがかなり参考になる。

default

defaultにはfirewall rulesとかREGIONごとにsubnetが切られている SRC_RANGESが0.0.0.0/0 でtcp:22なので sshでどこからでもつなげる。

subnetはregion単位 firewall ruleを指定しないとsshとかできない

GCE上は同一DNSサーバを見てるので、 名前解決ができる。

custom subnet network

subnetを自分で作った場合、firewall ruleを定めないと内外部どちらも接続できない。 gcloud コマンドから作ると警告と、firewallのルール例が出る。

GCPの外の世界を意識した場合subnetが有用かもしれない。

BigQueryとCompute Engineで扱う自然言語ビッグデータ

雑談対話システムの作成

App Engineで受ける。ユーザからの発言に対してどのアルゴリズムを使うかとログをStackDriverに投げてBQに入れたりするのに使う Compute Engine -> Chainer Memcache or Data store Compute Engine Tensor Flow Data store 発話Data

アルゴリズム

直近の話題から TensorFlowであらかじめ用意しておいた発話候補に得点つけて返答

発話データ

Datasotreに key(話題となるキーワード) と candidates(発話候補) で入れ込んでおく。 ここの準備が大変

発話元データ

TwitterのデータをBQに入れておく。 keyword と tweetの形で。 これをいい感じに加工してDataStoreに入れ込むのにCompute Engine使ってるけど結構大変。

 前処理

BQでできるものはBQでやる。 NGワードとかメンションとか長すぎるものとか。 Not Contains ~ みたいなクエリを自動生成して叩いた。 100GBくらいまで減らせたので、あとはGCEでやる。

バッチ処理を実行するためのアーキテクチャ

BQから必要なデータを分割してファイル出力。 Preemptible VM 500台で1番で終わらせた。 ファイル処理が終わったかはApp Engineのpull queueで管理

構成

ユーザ -> Appengine -> Pull Queue (Request) ↓  ↑ Lease Instance Group -> Datastore

BQ -> GCS ↑ DL

Compute Engineを立ち上げた時のstart up scriptで pull queueから引っ張ってきたりとか DatastoreにPutしたりとかしてる。

スケールするアーキテクチャ

なぜ前段にApp Engineをかませているのか? スケーラビリティとアベイラビリティの向上 -> Compute Engineが忙しくてもApp Engineでタスクを貯めておくことができる。

発話ロジックの選択を行うことができる -> ロジックがかけるLB

Cacheの作成

スケーラビリティするには。

非同期・並列にする。

App EngineではQueueに入れたあとすぐに Responseを返す。

Pull Queueに入れ込んで、 Queueの中のTask数に応じてスケールする。

Firebase

発話をレスポンスするところができない。 LineとかはLine側のサーバに返せばいいけど、今回はレスポンスを直接プログラムに返す必要がある。

FireBaseを使う。 発話結果をFirebase Realtime DBに突っ込む。 App Engineはkeyだけを返す。 クライアントはkeyの場所をWatchしておいて、そこのメッセージを見る。

学習部分の課題

Tensorflowの学習部分 特に工夫していない。GCEインスタンスを手で立ち上げていた。 ちゃんと考えれば安価に効率よくできそう。

機械学習で並列化できそうなとこ

ハイパーパラメータの設定を並列化する。 途中経過を定期的に保存しておいて他インスタンスでやる Preemptible VMなので気軽に良いスペックを選べる

学習用アーキテクチャ

App EngineでPull Queueに突っ込むのと同時にインスタンスの数を制御して、 Instance 起動時に startup scriptに仕込む

Cloud Machine Learningがよさそう。

ハイパーパラメータの調整機能 ここの学習の並列化 学習済みモデルのデプロイ

Q&A

Chainer と Tensorflowの違いは? アルゴリズムが違うけど単純に組んだ人が違う。

エンジニアとして知っておくと幸せになれる(かもしれない)機械学習とTensorFlowのこと

スライド: https://goo.gl/o8gBB1

TensorFlow User Groupが立ち上がった。

https://goog.gl/NzrHei ↑ User Group

機械学習の勉強方法わからんすよ。

Step別イメージ

step1:ブラックボックスとして使う 機械学習アルゴリズムを使って

step2: 用途別に呼び出す手法を判断できる scikit-learn alogorithm cheat-sheet どれをやればいいかわかるチートシート

step3: 得られた結果の判断とパラメータチューニング

http://playground.tensorflow.org がいい感じ。

多くの人がstep2 -> step3で脱落している。

数学から逃げずに比較的硬派な本を読むべき

機械学習理論入門、実践機械学習システム, Python 機械学習プログラミング

— 深層学習との関連は? 機械学習アルゴリズムが取扱えるデータフォーマットへの変換が大きく影響を与える 深層学習では ロウデータを与えまくると向上する。けどパラメータチューニングするところが多くなって分からなくなる。

ImageNetという画像分類のベンチマーク Inception-V3

TensorFlow

2015/11に公開されたOSS音声認識やスパムフィルタで使われてるらしい。

TensorFlowは深層学習に特化したツールである。というのは勘違いであって、 データフローグラフを利用した数値計算のためのOSSソフトウェアライブラリ

ざっくり言うと 入力から出力までグラフを記述して最後に実行する。 分散処理の実行系。

Tensorflowのパラダイム

  • テンソルの演算グラフを作る
  • 実行単位をセッションとしてまとめる
  • 定数、変数をプレースホルダーとして宣言できて、グラフはCPU/GPUテンカイスル。
  • 分散処理も可能

Pythonをインターフェースとしているフレームワーク機械学習に関しては便利なヘルパーがある。

演算がグラフのノードとなる。 逆ポーランド記法みたいな

プレースホルダー : 学習データが変わって入るよ。という考え方。

セッション: 名前空間みたいなもの。別の環境で同じ関数を実行しているイメージ

多次元の話に拡張 -> テンソルを拡大

ランク 0 -> スカラ 1 -> ベクトル 2 -> 行列 n -> n次元配列

入力を多次元にすると、多次元にできる。

深層学習

入力に対して途中の演算があってアルゴリズムからの出力がある。 アルゴリズムを構成する演算それぞれに、理想的な出力値を返してあげる。 と、フィードバックがたまって人工知能っぽくなる。

データセットはよく使われるアイリスデータセットを使ってる。

tf.contrib.learn

scikit-learnを関数呼び出しの関学でTensorFlowで使えるようなもの。 深層学習以外のアルゴリズムも提供されている。

Keras

tensorflowをBackendとしたもの。

生のTensorFlowrを書くのは辛いのでtf.contrib.learnとかKerasになるかも

Cloud ML

TensorFlownによる学習をクラウド上で実行できる。 ローカルPCでやるのは辛い(スペック的に)

小規模でもGKE

http://www.slideshare.net/lestrrat/

カンファレンスのページの運用は割と技術力が必要 builderscon https://builderscon.io/

kubernetes visualizer

https://github.com/brendandburns/gcp-live-k8s-visualizer

https://github.com/builderscon

ミニマム構成をしている。

小規模構成でも得られるメリット(1)

1 .ノウハウの文章化

  1. Podが最高 Podは複数のコンテナ. pod単位で複製してデプロイできる。

  2. Node Pod内のコンテナは必ず同じNodeに配置される

4.Deploymentsが最高すぎる Deploymentがシステム構成のテンプレート Replica set 実際にデプロイされている構成 Replica set は世代ごとに管理されている

5.kubectl rollout undo とかでrollback できる。

6.kube-lego

Ket’s Encrypt対応 勝手に証明書の確認更新とかがしてくれる。

7.GCPのログが勝手に使える。

イマドキのGAE

google slideでいい感じにしてくれる機能があったりする。

最新の更新情報

App Engine のRelease Notesみればいい。 最新機能追加もなかったように安定したから更新がなくなってきた印象。 SDKは更新なし。repositoryは更新ある(go) 周辺のサービス(Firebase StackDriverなど)

Google app engine Flexible Environment (FE)

旧Managed VM / 自由なライブラリ,ランタイム、環境が利用可能 Dockerコンテナを走らせることができる。

Compute Engineよりは手軽に使えるものだと考えれば結構使えるかも

StackDriver

StackDriver Trace appstatsのサービス版

StackDriver Debugger ブレークポイントを直接置いてデバックできる。

LogVIewer ソースコード連携しとくとそこ見れる。

logger

Pub/Subに投げてCloud Functionsで処理を追加したりできる。

Cloud Endpoint v2

アプリケーション前にプロキシを置くことでAPIの監視、認証周りを実施

GAEは衰退した?

盛り上がりはないけど安定した。 普及気になった?

GCP全体で追うといいかも。

まとめ

いいイベントでした。自分が参加したセッションは席数も割と余裕あったし、キャパ的には余裕そうでした。 Wifiは飛んでなかったけどまあ大学借りてやってるししょうがないよね。

Fitbit Charge HRが故障したからサポートに連絡して交換してもらった。

6月にかったfitbitがラバーバンドが取れかけてきて、ラバーバンドの下のプラスチック部分にも亀裂が入ってきた。

このまま使い続けると防水的な意味で不味そうなのでサポートに連絡してみた。

サポートに連絡

Fitbit Help

のサポートに連絡からEメールサポート -> 製品を選択でCHARGE HR

-> プラットフォームを不明/その他 -> 問題を選択を破損

を選択。

今回は以下の記事は役立ちますか?に当てはまらないのでEメールサポートをクリック

で、必要な情報を記入して写真も一緒に送った。

その後

メールアドレスに代替品を送るので保証書か領収書と本当にあなたのものが壊れているか証明するため 指定した番号を書いた紙と一緒に写真を送ってくれ。と言われたので、代替品送付先住所と一緒に送った。

そうすると1日ぐらいで確認出来たので代替品を送ります。1週間ぐらいで届きます。と連絡が来た。 (国内代理店で買わないとだめ。とはいえ、そうそう国内代理店以外ではうってないので問題ないと思う) Fitbit 製品の小売業者一覧

代替品送付

クロネコヤマトでそのメールが送られてきた3日後ぐらいにきました。 受け取れなかったので土曜日指定に変更して受取。

サポートの良さ。

平日に送ったので大体レスポンスまで1日で返してくれました。 かなりサポートの対応は良かったです。

参考

Fitbit Charge HRのラバーバンドがおかしな事に。サポートが神対応だった!

この記事を見ていけるかなーと思い問い合わせてみました。 破損の状況によりますが、買い換える前に念のため問い合わせてみるといいでしょう。

入社後3.5年たって

入社後3.5年

いつの間にか入社して3.5年も経っていたので、いろいろまとめてみようと思う。

意味のない仕事はない

実案件やっている時にこの仕事意味あるのかな。俺がやる必要あるのかなと思うこともあったけど、 思い返してみればすべては力になっている。

この前の勉強会でもあったけど、引き出しという点でいろいろできたのは良かったかなと思う。 趣味開発は楽しさに逃げて辛いことはやらないけど、実は辛いところこそ身につくところだと思う。

できない。に逃げない

できない。というのは言い訳でしかないし、それで怒られたこともあった。

できないというのはそこで思考停止に陥っていることになるし。 konifar.hatenablog.com

konifar.hatenablog.com

できないって言っていいのは - 法律に違反しそうな場合 法律に違反するのはダメだし、もうその場合は潔く会社やめるか告発するか

  • 使っているサービス(クラウドとか)の制約上できない場合 方針としてあるクラウドサービスを使うことになっていて、それで機能がない場合

  • やらないほうがいい場合 上の記事にある通り。やってやれないことはないけど、費用がかかりすぎちゃってできない場合とか。

プログラミングのみできるエンジニアにならない

すごくプログラムが書けて保守性も高く他のエンジニアに比べて2-3倍書けますよ。って人は別で、普通の人はそのレベルに達することはなかなかできない。 プログラムを書く能力はそれはそれで必要だけど、設計能力とその設計を実装単位でタスクに分類できることだったり、ミドルウェア周りやインフラ周りが強かったりと、プログラミング + αの能力が必要だと感じている。

よくエンジニアマネージャになりたくない問題があると思うけど、ちゃんと技術に精通していてマネジメントできる人材はすごく貴重だと思う。

英語

日本語ドキュメントだけだとどうしても限界があるし、クラウドサービスやOSSも英語のドキュメント見たほうが早いし、 問い合わせとかも英語だし英語を読む・書く能力は最低限必要であることは感じている。

google翻訳とか使うのは別に問題なくてそれで翻訳した内容に違和感あって直せるレベルは必要。 話す能力は英語が必要なところで働いていないからなんとも言えないや。できればいいし、かっこいいけど

情報の発信と整理

インプットはもとより、細かいことでもアウトプットは必要。 あとアウトプットも整理されたものだといい。

今後必要なこと

  • 業務以外でプログラミングしたりする時間を増やしたい。どんな細かくてしょぼいものでもいい。
  • 他の言語。特にスクリプト系じゃなくてコンパイル系の言語

【なつやすみのしゅくだい】go言語でfitbitAPIを叩いて睡眠情報を取得する。

【なつやすみのしゅくだい】

前々からgo言語触りたかったってことと、FitbitAPIを叩いて情報を取得したかったので、夏季休暇期間の暇な時間にgo言語でfitbitAPIを叩いて睡眠情報を取得してみた。

ソースはこちら

github.com

作業のお供

zenpad7で dアニメストアでアニメ見ながら作業するのが捗った。
タブレットスタンドがかなり役立った。 CLANNAD Afterの後半とハナヤマタ前半見終わった。

anime.dmkt-sp.jp

fitbitAPIを使うために諸々登録する

dev.fitbit.com

dev.fitbit.comにユーザ登録をした後アプリケーションの登録を行う。
f:id:ytacky:20160818201858p:plain

画像の通りに必要なところを埋めていく。
Applicatinon NameやDescription, Application Website, Organization, Organization Websiteまでは適当でOK
自分で使うだけだし。
OAuth 2.0 Application Type はClientを選択した。
Using Implicit Grant Flowを使うためにはClientを選択する必要がある。

Using OAuth 2.0 — Fitbit Web API Docs

Callback URLは重要で、ここで登録したアドレス以外がcallbackのURLとして指定されても使うことができない。
今回はgoのビルドインサーバを使うのでlocalhost:8080とした。
Default Access Typeは読み取りだけでいいのでReadとした。

これでSaveすると、OAuth 2.0 Client ID / Client Secretが発行される。
また、 OAuth 2.0: Authorization URI と OAuth 2.0: Access/Refresh Token Request URIも取得できる。 (このURLは共通なので発行される。というより表示される。という書き方が正しいかもしれない)

どんな感じに叩くか確かめたい

Fitbit API Debug Tool

Debug toolが用意されている。
これに自分のClient IDやsecretを入力し指示に従って行くと、一通り認証から必要な情報の取得までできる。
プログラムを組み終わった後この機能に気づいた...

認証ページのURLを生成する

generateOauthURL.goとして作成した。

今回はAuthorization Code Flowで認証するための認証ページのURLを作成した。 examplsにあるように、

https://www.fitbit.com/oauth2/authorize?response_type=code&client_id={client_id}&redirect_uri={redirect_uri}&scope={scopes}

となる。 client_id/redirect_urlは上で生成したものになる。

scopeは

Using OAuth 2.0 — Fitbit Web API Docs

から見たい情報のscopeを選択する。今回は睡眠情報なのでsleepを指定。複数の場合空白で繋げて%エンコードする必要がある。 (%20で複数scopeをつなぐ)

コード上では、HttpParam構造体とAuthUrl構造体を作り、必要な情報はこれを使うようにしている。
また、環境変数は.envとしてアプリケーションのルートディレクトリに作成して、それをgithub.com/joho/godotenvライブラリを使用して読み込んで使用している。

アクセストークンの取得

上記で生成したURLにアクセスすると認証画面が表示され、認証するとredirect_urlに設定したページに飛ばされる。
このリダイレクト先をfitbit.goとして作成している。
今回は簡単に使いたかったのでgoのbuild inサーバを使用している。

リダイレクトされるとクエリパラメータに?code=とaccess token取得用のcodeが付与される。
まずはこのcodeを使用してaccess tokenを取得する。

https://dev.fitbit.com/docs/oauth2/#accessT

endpointのURLはhttps://api.fitbit.com/oauth2/token これに対してPOSTを行う。必要なBody部分としては、
リダイレクトのときについてきたcodeとgrant_type=authorization_code,client_id,redirect_uriが必要。 また、Headerには {client_id}:{client_secret}をBase64 Encodingしたものが必要となる。:をつけた状態の文字列をBase64 Encoding忘れるのがありがちなミスなので注意したいところ。

これでPOSTするとjson形式でaccess_tokenやscope,user_idが返却される。
この値をdecodeしたいので、FitbitJsonという構造体を作り、json.Unmarshalでdecodeした。

これで睡眠情報を取得するためのユーザIDとaccess_tokenが取得できた。

睡眠情報を取得する。

Sleep Logs — Fitbit Web API Docs

睡眠情報に関してAPIは多種あるが、今回は単純に睡眠時のログを取得するAPIを叩く。
APIのエンドポイントは、https://api.fitbit.com/1/user/[user-id]/sleep/date/[date].json となる。user-idはアクセストークンの取得で取得できたものを使用する。
dateはyyyy-MM-dd形式で指定する。
このAPIを叩くときには認証が必要なのでHeaderに Authorization: Bearer [access_token]
を与えてあげる必要がある。
これで睡眠情報が取得できる。

睡眠情報の形式

以下のようにjson形式で返却される。 (ここでは見やすいようにjson_decodeしたものを記載している)
起きた回数や睡眠効率。何時に寝てその時間帯はどんなステータス(寝返りを打っていたのか、目覚めていたのか)
何時間寝ていたのか。など取得できる。

{
    "sleep": [
        {
            "awakeCount": 0, 
            "awakeDuration": 0, 
            "awakeningsCount": 13, 
            "dateOfSleep": "2016-08-xx", 
            "duration": 25260000, 
            "efficiency": 94, 
            "isMainSleep": true, 
            "logId": 12226936629, 
            "minuteData": [
                {
                    "dateTime": "00:49:30", 
                    "value": "1"
                }, 
                {
                    "dateTime": "00:50:30", 
                    "value": "1"
                }, 
               ~~~~~
                {
                    "dateTime": "07:49:30", 
                    "value": "1"
                }
            ], 
            "minutesAfterWakeup": 0, 
            "minutesAsleep": 396, 
            "minutesAwake": 25, 
            "minutesToFallAsleep": 0, 
            "restlessCount": 13, 
            "restlessDuration": 25, 
            "startTime": "2016-08-xxT00:49:30.000", 
            "timeInBed": 421
        }
    ], 
    "summary": {
        "totalMinutesAsleep": 396, 
        "totalSleepRecords": 1, 
        "totalTimeInBed": 421
    }
}

今後

REFRESH TOKENをつかって認証したり、何か別なシステムと連携して捗るようにしたい。