機械学習基盤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エンジニアリング第一グループ
   川瀬　拓実
   

   View Slide

2. 自己紹介
   20卒エンジニア
   配属からずっと MLOps 周りを担当
   特に Hekatoncheir の開発
   その中でも最近は Hekatoncheir Serving の開発がメイン
   

   View Slide

3. 1. 機械学習基盤 Hekatoncheir
   AI 開発における以下の課題を解決することを目指した機械学習基盤
   1. データサイエンティスト(DS)が各々自由な環境で開発した場合、プロダクションへのデプロイが大変
   →学習からデプロイまでの統一したインターフェースを提供
   →成果物として Web API 用の Docker イメージ(アーティファクト)を吐き出す
   2. モデルやデータセットの更新に伴う継続的な再学習が面倒
   →更新をトリガーとした再学習の仕組みを提供
   

   View Slide

4. Hekatoncheir の構成
   Hekaton は Google Cloud (GC) 上でマネージドサービスを駆使してパイプラインを構成
   詳しいアーキテクチャについては
   DeNA Techcon 2021 機械学習基盤 Hekatoncheir の取り組み
   

   View Slide

5. Hekatoncheir のこれから
   運用を続けるにあたっていくつかの課題が発生
   ● ログがサービスごとにばらけてしまうため、デバッグが困難
   ● Hekaton 本体のアップデートが入ると全体に即座に影響するため、アップデートが困難
   ● 複数の AI が同一の GC 上で開発されているため、セキュリティ的な懸念
   ● そもそもアーキテクチャ的に対応できないユースケースの存在
   ワークフローエンジン Kubeflow Pipelines のマネージド版 Vertex Pipelines の採用
   ● 各 AI ごと（事業部ごと）に GC 上で Vertex AI Pipelines を展開
   ● パイプラインはユーザが自由にカスタマイズ可能
   Hekaton 開発チームはインターフェースを統一するためのテンプレートの提供とアドバイス
   ● 基本的な機能は各 AI 開発を行う GC 上の Vertex AI Pipelines に委譲し
   再学習の仕組みを Hekaton 側から提供
   既存の Hekaton に求められる機能はそのままに、より柔軟性のあるアーキテクチャを目指す
   

   View Slide

6. AI 導入の障壁
   既存の Hekaton パイプラインは、アーティファクトの生成までが責務
   Web API としての AI の運用は各事業部に任せられている状態
   ● インフラの整備
   ● 認証認可の仕組み
   ● 自動デプロイの実装
   ● リリース手段の確立
   ● SLO(Service-Level Objective) の維持
   ● 運用ノウハウの属人化
   ● etc...
   チームをまたいだ運用の煩雑さがネック
   

   View Slide

7. 2. Hekaton Serving
   Hekaton 側の機能として Web API のサービングを提供することで
   事業部の AI 導入を推進させる
   

   View Slide

8. Hekaton Serving の仕様
   ● 認証認可によるアクセス制限
   ● 監視システムと通知(ログ、アラート)
   ● 高可用性(SLO)
   ● 柔軟なリリース(カナリアリリース、A/Bテスト)
   ● データサイエンティスト(DS)によるWeb API の動的なデプロイ更新及び削除
   ● オートスケーリング
   以上の要件に応えるため拡張性の高い Google Kubernetes Engine(GKE) を採用
   

   View Slide

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 を採用
   

   View Slide

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 を採用
    

    View Slide

11. どう仕様を満たしていくか
    ● サービスメッシュ(Istio)
    ● Knative Serving
    ● オートスケーリング
    

    View Slide

12. Hekaton Serving の仕様(再掲)
    ● 認証認可によるアクセス制限
    ● 監視システムと通知(ログ、アラート)
    ● 高可用性(SLO)
    ● 柔軟なリリース
    ● データサイエンティストによるWeb API の動的なデプロイ更新及び削除
    ● オートスケーリング
    サービスメッシュ
    

    View Slide

