環境の作成

これは、環境の初期化プロセスを詳しく説明する高度なガイドです。初期化のパフォーマンスに影響する可能性のある技術的な考慮事項に関心のあるユーザーを対象としています。

環境に関連する一般的な問題への対処については、環境のトラブルシューティングガイドを参照してください。

Conda は、言語に依存しないオープンソースのパッケージおよび環境マネージャーです。Mamba は、Conda パッケージマネージャーを再実装したオープンソースのソフトウェアです。Code Workbook では、パッケージの依存関係を解決し、独立した環境にパッケージをインストールするために、Mamba を使用するようになりました。Mamba は、パッケージの依存関係解決において Conda よりもいくつかの優れた点を備えており、特に速度の向上とエラーメッセージの読みやすさの向上が挙げられます。

このページでは、最も重要な概念を紹介し、環境の作成プロセスの概要を説明します。詳しくは、Conda の公式ドキュメント ↗と Mamba のドキュメント ↗を参照してください。

重要な用語

• パッケージ
• チャネル
• 環境

パッケージ

パッケージはファイルの集まりで、通常はメタデータ、ライブラリ、バイナリのいずれか、またはそれらの組み合わせが含まれます。Code Workbook では、言語の基本機能を補う幅広いパッケージ（たとえば numpy）を利用できます。

パッケージにはバージョンが付けられており、ほぼ必ず依存関係があります。依存関係とは、そのパッケージが正常に機能するために併せてインストールする必要があるほかのパッケージです。依存関係では、パッケージの特定のバージョン、許容されるバージョンの範囲、または任意のバージョンが指定されます。

チャネル

チャネルは、リポジトリと呼ばれることもあり、パッケージが保存される場所を指します。ローカルファイルシステムのディレクトリの場合もあれば、Web サーバー上でホストされるディレクトリの場合もあります。

種類にかかわらず、チャネルはパッケージをプラットフォームのアーキテクチャ別に分けたディレクトリツリーです。各プラットフォームのサブディレクトリには、そのサブディレクトリ内のすべてのパッケージのインデックスである repodata.json というファイルが含まれています。

Conda は、パッケージを取得する必要があるたびに、事前設定されたチャネルを検索します。Foundry でのチャネル管理について詳しくは、Code Repositories のドキュメントを参照してください。

環境

Conda の環境は、特定のパッケージ群を含むディレクトリです。環境設定パネルで指定されたパッケージを Conda に渡すことで、Workbook ごとに環境が作成されます。Conda は、設定とすべての依存関係を満たすパッケージ群を構成し、Workbook の基盤となる Spark モジュールにこれらのパッケージをインストールします。

パフォーマンス

以下のパフォーマンスの説明は、Conda のパフォーマンスについて詳しく解説したこちらの Anaconda ブログ記事 ↗に基づいていますが、Mamba の実装にも同様に当てはまります。次の2つのセクションでは、この内容を要約し、Code Workbook に最も関係のあるパフォーマンス要因の概要を説明します。

• 環境を作成する
• 制限事項

環境を作成する

環境の作成は、解決ステップとインストールステップという2つの主要なステップで構成されます。

解決ステップ

解決ステップでは、指定されたパッケージマネージャー（Conda または Mamba）が、すべての推移的依存関係を満たすパッケージとバージョンの特定を試みます。推移的依存関係には、環境設定パネルで指定されたパッケージの依存関係、それらの依存関係の依存関係などが含まれます。このステップは4つの段階で構成されます。

1. パッケージのインデックスをダウンロードして処理します。Conda は、設定された各チャネルから関連する repodata.json ファイルをダウンロードし、インデックスのエントリをメモリー内のオブジェクトに変換します。
2. インデックスを絞り込みます。Conda は、その環境で使用される可能性のあるすべてのパッケージを集めます。そのために、アルゴリズムは指定されたパッケージ仕様から始め、すべての依存関係を再帰的にたどります。不要なパッケージ（主に依存関係グラフに含まれないパッケージ）はすべて除外されます。
3. 依存関係の制約をブール充足可能性（SAT）問題として表現します。Conda は特定の種類の解を優先します（たとえば、パッケージの可能な限り新しいバージョンを使用する）。こうした優先傾向は、論理節の構成に組み込まれています。
4. SAT ソルバーを実行します。

インストールステップ

解決に成功すると、次にインストールステップが実行されます。ここでは、各アーティファクトが適切なチャネルから取得され、環境の構築に使用されます。このステップは3つの段階で構成されます。

1. 依存関係の解決済み環境に含まれるすべてのパッケージをダウンロードし、展開します。
2. パッケージの内容を検証します。設定に応じて、Conda はチェックサムを使用するか、ファイルサイズが正しいことを検証します。
3. パッケージを環境にリンクします。

制限事項

上記のすべてのステップは、特定の状況で処理が遅くなる可能性があります。処理の遅さの原因は通常、次の3つのカテゴリーのいずれかに分類されます。

• 上流の変更
• 環境仕様
• パッケージサイズ

上流の変更

処理の遅さの大部分は、Foundry 外部の要因によって生じます。

• チャネルのインデックスのダウンロードと処理にかかる時間は、インデックスファイルの合計サイズに応じて増加します。考慮する必要があるチャネルが多く、それらのチャネルが大きいほど、これらのステップにかかる時間は長くなります。
• インデックスの絞り込みにかかる時間も、推移的依存関係の数に応じて増加します。推移的依存関係の数は、パッケージがどの依存関係を宣言しているかによって決まります。

