マイクロチームでの機械学習PoC / ShibuyaSynapse #4,

Copyright © DeNA Co.,Ltd. All Rights Reserved.
多角型事業組織における
MLOps/AI基盤
~マイクロチームでの機械学習PoC~
Shibuya Synapse #4
confidential

View Slide

2
@yurfuwa
DeNA
System Unit,
AI System Dept.
ML Engineering Gr.

View Slide

Agenda (15min)
■ DeNAにおける機械学習案件と事業部
■ マイクロチームでの機械学習PoC
■ 機械学習案件のPoCはレポートレベルで良いのか？
■ フィージビリティスタディを加速させながらサービスを作る
■ What should I do?
3

View Slide

前提情報: DeNAにおける機械学習案件と事業部
■ DeNAは多角型事業組織であり、ドメインを定めない大小多数のサー
ビスと事業で成立している。
■ オンプレミスからAWS,GCPに主戦場が移り、数百のアカウントを持
ち、エグゼクティブサポートを受けている。
■ AIシステム部は機械学習特化型集団として、リサーチャーとMLエン
ジニア、データサイエンティスト約50名で構成。
■ リサーチャーはエキスパート寄り、MLエンジニアはゼネラリスト寄り。
MLエンジニアはデータエンジニアリングからサーバーサイド、アルゴ
リズムまで広く書けるスキルセット。
■ 事業部及び横断部と密に連携し、機械学習で事業貢献を推進。
4

View Slide

マイクロチームで
最大化するための
機械学習PoC
5
©Alejandro Lopez
https://creativecommons.org/licenses/by-sa/2.0/

View Slide

6
この先は実案件における紹介ですが、秘匿性が高いため
’何を’機械学習して’何を’達成すのかなど詳細は非公開となります

View Slide

マイクロチームでの機械学習案件
7
極少人数成果主義
コスト意識短納期

View Slide

PoCはレポートレベルでいいのか？
8
機械学習案件の

View Slide

■ 期待値調整によるが、大抵否。
■ その案件は、本当にフィージビリティスタディだけで終わるとお思いで
すか？
■ レポートレベルで上げても、運用に落とすリソースが現場に無い場
合、シビアな意思決定は避けられない
■ サービスとして提供されたほうが、目に見えてわかりやすい
■ 非エンジニアの現場の巻き込みが圧倒的にしやすい
■ 成果はコトとスピードを尊ぶ。
■ ならそれを踏まえて、最初からサービスレベルで動いたほうが良い。
（予算掌握を忘れてはならない）
PoCはレポートレベルでいいのか？
9

View Slide

機械学習案件の
10
フィージビリティスタディを
加速させながらサービスを作る
https://commons.wikimedia.org/wiki/File:The_Z_Machine_(8056998596).jpg

View Slide

11
２ヶ月

View Slide

12
あるPoCの初期開発に当てられた
開発期間

View Slide

2ヶ月で運用まで持っていく
13
Nov Dec Jan Feb Mar On Seasons
承認
フィージビリティ
スタディ
コア開発サービス品質改善・運用
リアルタイムデータ導入によるCDとアルゴリズム改善
評価
評価評価

View Slide

2ヶ月で運用まで持っていく
■ 結局の所、実データで、実サービスで触ってみないと何もわからない
ことが多い
■ 過去データも重要だが、PoCでもいかにリアルタイムなデータに触れ
て、リアルタイムなフィードバックから導いたアルゴリズムとサービス
改善が大切
■ とある事情で3月に生データが大量に来る案件では、企画承認から
2ヶ月しかなかった
■ とある事情で3月からの1日1日は、データ的にあまりに価値が高く、
一日とて遅れるわけには行かなかった
■ それまでにPoCでフィージビリティスタディと、形作りを行うことで、生
データの運用開始時点でステークホルダーからのフィードバックが
返ってくるだけでなく、チームも計画段階では気づかない課題を積む
ことができた
14

View Slide

開発体制(※極端なケース)
15
・クラウドインフラ
・データパイプライン
・データウェアハウス構築
・バックエンド
・フロントエンド
・サービス設計
・IA,UI,UX
・CD/CI
・Automation
MLE
PO,
Researcher
Researcher
・コアコンセプト
・データサイエンス
・リサーチ
・アルゴリズム
・データエンジニアリング
・CV(前処理,後処理)
・Automation

View Slide

MLOpsでMLエンジニアが主に取り組む課題
■ E2Eでのデータフローとシステムアーキテクチャ
⁃ データウェアハウスの整備、設計、実装
⁃ セキュアなデータのやり取り、ネットワーキング
⁃ 機械学習フレームワークにロックされないシステム構成
⁃ 非同期的な学習プロセスとパイプライン
⁃ 学習用/サービス用APIの開発
⁃ アノテーションシステム
⁃ CI/CD
⁃ 自動化
⁃ 可視化
• IA,UI/UX
• フロントエンド
16

View Slide

17
全部やる
※全部やれと上から言われたわけではないことに注意
DeNAはあらゆる裁量がエンジニアに任される。
コトをなすために我々がすべきことをやるまで。

View Slide

18
What should I do?

View Slide

19
クラウドをシンプルに
フル活用する
シンプルな答え 1

View Slide

マイクロチームでのPoCにおけるクラウドをフル活用
■ AWS/GCPは案件によって異なる。
■ 事業部側とAI側でマルチアカウントとなることが多い
■ データレイクからクレンジングされたデータをウェアハウスに、APIと共
に用意
■ 安易な潮流に乗るのではなく、案件の要件によって確実な構成と技
術選択を行う
■ ミッションクリティカル以外は速度を優先する
■ セキュリティ要件を踏まえ、VPCダイレクトコネクトや専用線、データ暗
号化(SSE-KMS)を徹底的に活用する
■ エグゼクティブサポートを有効活用する
⁃ フルスイングを参照
20

