AI事業本部におけるGPU活用の取り組みとKubernetes - CloudNative Days Spring 2021 Online / cndo2021-ca-ml-gpuaas-aiplatform

AI事業本部におけるGPU活用の取り組みとKubernetes
at CloudNative Days Spring 2021 Online

Speaker: 青山 真也・李 榮宰・高橋 大輔
Video: https://event.cloudnativedays.jp/cndo2021/talks/451

サイバーエージェント AI事業本部では、広告領域を始めとして、様々な領域での機械学習のワークロードが増えています。研究者・データサイエンティスト・プロダクト開発者など様々なメンバーが機械学習を利用するなか、利便性の高いGPU/ML環境の提供は欠かせません。 現在に至るまでAI事業本部におけるオンプレGPU環境は様々な変遷があり、現在は2020年にリリースされた NVIDIA A100を利用しNetApp TridentとKubernetesをあわせてGPU/ML環境の提供を開始しています。 本セッションではこれまでの背景をお話しつつ、オープンソースなエコシステムと拡張性を活かしながら、GPU/ML基盤をどのように開発しているかについて紹介します。

Transcript

1. AI事業本部におけるGPU活用の取り組みとKubernetes
   CyberAgent, Inc.
   ・Masaya Aoyama
   ・Lee Yeongjae
   ・Daisuke Takahashi
   @CloudNative Days Spring 2021 Online
   Session page: https://event.cloudnativedays.jp/cndo2021/talks/451
   

   View Slide

2. Who are we?
   AI Platform Project Manager
   2016年にサイバーエージェントに入社。入
   社後は広告プロダクトでソリューションアー
   キテクト、さらにプライベートクラウドや
   GKE互換なコンテナプラットフォームの開発
   を担当。AI系基盤プロジェクトのマネージャ
   としてAIプラットフォームを開発。
   Lee Yeongjae Masaya Aoyama Daisuke Takahashi
   Developer Experts
   Kubernetes / Cloud Native
   2016年入社。OpenStackを使ったプラ
   イベートクラウドやGKE互換なコンテナ
   プラットフォームを構築。Kubernetes
   完全ガイド著者。CloudNative Days
   Tokyo 2019/2020 の Co-chairの他、
   MeetupのOrganizerなどにも従事。
   Infrastructure Engineer
   主にプライベートなOpenStackプラット
   フォームとKubernetes-as-a-Serviceの
   開発、およびさまざまなアクセラレータ
   デバイス提供における全ての工程を担
   当。 GPUaaS / AIプラットフォームの基
   盤となる物理インフラを構築。
   

   View Slide

3. AIソリューションの実行環境 (例)
   ユーザ：Researcher, DataScientist, MLOps Engineer
   Jupyter Notebook ：GUI上で動作する対話型プログラム実行環境
   Google AI Platform ：Clientツール/GUIでMLワークフローを管理
   モデル学習、評価 モデルのデプロイ
   モデルによる推論 推論のモニタリング モデルのバージョン管理
   コードの実装
   入力データの用意
   

   View Slide

4. システム構成
   DGX A100 AFF A800
   GPUaaS （Kubernetes）
   AI Platform
   DGX A100 + AFF A800 → 高性能GPUとストレージを提供
   GPU as a Service → Jupyter Notebookを提供
   独自AI Platform → Google AI Platform相当の基盤を提供
   

   View Slide

5. GPUaaSのハードウェアと
   Kubernetes
   

   View Slide

6. ● AI基盤の需要に応じて増設
   ● GPU不要なワークロードには、
   OpenStack環境のVMを提供
   ○ Kubernetesクラスタは同一
   ● 設計/運用はGPUaaS以外と独立
   ○ 物理的な要件の極端な違い
   ■ 電源: 0.5~1kW→6.5kW
   ■ NW: ~40GbE→100GbE
   GPUaaSの物理構成
   100GbE
   25GbE
   Compute
   NVIDIA DGX A100
   Network
   Mellanox SN2010
   Storage
   NetApp AFF A800
   

   View Slide

