機械学習基盤HekatoncheirにおけるWeb APIサービングの取り組み【DeNA TechCon 2022】

DeNAではMLOpsの活動の一環として、社内のデータサイエンティスト向けに共通の機械学習基盤であるHekatoncheirを提供することでAIの開発を促進してきました。当初Hekatoncheirでは学習と推論、そしてweb APIとして使うDockerイメージの生成までを責務としてきましたが、現在Web APIのサービング機能を新たに開発しています。

Web APIのサービング機能にはベースとしてGCPのマネージドKubernetesサービスであるGKEを採用しました。更にサービスメッシュとしてIstioの採用とWeb APIのサービングシステムとしてKnative Servingを使用しています。また、これらについてもGCPのマネージドサービスであるAnthosを取り入れてメンテナンスコストを下げています。

本セッションでは今回実装を進めているHekatoncheirのサービング機能について技術的に詳しく掘り下げてご紹介していきます。

DeNAではMLOpsの活動の一環として、社内のデータサイエンティスト向けに共通の機械学習基盤であるHekatoncheirを提供することでAIの開発を促進してきました。当初Hekatoncheirでは学習と推論、そしてweb APIとして使うDockerイメージの生成までを責務としてきましたが、現在Web APIのサービング機能を新たに開発しています。

Web APIのサービング機能にはベースとしてGCPのマネージドKubernetesサービスであるGKEを採用しました。更にサービスメッシュとしてIstioの採用とWeb APIのサービングシステムとしてKnative Servingを使用しています。また、これらについてもGCPのマネージドサービスであるAnthosを取り入れてメンテナンスコストを下げています。

本セッションでは今回実装を進めているHekatoncheirのサービング機能について技術的に詳しく掘り下げてご紹介していきます。

資料内でのリンク集：
p4, https://speakerdeck.com/dena_tech/techcon2021-12
p17, https://github.com/kubernetes/client-go

◆ You Tube
https://youtu.be/XpIvdyH7CuA

◆ You Tube チャンネル登録はこちら↓
https://youtube.com/c/denatech?sub_confirmation=1

◆ Twitter
https://twitter.com/DeNAxTech

◆ DeNA Engineering
https://engineering.dena.com/

◆ DeNA Engineer Blog
https://engineering.dena.com/blog/

◆ DeNA TechCon 2022 公式サイト
https://techcon2022.dena.dev/spring/

Transcript