View Slide

あるPoCでのシステム構成例
21

View Slide

機械学習PoCにおけるAWSでの最小MLOpsシステム例 1/2
■ 学習環境
⁃ 自社共通基盤に乗り、土固め。
■ API 環境
⁃ k8sのないtokyoにおいてECSよりもさらに小回りの効くEBという選択肢
⁃ ElasticBeanstalk Multiple Docker Container
⁃ docker-compose like なECR+ECS+ALBコンテナオーケストレーション
⁃ マイクロサービスとして展開し、学習環境とは非同期/疎結合を維持
⁃ GAE,k8sなどを利用した競合システムに乗り換えが比較的簡単
■ Datastore
⁃ S3 + Dynamodb
⁃ Dynamodbには学習に利用するメタデータを格納
⁃ トラフィックのない小規模案件の場合、従量課金はオンデマンドRDSより割安
22
これらはマイクロチームでの機械学習PoCに当てはまるレイアウトであることに注意！
最初からタフなチーム構成で、シビアなトラフィック、スケーラビリティを要求される事業適応にはもちろん別
のレイアウトが適応される。この後のセッションをお楽しみに！

View Slide

ElastickBeanstalk Docker Multiple Container
23

View Slide

機械学習PoCにおけるAWSでの最小MLOpsシステム例 2/2
■ パイプラインはSQSで組む
⁃ 比較的安く、圧倒的に手軽。
⁃ SQS監視でキックされた学習ワーカが処理のシンプル構成
⁃ 但し、一定規模が見込まれる複雑なワークフローは素直にStepfunctionやAirflowを
使ったほうが後に幸せだが、速度優先のPoCでやる必要はないと考える
■ モデル・特徴量管理を煩雑にしない
⁃ リアルタイム推論が必要な場合、モデルをcontainer imageに閉じ込めバージョン管理。
特徴量を外出しさせる。
⁃ リアルタイム推論が不要な場合は、学習後推論結果をDB/cacheに格納。
⁃ PoCではサービングサーバは用意しない。Internal APIに入れ込む。
⁃ モデル・特徴のバージョニングは学習と非同期で更新できる設計にする
⁃ CircleCI以上のCDは、PoC段階では必要ない
⁃ Deployment,BlueGreenDeployはEBが担保
■ フロントエンドに銀の弾丸はない
⁃ ドメインによって、機械学習ではカバーできない部分(ブラックボックス)をサービスがUIUX
で解決することで、両輪の駆動となる。
24

View Slide

AWSにおけるシンプルな自動学習モデルデプロイ例
25
SQS
S3 Train
API on
Docker
on EB
Annotate
in model
container
enqueue

View Slide

AWSにおけるシンプルな自動学習+事前推論例
26
SQS
S3
Train and
inference
API on
Docker
on EB
Annotate inferenced results
dynamodb
enqueue

View Slide

27
共通基盤をフル活用する
シンプルな答え 2

View Slide

機械学習PoCにおける共通基盤のフル活用
■ クラウド環境基盤
⁃ 環境セットアップ前に基盤部とMLEが迅速に連携する機械学習用構成ツール
⁃ 基盤部が提供する謹製の共通基盤(aws-tools/gcp-tools)
⁃ 小規模～大規模まで柔軟に対応
⁃ 学習用インスタンス管理、Spotの自動選択など便利機能満載
⁃ spotinstanceの死活監視や、GPU不使用起動をSlack報告
⁃ 学習用インスタンス向けAMI
⁃ コストアラート
⁃ 事前にセキュリティ要件を満たしたネットワーク、セキュリティグループが提供
⁃ sagemaker / jupiter nootebook 環境もセットアップが簡便
⁃ 共通アノテーション環境(nota)との連携（内製アノテーションチーム利用）
■ 機械学習用共通ミドルウェアの開発導入検討（進行中）
⁃ 共通利用可能なモデルデプロイメント、サービング、パイプライン、モデル実験管理、ハイ
パラ調整などを統合した機械学習ミドルウェアパッケージの開発と導入を検討
28

View Slide

ところでGCPやk8sは？
■ もちろんDeNAは、共通基盤でも実案件でも利用している
■ k8sを利用した大規模MLOps案件も多数。さらにAWS+GCPハイブ
リットなプロジェクトもある。
⁃ DeNA TechCon 2019！
■ AWSはk8s対応しているものの、AWS独自のオーケストレーションで
MLOpsを強く推しているのはre:Inventの通り
■ 技術選択は各案件の複雑な要件、時流、コンテキストに依存するた
め、一概にどちらが良いとは言えない。
■ ただし、SPOFを排除するのはもちろん、どの選択肢も把握しておくこ
とは非常に大切。
29

View Slide

30

View Slide

31
まとめ

View Slide

まとめ
32
PoC＝
サービス提供
ロック回避
シンプル
抽象化された
共通基盤

View Slide

フルスピードで機械学習案件をドライブする
■ モデルアルゴリズムもMLOpsも物凄い勢いで変化する
■ 最小構成は最小構成の、大規模構成は大規模構成の、GCPとAWS
の強みをそれぞれを上手く活用して技術ロックを相互に回避する
■ 学習実験・共通基盤の抽象度を高める
■ 他社事例含め、大小様々な構成を横断グループで議論することで、
人的SPOFを排除
33

View Slide

34
ありがとうございました
@yurfuwa

View Slide

マイクロチームでの機械学習PoC / ShibuyaSynapse #4,

マイクロチームでの機械学習PoC / ShibuyaSynapse #4,

yurfuwa

More Decks by yurfuwa

Other Decks in Technology

Featured

Transcript