Machine Learning Production Pitch #5に参加しました
[更新] (12/13) 中川さんの資料追加しました
概要
2日前に続きMachine Learning Production Pitchに参加してきたので、その備忘録です。 資料追加されましたら順次更新したいと思っています。
machine-learning-pitch.connpass.com
イントロ
- 発表したかったらtwitterとかでつぶやくと見つけてくれるとのこと
gokartの紹介とgokartで失敗した事例
レポジトリはこちら
自分メモ
- いつも使ってます!
- データエンジニアとして機械学習以外全部やってるとのこと
- luigiをwrapしたもの
- エムスリーの機械学習バッチは全てこれにしたがって書いている
- 1つのタスクは
requiresoutputrunを実装するだけ - タスクが終わることにファイルを吐くという思想
- 再実行時などは中間ファイルが再利用される
- ワークフローが失敗した場合そこから利用できる
- MLエンジニアが余計なことを考えなくてすむ
- ログ、ジョブのslack通知など本質的でないけど重要な部分をライブラリ側でサポートしている
- レビューが楽になる
- 型にはまったコードになり、レビューする側も楽になる
- AIチームでは全員が全員のコードをレビューしている
- 以下失敗事例
- 開発時に起こりがち
- computer scienceで難しい2つのことは「キャッシュの無効化」と「名前付け」
- コードが新しくなってるのにキャッシュが使われてジョブが失敗することが多数
- MLエンジニアとDataエンジニアの境目に落ちる部分
- 早い段階ですり合わせることが大切
- そもそもキャッシュは人類には早すぎる
- 以下質疑応答
- なぜluigiベース?
- DigdagはJVM依存だからやめる
- airflowはcloud composerのバグを踏んで重厚すぎてやめた
- 薄い感じで自分たちも触れる点でluigiにした
- metaflowも触ってみている
- luigiにプルリク出さないの?
- dynamoまわりのやつ書いたけど、置いておいたら色々変わってそのままになってしまった
- luigiとgokartの思想の違いは?
- outputを省略できるとか
- 詳しくはtwitterで
フリーランスだらけのML基盤開発
自分メモ
最近使っているプロダクトの構成
- 1API-1レポジトリ
- devデプロイはcircleCIで自動化
- なるべくシンプルな作りにしている
- ジョインコスト低減
- 本質的な開発に専念
- 一方でなるべくモダンにしている
- 新しい仲間に来てもらうための環境づくり
フリーランスが多いプロジェクトの悩み
講じた解決策
- 関心外に関与してもらわなくても良い構造
異なる専門間でのコミュニケーションを削減し負担を減らす
質疑応答
- フリーランスの情報の管理はどうしている?
- 個人情報はマスクしている
- properから提供されない
- type hintで制御しきれなかった例は?
- type hintだけでなくisinstanceで見に行っている
- フリーランスの情報の管理はどうしている?
楽しむために楽するアーキテクチャ
www.slideshare.net
自分メモ
- リサーチャーとキャッチアップして最新の技術をプロダクトに活かせないか考えている
- プロダクトにフィットするアーキテクチャの考察
- 忙しい仕事内容の中で楽しく仕事するために楽するアーキテクチャを構成したい
- statefullとstatelessが混在しているのが特徴
- 平日と土日では負荷状況が変わる
- 土日に負荷が大きいが、サラリーマンなので土日は遊びたい
- 気づいたらサービスが成長しているぜって安心してみてられる開発状況を保ちたい
- サービスの形態に応じて変更を容易にする
- 負荷に対してエラスティックにスケールする
- 障害が起きても勝手に回復する
- 変更性、拡張性、回復性
- 動画解析をマイクロサービスのDAGとして実装している
- DAGを組み替えれば変更も容易
- それぞれのタスクをオートスケールできるようにする
- 冪等性を保ちつつリトライする
- statefullなやつが厄介
- データの層とロジックの層を分けて、SearchとUpdateのみでやりとりさせる
- 楽しむために楽をしよう
クックパッドでの機械学習デプロイ&データフロー
自分メモ
- 材料名や手順の正規化後ほど
- まずはjupyeter notebookをスクリプトにする
- 実験フローの構造化
- Dockerで動かせるようにする
- 最低限のテストは書く
- 教師データを継続的に管理する
- 大量のデータを安全に取得する(サービスに負荷をかけないようにする)
- Redshiftに安全にクエリをするような社内ツールを使っている(サービスに負荷をかけないようにする)
- Queury
- HTTP APIでクエリを発行できる内製ツール
- 機械学習エンジニア自身でデプロイまでやる
- Hakoというデプロイツールを使っている
- ECS上で動作する
- 機械学習はバッチで実行している
- dmemoを使ってDB・スキーマにメモを書いている
- 推論結果をちゃんと使ってもらえるようにしている(使ってもらわなきゃ意味がない)
- 機械学習エンジニアが最後まで面倒をみる
マイクロサービス化されているので他に迷惑をかけない
質疑応答
- 社内ツールを運用するチームがあるの?
- SREチームなどが担当してるOSSにしてるのでPRきたりする
- ライブラリのバージョン違いで死ぬことを管理してます?
- pipのバージョンをちゃんと指定しておく
- 社内ツールを運用するチームがあるの?
まとめ
普段使っているgokartの失敗事例を聞けたのはすごく貴重でした。キャッシュ、注意します。
いかに機械学習部分に集中できる環境づくりをするかというのは本当に重要だなと感じる今週となりました。
