Kubernetes上のホスト型Jupyter NotebooksとVS Code

Jupyter Notebookは、コード、データ可視化、説明テキストを組み合わせた対話型コンピューティング環境を提供する、強力で人気のあるツールであり、データの操作や洞察の共有を容易にします。データサイエンティストは、探索的データ分析（EDA）、データ前処理、可視化、モデル開発、評価、検証など、データ分析および機械学習のライフサイクル全体にわたるさまざまなタスクにJupyter Notebookを使用します。これらのユースケースの多くでは、単に Jupyter Notebookをインストールするだけで 自分のラップトップにインストールするだけで十分です。しかし、多くの企業や組織にとって、これは選択肢ではなく、ホスト型Jupyter Notebookが必要となります。

ホスト型Jupyter Notebookはなぜ必要なのでしょうか？

1. リソースへのアクセス： 多くのデータサイエンスのワークロードは重い計算処理を必要とし、DSやMLEのローカルマシンでは対応できません。ホスト型Jupyter Notebookは、DS/MLEに強力なマシンやGPUへのアクセスを提供できます。
2. データアクセスとセキュリティ： 多くの企業では、DS/MLEは従業員のラップトップにダウンロードできない機密データを扱うプロジェクトに従事しています。そのため、ホスト型Jupyter Notebookを使用することで、企業はDS/MLEが機密プロジェクトに取り組むためのアクセスを提供できます。
3. 再現性とコラボレーション： ホスト型Jupyter Notebookは、チーム内で実行可能なコードと結果を共有する優れた方法です。開発環境が同じであるため、結果は100%再現可能であり、チームメンバーはプロジェクトで共同作業を行うことができます。

企業はデータサイエンティストにホスト型Notebookをどのように提供できるでしょうか？

エンジニアにJupyter Notebookへのアクセスを提供するために、企業が今日利用できる選択肢は次のとおりです。

データサイエンティストごとにVMをプロビジョニングする：

DS/MLEはVM上に環境をセットアップし、Jupyterサーバーを実行できます。これはワークロードの実行に使用できます。以下に、その方法に関する簡単なガイドを示します。 EC2インスタンスでJupyterLabを実行する。

👍 メリット：
- DSがマシンを完全に制御できる
- 環境全体が永続的です。VMは停止しても同じ状態で再起動できます。

👎 デメリット：
- クラウドコンピューティングの高額なコスト - 自動停止機能がないため、DSがVMを起動したまま、長時間利用せずに放置してしまうことがあり、その結果コストが増大する可能性があります。
- 多数のVMを一元的に管理・追跡することが困難です。
- DSは実験を開始するためのワークベンチをセットアップするために、多くの設定を行う必要があります。
- 再現性の困難さ - DSが追跡されていない多数のパッケージをインストールしている可能性があり、そのVM上で動作するコードを本番環境に移行するのに多くの時間がかかります。

マネージドソリューションの利用：

AWS Sagemaker、Vertex AI Notebooks、Azure ML Notebooksのようなマネージドソリューションを利用することも選択肢の一つです。これらの各方法にはそれぞれ利点がありますが、ここでは一般的な長所と短所をいくつかご紹介します。

それぞれの項目が何を意味するのか、説明しましょう：