13. サービスメッシュ
    Kubernetes のネットワーク周りを強化してくれる
    メッシュの名の通り、複数のサービスが相互に通信し合うような状況(例:マイクロサービス)で特に有用
    ● 柔軟なトラフィック管理
    ○ サーキットブレーカ、タイムアウト、リトライ、カナリアリリース...
    ● セキュリティ
    ○ jwt による認証認可、サービス間TLS…
    ● 監視
    ○ メトリクス収集、通信の可視化...
    素の Kubernetes を使っていると、少し物足りないところを補ってくれる
    

    View Slide

14. Istio
    Istiod(コントロールプレーン)が、各 Pod にサイドカー(※)コンテナとしてインストールされた
    Envoy プロキシ(データプレーン)と連携してサービスメッシュを実現する
    デプロイされた Pod に入った Envoy が通信を仲介する
    透過的にサービスメッシュの機能が提供されるので、アプリケーション側の変更が必要ない
    ※サイドカーパターンとは、同一 pod に機能提供用の別のコンテナを注入するパターンのこと
    　今回であれば、プロキシとして Envoy コンテナがサイドカーとしてアプリケーション Pod に
    　注入されている
    

    View Slide

15. Anthos Service Mesh
    Istio を直接 Kubernetes クラスタにインストールすることも可能だが GC には Istio のマネージド版である
    Anthos Service Mesh(ASM)が存在する
    Anthos とは GC を含め、複数環境(オンプレやAWS)にインストールされた GKE をまとめて管理するサービス
    ASM は Anthos で提供される機能の一つで、もちろん単一のクラスタに対しても適用可能
    基本的な Istio の機能はそのままに、マネージド由来の管理コストの低下が見込める
    ● コントロールプレーン(Istio 本体)の自動アップデート
    ● データプレーン(Envoy プロキシ)の自動アップデート
    ● マネージドのダッシュボード
    ● Google によるサポート
    

    View Slide

16. ダッシュボード
    Istio によって収集されたログを活用するための OSS が複数存在する
    ● Prometheus + Grafana(メトリクス監視)
    ● Kiali(サービスメッシュ可視化)
    ● Jaeger(トレーシング)
    ただしASM を使って、マネージドコントロールプレーンを採用する場合 Service Mesh Dashboard が推奨
    Service Mesh Dashboard によっても上記の OSS と同様に以下の項目が確認及び設定できる
    ● サービスの接続性
    ● QPS
    ● エラーレート
    ● 遅延
    ● Service-Level Objective(SLO) とアラート
    

    View Slide

17. Hekaton Serving の仕様(再掲)
    ● 認証認可によるアクセス制限
    ● 監視システム(ログ、アラート)
    ● 高可用性(SLO)
    ● 柔軟なリリース
    ● Web API の動的なデプロイ更新及び削除
    ● オートスケーリング
    Knative Serving + Client Go
    

    View Slide

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 リソースが、他のリソースを管理
    

    View Slide

19. リソースのデプロイ更新削除
    Kubernetes におけるマニフェスト(yaml)を使用した宣言的なリソース管理は
    今回要件として求められる動的なリソースのデプロイ更新削除とは相性が悪い
    →マニフェストとして一元管理ができない
    本来はマニフェストに対応した Kubernetes のリソースが作られていることが理想(GitOps など)だが
    ある程度の整合性は無視してでもリソースをデプロイ更新削除する仕組みが必要
    →SDK によるリソース操作を行う
    

    View Slide

20. Client Go によるリソースのデプロイ更新及び削除
    Kubernetes は Rest API による操作が可能
    各言語に対して SDK が提供されており、その Go 実装が https://github.com/kubernetes/client-go
    動的なリソース操作に加えて、追加の要件として
    様々な案件の Web API が同じクラスタ上で動いているため、好き勝手リソースを作られたり削除されたりすると困る
    データサイエンティストが Hekaton Serving の Web API サーバにリクエストを送ると
    Go で書かれたサーバ側で client-go を使ってリソースのデプロイ更新及び削除を行う仕組みを構築
    

    View Slide

