環境作成の概要

概要

Conda は、オープンソースの言語非依存のパッケージおよび環境マネージャーです。Mamba は、Conda パッケージマネージャーのオープンソースの再実装です。Code Workbook は、Mamba を使用してパッケージの依存関係を解決し、独立した環境にパッケージのセットをインストールします。Mambaは、パッケージ解決において Conda よりも速度の向上やエラーメッセージの可読性の向上など、いくつかの利点を提供します。

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

重要な用語

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

パッケージ

パッケージとは、メタデータ、ライブラリ、および/またはバイナリを含むファイルの集まりです。Code Workbook は、コア言語機能を補完するために、多くのパッケージ（たとえば numpy）にアクセスできます。

パッケージには バージョン があり、ほとんどの場合、依存関係があります。これは、他のパッケージが正しく機能するためにインストールされている必要があるものです。依存関係は、特定のバージョンのパッケージ、許容範囲のバージョン、またはすべてのバージョンのいずれかです。

チャンネル

チャンネルは、パッケージが保存されている場所です。リポジトリとも呼ばれます。チャンネルの1つは、ローカルファイルシステムのディレクトリであり、もう1つはウェブサーバーでホストされるディレクトリです。

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

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

環境

Conda の環境とは、特定のパッケージのコレクションが含まれるディレクトリです。環境設定パネルで指定されたパッケージを Conda に渡すことで、各 Workbook 用の環境が作成されます。Conda は、設定とすべての依存関係を満たすパッケージのセットを構築し、これらのパッケージを Workbook をサポートする Spark モジュールにインストールします。

パフォーマンス

以下のパフォーマンスの説明は、この Anaconda のブログ投稿から引用しており、Conda のパフォーマンスについて詳しく説明していますが、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 解決は、パッケージのバージョンを考慮する必要がなくなります。

パッケージサイズ

パッケージサイズは、このセクションの他の要因に比べて通常は問題が少ないですが、一部のケースでは関連があります。

たとえば、pytorch パッケージは約 460 MB のサイズがあり、抽出に 35 秒以上かかることがあります。

ダウンロード、抽出、および検証は、環境内のパッケージのサイズと数に比例してスケーリングされます。遷移的な依存関係により、解決された環境には、環境定義で明示的に指定されたパッケージよりも多くのパッケージが含まれることが一般的であり、パッケージの増加が遅さを引き起こす可能性があります。

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

環境の最適化

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

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

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

環境の要求されたパッケージのセットに変更がない場合、環境を再度解決する必要はありません。なぜなら、それは同じ解決された環境につながるからです。そのため、Code Workbook は、成功した解決の結果を spec ファイル に格納することで、環境初期化の解決ステップを回避します。同じ環境を初期化する必要がある次回には、Code Workbook は spec ファイルを参照して解決ステップをスキップします。これにより、インストールステップだけを実行するため、初期化時間が厳密に短縮されます。以前は成功していた環境が動作しなくなるという稀なケースに対処するための予防策として、Code Workbook は、デフォルトで 24 時間後に spec ファイルを無効にします。その後、環境の次回の成功した解決時に新しい spec ファイルが生成されます。

その結果、spec ファイルを使用すると、既知の環境のすべての後続の初期化試行が次の図のようになります。

初期化最適化：Conda Docker

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

次の図は、Conda Docker が初期化プロセスを簡素化する方法を示しています。

Conda Docker の無効化

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

プリウォーミング

上記の最適化が環境の初期化時間を短縮できる一方で、モジュールを積極的に初期化することで、環境の待機時間を完全に回避できます。これらのモジュールは、「ウォーム」モジュールと呼ばれます。ウォームモジュールキューを設定することで、Code Workbook は、事前に初期化された Spark モジュールのセットが常に割り当てる準備ができていることを保証します。ウォームモジュールの設定方法については、Code Workbook 設定ドキュメントのプリウォーミングセクションを参照してください。