分散キャッシュシステム on Kubernetes / Kubernetes Meetup Tokyo 60

PFN が開発した分散キャッシュシステム（ https://tech.preferred.jp/ja/blog/distributed-cache-for-deep-learning/ ） について Kubernetes の観点から紹介します。イベントサイト： https://k8sjp.connpass.com/event/291103/

Transcript

1. 分散キャッシュシステム on Kubernetes Kubernetes Meetup Tokyo #60, 2023/08/22 (Tue) Yuichiro Ueno (@y1r96) / Preferred Networks, Inc.
2. 2 • 上野 裕一郎 (Yuichiro Ueno) ◦ 2021/04 新卒でPFNに入社 ◦ Cluster Services チーム ▪ 「計算基盤のサービス化」 • 入社前 ◦ スパコンで深層学習 • 趣味 ◦ ISUCONなど性能最適化 • SNS ◦ x.com/y1r96 発表者の紹介 We're hiring!
3. 3 深層学習のための分散キャッシュシステム - Preferred Networks Research & Development 最近こういうブログを書きました 今日はこの話を Kubernetes 多めで
4. 4 背景: PFNの計算基盤・ストレージ
5. 5 豊富な計算資源と高度な技術を基盤に複数の事業を創出 Computer Vision（コンピュータビジョン） Data Analytics（データ解析） Navigation（ナビゲーション） Visual Inspection（外観検査） Pose（ポーズ推定） Scene（シーン解析） Image Segmentation Anomaly Detection（異常検知） Optimization（最適化） Time series data（時系列データ） Infrastructure （インフラ技術） Machine Learning and Deep Learning（機械学習と深層学習） Manufacturing Transportation Bio & Healthcare Personal Robot Visual Inspection Entertainment PFN Technology Business Object Detection（物体検出）
6. 6 PFNのオンプレKubernetesクラスタ Icon pack by Icons8 - https://icons8.com MN-2b (A30) 42 nodes (252 GPUs) A30 (24G) PCIe x 6 100GbE x 2 RoCEv2 with SR-IOV MN-2b (A100) 42 nodes (168 GPUs) A100 (80G) SXM4 x 4 100GbE x 2 RoCEv2 with SR-IOV 拠点名: MN-J MN-2a 128 nodes (1024 GPUs) V100 (16 / 32 G) SXM2 x 8 100GbE x 4 RoCEv2 with SR-IOV MN-3 48 nodes (192 MN-Cores) MN-Core x 4 100GbE x 2 MN-Core DirectConnect 80 CPU Cores 128 CPU Cores 48 CPU Cores 36 CPU Cores DDR4 384GB DDR4 384GB DDR4 1024 GB DDR4 512 GB
7. 7 PFNのオンプレストレージクラスタ Icon pack by Icons8 - https://icons8.com トータル 約 10 PB (論理容量) File System Medium MN-J ストレージ NFS HDD NVMe SSD HDFS Apache Ozone 拡大中!
8. 8 深層学習Podからのデータセット読み込み ファイルストレージ NFS オブジェクトストレージ Apache Ozone ファイルストレージ Node Local NVMe 利点 • 速い 欠点 • 容量に限界がある • 利用効率が悪い • プリエンプションで消える 利点 • ぼちぼち速い • プリエンプションで消えない 欠点 • 利用者が増えると遅くなる • スケールアウトできない 利点 • スケールアウトできる • プリエンプションで消えない 欠点 • HDDの採用により 読み込み性能が不十分 高速・スケーラブル・Podのプリエンプションで消えないストレージが欲しい！
9. 9 分散キャッシュシステム
10. 10 • 高速 ◦ Node Local NVMe を活用する ◦ シンプルなつくりにして性能を追求する • スケーラブル ◦ SPOF なものをつくらない ◦ 各バックエンドインスタンスがデータベースを共有しない • プリエンプションで消えない（＝ Pod よりも長いライフサイクル） ◦ Pod とは独立したストレージサービスとする どのようなストレージを開発するか？
11. 11 分散キャッシュシステムのアーキテクチャ Envoy Pod Kubernete s Service Envoy Pod Envoy Pod Envoy Pod Layer 4での負荷分散 (Service with Topology Aware Hints) Cache Pod Cache Pod Cache Pod Cache Pod Layer 7での負荷分散 (Envoy Proxy with Consistent Hashing) User Pod
12. 12 • HTTP REST APIで簡単（GET & PUT） • 速い ◦ Cache Pod は ローカルのファイルを返すだけ • 負荷が分散する ◦ 多くのWeb アプリケーションでの信頼と実績がある L4 LB と L7 LB の構成 • スケールアウト可能 ◦ Cache Podを増やせば容量と帯域が増える ◦ "共有DB" がないのでスケーラブル、代わりに Consistent Hashing を 採用 • Least Recently Used ポリシーによる最近使われていないデータの自動削除 • 冗長化はしない ◦ Cache Nodeの増減や LRU でデータロスする ◦ あくまでも "キャッシュ" であって "永続ストレージ" ではないという位置づけ 分散キャッシュシステムの特徴
13. 13 ルーティングの具体例 Network Zone 1 Envoy Pod Envoy Pod Envoy Pod Envoy Pod Layer 4での負荷分散 (Service with Topology Aware Hints) Cache Nodes Cache Pod Cache Pod Cache Pod Cache Pod Layer 7での負荷分散 (Envoy Proxy with Consistent Hashing) User Pod User Pod Cache A Cache C Network Zone 2 Cache B Cache D GET /objects/A GET /objects/A GET /objects/B GET /objects/D
14. 14 どこに Kubernetes が使われているか？ Envoy Pod Envoy Pod Envoy Pod Envoy Pod Cache Pod Cache Pod Cache Pod Cache Pod User Pod A User Pod B ヘルスチェック ヘルスチェック ヘルスチェック ヘルスチェック EDS Pod K8s API 経由で 最新の Cache Pod の IP リストを取得 Envoy の LB エンドポイントを更新 Bound Service Account Token を付与 し HTTP リクエスト SA Token を検証し 接続元の namespace を解決 接続元の namespace で認可を実施 Bound Service Account Token を付与 し HTTP リクエスト
15. 15 • Bound Service Account Token を利用した認証認可 ◦ TokenReview API の使い方 • Service における トラフィック制御 ◦ Topology Aware Hints • Envoy EDS の実装 ◦ Kubernetes Informer ◦ readiness probe & liveness probe 分散キャッシュシステムの Kubernetes まわり！ 今日のおしながき
16. 16 Bound Service Account Token を 利用した認証認可
17. 17 • 3つの Binding が実施されたJWTトークン Bound Service Account Token Audience 「誰のためのトークンか」 例: K8s APIでのみ有効 キャッシュシステムでのみ有効 Time 「有効期限付き」 例: 1h 有効で rotation される Object 「特定のオブジェクト用」 例: "nginx" podが生存している間有効
18. 18 Audience "github.com/pfnet/xxxxx" • xxxxx アプリは、 aud が期待（xxxxx）か確認する ◦ OK • それ以外のアプリ（K8s APIを含む）は、 aud が期待か確認する ◦ xxxxx は期待ではないので NG になる Time: • 勝手に rotation されるので適宜読み込み直す Object: • Pod が消えたら消える • 万が一 token が漏れたら Pod を消せば OK Projected Volume で Pod にマウントできる apiVersion: v1 kind: Pod metadata: name: pod spec: containers: - name: container volumeMounts: - mountPath: /token name: mytoken volumes: - projected: sources: - serviceAccountToken: path: token audience: github.com/pfnet/xxxxx name: mytoken
19. 19 分散キャッシュシステムでの使い方 Envoy Pod Kubernetes Service Cache Pod User Pod • Bound Service Account Token を マウント • Token を Authorization Header に付与し、HTTPリクエ スト • TokenReview API で有効性を検証 ◦ 「Audが期待通りか、有効期限内か、Podが存命 か」 ◦ SAのユーザ名から namespace を解決 ▪ namespace 単位の認可を実装できる！ • Goのライブラリが結果をキャッシュするので 呼びまくっても性能劣化なしで OK
20. 20 Service におけるトラフィック制御
21. 21 PFN が採用している CLOS ネットワークトポロジ Spine SW Spine SW Leaf SW Leaf SW Leaf SW Leaf SW Node Node Node Node Node Node Node Node Node Node Node Node External / Super Spine 遠いNode間の通信を 担当 近いNode間の通信を 担当
22. 22 分散キャッシュシステムのスケジューリングの例 Spine SW Spine SW Leaf SW Leaf SW Leaf SW Leaf SW Node Node Node Node Node Node Node Node Node Node Node Node External / Super Spine Envo y Pod Cach e Pod User Pod Leaf-Spine間の 帯域を浪費する 😭😭😭 Envo y Pod Envo y Pod Envo y Pod 通信に関わる Pod 通信に関わらない Pod
23. 23 • Topology を参考にしてトラフィックのルーティングを可能にする機能 ◦ Topology ▪ node object に設定された topology.kubernetes.io/zone ラベルの値が同じものを「近い」とする ◦ トラフィックのルーティング ▪ 複数のエンドポイントがある Service に通信するときに どのエンドポイントに流すか、ということ → 事前に設定したnode objectのラベルの値で、 接続元Pod によって接続されるエンドポイントを制御できる機能 Topology Aware Routing
24. 24 Zone 4 Zone 3 Zone 2 Zone 1 つまり Topology Aware Routing でどう変わるの か？ Spine SW Spine SW Leaf SW Leaf SW Leaf SW Leaf SW Node Node Node Node Node Node Node Node Node Node Node Node External / Super Spine Envo y Pod Cach e Pod User Pod Leaf-Spine間の 帯域使用量が減少 😄😄😄 Envo y Pod Envo y Pod Envo y Pod 通信に関わる Pod 通信に関わらない Pod
25. 25 Envoy EDS の実装
26. 26 • Pod として分散キャッシュシステムの Cache Pod をデプロイすると： ◦ Pod 再作成 で Pod の IP アドレスが変わる ▪ Envoy が どこにトラフィックを流せばいいかわからなくなる😭 • 最新の IPアドレス を Envoy に通知したい！ ◦ Endpoint Discovery Service (EDS) を使って、gRPC経由で注 入 Envoy と Kubernetes Pod の連携 contour (ingress proxy) が Envoy に設定を入れるときに使うやつ！
27. 27 Cache Pod の再起動・停止に耐えられる アクセスできなくなった Cache Pod にあるデータは失われるが、キャッシュなので OK ! Envoy Pod Envoy Pod Envoy Pod Envoy Pod Cache Pod Cache Pod Cache Pod Cache Pod ヘルスチェック OK ヘルスチェック NG ヘルスチェック OK ヘルスチェック OK EDS Pod K8s API 経由で 最新の Cache Pod の IP リストを取得 Envoy の LB エンドポイントを更新 User
28. 28 まとめ
29. 29 • データセットの読み取り性能を加速させる分散キャッシュを開発 ◦ Kubernetes のおかげでいいかんじになりました！ ▪ 認証認可 → Bound Service Account Token ▪ トラフィック制御 → Topology Aware Hints ▪ Envoy EDS → Informer & health check • PFNの計算基盤関連チームでは採用を実施中です！ ◦ Kubernetes、ストレージ、ネットワーク、性能最適化好きな方等、 どんどんご連絡ください ◦ カジュアル面談もやってます → まとめ
30. Making the real world computable