• 永続的な環境： これはPython環境の永続性を指します。（pipパッケージのインストールやユーザーが作成した環境が、ノートブックの再起動後も保存されるかどうか）
• 永続的なルートインストール： ユーザーにルートアクセスが提供されている場合、ルートパッケージのインストール（例：apt install pkgs）がノートブックの再起動後も永続化されるかどうか。
• リソース使用状況モニター： ユーザーがノートブック画面内で、ノートブックから直接CPU/メモリ使用量を監視できるかどうか。
• コードサーバーサポート： ノートブックインスタンスがホストされたVS Codeサーバーに接続できるかどうか。
• コンテナへのSSH接続： 実行中のノートブックにSSH接続し、ローカルマシンから接続する機能
• 自動停止： 「非アクティブ期間」後にノートブックを停止する機能。Vertex AIは「マネージドノートブック」版でこの機能を提供しています。Sagemakerにも非アクティブ状態が続いた後にノートブックを停止する方法はありますが、簡単なデプロイオプションではなく「初期化スクリプト」を設定する必要があり、ユーザーにとって多少の煩わしさがあります。
• クロスクラウド対応： この機能はTruefoundry独自のものです。3つのクラウドプロバイダーのいずれでも、まったく同じユーザーエクスペリエンスでノートブックを実行できます。
• イメージのカスタマイズ： 特定のパッケージセットがプリインストールされた状態でノートブックを開始する。
• ノートブックでの共有ボリュームのマウント： 各クラウドプロバイダー（AWS/Azure/Vertex）が提供するノートブックでは、ノートブックごとに個別のボリュームを作成できますが、共有ボリュームをマウントする方法は提供されていません。例えば、ある企業が複数のデータサイエンティストによって様々なユースケースで利用されている500GBのデータセットを持っているとします。現在、すべてのデータサイエンティストがこのデータを複製し、ノートブックが実行されていない間でも複数のボリュームの費用を支払う必要があります。これは、クラウド費用で数百ドル、数千ドルを浪費する可能性があります！
  Truefoundryを使用すると、NFSタイプのボリュームを読み取り専用モードで複数のノートブックにマウントできるため、データの重複にかかるコストを削減できます！

Kubernetes上でのノートブックのホスティング：

もう一つの選択肢はKubernetes上でノートブックをホストすることですが、データサイエンティストはKubernetesと直接やり取りできないため、Jupyterノートブックを起動するためのシンプルなインターフェースを提供する中間ソフトウェアが必要となり、これには独自の課題が伴います。これにはどのような選択肢があるか見てみましょう。

Kubeflow Notebook Operator：
Kubeflow は、Kubernetes上での機械学習（ML）ワークフローのデプロイをシンプル、ポータブル、スケーラブルにするのに役立ちます。これには ノートブック 機能があり、ノートブックの管理と実行を容易にします。
Kubeflowは機械学習のユースケースに多くの機能を提供する大規模なオープンソースプロジェクトですが、Kubeflowを自分でインストールして管理するのは非常に困難です。

👍 利点：
- データサイエンティスト向けのノートブックの起動と管理が容易
- ディスクにバックアップされた永続的なホームディレクトリ
- sklearn、pytorch、tensorflow用の事前定義済みイメージのオプション（すべての依存関係がインストール済み）
- オープンソースのコードベース
- 一定時間非アクティブ状態が続いたノートブックを停止するカリング機能が利用可能。

👎 デメリット：
- Kubeflowのセットアップが難しい Kubernetes上でのKubeflowのインストールとメンテナンスには多くの時間がかかります。
- 複数のリージョンでノートブックを提供する場合、異なるKubernetesクラスターを作成する必要があり、 Kubeflowをすべてのクラスターにインストールする必要があります - 結果として、インフラストラクチャとメンテナンスのコストが高くなります。
- Pythonパッケージはデフォルトでは永続的ではありません、つまり再起動するたびにパッケージをインストールする必要があります
- ルートアクセスを直接取得する方法がない コンテナへの [複数のユースケースで役立つ場合があります]
- ノートブックの停止は、ノートブックごとに設定することはできません グローバル設定です。 

Kubernetes上でJupyterHubをホストする：
JupyterHubは、マルチユーザーのユースケースに最適なセットアップであり、リソースの最適な利用に役立ちます。KubernetesにJupyterHubをデプロイするには、あるオープンソースプロジェクトを使用できます Zero to JupyterHub Kubernetesを使った場合：

👍 利点：
 - 認証サポートにより、複数のユーザーが簡単に共同作業できる
 - ノートブックの自動停止を簡単に設定できる
 - 環境の管理が容易

👎 欠点：
- セットアップと管理が難しい。JupyterHubを正しく機能させるには、ネットワーク、永続ボリューム、スケーリング、ロードバランシングを設定する必要があります。
- Jupyterhub上で異なる種類のGPUでGPUワークロードを実行するのが難しい。例えば、 こちらをご覧ください。
- 環境は永続的ではない

