今年も個人スポンサーです。
エンジニアなら使える深層学習 〜TensorFlowやDataRobotで機械学習がもっと身近に〜
シバタアキラ氏 @madyagi
DataRobot
http://www.slideshare.net/hijiki_s/akira-shibata-at-developer-summit-2016-58449436
http://togetter.com/li/940094
データロボットって？
まだステルスな感じ
100人くらい
60億くらい調達してる
kaggle
トップKagglerが在籍
PyData Tokyo
データサイエンティストのたまり場
PyData.Tokyoは開始当初から深層学習やってた
人工知能って何？
Google発の深層学習フレームワーク「TensorFlow」が一般エンジニアに与える可能性
- ディープラーニングすごすぎ
- シンギュラリティやばい
人工知能＞機械学習＞深層学習
機械学習とは？
アルゴリズムにデータを分析させてパターン学習させることで予測や識別などの問題をとかせること
大事なのはどう言うデータを入力して、どう言う問題をとかせるかということ
- 分類
- 2地分類
- 多値分類
- 回帰
- 時系列
- 時間と共に動く数値を予測するかとか
- レコメンデーション
- クラスタリング
トラディショナルな機械学習は歴史が古くてビジネス分野での応用されてる
進化している
こんな遷移をしてる
- 研究者が自分でアルゴリズムを考案して論文発表（かまどで炊く）
- コーディングできる人は使える（自分で作る）← 深層学習はイマココ
- ボタンポチーで誰でも使える（電子レンジでチン）← イマココ
DataDogのデモ
再入院率の予測
以前ならデータサイエンティストが何ヶ月もかかって出してた結論をサクッと出してくれる
深層学習って何？
ニューラルネットワーク型のアルゴリズムの隠れ層を多段にすることでしばらくは成果が出てなかった
- HWの進歩
- GPU
線形代数的な変換をかけるっていうのを何回も何回も組み合わせて出していく。
これを深層学習にする。
めちゃ増やす。
決定しないといけないパラメータが膨大になっていく。
上記を天才ががんばったおかげで色々できるようになってきた
最終的に解決できる問題の質は変わっていない。
何が違うか？
特徴量を自分で作ってくれて、それを判断に使うことができる
教師なし学習
TesorFlow
深層学習の構築に必要な線形代数を表現し、GPUなどの分散処理技術を使って高速に計算するためのライブラリ
Python/C++でわりと簡単に使える（超かんたんとまでは言わない）
Googleの物体識別アルゴリズム、Inception3は96%以上で人間より精度が高い
（実際に同じ問題を人間がやったら95%だった）
TensorFlowデモ
怪しげな画像を識別してみたｗｗｗ
DeepDreamももうすぐTensorFlowから使える
COMING SOON
深層学習は今コーディングできる人はできるレベルになってきてる
これからは機械学習できる人だけじゃなく誰でもできる
→その業界にいる人の知識を使ったアイデアを実現できるようになる
MARSFACE PROJECT
現場を変えたサービスのつくりかた - 何を作るのかではなくなぜ作るのか -
どういったマインドでYahooの人達が作ってるのか
荒瀬さん Yahoo
アジャイル開発推進、導入、改善サポート
http://togetter.com/li/940094
アジャイル開発
大多数がスクラムを採用している
- スモールチーム
- 権限委譲
これがスクラムに適している
イノベーター理論に当てはめると、レイトマジョリティ
普及活動はいったん落ち着いて、改善活動にシフトしてる
今日話すこと
- 支援サポートしてた内容
- 改善の取り組み
間違ったアジャイルしてるチームもちらほらいたのでそれをどう改善してるか
アジャイル開発チームの変化
変化の定義
- アジャイル開発前
- プロダクトマネージャーと開発チームが別れていた
- 依頼して、チームが作る
- 変化後
- アジャイル開発チーム
- なぜ作るのかを考える
- チーム全員が考えるようになる
- プロダクト開発をチームで考える
変化の傾向
傾向は大きく4段階
- ファースト変化
- チーム開発の可視化
- ここの担当しか気にしてなかった
- クロスファンクションな体制
- 可視化が必要になってくる
- セカンド変化
- 開発サイクルが安定
- スプリント1週間のチーム
- 差し込み案件が多いチーム
- リモートワークチーム
- 2週間のチーム
- 開発に集中したいチーム
- 作業のムダが目につくようになって改善に向かう
- ミーティング調整がムダ
- 依存タスクがムダ
- 見積もりすぎる計画がムダ
- 粒度はこれでいいのか、そこらへんを改善
- ムダをそぎ落としていった結果、開発サイクルが安定、早くなる
- サード変化
- 自立したチーム
- チームの成長にチームが責任を持つ
- 開発サイクルが安定すると視野が広がる
- チーム全体の課題が見えるようになる
- 改善に向かう
- フォース変化
- プロダクトマネジメントチーム
- プロダクトオーナーの考えてるビジョン
- プロダクトオーナー視点でチームが考えるようになる
サポートの内容
- 導入サポート
- 改善サポート
スクラム実戦前サポート
アジャイル開発を理解するためのワーク
チーム設計
目指すチームの決定
一番重要視してるところ
- スクラム実戦する目的
- 目的を達成した理想のチーム像
- 理想のチーム像への明確なゴール
- チームの現状
あとは進む速度とかを決めるためにメンバー同士で期待していることなどを共有する
まずはスクラムマスターを代役する
スクラムマスター1 on 1
サポートポイント
大事にしてること
ストレスを軽減すること
開発プロセスが変わる
働き方が変わる
アジャイル開発が好きな人だけとは限らない
やりたくない人は特にストレス溜まる
教科書のルールを全部守るのではない
個人の感情とかも踏まえて進める
スクラムの原則だけは守る
改善サポート
チームを観察
スクラムマスター1オン1
- 課題、チーム状況の確認
- じつはただのウォーターフォールになってないかとか確認
- チームの成長の確認
- プロダクトの確認
必要ならファシリテート
とにかくチームが成長しているか
正しくスクラムやってるか（＝チームが成長したい姿になっていってるか）
スクラムになれてくるとマンネリに…
似たような改善とか、改善しなかったりとか、チームの成長が止まる
スクラム実戦、ルールを守ることが目的になる
- 成長、ゴールの再認識
- 改善のテクニックやナレッジシェア
組織改善の取り組み
- 組織の課題
- 取り組み
組織の課題
アジャイル開発が形骸化してくる
- スクラムルールを守ることにフォーカスする
- 目先の課題解決だけで本質の問題を解決しない
- スクラムマスターと開発チームを兼任してる事が多くて、解決すべき課題を許容してしまう
アジャイル開発状態不明
広まっているので、サポートチームが知らないところでやってる
- サポートが必要なチームをピックアップできない
- オレオレアジャイルが蔓延してないか
- 正しくやってないせいで効果を感じられずにアンチになってしまってる
取り組み
アジャイル開発コミュニティを作って興味のある人を入れて一緒にやっていく
サポートする範囲が広がってるのでコミュニティでやる
メンバーと一緒に社内イベント・研修をしてる
Yahoo全体の底上げ
ワークショップでレゴスクラム
これからの取り組み
チーム評価アセスメント
- チームは自立しているか
- 中長期の計画は見積もられているか
- 品質は随時見直されているか
コンテンツ配信
- 導入チーム向けのアジャイル開発Tips、コンテンツ
- マインドとかのコンテンツ配信予定
- まんがで分かるダメなスクラム
改善意識がない人は勉強会とか開いても来ない。
まずは読んでもらうこと。
敷居を下げるためにマンガで配信してみる。
もしかしたら気付いてもらえるかもしれない。
まとめ
アジャイルは効果が見えやすい
数ある手法の一つとしてのアジャイル開発
大事なのはアジャイルが良いんじゃないかって時にすぐに使えるようにする体制作りが大事
大規模SPAをTypeScriptとAngularJSを駆使して5ヶ月で作った話
リクルートマーケティングパートナーズ 山田氏 @wakamsha
完全SPAを目指した
いきなりフロント振られたｗ
元Flashデベロッパー、ActionScriptはすでに忘れた
SPAはやったことない
情報はプロダクトオーナーの壮大な夢が書かれた社内Wikiのみ
まずは技術調査
想像はついた。
Javascriptが大規模になる。
開発言語を何にするか
- CoffeeScript
- Babel
- TypeScript
TypeScriptを採用
- 静的型付け言語が一番の理由！
- 多機能
- 将来しありそうと判断
- 早い段階で決めた
フレームワークどうするか
AngularJS
- 多機能
- ルーティング機能が強力
- SPAに向いてる
タスクランナー
- Gulp
- Grunt
Gulpを採用
- Gruntと違ってよりプログラマブルに定義できる
- 複雑なタスクもけっこうかける
- プログラム書けるからごり押しでやれる
NET BIZ DIV TECH BLOGに大体書いてる
アウトプットまでやって技術調査
その後
仕様が決まってない
なぜ？
POが過去のいざこざがあって現場に来ない
現場リーダーがやりとりするんだけど憔悴していく
見ているしかできなかった。どうしようもない…。
やばい
メンバー全員で缶詰。
技術調査とか全部ストップしてやった。
POを引きずり出してきた
開発スタート
ツーマンセルで開発
新卒の子がすごかった
TypeScriptが2日、AngularJS1週間
設計は何度でも見直す
めっちゃダメ出される
大丈夫ですか？
がががが、がんばります
UI Routerを導入
AngularJS使うときはこれをセットで使うのが定番くらいのいいもの
開発ポリシー
- コードの品質に妥協しない
- スケジュールの余裕とか気にしない
- とにかくやる
- プルリクは優先的にさばく
- 夜にまとめてやるとかじゃなく、依頼来たらその場で見る
- 手を止めてやる
- わからないことがあったら即座に聞く
- 先輩・後輩とか関係ない
- 初歩的な質問でもまじめに答える
- これすごく重要
進んでいく開発
佳境
細かいバグが大量に積み上がって大変
iSO&AndroidエンジニアもWebに参戦
わからないところはプルリクやペアプロでカバー
領域に捕らわれずに一つのプロダクトにみんなで取り組んだ
これがけっこうよかった
終盤
IE9のみで発生するクロスドメイン問題
API疎通がどうしてもできない
IE9のサポート切ろうぜ！
他のサービスでIE9の利用率はどれくらい？→8％…
微妙な数字
切った
リリース
ホワイトな感じで開発できた（残業/休日出勤なし）
まとめ
TypeScriptに救われた
- 型は正義
- 明示的に型は定義してる
- コード量は増えるけど、いいはず
- コード量増えるんじゃないの？→エディタ変えた方がいい
- SublimeTextからIDEAに乗り換えた
- タイプ数は減った
- Javascript苦手な人にこそオススメ
AngularJSも正解だった
- 学習コストはたしかに高い。
- 代償を払う価値は十分にある
- 過去AngularJSにチャレンジしたけど挫折してる
- Vue.jsにチャレンジしたら余裕だった
- Vue.js→AngularJSでいってみるとすんなりいける
- UI Routerは超いい
その他
- 絶えずリファクタリング超大事
- 自分が携わってないところを理解できてない
- リファクタリング時に俯瞰してみるので理解するチャンス
- 勇気を持ってやってみると見返り大
- プルリクは優先的に
- 相手の作業をストップさせない
- お互いのコードを見続けてるとコードが似てくる
- 指摘箇所が少なくなってくる
- レビューのコストが下がる
- レビューのサイクルをたくさん回す
- 小さいことでも分からなかったら聞く
- 人間関係大事
- POといつでもどこでもコミュニケーションできることが大事
- 自社開発だと特に大事
Spark入門
一言で言うとオープンソースの並列分散処理基盤
分散処理でなくてもいい処理を実装しがち
分散のフットプリントがあるから筋はよくない
MapReduceの良い点
シンプル
しかし…
色々使っていくと処理効率が課題になる
- ジョブが多段に構成される場合
- 反復処理・機械学習
- 複雑な業務処理（売上げデータの集計とか）
- 複数ジョブで何度も同じデータを利用する場合
Sparkとは
抽象化を進めて、スループットとレイテンシとのバランスを追求し、使いやすいAPIを提供
他の話してて全然聞けませんでした。。。。
大規模Redisサーバー縮小化への戦い
アカツキ 駒井氏
インフラ運用保守担当
AWSのElastiCacehの話
- Redis dumpのバイナリ構造
- マージ方法
- マージ後に発生した接続数トラブル
前提
Redisって何？
インメモリデータベース
KVS
構成
EC2の20台に対して64台のRedis
元々は8台運用だった
緊急対応で64台にスケールアウト
KEYSコマンドはパフォーマンスめっちゃ落とすから本番では細心の注意払って使え
KEYS("*")使ってるところがあった
サーバー増やしても意味なかった。
64台→135万円/月!!!
冗長化に腰が重くなる
設定ファイルがヤバいことになる。
運用するの辛い
やってみよう
現状整理
- ショップのセール情報
- イベントのランキング情報
- ゲームのフレンドの情報
何か同じデータがはいってるっぽい
各Redisが使ってるdbは一個だけ
コピーしてサーバーを増やした
dbを分散させた結果、ゴミが残った
マージ検討
- マージできるの？
- 公式ドキュメント→のってない
- AWSドキュメント→のってない
- それっぽいツール→動かない
自分たちでやろう
- 案1 全部取って別のdbに入れてく
- 案2 ダンプファイルを結合しよう
- データアクセスしなくてもよさそうだからこっち採用
ダンプファイルの中身
バイナリデータ
意外とちゃんと見るとシンプルな構造
- ヘッダ
- DB番号
- データ
- 終端文字
- チェックサム
マージ方法
前のファイルの終端とチェックサムを消し、後のファイルのヘッダ消して単純に結合
リストアした結果…
チェックサムを更新してなかったからエラー…
ダンプファイルがデータ構造問題ないかチェックする方法
redis-dump-check
定期メンテナンスでつなげた
縮小化の流れ
EC2にRedis server立ててRead Replica作った
失敗談
1台目のリードレプリカ取った後、2台目のリードレプリカ取ろうとしたとき、タイムラグがけっこうあった
終わった後…
突然のエラーの嵐
接続数がヤバイ
Redisクライアント側のサーバーが増えていって、Redisが悲鳴を上げた。
maxclients -> 65000
複数DBを使ったことで16倍になって接続数が激増
→ 接続数上限変更しよう！
→ AWSは変更不可…！！！
再度縮小
台数減らしの次はDBの数を縮小
マージ方法の検討
ダンプファイルのマージは難しそう
案1は計算量は多いけど、どうにかなりそう
まとめ
- 2種類のRedisマージ方法
- ダンプファイル構造
- 複数db使うときは接続数に注意
マイクロサービス時代の動画配信基盤 Ruby x Go = ∞
DMM.com Labo 小島氏、江藤氏
システムアーキテクト
動画配信基盤の刷新中
マイクロサービスとは
独立した軽量なシステムをシンプルに連携し構成したアーキテクチャ
連携＝主にHTTPのRestfulな通信を想定
モノリシック
むかしDMMは色々一つでやってた
会員1900万人
大規模化してる
独立した軽量なサービスを小さなチームで作ることで、開発のスピードを上げる
動画配信基盤
インターネットを介して動画コンテンツを配信するサービス
動画配信は大きく2種類に分類
- VOD 録画されてる動画を配信
- LOD ライブに動画を配信
システムの切り出し
- 論理的な独立性を考慮する
- 物理的な独立性を考慮する
一つの変更が他に波及
多くの場合、ソースコードの変更によってバグが生まれる
レガシーシステムではサービス毎にモジュール持っていた
課金の変更があった場合、それぞれのモジュールで変更が必要であった
プラグインシステムにして、必要なものを選択するようにした
ソースコードの変更を最小限にした
Pub/Subメッセージングモデル
使いどころは？
設定変更を伝播させる
APIポリシー定義
普通にやると全部異なるものができてしまう
RESTful API over HTTP(s)
Twitter REST APIを参考にした
HATEOASのベストプラクティスにならって作った
APIできたけど
デバッグがしにくい
リクエストの開始から終了までを追いにくい
プロトコルシーケンスがドンドン長くなる
トレースIDを付与した
開発
どうやって技術選定したか
- エンジニアが
- 習得できるか
- 成長できるか
- 確保できるか
マニアックな言語を選ぶとエンジニアを確保できない
説得する際の品質特性の表を作った
- 開発コスト
- 環境適応
- 機能
- 拡張性
- 将来性
- 学習コスト
- 信頼性
- レスポンス速度
実装詳細
大規模高負荷が予想されるシステムに抜擢
設計、言語選定しましょう
やったことないので不安。
チャレンジするチャンス！
管理系システム
- 負荷は少ない
- 柔軟性を持たせる
言語は？
- Ruby
- Node.js
- PHP7
Railsやりたい欲求によりRuby on Railsに決定
バックエンドAPI
- 高負荷
- 堅牢
- プラグインアーキテクチャで柔軟に
言語は
- Java
- Go
- Erlang
- C
Ruby, PHPはムリっぽい
Qiitaトレンドで調べてみた
なんとなくGoがよさげ
Go言語
- シンプル
- 厳格なルール
- コードフォーマット
- コーディングスタイル
シンプルな文化を強いられるが，ツールによるサポートがある
なぜGoがいいのか
- PHP, Rubyと逆の発想
- 実行速度が速い
デメリット
- JSONなどの動的データの扱いが不向き
- エラーチェックが冗長
- ライブラリが少ない
最終的な決定要素
- ハイパフォーマンス
- システムコールまで追える
Goで。
Rubyと比較した
Ruby
おもてなし
オブジェクト指向
鉄板フレームワークがあるRails, Sinatra
Go
郷に入っては郷に従え
並行プログラミング
フレームワークはたくさんある
ツールキット系が多いように思う
開発していて楽しい！
アーキテクチャ
KVSとしてAerospirkeを採用
configリロード
ホットリロードを実装した
デーモン化
Goは完全にデーモン化できない
模索中
開発フロー
- APIを先に書く？
- モックを先に作る？
JSON Hyper SchemaでYAMLを書く
Herokuのprmdつかってる
詳しくは3月3日の勉強会で！