ゼロから作るKubernetesによるJupyter as a Service ー Kubernetes Meetup Tokyo #43
4 likes9,943 views
Preferred Networksでは新物質開発や材料探索を加速する汎用原子レベルシミュレータを利用できるクラウドサービスを開発しています。 顧客毎に独立した環境にユーザがJupyter Notebookを立ち上げ、自社PyPIパッケージによりAPI経由で弊社独自技術を簡単に利用できます。Kubernetesの機能を駆使してマルチテナント環境を構築しており、各顧客に独立したAPIサーバを提供し、その負荷状況によりAPIサーバをスケーリングさせたり、顧客毎にNotebookに対する通信制限や配置Nodeの制御などを実現しています。 本発表ではKubernetesによるマルチテナントJupyter as a Serviceの実現方法を紹介します。
ゼロから作るKubernetesによるJupyter as a Service ー Kubernetes Meetup Tokyo #43
- 1. Kubernetes Meetup Tokyo #43 Kubernetesでゼロから作る Jupyter as a Service (JaaS) Daisuke Taniwaki Preferred Networks, Inc 1
- 2. 自己紹介 谷脇 大輔 (Daisuke Taniwaki) 2 dtaniwaki dtaniwaki 2008~2012 Trend Micro 未知の脅威を発見する Webクローラ 2012~2014 Kakaku.com Tabelog USの立ち上げ 2014~2017 Kaizen Platform Kaizen Optimization Platform 2017~現在 Preferred Networks GPUクラスター向けツール 材料探索サービス 職歴 技術領域 Python, Go, Jupyter, Kubernetes, Docker, Argo, OpenTelemetry, AWS
- 3. 本日の発表について 話すこと - KubernetesでJaaSを実現するアーキテクチャ - 実装・構築におけるノウハウ 話さないこと - 各技術の詳細 - AWS等クラウドサービスのリソース構成 - 自社サービスの仕様や構築方法 必要とされる知識 - Kubernetesのリソースの基本的な知識 - Webアプリケーションに関する基本的な知識 3
- 5. 構築するJaaSの要件 - マルチテナント - テナント環境と共有環境の共存 - Notebook内での自社技術の提供 - Notebookのデータ管理 - Notebookのセキュリティ - Webサービスのリソースとの連携 5
- 9. Notebookの構成 9 Jupyter Serverを継承。 サービスとインテグレートされたNotebookサーバ。 ② JupyterLabでリッチなUIの提供。 Lab Extensionで拡張。 ① ③ Notebookのroutingを大量に保持できるAPIでRoute更新できるプロキシ。 (AWSのALBのroutes数は最大100, Ingressリソースのサイズ制限もある) WebUIから立ち上げたNotebookのrouteを登録。 ③
- 10. APIサーバの構成 10 推論技術を提供するgRPC API。 APIをNotebook上で使うためのPyPIパッケージ。 インフラコスト最適化のためのロードバランサー。 ① 推論結果の補助ロジックを提供するgRPC API。 APIをNotebook上で使うためのPyPIパッケージ。 Publicなロジックを提供するPyPIパッケージ。 ②
- 11. テナント環境を実現するデータモデル 11 - テナントはNotebookとAPIのServer Envを持 つ。 - それぞれのEnvにServerが立ち上がる。 - テナントに所属するユーザはNotebook Server を利用する。 - Notebook Serverから接続されているAPI Serverへアクセスできる。 - API Serverは他API Serverへの参照を持つ。
- 13. マルチテナントのNS構成 13 - Tenant毎にNotebook用のNS - Tenant間で共有または占有の API用NS - システムプロセスが動く System NS - 全テナントからのアクセスできる common NS
- 14. Notebook内での自社技術の提供 14 - 推論(非公開), 補助ロジック(公開・非公開)をNotebookに提供。 - 公開する技術はPyPIパッケージとしてPrivate PyPIで配布。 - 非公開の技術はAPIを提供し、PyPIパッケージのAPIクライアントか ら利用。 - 各種補助ロジックはインターフェース毎に実装を切り替え可能にす ることでユーザ毎のカスタマイズも可能。 - NotebookにGPUを積まず、推論用APIサーバのみGPUを使う。 GPUサーバ高い！
- 15. APIインフラコストの最適化 15 - リクエストに応じて高性能GPUにrouting - ダウンしている時は低性能GPUにfallback - 同類のリクエストは負荷分散 - gRPC metadataをlua filterで処理 - Header routingによるクラスタ選択 - Endpoint priorityによるEP選択 - Headless serviceによるロードバランス
- 16. マルチテナントでのAPIサーバのスケーリング 16 - PodのスケールはHPA。 - NodeのスケールはCluster Autoscaler。 - テナント間のfairnessは2つのpriority class のdeploymentで担保。 - Object Metricsでdeployment間のMetrics を連携。 *HPAScaleToZeroが必要
- 17. Notebookのデータ管理 17 - ユーザ毎のr/wワークスペース。 (PVC Dynamic Provisionerで自動作成) - グローバルまたはテナント毎のr/o共有ディ スク。 (PVC Static Provisioningで作成) - 共有ディスクへはCronJobでGitHub等のコ ンテンツをSync。
- 18. Notebookのセキュリティを強化する理由 18 ユーザはサービス内のネットワークで 任意のPythonコードを実行できる！ 具体的には以下が容易に行える環境。 * 他ユーザ、テナントへの攻撃 * システムのサーバへの攻撃 * Kubernetes自体への攻撃 * 踏み台にしてインターネットへの攻撃
- 19. Notebookのセキュリティ - ユーザ用Python Kernelの分離 - 最小権限のNotebookコンテナ - PodAntiAffinity (NotIn)によるテナント毎の Notebookノード (Firecracker等も検討) - NetworkPolicyによるネットワーク制限 - mTLSによる通信暗号化と認証 (Istioも検討) - ドメインによる外部アクセス制限 19
- 20. Webサービスのリソースとの連携 20 Icon made by Freepik from www.flaticon.com - WebUIでログイン。 - Notebookを立ち上げる時にOAuth2 Clientを作成。 - 立ち上げたNotebookから同一ドメイ ンにあるOAuth2サーバから認可とトー クン取得。 - NotebookのFrontendからは直接 cookieでリソース取得・操作。 - Python KernelからはOAuth2トーク ンを使ってリソース取得・操作。