現在、多くのソリューションが存在しますが、それぞれのソリューションには独自の制限があります。Truefoundryでは、このギャップを埋めるべく、データサイエンティスト（DS）のあらゆるニーズを満たし、かつコストも抑えられるノートブックソリューションの構築に取り組んできました。次のセクションでは、ノートブックソリューション構築への当社のアプローチと、その実現において直面した課題について説明します。

Truefoundryのノートブックソリューション構築へのアプローチ

Truefoundry は、MLチーム向けの開発者プラットフォームであり、モデル、サービス、ジョブ、そして今回ノートブックをKubernetesにデプロイするのを支援します。当社の取り組みについては、さらに詳しく こちらをご覧ください。ノートブックソリューションを構築する動機は、当社のプラットフォーム上での実験と開発をシンプルに可能にすることでした。利用可能なすべてのソリューションを検討した結果、他のプラットフォームにおける課題点や不足している機能を解決し、データサイエンティストが多大なコストをかけずに最高の体験を得られるようにすることにしました。私たちが実現したかったことのいくつかをご紹介します。

1. 環境の永続化
2. ユーザーがルート依存関係を動的にインストールでき、いくつかの依存関係のセットに限定されないこと。
3. 特定のケースでは、価格が大幅に低くなるため、スポットインスタンスで実行できます。VMが回収される可能性があるため、いくつかのケースではエクスペリエンスが悪くなることがありますが、実際にはこれは非常に稀であり、コストメリットが時折発生する問題に見合うと判断しています。
4. コスト削減のために自動停止を設定する機能。

Kubeflow Notebooksを基盤として構築

KubeflowはKubernetes上でのノートブック実行をサポートしており、ノートブックに関する多くの機能を標準で提供しています。しかし、私たちはKubeflow Notebooksで上記で指摘した問題に対処し、データサイエンティストや開発者にシームレスな体験を提供したいと考えました。

そのため、ノートブックコントローラーに変更を加え、Truefoundryのバックエンドと統合し、UI上にノートブックを表示する必要がありました。

ノートブックコントローラーをインストールしましたが、いくつかの問題に遭遇したため、kubeflow-notebook-controllerに変更を加える必要がありました。

1. Culling（ノートブックの自動停止機能）はカスタムエンドポイントでは機能しません。Kubeflow Notebook Controllerは、cullingが機能するために特定のエンドポイント形式に依存していました。これにより、ユーザーが自由にエンドポイントを定義することが制限されます。
2. クラスター全体で同じCull-Timeout。これは、ノートブックの「非アクティブタイムアウト」をクラスターレベルでしか設定できないことを意味します。ノートブックごとに異なるcull-timeout値を設定することはできません。
3. デフォルトの Python環境は永続的ではありません

上記2つの問題を解決し、 tfy-notebook-controller
をhelmチャートとしてTruefoundryの公開チャートリポジトリに公開しました。チャートは こちらで確認できます。

ノートブックの作成、開始、停止用UI：

データサイエンティストがノートブックを簡単に開始できるよう、わかりやすいUIを作成しました。ユーザーはアイドルタイムアウト（非アクティブ状態が続いた後にノートブックが停止されるまでの時間）、永続ボリュームサイズ（データセットとコードファイルを保存するディスクのサイズ）、リソース（CPU、メモリ、GPUの要件）をカスタマイズして、ノートブックを起動できます！

これらの変更により、 v0 当社のノートブックの

しかし、まだ優れたユーザーエクスペリエンスには程遠い状況です。このアプローチの長所と短所を見てみましょう。

👍 メリット：
- 永続的なホームディレクトリ [すべてのファイルとパッケージは永続化されます]
- ノートブックごとに非アクティブタイムアウト（カルトタイムアウト）を設定可能
- 数回のクリックでノートブックを起動
- GPUを使用してノートブックを簡単に起動

👎 制限事項：
- Python環境は永続的ではありません（インストールされたすべてのパッケージはPodの再起動時に失われます）
- ルートアクセスを必要とするパッケージをインストールする方法がない
- 実験用の複数の環境を適切に管理する方法がない
- ノートブックのエンドポイントを設定できません [次バージョンで追加予定]

これらの制限は、データサイエンティストの多くのワークフローを妨げるため、解決が非常に重要です。例えば、次のような「aptパッケージ」のインストールなど、簡単な作業もブロックされます。 ffmpeg.

