DeNA の MLops エンジニアは何をしてるのか【DeNA TechCon 2021 Winter】/techcon2021 winter_5

DeNA では様々な事業で AI を活用しており、事業毎に異なる制約条件のもとデータサイエンティストが様々なモデルをつくっています。

データサイエンティストがつくったモデルはそのままでは利用できず、実際に利用するために機械学習基盤やインフラを用意したり、フロントエンドの開発を行うなど、様々なサポートが必要となります。そういった AI 以外の全てをサポートするのが MLOps エンジニアであり、様々な課題を解決することが求められます。

本発表では、DeNA の MLOps エンジニアの業務を俯瞰しながら、主に機械学習基盤周りの話をご紹介するとともに、MLOps エンジニアがどのような課題と日々向き合っているのかお話します。

Transcript

1. DeNA の MLOps エンジニア
   は何をしているのか
   Takumi Kawase
   

   View Slide

2. 自己紹介
   - 川瀬拓実
   - 20卒エンジニア
   - システム本部データ統括部AI基盤部MLエンジニアリング第一グループ
   - 通称 MLEG が MLOps を行っている
   

   View Slide

3. MLOps って何？
   - DevOps + AI が組み合わさった概念で、特に AI 周りのサポートをする
   - DeNA では AI 以外のすべてをスコープとする
   - その集団が MLOps エンジニア
   - もちろん AI のドメイン知識があると尚良い
   - 少ない人数でも業務が回る（スケールする）ように主に自動化を頑張る
   

   View Slide

4. 具体的に何をしているの（主なスキルセット）
   - フロントエンドの開発
   - React, Vue, TypeScript
   - バックエンドの開発
   - Python, Go, Database(MySQL, NoSQL…)
   - クラウド
   - Amazon Web Services, Google Cloud Platform, Terraform
   - コンテナ
   - Docker, Kubernetes(K8s)
   - CI/CD, セキュリティ、ネットワーク、アーキテクチャ etc...
   

   View Slide

5. 今自分がしていること
   - データサイエンティスト (DS) が作った成果物を提供する
   - フロントエンド開発(Nuxt.js → Next.js)
   - バックエンド開発(FastAPI, MySQL)
   - インフラ(AWS)
   - ツールの作成
   - AI を活用した web API の運用
   - Pococha 関連の AI を実際に運用中
   - 不正な配信を自動検出し、サポートの負担減
   - 機械学習基盤 Hekatoncheir の開発（メイントピック）
   - Web API サービング機能の整備
   

   View Slide

6. 機械学習基盤 Hekatoncheir
   - DS が作ったモデルをプロダクションに持っていくにはいくつか
   ハードルがある
   - 各々の環境で作られたモデルを web API として使えるようにする
   - 継続的なモデルやデータセットの更新
   - 学習から推論用の web API サーバーの
   Docker イメージ（アーティファクト）の生成までを行う
   GCP 上に構築された一連のパイプライン
   

   View Slide

7. Hekatoncheir アーキテクチャ
   - GCP を活用したパイプライン
   - Cloud Functions
   - Cloud Build
   - AI Platform
   - Pub/Sub
   

   View Slide

8. Hekatoncheir Serving
   - 既存のパイプラインはアーティファクトの生成までを責務としている
   - 実際に web API としての運用は事業部に委譲するような状態
   - AI を取り入れたい事業部が運用までとなると腰が重い
   - web API のサービングもスコープとしたい
   

   View Slide

9. Hekatoncheir Serving 要件
   - 既存のパイプラインの延長として、アーティファクトを web API として
   サービングする
   - MLOps エンジニアの数は限られるため、とにかく自動化をしたい
   - 認証機構を入れてアクセス制限をする
   - 動的に web API を作成更新削除ができる
   - アクセス数に応じてスケールさせる
   - Kubernetes(Google Kubernetes Engine)を採用
   

   View Slide

10. Hekatoncheir Serving の問題点
    - アーティファクトが実際に正しく web API として動くかどうかは
    デプロイしてみるまでわからない
    

    View Slide

11. 検証機構
    - アーティファクト生成後に有効な web API かどうかを確認するために
    一時的にデプロイしてヘルスチェックだけを行うための検証機構
    

    View Slide

