KubernetesベースのGPU as a Service Platform ～サイバーエージェントにおけるGPU活用の取り組み～ [INSIGHT Japan 2022 Digital]

AIを活用した新サービスの開発を積極的に進めています。その中でOSSを積極的に利用することで、開発のアジリティを高め、サービス品質を継続的に向上させています。本セッションではKubernetesをはじめとしたOSSを利用し、柔軟に進化し続けるプラットフォームを、NetApp AFF A800、NVIDIAのDGX A100とTridentを活用して構築・提供している事例について紹介します。

Transcript

1. KubernetesベースのGPU as a Service Platform ～サイバーエージェントにおけるGPU活用の取り組み～ Lee Yeongjae Masaya Aoyama (@amsy810) Daisuke Takahashi
2. Who we are? Daisuke Takahashi Infrastructure Engineer 2019年にサイバーエージェントへ新卒入 社。プライベートクラウド運用やコンテナ基盤 開発に携わった後、現在は主に Solution ArchitectとしてML/3DCG/アドテク領域を担 当。本プロジェクトでは物理層を設計・運用。 Masaya Aoyama 2016年新卒入社。OpenStackを使ったプラ イベートクラウドや GKE互換なコンテナプ ラットフォームをゼロから構築。 国内最大のCloud Nativeカンファレンスの Co-chairの他、Kubernetes Meetupの Organizerなどにも従事。 著書『Kubernetes完全ガイド』 Software Engineer 2016年にサイバーエージェントに入社。入社 後は広告プロダクトでソリューションアーキテ クト、さらにプライベートクラウドや GKE互換 なコンテナプラットフォームの開発を担当。 基盤開発チームのマネージャとして AIプラッ トフォームを開発。 Lee Yeongjae Manager
3. Agenda 1. GPUの必要性 2. ハードウェア 3. KubernetesベースのGPU as a Service 4. AI Platform 5. まとめ・今後の展望
4. なぜAIソリューションが必要なのか コスト削減 • ビジネスのドメイン知識習得 • 広告の自動生成 効果改善 • 思いもよらない効果的な広告の発見 • 広告の効果分析と改善 リスク対応 • 掲載広告の炎上リスク回避
5. なぜGPUが必要なのか 莫大・複雑な処理 • 広告と掲載メディアの組み合わせが膨大 • 人口統計情報（地域、年齢など）など考慮する情報が膨大 高速な実行 • 急速なトレンドの変化 • リアルタイムな情報取得
6. ユーザ: 研究者, Data Scientist, MLOps Engineer Jupyter Notebook : GUI上で動作する対話型プログラム実行環境 Google AI Platform : Clientツール/GUIでMLワークフローを管理 AIソリューションの環境 モデルの学習・評価 モデルのデプロイ モデルによる推論 推論のモニタリング モデルのバージョン管理 コードの実装・ 入力データの用意
7. システム構成 DGX A100 + AFF A800: 高性能GPUとストレージを提供 GPU as a Service: Jupyter Notebookを提供 独自AI Platform: Google AI Platform相当の基盤を提供 DGX A100 AFF A800 GPUaaS (Kubernetes) AI Platform
8. なぜオンプレミスなのか 機能面 • 柔軟なソフトウェアスタック • 既存のサービスとの接続が容易 コスト面 • クラウドの費用は高い • 長期的に見ると安い クラウドのGPU費用 (ある部門)
9. GPU as a Serviceの ハードウェアの歴史
10. v1: GPUコンテナ
 • 複数の研究者が持つ GPU資源の一元管理 を実現
 ◦ 原則、各自が1ホストを占有 
 
 v2: GPUコンテナ + Jupyter Notebook
 • 研究者向けにマネージドなNotebook環境 を提供
 • v1同様のGPUコンテナ単体も選択可能 
 
 v3: GPUコンテナ + Jupyter Notebook + AI Platform
 • 研究者に加え、開発者向けにもv2と同等機能を提供 
 • GPUaaS上で動作するAI Platform (GCP互換のML基盤) を開発・ホスティング 
 GPUaaSの歴史