7. NVIDIA DGX A100
   ● スペック
   ○ GPU: 8x NVIDIA A100 40GB (320GB)
   ○ CPU: 2x AMD Rome EPYC 7742 (128コア)
   ○ メモリ: 1TB
   ● 「DGX-Ready」対応データセンターへ設置
   ○ 今回はIDCフロンティア様
   ○ 電力や冷却能力、搬入経路などが安心
   

   View Slide

8. NVIDIA A100
   ● Ampereアーキテクチャ
   ○ 前世代 (V100) と比べて最大20倍
   の性能
   ● 新しいハードウェア機能
   ○ Multi-instance GPU, Sparsity
   ● GPU同士のより高速な内部接続
   ○ 第3世代NVLink/第2世代NVSwitch
   ○ 最大16枚まで接続可能
   ○ 各GPU間を600Gbpsで接続
   

   View Slide

9. MIG: Multi-instance GPU
   MIG mode in the NVIDIA Ampere architecture can run
   seven jobs in parallel on an A100 GPU (NVIDIA Blog)
   ● マルチテナンシー
   ○ DGX A100の場合、8GPUを最大56インスタンスに分割可能
   ○ アプリに応じたサイズのGPUを提供可能
   ● QoS保証
   ○ 各GPUインスタンスのメモリ・コア・転送帯域が独立
   

   View Slide

10. MIG for Kubernetes
    ● パターン1: 事前に分割
    ○ 公式Device Pluginで実装済み
    ○ すべてのワークロードを事前に把握できる必要
    ■ 様々な利用者を抱える今回の基盤には不適
    ■ 最小単位で分割してマルチGPUとして使うことは不能 (現行CUDAの制約)
    ● パターン2: 動的に分割
    ○ 公式Device Pluginで未実装
    ○ Podのresource.requestsに応じて分割
    ○ 実装に向けた課題が複数存在 (以下は一部)
    ■ GPU空き領域のフラグメント化
    ● GPUインスタンスの配置を工夫して軽減
    ■ Pod作成時はKubernetesから空きGPUが見えない (unschedulable)
    ● Pending Pod検知→空き領域のあるノードでGPUインスタンス作成
    

    View Slide

11. GPUaaS based on Kubernetes
    

    View Slide

12. コンテナ + Kubernetes を利用した
    利用者や上位のサービスに対して
    GPUインスタンスを提供する基盤
    多岐にわたる Kubernetes の
    エコシステムをフル活用
    ⇒ エコシステムの進化にも追従しながら、
    　 プラットフォームの進化を続けることで
    　 ビジネスの成功へ
    GPU as a Service の概要
    Container
    icons: https://icons8.jp/icons/set/video-card
    Computing resource pool
    Storage pool
    

    View Slide

13. Kubernetes と GPU
    Kubernetes には Device Plugin という仕組みが用意されている
    Device Plugin は Plugable になっており、様々なデバイスを Kubernetes で取り扱うことが可能
    ● GPU (NVIDIA / AMD / Intel)
    ● TPU (Tensor Processing Unit)
    ● FPGA
    ● etc.
    先程紹介した NVIDIA A100 の MIG (Multi Instance GPU) も
    将来的には Device Plugin によって動的に扱えるように進めています
    モニタリングでは Prometheus + DCGM Exporter を利用し、GPU とメモリ使用率を収集
    containers:
    - name: mljob
    image: my-mljob:v0.1
    resources:
    limits:
    nvidia.com/gpu: 1
    nvidia.com/mig-3g.20gb: 1
    （コンテナランタイム側の対応も必要）
    

    View Slide

14. Kubernetes とストレージ
    ストレージ / CSI Driver には NetApp / Trident を採用
    １．CSI Driver が多くの機能に対応
    ● 3 ヶ月おきのリリースサイクル（2016年12月〜）
    ● オープンソースでの開発
    ● コミュニティへの貢献にも積極的なため、Upstream の追従速度への期待も大きい
    ○ ストレージ側の機能が十分であっても、CSI Driver が未対応ならその機能は利用できない
    ○ ＝ 基盤側の機能不足で上位のサービスの価値が提供できない懸念が生まれる
    ２． ReadWriteMany / ReadWriteOnce の両方に対応（弊社は AFF A800）
    ● NAS：ML ワークロード向け
    ● SAN：GPUaaS を構成するアプリケーション向け（Databese、Prometheus、etc）
    Storage
    Kubernetes (CO)
    Container Storage Interface
    

    View Slide