12. - POST リクエストを受けると、イメージをデプロイ
    - DELETE リクエストを受けると、デプロイされた web API を破棄
    検証機構のサーバ実装
    POST
    イメージデプロイ
    エンドポイント払い出し
    試しにリクエストを飛ばして
    想定されたレスポンスが
    返ってくるかチェック
    

    View Slide

13. 検証機構のサーバ実装
    - k8s の公式クライアント
    https://github.com/kubernetes/client-go
    - helm の公式クライアント
    https://github.com/helm/helm
    - 必然的に Go 言語による実装
    - レイヤードアーキテクチャを採用
    

    View Slide

14. Hekatoncheir Serving 要件（再掲）
    - 既存のパイプラインの延長として、アーティファクトを web API として
    サービングする
    - MLOps エンジニアの数は限られるため、とにかく自動化をしたい
    - 認証認可機構を入れてアクセス制限をする
    - 動的に web API を作成更新削除ができる
    - アクセス数に応じてスケールさせる
    - Kubernetes(Google Kubernetes Engine)を採用
    

    View Slide

15. サービスメッシュ(Istio)
    - K8s のネットワークを拡張してくれる
    - 高度なルーティング制御
    - ネットワーク状況の監視
    - 認証認可の機能を提供
    認証されたユーザのみによるアクセス
    各コンポーネントが通信し合うような構成
    (=マイクロサービス)
    

    View Slide

16. Knative
    - Istio 上で動く、サーバーレス基盤用プラットフォーム
    - Knative のマネージドサービスが Cloud Run
    - イメージのデプロイとルーティングなどをよしなにしてくれる
    - 検証機構で色々頑張っていた部分をそのまま代わりにやってくれる
    - 動的に web API の作成と削除が可能
    POST
    Knative によるデプロイとルーティング
    

    View Slide

17. オートスケール
    - Horizontal Pod Autoscaler(HPA)
    - CPUやメモリなどの使用率を元に pod (≒コンテナ) 数を増減
    

    View Slide

18. オートスケール
    - Cluster Autoscaler(CA)
    - 各 Pod はノード(=サーバ)上で動く
    - ノードプール(=ノードの集合)のスペックは自分で指定する必要がある
    - ノードプール内でのノード数を増減
    

    View Slide

19. オートスケール
    - Node Auto-Provisioning(NAP)
    - ノードプールそのものを自動で作ってくれる
    - pod の要求するスペックを考慮 (GPU も使ってくれる)
    

    View Slide

20. Hekatoncheir のリアーキクテト
    - 実際に使われていく上で、より良いアーキテクチャが提案された
    - web API への移行
    - 現状 cli が分厚いが web API を作ってサーバに処理を持っていく
    - Vertex Pipelines(マネージドな Kubeflow Pipelines)
    - 複雑なユースケースが出てきており、既存のパイプラインでは
    無理が生じてきた
    - 分岐
    - 待ち合わせ
    - 途中からの実行
    

    View Slide

21. Hekatoncheir の将来像
    

    View Slide

22. View Slide

23. Appendix
    - 口頭では説明しなかった部分について補足
    

    View Slide

24. Cloud Run VS AI Platform Prediction VS GKE
    - Cloud Run
    - GPU が使えないのはユースケースが限定されてしまう
    - AI Platform Prediction
    - 機能的には十分
    - リクエストとレスポンスのサイズ上限(1.5MB)が不安
    - GKE(Kubernetes, k8s)
    - あらゆるユースケースに対応できる
    - 将来的に AWS にも展開できる可能性
    - 学習コストは高そうだが、メンバー的にもモチベ高い
    

    View Slide

25. GKE standard VS GKE autopilot
    - GCP には２つの GKE のモードが存在する
    - GKE standard
    - ノードを管理する必要がある
    - GKE autopilot
    - ノードの管理が必要ない
    - いくつかの制約が存在する（した）
    - admission webhook
    - cert-manager, istio
    - GPU が使えない
    - requests = limits になる
    - ユーザにこの辺を設定してもらうのは難しい
    

    View Slide

26. Anthos Service Mesh
    - Hekatoncheir では Istio を採用
    - アップデートが大変
    - Anthos Service Mesh は GCP のマネージドな Istio
    - アップデートの煩雑さがなくなる
    

    View Slide