ユーザーワークフローにおける重要な課題の解決

これまで、私たちは 構築済みのイメージ Kubeflowが提供するJupyterlab用のものです。しかし、非永続的な環境の問題、ルートアクセスの許可、aptパッケージのインストールといった課題を解決する必要があるため、独自のDockerイメージを用意する必要があります。
では、これらの問題をどのように解決したか見ていきましょう！

• 非永続的な環境： 目標は、ユーザーがそれぞれのユースケースでノートブックを簡単に利用できるよう、ベースとなるPython環境を永続化することでした。

- Dockerイメージのinitスクリプトを修正し、ベースのconda環境をホームディレクトリにクローンして名前を付ける jupyter-base
- .condarcファイルを追加し、 $HOME ディレクトリをデフォルトの環境パスとして設定
- .bashrcファイルを変更し、 jupyter-base 環境をデフォルトでアクティブ化する

• aptパッケージのインストール
  ユーザーは、イメージにプリインストールしたいaptパッケージのリストを提供できます。
  その後、ビルドステージを追加し、指定されたすべてのパッケージがノートブックにプリインストールされたカスタムイメージを作成します！

• ルートアクセスを提供する
  多くの場合、ユーザーは一部のパッケージをインストールしたり、いくつかのことを素早く試したりするためにルートアクセスを必要とします。このため、各イメージタイプに対して2つのイメージを作成しました。
  truefoundrycloud/jupyter:latest と truefoundrycloud/jupyter:latest-sudo。sudoが有効なイメージでは、ユーザーにパスワードなしのsudoアクセスを提供します。
  これは、sudoバイナリをインストールし、こちらに記載されているようにユーザーをsudoersリストに追加することで行われました。 リンク。

注記：ホームディレクトリがマウントされたKubernetes上でノートブックを実行しているため、ホームディレクトリのみが永続化されます。ルートパッケージのインストールは、Podの再起動後も永続化されません。詳細については、こちらをお読みください。

これらの問題を解決することで、ユーザーが直面する問題のほとんどを解決し、適切なノートブック体験を提供しました。しかし、時間が経つにつれて、ユーザーがいくつかの課題に直面していることがわかりました。それについては次のセクションで説明します。

ノートブックにおける利用上の課題

• リソース使用量（ノートブックのCPUとメモリ）の監視が困難： メモリ不足（OOM）の問題により、カーネルが頻繁に停止します。ノートブックを実行中に、何らかの理由でカーネルが停止する状況によく遭遇しますが、これはデバッグが困難な場合があります。

• Python環境の変更は、時として、 ノートブックサーバーが再起動に失敗するという不適切な状態を引き起こすことがあります。これは、誰かが jupyterlab パッケージをアンインストールするなどの複数の理由で発生する可能性があります。環境が永続化されているため、（現在のノートブックが停止すると）ノートブックが起動しなくなります。
• 複数の環境を管理することは可能です。しかし、ユーザーはconda環境を kernelspec に手動で追加し、 kernelspec が正しく設定されていることを確認する必要がありますが、これが問題を引き起こす可能性があります。

利用上の課題の解決

ノートブックにリソース使用量メトリクスを追加する:
拡張機能をインストールすることで、ノートブックにリソース使用量メトリクスを追加しました。 jupyterlab-system-monitor==0.8.0 そして、Jupyterlabサーバーの起動時に引数を渡すことで、初期化スクリプトでその設定を構成しました。

...


jupyter lab \
   ...
   --ResourceUseDisplay.mem_limit=${mem_limit} \
   --ResourceUseDisplay.cpu_limit=${cpu_limit} \
   --ResourceUseDisplay.track_cpu_percent=True \
   --ResourceUseDisplay.mem_warning_threshold=0.8


UIでの表示は以下の通りです:

Jupyterlabサーバーを実行するカーネルと実行カーネルの分離

ユーザーがホームディレクトリで行う変更にかかわらず、ノートブックが常に問題なく再起動するようにする必要があります。このため、Jupyterlabサーバーの起動には、 /opt/conda ディレクトリにある 'base' anaconda環境を使用しました。
これに加えて、私たちは $HOME ディレクトリに別の環境を作成しましたが、これにより、 ベース conda環境をカーネルリストに表示する。

