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