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

4.
簡単なJaaSの構築
4
Zero to JupyterHubをHelmでインストールしてください。
本日の発表はもっと複雑なJaaSの構築についてお話しします。

5.
構築するJaaSの要件
- マルチテナント
- テナント環境と共有環境の共存
- Notebook内での自社技術の提供
- Notebookのデータ管理
- Notebookのセキュリティ
- Webサービスのリソースとの連携
5

6.
全体の構成
6
部分的に解説していきます。

7.
Webアプリケーションの構成
7
非同期処理やスケジュール処理。
②
WebUIは一般的なSPAのWeb application構成
①

8.
Kubernetesリソースのデプロイ
8
KubernetesのリソースをデプロイするUtility。

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への参照を持つ。

12.
テナント環境を実現するKubernetesリソース
12
*将来的にCRD化も検討

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トーク
ンを使ってリソース取得・操作。

21.
21
Kubernetesを使って、自社技術をJaaSで提供してみましょう！