15. Kubernetes とさらなる拡張
    Kubernetes の拡張性を生かして、自社の特定のドメインに特化した機能を追加
    例えば、
    ● DB の代替としてアプリケーションが利用するメタデータの保管（Custon Resource / Secret）
    ● クラウド向け認証情報の自動的なインジェクト（Mutating Webhook / Validating Webhook）
    ● 自動的に S3 / GCS からのデータロード ＋ キャッシュ（Custom Controller）
    ● Kubernetesから取得される情報を元にした課金システム
    

    View Slide

16. DB の代替としてメタデータの保管
    Web UI Console が利用するメタデータは Custom Resource として保存
    ● データベースを別途用意する必要が不要
    ● Kubernetes RBAC で制限可能
    ● 将来的に Controller での機能拡張も容易
    e.g. Web UI から起動する際に利用可能なコンテナイメージ
    

    View Slide

17. クラウド向け認証情報との連携
    クラウド向けの認証情報用に Secret の type を拡張（Validating webhook で検証）
    ● type: gcp-credential
    ● type: aws-credential
    クラウド向けの認証情報を自動マウント（Mutating webhook で挿入）
    ● Pod のアノテーションに指定
    ● ServiceAccount への紐付け
    ※ その他にも Pod のアノテーションでのマウント無効化など、いくつかの機能も実装
    

    View Slide

18. PersistentVolume への S3/GCS データのロード
    PersistentVolumeClaim 作成時にアノテーションを付与することで S3 / GCS からデータをロード
    前述のクラウド向け認証情報を利用することで、Private Bucket のロードも可能
    1. PVC にデータをロードする Job の作成
    2. PVC の .status.conditions で状態管理
    （type = Loading を拡張して追加）
    　　　課題：.status.conditions が特に使われておらず、
    　　　ロード完了前にも PVC の attach が行われてしまう
    機械学習の元データを効率的に扱えるように、
    Volume Snapshot との連携も検討中
    ※ その他にも 元データを変更されないように ReadOnly なマウントなど、いくつかの機能も実装
    （Controller）
    

    View Slide

19. GPU as a Service の 2 つの利用方法
    GPUaaS は 「専用の Web コンソール」 と 「kubectl」 から操作する
    Kubernetes API Server
    GPUaaS API Server
    $ kubectl ...
    ● Notebook の起動
    ● ボリュームの管理
    ● 課金情報の表示
    ● プロジェクトの管理
    ● etc
    Web Console kubectl
    A B
    

    View Slide

20. Kubernetes におけるマルチテナンシー
    ClusterRole と RoleBinding を用いて権限を管理
    　「WebUI Console からのプロジェクトへのメンバーの追加」 ＝ 「RoleBinding の追加」
    　　にすることで、シームレスに管理（ある意味前述のユーザーDB的にも利用）
    　　WebUI Console 側ではその他ロールに応じて様々な処理が可能
    UserA namespace UserB namespace
    TeamX namespace
    A B
    TeamY namespace
    admin
    clusterrole
    member
    clusterrole
    rolebinding
    

    View Slide

21. Hierarchical Namespace によるマルチテナント管理
    Hierarchical Namespace Controller を利用して全ての Namespace に対して共通設定を伝搬
    　ポリシー、設定データ、クラウドの共通アカウントの認証情報、メタデータ（CustomResource）、etc
    UserA namespace UserB namespace
    TeamX
    namespace
    GPUaaS namespace
    policy
    policy policy
    policy
    A B
    

    View Slide

