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

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

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

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

Transcript

1. DeNA の MLOps エンジニア は何をしているのか Takumi Kawase
2. 自己紹介 - 川瀬拓実 - 20卒エンジニア - システム本部データ統括部AI基盤部MLエンジニアリング第一グループ - 通称 MLEG が MLOps を行っている
3. MLOps って何？ - DevOps + AI が組み合わさった概念で、特に AI 周りのサポートをする - DeNA では AI 以外のすべてをスコープとする - その集団が MLOps エンジニア - もちろん AI のドメイン知識があると尚良い - 少ない人数でも業務が回る（スケールする）ように主に自動化を頑張る
4. 具体的に何をしているの（主なスキルセット） - フロントエンドの開発 - React, Vue, TypeScript - バックエンドの開発 - Python, Go, Database(MySQL, NoSQL…) - クラウド - Amazon Web Services, Google Cloud Platform, Terraform - コンテナ - Docker, Kubernetes(K8s) - CI/CD, セキュリティ、ネットワーク、アーキテクチャ etc...
5. 今自分がしていること - データサイエンティスト (DS) が作った成果物を提供する - フロントエンド開発(Nuxt.js → Next.js) - バックエンド開発(FastAPI, MySQL) - インフラ(AWS) - ツールの作成 - AI を活用した web API の運用 - Pococha 関連の AI を実際に運用中 - 不正な配信を自動検出し、サポートの負担減 - 機械学習基盤 Hekatoncheir の開発（メイントピック） - Web API サービング機能の整備
6. 機械学習基盤 Hekatoncheir - DS が作ったモデルをプロダクションに持っていくにはいくつか ハードルがある - 各々の環境で作られたモデルを web API として使えるようにする - 継続的なモデルやデータセットの更新 - 学習から推論用の web API サーバーの Docker イメージ（アーティファクト）の生成までを行う GCP 上に構築された一連のパイプライン
7. Hekatoncheir アーキテクチャ - GCP を活用したパイプライン - Cloud Functions - Cloud Build - AI Platform - Pub/Sub
8. Hekatoncheir Serving - 既存のパイプラインはアーティファクトの生成までを責務としている - 実際に web API としての運用は事業部に委譲するような状態 - AI を取り入れたい事業部が運用までとなると腰が重い - web API のサービングもスコープとしたい
9. Hekatoncheir Serving 要件 - 既存のパイプラインの延長として、アーティファクトを web API として サービングする - MLOps エンジニアの数は限られるため、とにかく自動化をしたい - 認証機構を入れてアクセス制限をする - 動的に web API を作成更新削除ができる - アクセス数に応じてスケールさせる - Kubernetes(Google Kubernetes Engine)を採用
10. Hekatoncheir Serving の問題点 - アーティファクトが実際に正しく web API として動くかどうかは デプロイしてみるまでわからない
11. 検証機構 - アーティファクト生成後に有効な web API かどうかを確認するために 一時的にデプロイしてヘルスチェックだけを行うための検証機構
12. - POST リクエストを受けると、イメージをデプロイ - DELETE リクエストを受けると、デプロイされた web API を破棄 検証機構のサーバ実装 POST イメージデプロイ エンドポイント払い出し 試しにリクエストを飛ばして 想定されたレスポンスが 返ってくるかチェック
13. 検証機構のサーバ実装 - k8s の公式クライアント https://github.com/kubernetes/client-go - helm の公式クライアント https://github.com/helm/helm - 必然的に Go 言語による実装 - レイヤードアーキテクチャを採用
14. Hekatoncheir Serving 要件（再掲） - 既存のパイプラインの延長として、アーティファクトを web API として サービングする - MLOps エンジニアの数は限られるため、とにかく自動化をしたい - 認証認可機構を入れてアクセス制限をする - 動的に web API を作成更新削除ができる - アクセス数に応じてスケールさせる - Kubernetes(Google Kubernetes Engine)を採用
15. サービスメッシュ(Istio) - K8s のネットワークを拡張してくれる - 高度なルーティング制御 - ネットワーク状況の監視 - 認証認可の機能を提供 認証されたユーザのみによるアクセス 各コンポーネントが通信し合うような構成 (=マイクロサービス)
16. Knative - Istio 上で動く、サーバーレス基盤用プラットフォーム - Knative のマネージドサービスが Cloud Run - イメージのデプロイとルーティングなどをよしなにしてくれる - 検証機構で色々頑張っていた部分をそのまま代わりにやってくれる - 動的に web API の作成と削除が可能 POST Knative によるデプロイとルーティング
17. オートスケール - Horizontal Pod Autoscaler(HPA) - CPUやメモリなどの使用率を元に pod (≒コンテナ) 数を増減
18. オートスケール - Cluster Autoscaler(CA) - 各 Pod はノード(=サーバ)上で動く - ノードプール(=ノードの集合)のスペックは自分で指定する必要がある - ノードプール内でのノード数を増減
19. オートスケール - Node Auto-Provisioning(NAP) - ノードプールそのものを自動で作ってくれる - pod の要求するスペックを考慮 (GPU も使ってくれる)
20. Hekatoncheir のリアーキクテト - 実際に使われていく上で、より良いアーキテクチャが提案された - web API への移行 - 現状 cli が分厚いが web API を作ってサーバに処理を持っていく - Vertex Pipelines(マネージドな Kubeflow Pipelines) - 複雑なユースケースが出てきており、既存のパイプラインでは 無理が生じてきた - 分岐 - 待ち合わせ - 途中からの実行
21. Hekatoncheir の将来像
23. Appendix - 口頭では説明しなかった部分について補足
24. Cloud Run VS AI Platform Prediction VS GKE - Cloud Run - GPU が使えないのはユースケースが限定されてしまう - AI Platform Prediction - 機能的には十分 - リクエストとレスポンスのサイズ上限(1.5MB)が不安 - GKE(Kubernetes, k8s) - あらゆるユースケースに対応できる - 将来的に AWS にも展開できる可能性 - 学習コストは高そうだが、メンバー的にもモチベ高い
25. GKE standard VS GKE autopilot - GCP には２つの GKE のモードが存在する - GKE standard - ノードを管理する必要がある - GKE autopilot - ノードの管理が必要ない - いくつかの制約が存在する（した） - admission webhook - cert-manager, istio - GPU が使えない - requests = limits になる - ユーザにこの辺を設定してもらうのは難しい
26. Anthos Service Mesh - Hekatoncheir では Istio を採用 - アップデートが大変 - Anthos Service Mesh は GCP のマネージドな Istio - アップデートの煩雑さがなくなる