11. GPUaaS v1 GPU資源の運用の効率化 • 研究者が個別に利用していたワークステーションを 一元管理 ◦ 各利用者に1ホスト (ノード) 単位で提供 • オフィス内のサーバールーム (という名前のMDF室) に設置 ◦ GPU: 20x NVIDIA GeForce GTX 1080Ti 11GB (220GB) ◦ CPU: 324コア ◦ メモリ: 1.28TB 再現が容易な環境 • コンテナ型仮想化によって実験環境を容易に再構築可能 • 社内でマネージド基盤の運用実績がある Kubernetesを導入 ◦ Kubernetes APIへの直接アクセスを利用者に提供
12. GPUaaS v2 GPUaaS v1の後継 • GPU資源などはv1から移行 • ホスト占有から共同利用へ変更 (マルチテナント) NEW: 学習データ用共有ストレージ • クラスタ内の各コンテナから同一データを参照可能 • Kubernetes上にSoftware-defined Storageを構築 ◦ Rook (Ceph) によるNFSストレージ ◦ SATA SSD 48TB分 NEW: マネージドな学習環境 • Kubernetesを意識させずにJupyter Notebookを提供 • 他のコンテナイメージも利用可能
13. v2の運用上の課題 設置環境 • オフィスへの高電力機器の設置は想定外 ◦ 限られた電力供給と冷却性能 ◦ 法定停電 • データセンターとの接続品質 ◦ Site-to-site VPNのみ ◦ 非冗長構成 マシンの管理 • リモート管理機能 (IPMI/BMC) の欠如 ◦ 些細な作業でも現地での運用が必要 ◦ COVID-19によるオフィスの制限 性能 • GPUメモリの不足 ◦ ML向けではないGeForceシリーズ • 経年による陳腐化 ◦ 新世代のCPUやGPUの登場 ◦ ハードウェア故障の頻度上昇
14. GPUaaSの改善のための検討 好評を受けて、サービスの開発者から本番環境としての要望が届いていた 求められる品質の達成には、ソフトウェアだけでなく、ハード面の取り組みが不可欠 設置環境 • オフィスの一角を脱却 • プライベートクラウドを運用している DC (東京都内) に設置 スペック • GPUaaS用のサーバーを新規調達 (IPMI搭載) • 大容量のメモリを持つデータセンター向け GPU ◦ Tesla V100, T4, etc.
15. NVIDIA A100 Ampereアーキテクチャ • 前世代 (V100) と比べて20倍の性能 新しいハードウェア機能 • Multi-Instance GPU, Sparsity, etc. より高速なGPU-to-GPU接続 • 第3世代NVLink / 第2世代NVSwitch • 最大16GPU • 600 Gbpsのフルメッシュ
16. GPUaaS v3 GPUハードウェアを刷新 • NVIDIA DGX A100を採用 ◦ GPU: 8x NVIDIA A100 40GB (320GB) ◦ CPU: 128コア / メモリ: 1TB ▪ ソフトウェア面の詳細は後述 • 「DGX-Ready」対応データセンターへ設置 ◦ 電力や冷却能力、搬入経路などが安心 • 推論: 9x NVIDIA T4 (144GB) を導入済み • 学習: NVIDIA A100 80GB (500W仕様) を導入予定 INSIGHT初公開情報
17. 「ストレージも刷新したい」

18. v2のストレージの制約 (ハードウェアの仕様) 
 • ラックの占有スペースに対して、 容量効率が低い
 → 大容量ディスクやディスク搭載数の多い筐体 の導入
 • A100 GPUの性能に対して、 アクセス速度の不足 
 → ディスク性能とネットワーク性能の改善
 
 ストレージ運用からの解放
 • Rook (Ceph) は既存資源を活用する方針にマッチしていたため選定 
 ◦ ストレージ自体が目的ではないため、 SDSへのモチベーションが高くない
 • → SDSに限らず、アプライアンスも検討 
 
 追加の機能
 • GPUaaSの内部メタデータ用の ブロックアクセス
 • GPUaaSのログ・メトリクス用の オブジェクトアクセス 
 ストレージの改善 INSIGHT初公開情報