これを解決するために、私たちは nb_conda_kernels をインストールしてJupyterカーネルを管理しました。永続的なPython環境のみがカーネルリストに表示されるように、initスクリプトを設定しました。

jupyter lab \
   ...
   --CondaKernelSpecManager.conda_only=True \
   --CondaKernelSpecManager.name_format={environment} \
   --CondaKernelSpecManager.env_filter=/opt/conda/*"


これにより、ユーザーがノートブック内で行った変更が常に反映された状態でノートブックサーバーが起動することが保証されます。
これにより、複数のカーネルの管理も容易になります。コマンドを使って新しいconda環境を作成するだけで、 conda create -n myenv カーネルリストに表示されるようになります。

Code-Serverサポートの追加

Jupyter Notebookは多くの問題を解決しますが、役立たなくなるタスクもいくつかあります。

1. シンプルなGradioやStreamlitアプリのようなサービスの開発。ユーザーはJupyter Notebookでコードを記述して実行できますが、ブラウザでサービスを表示することはできません。
2. コードが複数のファイルにパッケージ化されているプロジェクトで作業している場合、JupyterLab環境はこの開発には適していません。

これらの制限を考慮し、私たちはこの問題を解決することにしました。ブラウザでユーザーに完全なIDE体験を提供するために、code-serverサポートを追加しました。

VS Codeサポートを追加することで、ユーザーは以下のことができるようになります。

1. VS Codeのポートフォワーディングプロキシを使えば、ブラウザ上で直接サービスを開発・テストできます。これにより、デプロイされたサービスは  localhost:8000 で利用可能になります。 ${NOTEBOOK_URL}/proxy/8000
2. 完全なIDE体験が提供されるため、適切なパッケージを使ってコードを簡単に管理できます。
3. 生産性向上のため、有名なVS Code拡張機能をすべて活用できます。
4. デバッグモードで実行し、ブレークポイントを設定することで、アプリケーションを簡単にデバッグできます。

これは、別のDockerイメージを追加することで実現されました。TruefoundryのDockerイメージを示す図を以下に示します。

ノートブック/VS CodeへのSSHアクセス:

ほとんどの場合、ホストされたVS Codeで問題は解決できます。しかし、特にJupyter Notebookの場合など、ユーザーが立ち往生し、Jupyter Notebook / VS Codeサーバーを実行しているコンテナへの直接アクセスが必要になる場合があります。
そこで、各ノートブックにSSHサーバーをインストールすることで、それを簡素化しました。コンテナに接続するには、簡単なコマンドを実行してパスワードを入力するだけです。

ssh -p 2222 jovyan@test-notebook.ctl.truefoundry.tech


このツールの機能は、あなたのVS Code拡張機能「 Remote Explorer 」を使えば、VS Code内で直接すべてのファイルを開くことができます！
クリック こちら 詳細はこちら

最終的なユーザーエクスペリエンス：

当社のノートブックソリューションにすべての機能が組み込まれているため、ノートブックのデプロイフォームは次のようになります。

価格比較

最後に、各マネージドソリューションの価格とTruefoundryを比較します。

Truefoundryは、お客様のKubernetesクラスターを接続し、お客様のクラウドにデプロイして動作するため、異なるクラウドプロバイダーでTruefoundryを実行した場合の価格は以下の通りです。

Truefoundryでは、以下の理由から大幅なコスト削減が可能です。

• 仮想マシンのコストに上乗せする追加料金は一切いただきません。
• 非本番環境のワークロードでは、スポットインスタンスでのノートブック実行をサポートしており、これにより 50〜60% クラウドコストを削減できます。

まとめ

これは、ノートブックソリューション構築における当社の取り組みについて、簡単にご紹介したものです。当社の Friends of Truefoundry Slackチャンネルにご参加ください。当社の取り組みについて詳しく議論したい場合や、ご提案がある場合は、ぜひどうぞ。

当社のプラットフォームをお試しになりたい方は、こちらからご登録いただけます。 こちら！