1. 機械学習基盤Hekatoncheirにおける Web APIサービングの取り組み システム本部データ統括部AI基盤部MLエンジニアリング第一グループ 川瀬　拓実
2. 自己紹介 20卒エンジニア 配属からずっと MLOps 周りを担当 特に Hekatoncheir の開発 その中でも最近は Hekatoncheir Serving の開発がメイン
3. 1. 機械学習基盤 Hekatoncheir AI 開発における以下の課題を解決することを目指した機械学習基盤 1. データサイエンティスト(DS)が各々自由な環境で開発した場合、プロダクションへのデプロイが大変 →学習からデプロイまでの統一したインターフェースを提供 →成果物として Web API 用の Docker イメージ(アーティファクト)を吐き出す 2. モデルやデータセットの更新に伴う継続的な再学習が面倒 →更新をトリガーとした再学習の仕組みを提供
4. Hekatoncheir の構成 Hekaton は Google Cloud (GC) 上でマネージドサービスを駆使してパイプラインを構成 詳しいアーキテクチャについては DeNA Techcon 2021 機械学習基盤 Hekatoncheir の取り組み
5. Hekatoncheir のこれから 運用を続けるにあたっていくつかの課題が発生 • ログがサービスごとにばらけてしまうため、デバッグが困難 • Hekaton 本体のアップデートが入ると全体に即座に影響するため、アップデートが困難 • 複数の AI が同一の GC 上で開発されているため、セキュリティ的な懸念 • そもそもアーキテクチャ的に対応できないユースケースの存在 ワークフローエンジン Kubeflow Pipelines のマネージド版 Vertex Pipelines の採用 • 各 AI ごと（事業部ごと）に GC 上で Vertex AI Pipelines を展開 • パイプラインはユーザが自由にカスタマイズ可能 Hekaton 開発チームはインターフェースを統一するためのテンプレートの提供とアドバイス • 基本的な機能は各 AI 開発を行う GC 上の Vertex AI Pipelines に委譲し 再学習の仕組みを Hekaton 側から提供 既存の Hekaton に求められる機能はそのままに、より柔軟性のあるアーキテクチャを目指す
6. AI 導入の障壁 既存の Hekaton パイプラインは、アーティファクトの生成までが責務 Web API としての AI の運用は各事業部に任せられている状態 • インフラの整備 • 認証認可の仕組み • 自動デプロイの実装 • リリース手段の確立 • SLO(Service-Level Objective) の維持 • 運用ノウハウの属人化 • etc... チームをまたいだ運用の煩雑さがネック
7. 2. Hekaton Serving Hekaton 側の機能として Web API のサービングを提供することで 事業部の AI 導入を推進させる
8. Hekaton Serving の仕様 • 認証認可によるアクセス制限 • 監視システムと通知(ログ、アラート) • 高可用性(SLO) • 柔軟なリリース(カナリアリリース、A/Bテスト) • データサイエンティスト(DS)によるWeb API の動的なデプロイ更新及び削除 • オートスケーリング 以上の要件に応えるため拡張性の高い Google Kubernetes Engine(GKE) を採用
9. プラットフォーム Cloud Run AI Platform Prediction Google Kubernetes Engine (GKE) Pros • 手軽 • スケーリング • IAP(※) による制限 • マネージド由来の 高可用性 • 手軽 • スケーリング • IAP による制限 • GPU が使える • マネージド由来の 高可用性 • あらゆる要求に対応 • 他クラウドへの展開 AWS • Workload Identity による GC 上での アクセス管理 Cons • GPUが使えない • 認証認可が面倒 • ユーザ(=DS)単位の デプロイや監視 リリースなどの 仕組みは自前実装 • 1.5MB の リクエスト制限 • 認証認可が面倒 • ユーザー単位の デプロイや監視 リリースなどの 仕組みは自前実装 • 学習コストの高さ K8s そのものに加え サービスメッシュ Kubernetes(K8s) のマネージドサービス ※Identity-Aware Proxy 上記メリット・デメリットとメンバーの熱量を考慮して GKE を採用
10. GKE Standard VS GKE Autopilot GKE Standard GKE Autopilot Cons • ノードの管理が必要 • GPU が使えない • Admission Webhook が使えない(※) cert-manager(証明書発行)と Istio(サービスメッシュ)が導入不可 • Pod (≒Docker コンテナ) における limits の指定ができない requests: 最小の CPU, Memory limits: 最大の CPU, Memory ※検討当時 • GPU は使いたい • Requests = Limists となる状況で最適なリソース量を指定するのは難しい • ワイルドカード証明書を使うために cert-manager が欲しい • 実はNode Auto-Provisioning を使うと GKE Standard でもインスタンスの管理が必要ない 以上の理由から GKE Standard を採用
11. どう仕様を満たしていくか • サービスメッシュ(Istio) • Knative Serving • オートスケーリング
12. Hekaton Serving の仕様(再掲) • 認証認可によるアクセス制限 • 監視システムと通知(ログ、アラート) • 高可用性(SLO) • 柔軟なリリース • データサイエンティストによるWeb API の動的なデプロイ更新及び削除 • オートスケーリング サービスメッシュ
13. サービスメッシュ Kubernetes のネットワーク周りを強化してくれる メッシュの名の通り、複数のサービスが相互に通信し合うような状況(例:マイクロサービス)で特に有用 • 柔軟なトラフィック管理 ◦ サーキットブレーカ、タイムアウト、リトライ、カナリアリリース... • セキュリティ ◦ jwt による認証認可、サービス間TLS… • 監視 ◦ メトリクス収集、通信の可視化... 素の Kubernetes を使っていると、少し物足りないところを補ってくれる
14. Istio Istiod(コントロールプレーン)が、各 Pod にサイドカー(※)コンテナとしてインストールされた Envoy プロキシ(データプレーン)と連携してサービスメッシュを実現する デプロイされた Pod に入った Envoy が通信を仲介する 透過的にサービスメッシュの機能が提供されるので、アプリケーション側の変更が必要ない ※サイドカーパターンとは、同一 pod に機能提供用の別のコンテナを注入するパターンのこと 　今回であれば、プロキシとして Envoy コンテナがサイドカーとしてアプリケーション Pod に 　注入されている
15. Anthos Service Mesh Istio を直接 Kubernetes クラスタにインストールすることも可能だが GC には Istio のマネージド版である Anthos Service Mesh(ASM)が存在する Anthos とは GC を含め、複数環境(オンプレやAWS)にインストールされた GKE をまとめて管理するサービス ASM は Anthos で提供される機能の一つで、もちろん単一のクラスタに対しても適用可能 基本的な Istio の機能はそのままに、マネージド由来の管理コストの低下が見込める • コントロールプレーン(Istio 本体)の自動アップデート • データプレーン(Envoy プロキシ)の自動アップデート • マネージドのダッシュボード • Google によるサポート
16. ダッシュボード Istio によって収集されたログを活用するための OSS が複数存在する • Prometheus + Grafana(メトリクス監視) • Kiali(サービスメッシュ可視化) • Jaeger(トレーシング) ただしASM を使って、マネージドコントロールプレーンを採用する場合 Service Mesh Dashboard が推奨 Service Mesh Dashboard によっても上記の OSS と同様に以下の項目が確認及び設定できる • サービスの接続性 • QPS • エラーレート • 遅延 • Service-Level Objective(SLO) とアラート
17. Hekaton Serving の仕様(再掲) • 認証認可によるアクセス制限 • 監視システム(ログ、アラート) • 高可用性(SLO) • 柔軟なリリース • Web API の動的なデプロイ更新及び削除 • オートスケーリング Knative Serving + Client Go
18. Knative Serving Istio を含めたサービスメッシュ上で動作する コンテナイメージに対して • デプロイ、更新、削除 • ルーティング • オートスケーリング • スナップショット をまとめて提供してくれる Cloud Run は Knative Serving のマネージド版 更に Knative Serving のマネージド版として Cloud Run for Anthos が存在 Knative Serving のリソースは Custom Resource Definition(CRD)で提供 • Service • Route • Configuration • Revision Service リソースが、他のリソースを管理
19. リソースのデプロイ更新削除 Kubernetes におけるマニフェスト(yaml)を使用した宣言的なリソース管理は 今回要件として求められる動的なリソースのデプロイ更新削除とは相性が悪い →マニフェストとして一元管理ができない 本来はマニフェストに対応した Kubernetes のリソースが作られていることが理想(GitOps など)だが ある程度の整合性は無視してでもリソースをデプロイ更新削除する仕組みが必要 →SDK によるリソース操作を行う
20. Client Go によるリソースのデプロイ更新及び削除 Kubernetes は Rest API による操作が可能 各言語に対して SDK が提供されており、その Go 実装が https://github.com/kubernetes/client-go 動的なリソース操作に加えて、追加の要件として 様々な案件の Web API が同じクラスタ上で動いているため、好き勝手リソースを作られたり削除されたりすると困る データサイエンティストが Hekaton Serving の Web API サーバにリクエストを送ると Go で書かれたサーバ側で client-go を使ってリソースのデプロイ更新及び削除を行う仕組みを構築
21. Hekaton Serving の仕様(再掲) • 認証認可によるアクセス制限 • 監視システム(ログ、アラート) • 高可用性(SLO) • 柔軟なリリース • Web API の動的なデプロイ更新及び削除 • オートスケーリング
22. オートスケーリング Kubernetes, GKE, Knative Serving それぞれが由来の複数のオートスケーリング手段が存在 • Horizontal Pod Autoscaler(HPA) • Vertical Pod Autoscaler(VPA) 自動で Pod のリソース使用量(requests, limits)を決めてくれるが、アクセスのない状態を基準にリソース使用量が決 まった場合 コンテナ立ち上げ時の動作に支障をきたすことがあったので不採用 • Knative Pod Autoscaler Knative Serving のリソースで HPA の代わりに使用可能 リクエスト数に応じたスケーリング リクエストが全く無い場合 0 にスケーリング • Cluster Autoscaler(CA) デフォルトで用意される Pod 用のノード(VM などのリソース)に対して適用 • Node Auto-Provisioning(NAP)
23. Horizontal Pod Autoscaler(HPA) Pod(=複数の Docker コンテナの集合)において 設定したメトリクスを基準に Pod 数を増減させるタイプのオートスケール CPU使用率、メモリ使用量、その他カスタムメトリクス（GPU使用率など） 例：CPU使用率の平均が一定を上回ると、平均CPU使用率を下げるように Pod が増える 　　CPU使用率の平均が一定を下回るとPod が減る CPUを基準にした場合
24. Cluster Autoscaler(CA) Pod が動く Node の数を増減させるタイプのオートスケール ただし Node は予め設定したスペックとなる 同一 Node pool(※) に属する Node は同じマシンスペック ※同じスペックの Node の集まり
25. Node Auto-Provisioning(NAP) 前述の CA では、予めマシンスペックを指定しておく必要がある Hekaton Serving では Pod ごとに要求されるスペックを見積もることが困難 • マシンスペックが低いと Pod を載せるのに十分なスペックが満たされない可能性 • マシンスペックが高いと Pod に対して中身がスカスカになって無駄なコストが発生する可能性 Node Auto-Provisioning は、自動的に Node pool を作成してくれる！ • CPU, Memory, Storage, GPU の要求 • affinity, label selector, taints, tolerations と言った Pod の配置 まで考慮してくれる 該当する Node pool が存在しなければ 新たに作成 既存の Node pool が不十分であれば 新たに作成
26. 使用しているツール • Helm • Helmfile
27. マニフェスト(yaml)の管理 Kubernetes において各リソースはマニフェストと呼ばれる yaml ファイルを使うことでデプロイができる ただし複雑な アプリケーションになるほど管理が大変 • yaml ファイルそのものの数 • 設定項目の多さ • 同じようなリソースをデプロイする際の書き換え 非常にシンプルなマニフェスト
28. Helm Kubernetes 用のパッケージマネージャ Kubernetes のマニフェスト(yaml)が Chart と呼ばれる単位でまとまっている 内部でテンプレートエンジンが使われており、変数を使用してデプロイ時にカスタマイズが可能 様々なアプリが Helm chart として公開されており、自作も簡単 自前のリソースでもマニフェストのどこを書き換えるべきか？が分かりやすい Kubernetes へのアプリのデプロイは基本的に Helm chart を使って行うのが楽
29. Helm chart の管理 Helm chart はマニフェストの管理を楽にしてくれるが、今度は Helm chart の管理が煩わしい • デプロイする chart • chart の依存管理 • 変数への値のセット • バージョン管理
30. Helmfile Helmfile を使うと • インストール先の環境(context) • インストールする Helm chart とそれらの依存関係 • Helm chart のレポジトリ • Helm chart にセットする値の管理 などが一括で管理できる Terraform とも連携可能
31. さいごに 現行アーキテクチャとまとめについて
32. Hekaton のアーキテクチャ クラスタ内は名前空間(Namespace) によって仮想的に分離
33. まとめ • Kubernetes を採用することで細かい要件にも応えられる一方、やはり Kubernetes の学習コストは高い サービスメッシュを入れることも考えると、より一層粘り強く付き合っていくことが必要 個人的には Kubernetes を使ってサービスを展開する場合はサービスメッシュは必須と考えている (主にトラフィック周りの機能が大きい) • Kubernetes を使うと言っても適切にマネージドサービスを使うことで、運用コストを下げられる (Anthos Service Mesh, Cloud Run for Anthos, Service Mesh Dashboard) ただしベンダーロックインとのトレードオフではある (GKE on AWS の可能性？) • ノードの管理は Node Auto-Provisioning のおかげでだいぶ楽ができるので、心配はあまり必要なさそう と言っても HPA など含めてオートスケール周りは実際に色々試して勘所を抑える必要がある