22. OAuth2 Proxy + Ingress の連携による認証
    API へのアクセス認証は
    　OAuth2 Proxy + Ingress（ingress-nginx）
    　を利用して Google Account 認証
    API Server 側では
    ユーザ情報をもとに処理を行う
    GPUaaS API Server
    Web Console
    kind: Ingress
    metadata:
    name: gpuaas-api-server
    annotations:
    nginx.ingress.kubernetes.io/auth-url:
    "https://$host/oauth2/auth"
    nginx.ingress.kubernetes.io/auth-signin:
    "https://$host/oauth2/start?rd=$escaped_request_uri"
    

    View Slide

23. GPU インスタンスの提供方法
    1. Jupyter notebook 環境の提供
    with 独自の Web Console
    データサイエンティストや研究者など
    Kubernetes に詳しくないユーザー向け
    2. Kubernetes CLI を使った
    SSH ライクな環境
    $ kubectl exec -it PODNAME-0 -- bash
    PODNAME-0 #
    

    View Slide

24. GPU インスタンスの提供方法
    3. 上位のサービスへの基盤の提供
    Kubernetes をベースとした機械学習基盤の開発へ
    下位のレイヤーの機能が不十分だと実現したいことが実現できない
    　⇒ ストレージの機能、CSI Driver の機能性は重要
    DGX A100 AFF A800
    AI Platform
    GPUaaS （Kubernetes）
    AI Platform
    Kubernetes のポータビリティを
    生かしてマルチ DC 上への展開も検討
    

    View Slide

25. AI Platform based on GPUaaS
    

    View Slide

26. GCP AI Platform
    コードベースでMLワークフローを管理するサービス
    ● Training
    ○ 機械学習フレームワークで学習
    ○ ハイパーパラメータチューニング
    ○ 分散学習
    ● Prediction
    ○ 学習済みモデルをホスティング
    ○ サーバレス・スケール可能
    ○ 推定値を取得
    ● Optimaizer
    ○ ハイパーパラメータのブラックボックス最適化
    ● Pipeline
    ○ MLワークフローをパイプライン化
    AI Platform
    

    View Slide

27. #!/bin/bash
    CURRENT_DATE=$(date +%Y%m%d-%H%M%S)
    MODEL_NAME="test-model"
    PACKAGE_PATH=./trainer
    JOB_NAME=${MODEL_NAME}-${CURRENT_DATE}
    gcloud ai-platform jobs submit training ${JOB_NAME} --package-path
    ${PACKAGE_PATH} --config ./config.yaml
    trainingInput:
    scaleTier: CUSTOM
    region: us-east1
    jobDir: "gs://test-bucket/test-job"
    masterType: n1-standard-16
    masterConfig:
    acceleratorConfig:
    count: 1
    type: NVIDIA_TESLA_V100
    args:
    - "--test_arg1=test1"
    - "--test_arg2=test2"
    pythonModule: trainer.task
    pythonVersion: 3.7
    runtimeVersion: 2.2
    GCP AI Platform Training
    Training
    Job definition
    Submit
    Training Job
    trainer/
    ├── __init__.py
    ├── experiment.py
    ├── model.py
    └── task.py
    ML Application
    Execute
    ML Application
    

    View Slide

28. trainingInput:
    scaleTier: CUSTOM
    ・・・
    hyperparameters:
    algorithm: BAYESIAN_OPTIMIZATION
    goal: MAXIMIZE
    hyperparameterMetricTag: accuracy
    maxTrials: 30
    maxParallelTrials: 1
    params:
    - parameterName: test-metrics1
    type: INTEGER
    minValue: 40
    maxValue: 400
    ・・・
    runtimeVersion: 2.2
    GCP AI Platform
    Hyperparameter Tuning
    Training
    Job definition
    #!/bin/bash
    CURRENT_DATE=$(date +%Y%m%d-%H%M%S)
    MODEL_NAME="test-model"
    PACKAGE_PATH=./trainer
    JOB_NAME=${MODEL_NAME}-${CURRENT_DATE}
    gcloud ai-platform jobs submit training ${JOB_NAME} --package-path
    ${PACKAGE_PATH} --config ./config.yaml
    Submit
    Training Job
    trainer/
    ├── __init__.py
    ├── experiment.py
    ├── model.py
    └── task.py
    Hyperparameter
    Section
    ML Application
    

    View Slide