19. 学習データ用共有ストレージを刷新 • NetApp AFF A800を採用 ◦ NVMe SSD 62TB (All-lash) ▪ スケールアウト・スケールアップが可能: • 空きベイへのディスク追加 • ディスクシェルフ追加 • コントローラー追加 ◦ マルチプロトコルでのアクセスに対応 ▪ File (NFS, SMB), Block (iSCSIなど), Object (S3) ◦ Kubernetesとの連携は後述 • 「NVIDIA DGX POD」を意識して選定 ◦ DGXシステムとストレージの scalableな参考構成 ◦ NetAppからはONTAP AIとして発表 GPUaaS v3 (ストレージ) * Photo of the evaluation system. Some configurations differ.
20. 参考: v3のハードウェア概要 (2022) Compute NVIDIA DGX A100 Dell PowerEdge Servers Network Mellanox SN2010 Storage NetApp AFF A800 100 GbE 25 GbE 10 GbE
21. GPU as a Service with Kubernetes
22. GPU as a Service の概要 Container Computing resource pool Storage pool GPU資源を ユーザー ・ 上位サービス に提供する基盤 要件 • タスク実行時に影響を受けないよう GPUを隔離して提供 • 同時接続可能な高性能ストレージを提供 基盤として コンテナ + Kubernetes を採用
23. Kubernetes の GPU 対応 Kubernetes には Device Plugin という仕組みが用意されている Device Plugin は Plugable になっており、様々なデバイスを Kubernetes で取り扱うことが可能 • GPU (NVIDIA / AMD / Intel) • TPU (Tensor Processing Unit) • FPGA • etc. NVIDIA A100 の Multi-instance GPU にも対応 containers: - name: mljob image: my-mljob:v0.1 resources: limits: nvidia.com/gpu: 1 （コンテナランタイム側の対応も必要）
24. Kubernetes の 強み Reconciliation Loop による宣言された状態への収束 エコシステムの豊富さ プラットフォームとしての拡張性の高さ 1 2 3
25. 1. Reconciliation loop による宣言された状態への収束 Kubernetes では Controller と呼ばれるプログラムがシステムを制御 複数の Controller によって 宣言された状態に収束 • 指定されたレプリカ数の維持 • ノード障害によりコンテナ停止時の再復旧 • 機密情報や設定ファイル変更時の自動的な再読み込み • ロードバランサーのメンバーの自動管理 • etc Actual ReplicaSet (replicas=3) Watch ReplicaSet Controller kind: ReplicaSet spec: replicas: 3 template: spec: containers: - image: nginx:1.16 Desired State Watch
26. 2. エコシステムの豊富さ CNCF / Kubernetes コミュニティではオープンな技術促進が進められており、 Kubernetes と連携した様々な OSS が開発・公開されている Reconciliation Loop を利用した OSS の拡張 Controller を利用することで、 様々な定常的な運用の大部分を Kubernetes に委譲し、機能追加することが可能 【参考】 • Prometheus / Grafana：GPU や多岐にわたるミドルウェアの監視 • cert-manager：ACMEを利用した証明書の自動生成と管理、 LoadBalancerとの自動連携 • external-dns：払い出されたIPアドレスとDNSレコードの管理 • oauth2-proxy + nginx ingress：WebUI へのリクエストに対する OAuth2 連携 • Others：オートスケーリング、 Progressive Delibery、プロジェクト間のデータ伝搬、 etc
27. 3. プラットフォームとしての拡張性の高さ Kubernetes は自社の特定のドメインに特化した機能拡張も可能 Controller を実装するためのフレームワークなども提供されている（汎用的な OSS も利用している） 例えば、 • 自動的に S3 / GCS からのデータロード ＋ キャッシュ（Custom Controller） • クラウド向け認証情報の自動的なインジェクト（ Mutating Webhook） • DB の代替としてアプリケーションが利用するメタデータの保管（ Secret / ConfigMap） • Kubernetesから取得される情報を元にした課金システム 他にも、コンテナランタイム（ OCI/CRI）・ネットワーク（CNI）・ストレージ（CSI）など、 様々な標準化と歩幅を合わせながら実装が進められている
28. Kubernetes の強み Reconciliation Loop による宣言された状態への収束 エコシステムの豊富さ プラットフォームとしての拡張性の高さ • 復元力がある • 管理しやすい • 可観測性がある • 堅牢な自動化で頻繁な更新 • etc 1 2 3 ⇒ OSS の進化にも追従しながら、 　 プラットフォームの進化を続けることで 　 ビジネスの成功へ
29. Kubernetes & Storage
30. Kubernetes と ストレージ の連携 Kubernetes とストレージの連携には Container Storage Interface (CSI) を利用 CSI はオープンな仕様のみ定められており、実際に利用できる機能は CSI Driver により異なる • https://github.com/container-storage-interface/spec • https://kubernetes-csi.github.io/docs/drivers.html Storage Container Orchestrator Container Storage Interface • ボリュームの作成・削除 • ボリュームのアタッチ・デタッチ • ボリュームの拡張 • ボリュームのクローン • スナップショット・リストア • トポロジ指定 • RAWボリュームの作成
31. CSI の機能セット Kubernetes における CSI Driver は複数のサブ機能に分けられている ストレージ側の機能が十分であっても、CSI Driver が未対応ならその機能は利用できない CSI Driver 面でストレージ 選定時に考慮した点 1. Kubernetes Upstream の機能への追従スピード 　　（リリース頻度・Upstream への参加具合） 2. CSI Driver のクオリティ 　　（バグ修正の対応速度含む） Container Orchestrator Container Storage Interface Storage Trident
32. OSS としての Trident Trident (CSI Driver) は OSS として公開 • CSI 以前から開発されていたこともあり、品質も十分 開発体制が優れている • 3 ヶ月おきのリリースサイクル（2016年12月〜） • コミュニティへの貢献にも積極的なため、Upstream の追従速度への期待も大きい ReadWriteOnce / ReadWriteMany の両方に対応（弊社は AFF） • NAS：ML ワークロード向け • SAN：GPUaaS を構成するアプリケーション向け（Databese、Prometheus、etc） • Object Storage：ストレージバックエンドに利用するアプリケーション向け（Loki、etc）
33. GPU as a Service experience
34. GPUインスタンスのユーザーへの提供 GPU as a Service は専用のコンソールからの操作・kubectl からの操作の 2通り Kubernetes API Server GPUaaS API Server $ kubectl ... • notebook の管理 • ボリュームの管理 • 課金情報の表示 • プロジェクトの管理 • etc Web Console kubectl A B
35. GPU インスタンスの提供方法 Kubernetes Namespace を利用してテナント分離 ClusterRole と RoleBinding を利用して権限管理 特定のプロジェクトにユーザを追加する＝ 特定の Namespace で RoleBinding を追加する Console からは Impersonate して Kubernetes API を使用 UserA namespace UserB namespace TeamX namespace A B TeamY namespace admin clusterrole member clusterrole rolebinding
36. GPU インスタンスの提供方法 Hierarchical Namespace Controller を用いて各 Namespace に設定を伝搬 ポリシー、設定ファイル、クラウドの認証情報、メタデータ（ CustomResource）など UserA namespace UserB namespace TeamX namespace GPUaaS namespace policy policy policy policy A B
37. GPU インスタンスの提供方法 1. Jupyter notebook 環境の提供 データサイエンティストや研究者など Kubernetes に詳しくないユーザー向け 2. Kubernetes CLI を使った SSH ライクな環境 $ kubectl exec -it PODNAME-0 -- bash PODNAME-0 #
38. GPU インスタンスの提供方法 3. 上位のサービスへの基盤の提供 Kubernetes をベースとした機械学習基盤の開発へ 下位のレイヤーの機能が不十分だと実現したいことが実現できない 　⇒ ストレージの機能、CSI Driver の機能性は重要 DGX A100 AFF A800 AI Platform GPUaaS （Kubernetes） AI Platform Kubernetes のポータビリティを 生かしてマルチ DC 上への展開も検討
39. AI Platform
40. なぜオリジナルのAI Platformが必要か (複数回答可) 現在のGPUaaSの不満点は何ですか？ 開発スピードが下がってしまうため、 GCP/AWSで完結さ せたい AI Platformのように簡単に学習させられないため クラウドから移行するのが大変なので使わない
41. AI Platformの要件 学習&推論 • Google AI PlatformのMLワークフローをオフロードできる ◦ オブジェクトストレージ をハブに • Google AI Platformと操作性を統一できる ◦ kubectlのプラグイン機能 学習 • ハイパーパラメータチューニングができる ◦ Kubeflowのコンポーネントである Katibを利用 • Google AI Platform Trainingの設定ファイルを再利用できる 推論 • 推論エンドポイントが作成できる ◦ Kubeflowのコンポーネントである KFServingを利用 • モデルのバージョン管理 ◦ 社内独自のモデルメタデータ管理基盤 を利用 • 社外からの推論エンドポイントへのアクセス ◦ IstioとExternal Authorizationで認可 • Google AI Platform Predictionの設定ファイルを再利用できる
42. 学習&推論
43. オブジェクトストレージをハブに
44. 操作性の統一 kubectl ai-platform jobs submit training... kubectl ai-platform jobs submit prediction... kubectl ai-platform predict... kubectl ai-platform models... kubectl ai-platform versions... On-prem. resource gcloud ai-platform jobs submit training... gcloud ai-platform jobs submit prediction... gcloud ai-platform predict... gcloud ai-platform models... gcloud ai-platform versions... Cloud resource Google AI Platform Definition
45. 学習
46. Kubeflow Kubernetes上でMLワークフローを構築できるツールキット https://www.kubeflow.org/docs/started/kubeflow-overview/ • デプロイする環境を選ばない ◦ オンプレミスにデプロイ • Kubernetesによってリソースを管理 ◦ 拡張性、豊富なエコシステム ◦ マニフェストによるオブジェクト操作 • ハイパーパラメータチューニング ◦ Katib • 推論エンドポイント作成 ◦ KFServing
47. Katib 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
48. 設定を再利用 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 Katibの Manifestに 変換/生成
49. AI Platform Trainingのシステム構成
50. 推論
51. Kubeflow https://www.kubeflow.org/docs/started/kubeflow-overview/
52. KFServing 概要 • 推論機能を提供(InferenceServerで定義) • モデルのサービングを抽象化 (TensorFlow, PyTorch, XGBoostなど対応) • サービング用コンテナを管理(Knative) • トラフィックルーティングを管理(Istio) 特徴 • 自動スケーリング可能 • カナリアロールアウト/ABテスト可能 • 予測、前処理、後処理が実行可能
53. Inference Server 概要 • KFServingのCustom Resource Definition • 推論エンドポイントの実体 ◦ モデルがロードされたコンテナ ◦ 推論エンドポイント(FQDN)を払い出す 特徴 • 前処理 / 後処理なども可能 • PodSpecが記述可能なのでカスタムコンテナも利用可能
54. KFServing Manifests Metadataなど を定義 コンテナ レプリカ数を定義 モデルのロケーションを 定義 リソースを定義 nodeSelectorなどを 定義
55. 設定を再利用 name: "tensorflow-gpu" machineType: "n1-standard-32" framework: "TENSORFLOW" deploymentUri: "gs://kfserving-samples/models/tensorflow/flowers" runtimeVersion: "2.4" acceleratorConfig: count: 1 type: "NVIDIA_A100_40GB" autoScaling: minNodes: 0 maxNodes: 5 KFServingの Manifest 変換/生成
56. 独自のモデルメタデータ管理基盤 概要 • モデルに様々なメタデータを付与して管理 • 元々は実験の追実験や再現のための基盤 • 他の部署で開発・運用 特徴 • モデルのバージョン履歴を保存可能 • モデルに様々なメタデータを紐付け可能 ◦ コードやデータセットなど • モデルへのアクセス権限を制御可能 ◦ READ / WRITE / RWの3パターン • モデルのロケーションを指定可能 ◦ GCS / S3に対応
57. IstioとExternal Authorization External Authorization • Envoyの機能の一部 • リクエストの認可を外部の認可サーバに移譲 • 独自の認可ロジックを実装可能 • 認可は決められたREST API / gRPC Serviceを実装 • Istioを用いると設定が簡略化 apiVersion: security.istio.io/v1beta1 kind: AuthorizationPolicy metadata: name: ext-authz spec: selector: matchLabels: app: istio-ingressgateway action: CUSTOM provider: name: "ext-authz-service" rules: - to: - operation: paths: ["/auth/*"] extensionProviders: - name: "ext-authz-service" envoyExtAuthzGrpc: service: "ext-authz.default.svc.cluster.local" port: 9000 認可対象の登録 認可サーバの登録
58. AI Platform Predictionのシステム構成
59. AI Platform PredictionのPredictフロー model作成 ①models createコマンド実行 ②External Authzサーバにて認可 ③モデル登録リクエスト生成 ④メタデータサーバにモデル登録 predict実行 ⑩predictコマンド実行 ⑪External Authzサーバにて認可 ⑫リクエストをInferenceServerに転送 ⑬推論実行 ⑭推論のレスポンスを返却 model version作成 ⑤versions createコマンド実行 ⑥External Authzサーバにて認可 ⑦InferenceServer作成リクエスト生成 ⑧モデルを GCS / S3からダウンロード ⑨InferenceServer生成 ① ② ⑥ ⑪ ③ ④ ⑤ ⑨ ⑦ ⑧ ⑩ ⑫ ⑬ ⑭
60. ログについて 必要なログ • Training Jobのログ ◦ 機械学習コンテナの出力 • Predictionのログ ◦ 推論コンテナの出力 • システムの各種コンポーネントのログ ◦ 各種コンポーネント(コンテナ)のログ ▪ Katib ▪ KFServingなど ユーザに提供 アプリケーションのDebugに使用 システム管理者に提供 障害発生時のアラート通知に使用
61. Grafana Loki 概要 • OSSのロギングツール • ログの可視化や検索が実現可能に • 3つのコンポーネントでログ基盤として動作 ◦ Grafana + Loki + Promtail 特徴 • マルチテナント管理 • 1ログデータ毎にラベルを持つ • 圧縮されたデータとメタデータを扱うので軽量 • 複数のバックエンドストレージを利用可能 • Alert Managerと連携してアラート設定可能 • Helm Chartsがあるので構築が容易
62. Grafana Loki と NetApp All Flash FAS(AFF) ログデータの構成と対応ストレージ • Index (検索用インデックス) ◦ BoltDB (Local Storage) ◦ Single Store (boltdb-shipper) ◦ Amazon DynamoDB / Google Bigtable ◦ Apache Cassandra • Chunk (実データ) ◦ Local File System ◦ Amazon DynamoDB / Google Bigtable ◦ Apache Cassandra ◦ Amazon S3 / Google Cloud Storage NetApp AFFはブロックストレージとしてもS3としても利用できるので最適 boltdb-shipper
63. まとめ
64. まとめ なぜGPUが必要なのか ★莫大・複雑な処理を高速にする必要がある オンプレミスのメリット 機能面 • 柔軟なソフトウェアスタックが組める • 既存のサービスとの接続が容易 コスト面 • クラウドの費用はやはり高い • 長期的に見ると安い
65. まとめ OSSによる継続的な機能改善 Kubernetesの強みを最大限に DGX A100 GPUaaS (Kubernetes) AI Platform AI Platform OSSを積極的に活用し、プラットフォームを改善することで、アプリ ケーション開発のアジリティが向上し、ビジネスに大きなインパクトを 与える AFF A800 Google AI Platformとの互換性 超高性能なGPU/ストレージ
66. 今後の展望 機能 • パイプライン機能 ◦ MLワークフローの自動化 • ブラックボックス最適化機能 物理 • DGX A100/A100 GPU、AFF A800の増強 • 他のGPU(T4など)との統合によるコスト効率の向上
67. ご静聴ありがとうございました