これらの要因は外部にあり、把握しにくいため、パフォーマンス低下の根本原因を分析するのは難しい場合があります。チャネルのサイズが最近増加したり、パッケージの最新リリースで新しい依存関係がいくつか宣言されたりしたために、環境の読み込みに突然時間がかかるようになることがあります。

環境仕様

より一般的には、初期化の遅さは環境仕様そのものに直接関係しています。解決ステップにかかる時間は、環境のサイズに対して線形を超える増加率で増えるため、一般的な目安として、パッケージが多い環境ほど、初期化にかかる時間はパッケージ数の増加割合以上に長くなります。

こうした状況を改善するには、2つの方法があります。

• まず、環境定義から不要なパッケージを削除します。大規模な汎用環境よりも、小規模で用途に特化した環境のほうが、パフォーマンスは大幅に優れています。
• 次に、環境設定パネルで一部のパッケージにバージョン制約を追加してみます。python のように既存のビルドが多いパッケージや、scipy のように依存関係グラフが複雑なパッケージのバージョンを固定するのが最も効果的です。これにより、Conda はインデックスをさらに絞り込めるようになり、SAT による解決で考慮する必要があるパッケージのバージョン数が減ります。

パッケージサイズ

パッケージサイズは通常、このセクションのほかの要因ほど問題にはなりませんが、一部のケースでは影響があります。

パッケージが1個だけでも、そのダウンロードと展開には相応の時間がかかる場合があります。たとえば、pytorch パッケージのサイズは約 460 MB で、展開に35秒以上かかることがあります。

ダウンロード、展開、検証にかかる時間はいずれも、環境内のパッケージのサイズと数に比例して増加します。推移的依存関係により、依存関係の解決済み環境には通常、環境定義で明示的に指定されたものよりはるかに多くのパッケージが含まれ、このパッケージ数の増加が処理の遅さにつながる場合があります。

この場合の対処方法は、環境仕様で示した対処方法と同様です。環境をできるだけ小さく保つようにします。

環境の最適化

このページの前のセクションでは、環境の初期化プロセスと初期化のパフォーマンスに影響する要因について説明しています。次の図は、環境を取得する標準的なプロセスをまとめたものです。

プロセスの「リソースを待機中」と「環境を初期化中」の段階にかかる時間を短縮するため、Code Workbook は、できるだけ早く環境を取得するための一連の最適化を使用します。

解決ステップの最適化：仕様ファイル

環境で要求するパッケージに変更がなければ、環境を再度解決しても同じ解決済み環境になるため、再解決は不要なはずです。そのため、Code Workbook は、解決に成功した結果を仕様ファイルに保存することで、環境の初期化時の解決ステップを省略します。次に同一の環境を初期化する必要があるときは、Code Workbook は仕様ファイルを参照することで解決ステップをスキップします。Code Workbook はインストールステップのみを実行すればよいため、初期化時間は確実に短縮されます。以前は正常に動作していた環境が動作しなくなるまれなケースへの予防措置として、Code Workbook はデフォルトで24時間後に仕様ファイルを無効化します。その後、次に環境の解決に成功したときに、新しい仕様ファイルが生成されます。

このように、仕様ファイルを使用すると、既知の環境の以降の初期化試行は毎回、次の図のようになります。

Code Workbook がこれまで扱ったことのない新しい環境の初期化には、当然ながら時間がかかります。ただし、環境の初期化に一度成功すると、それ以降の初期化試行はすべて、はるかに短い時間で成功するはずです。

初期化の最適化: Conda Docker

Conda Docker は、Kubernetes が有効な環境でのみ利用可能な最適化です。Kubernetes の詳細については、ブログ記事 Introducing Rubix: Kubernetes at Palantir ↗ を参照してください。

上の図に示すように、環境を初期化するには、Code Workbook はまず Spark モジュールを取得し、次にそのモジュールにパッケージをインストールする必要があります。Code Workbook が解決に成功した結果を仕様ファイルに保存するのと同様に、有効な環境を Docker イメージとして保存することもできます。このイメージを使用すると、Code Workbook は、必要なパッケージがすべてすでにモジュール上に存在する状態で、以降の Spark モジュールを要求できます。これにより、解決ステップとモジュール上での Conda のインストールステップの両方が省略され、環境の初期化時間が大幅に短縮されます。Code Workbook はデフォルトで24時間後に Docker イメージを無効化します。次に環境の解決に成功したときに、新しいイメージが生成されます。

次の図は、Conda Docker が初期化プロセスをどのように簡略化するかを示しています。

Conda Docker を無効にする

まれに、Conda Docker を使用する環境では、パッケージに pre-link または post-link スクリプト ↗が含まれていると、実行時に失敗することがあります。このようなスクリプトを含む環境で失敗していると思われる場合は、Code Workbook の環境設定タブの左下で、この最適化を手動で無効にできます。Conda Docker を無効にした後も、環境にはほかの利用可能な最適化が適用されます。この設定は、使用したプロファイルと、設定を切り替えたワークブックブランチの組み合わせに対して保存されます。

プリウォーミング

上記の最適化により環境の初期化時間を短縮できますが、あらかじめいくつかのモジュールを初期化しておくことで、環境の待機時間そのものをなくすことができます。これらのモジュールは「ウォーム」モジュールと呼ばれます。ウォームモジュールキューを設定すると、Code Workbook は、事前に初期化された Spark モジュールを常に割り当て可能な状態に保ちます。環境の初期化を待つ時間が日常的に長くなる場合は、該当するプロファイルにウォームモジュールキューを導入することを検討してください。ウォームモジュールの設定方法の詳細については、Code Workbook の設定ドキュメントのプリウォーミングセクションを参照してください。