29. 開発スピードが下がってしまうため、
    GCP/AWSで完結させたい
    GCP AI Platformのように簡単に学習させられな
    いため
    クラウドから移行するのが大変なので使わない
    (複数回答可)
    現在提供しているGPUサービスの不満点を教えてください。
    なぜ独自のAI Platformが必要なのか
    

    View Slide

30. GCP AI Platformと互換性のあるMLワークフローを管理できる社内基盤
    (現状学習部分のみ)
    要件
    ● GCP AI PlatformのMLワークフローをオフロードできる
    ○ オブジェクトストレージをハブに
    ● GCP AI Platformと操作性を統一できる
    ○ kubectlのプラグイン機能
    ● ハイパーパラメータチューニングができる
    ○ KubeflowのコンポーネントであるKatibを利用
    ● GCP AI Platformの設定を再利用できる
    ○ Katib用のマニフェストに変換
    GPUaaS上で動作 & GPUaaSの特徴を継承
    AI Platform の概要
    DGX A100 AFF A800
    GPUaaS （Kubernetes）
    AI Platform
    ML Pod
    

    View Slide

31. Kubectl Plugin
    kubectlを拡張し、サブコマンドを作成
    1. スクリプト/Binary作成
    2. 実行権限設定
    3. $PATH以下にkubectl-というPrefixで保存
    ※ コマンドで-を使用したい場合は_を使用
    $ kubectl plugin list
    The following kubectl-compatible plugins are available:
    /usr/local/bin/kubectl-plugin_test
    $ mv plugin_test.sh /usr/local/bin/kubectl-plugin_test
    $ kubectl plugin-test
    This is kubectl plugin test
    $ chmod +x plugin_test.sh
    $ cat << EOT >> plugin_test.sh
    #!/bin/bash
    echo "This is kubectl plugin test"
    EOT
    

    View Slide

32. GCP AI Platformとの操作性の統一
    kubectl ai-platform jobs submit training
    kubectl ai-platform jobs list|get
    kubectl ai-platform jobs describe
    kubectl ai-platform jobs stream-logs
    kubectl ai-platform jobs cancel
    On-prem. resource
    gcloud ai-platform jobs submit training
    gcloud ai-platform jobs list|get
    gcloud ai-platform jobs describe
    gcloud ai-platform jobs stream-logs
    gcloud ai-platform jobs cancel
    Cloud resource
    GCP AI Platform
    Job definition
    

    View Slide

33. Kubernetes上でMLワークフローを構築できるツールキット
    https://www.kubeflow.org/docs/started/kubeflow-overview/
    ● デプロイする環境を選ばない
    ○ オンプレミスにデプロイ
    ● Kubernetesによってリソースを管理
    ○ 拡張性、豊富なエコシステム
    ● ハイパーパラメータチューニング
    ○ Katib
    ● 多様なOperator
    ○ 多様なMLフレームワーク
    Kubeflow
    

    View Slide

34. Katib Components
    Experiment Suggestion
    Trial Trial Trial
    TFJob/PytorchJob/Job
    Pod
    Worker
    Container
    Experiment
    ● ハイパーパラメータチューニングの実行単位
    ● アルゴリズムなど全ての設定を書き込む
    Suggestion
    ● ハイパーパラメータを生成
    Trial
    ● 生成したハイパーパラメータを用いて学習を実行
    Metrics Container
    ● 学習モデルの予測精度をMetricsとして保存
    Metrics Collector
    ● MetricsをDBに書き込んでチューニングを完了
    Metrics
    Collector
    Katib DB
    Metrics
    Container
    

    View Slide

35. Katib Manifest #1
    Metadataなど
    を定義
    Trial数を定義
    最適化したい
    Metricsを定義
    アルゴリズム
    を定義
    Metrics Collector
    を定義
    ハイパーパラメータ
    を定義
    

    View Slide