21. Hekaton Serving の仕様(再掲)
    ● 認証認可によるアクセス制限
    ● 監視システム(ログ、アラート)
    ● 高可用性(SLO)
    ● 柔軟なリリース
    ● Web API の動的なデプロイ更新及び削除
    ● オートスケーリング
    

    View Slide

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)
    

    View Slide

23. Horizontal Pod Autoscaler(HPA)
    Pod(=複数の Docker コンテナの集合)において
    設定したメトリクスを基準に Pod 数を増減させるタイプのオートスケール
    CPU使用率、メモリ使用量、その他カスタムメトリクス（GPU使用率など）
    例：CPU使用率の平均が一定を上回ると、平均CPU使用率を下げるように Pod が増える
    　　CPU使用率の平均が一定を下回るとPod が減る
    CPUを基準にした場合
    

    View Slide

24. Cluster Autoscaler(CA)
    Pod が動く Node の数を増減させるタイプのオートスケール
    ただし Node は予め設定したスペックとなる
    同一 Node pool(※) に属する Node は同じマシンスペック
    ※同じスペックの Node の集まり
    

    View Slide

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 が不十分であれば
    新たに作成
    

    View Slide

26. 使用しているツール
    ● Helm
    ● Helmfile
    

    View Slide

27. マニフェスト(yaml)の管理
    Kubernetes において各リソースはマニフェストと呼ばれる yaml ファイルを使うことでデプロイができる
    ただし複雑な アプリケーションになるほど管理が大変
    ● yaml ファイルそのものの数
    ● 設定項目の多さ
    ● 同じようなリソースをデプロイする際の書き換え
    非常にシンプルなマニフェスト
    

    View Slide

28. Helm
    Kubernetes 用のパッケージマネージャ
    Kubernetes のマニフェスト(yaml)が Chart と呼ばれる単位でまとまっている
    内部でテンプレートエンジンが使われており、変数を使用してデプロイ時にカスタマイズが可能
    様々なアプリが Helm chart として公開されており、自作も簡単
    自前のリソースでもマニフェストのどこを書き換えるべきか？が分かりやすい
    Kubernetes へのアプリのデプロイは基本的に Helm chart を使って行うのが楽
    

    View Slide

29. Helm chart の管理
    Helm chart はマニフェストの管理を楽にしてくれるが、今度は Helm chart の管理が煩わしい
    ● デプロイする chart
    ● chart の依存管理
    ● 変数への値のセット
    ● バージョン管理
    

    View Slide

30. Helmfile
    Helmfile を使うと
    ● インストール先の環境(context)
    ● インストールする Helm chart とそれらの依存関係
    ● Helm chart のレポジトリ
    ● Helm chart にセットする値の管理
    などが一括で管理できる
    Terraform とも連携可能
    

    View Slide

31. さいごに
    現行アーキテクチャとまとめについて
    

    View Slide

32. Hekaton のアーキテクチャ
    クラスタ内は名前空間(Namespace)
    によって仮想的に分離
    

    View Slide

33. まとめ
    ● Kubernetes を採用することで細かい要件にも応えられる一方、やはり Kubernetes の学習コストは高い
    サービスメッシュを入れることも考えると、より一層粘り強く付き合っていくことが必要
    個人的には Kubernetes を使ってサービスを展開する場合はサービスメッシュは必須と考えている
    (主にトラフィック周りの機能が大きい)
    ● Kubernetes を使うと言っても適切にマネージドサービスを使うことで、運用コストを下げられる
    (Anthos Service Mesh, Cloud Run for Anthos, Service Mesh Dashboard)
    ただしベンダーロックインとのトレードオフではある
    (GKE on AWS の可能性？)
    ● ノードの管理は Node Auto-Provisioning のおかげでだいぶ楽ができるので、心配はあまり必要なさそう
    と言っても HPA など含めてオートスケール周りは実際に色々試して勘所を抑える必要がある
    

    View Slide