36. Katib Manifest #2
    Trialで利用する
    ハイパーパラメータを定義
    TrialのJob Template
    を定義
    

    View Slide

37. GCP AI Platformの設定を再利用
    trainingInput:
    scaleTier: CUSTOM
    region: us-east1
    jobDir: "gs://test-bucket/test-job"
    workerType: n1-standard-16
    workerCount: 2
    workerConfig:
    imageUri: gcr.io/kubeflow-ci/tf-mnist-with-summaries:1.0
    hyperparameters:
    algorithm: RANDOM
    goal: MAXIMIZE
    hyperparameterMetricTag: accuracy_1
    maxTrials: 12
    maxParallelTrials: 3
    params:
    - parameterName: learning_rate
    type: DOUBLE
    minValue: 0.01
    maxValue: 0.05
    - parameterName: batch_size
    type: INTEGER
    minValue: 100
    maxValue: 200
    pythonModule: trainer.task
    pythonVersion: 3.7
    runtimeVersion: 2.2
    Clientで
    変換/生成
    

    View Slide

38. AI Platformシステム構成
    icons: https://icons8.jp/icons/set/video-card
    

    View Slide

39. AI Platformの内部フロー
    Job submit基本フロー
    ①submitコマンド実行
    ②モデルのコードを圧縮
    ③圧縮したコードをGCSへ
    ④KatibのExperiment作成
    ⑤TrialがPodを作成(+PVをアタッチ)
    ⑥圧縮されたコードをダウンロード
    ⑦トレーニング実行
    ⑧トレーニング済みモデルを GCSへ
    ①
    ②
    ③
    ④
    ⑤
    ⑥
    ⑦
    ⑧
    

    View Slide

40. AI Platformシステム
    ~Jobの振り分け~
    LabelsでTrialのPod Template内のJob (Operator)を振り分け
    ● TFJob (TF Operator)
    ○ --labels framework=tensorflow
    ● PytorchJob (Pytorch Operator)
    ○ --labels framework=pytorch
    ● Job
    ○ それ以外
    

    View Slide

41. AI Platformシステム
    ~カスタムイメージ~
    利用開始時にINIT処理を行う(ADMIN権限)
    ● NamespaceのLabelsを更新
    ○ katib-metricscollector-injection: enabled
    ● AI Platform用のServiceAccount作成
    ○ imagePullSecretsを管理
    imagePullSecretsでカスタムイメージをPullする
    

    View Slide

42. AI Platformシステム
    ~Monitoring~
    Metricsの収集を有効化
    ● Job Submit時に--metrics-collectorオプションを指定
    ● ハイパーパラメータチューニングの設定
    → MetricsがPersistent Volumeに保存できる
    Monitoring環境の構築
    ● Monitoring用コマンド発行
    → TensorBoardのPod + Ingressが払い出される
    

    View Slide

43. TensorBoard
    学習フレームワークの可視化ツールキット
    ● Metricsの追跡と可視化
    ● データフローグラフの可視化
    ● 学習の履歴の可視化
    ● 途中過程で生成される画像などの表示
    

    View Slide

44. OSSによる継続的な機能改善
    Kubernetesの強みを最大限に
    まとめ
    DGX A100
    GPUaaS
    (Kubernetes)
    AI Platform
    AI Platform
    OSSを積極的に活用し、プラットフォームを改善することで、
    アプリケーション開発のアジリティが向上し、ビジネスに大
    きなインパクトを与える
    AFF A800
    Google AI Platformとの互換性
    超高性能なGPU/ストレージ
    

    View Slide

45. 今後の展望
    GPUaaS
    ● MIGの自動分割機能
    AI Platform
    ● サービング機能
    ○ 推論のエンドポイント
    ● モデルのバージョン管理
    ○ トラフィック制御
    ● パイプライン機能
    ○ MLワークフローの自動化
    物理
    ● DGX A100/A100 GPU、AFF A800の増強
    ● 他のGPU(T4など)との統合によるコスト効率の向上
    

    View Slide

46. ご静聴ありがとうございました
    

    View Slide