注: 以下の翻訳の正確性は検証されていません。AIPを利用して英語版の原文から機械的に翻訳されたものです。
環境作成概要
これは環境初期化プロセスについて詳しく説明する上級者向けのガイドです。初期化パフォーマンスに影響を与える技術的な考慮事項に興味があるユーザー向けです。
一般的な環境関連の問題についてのガイダンスは、環境トラブルシューティングガイドをご覧ください。
概要
Condaはオープンソースの言語に依存しないパッケージおよび環境マネージャーです。MambaはCondaパッケージマネージャーのオープンソース再実装です。Code Workbookはパッケージの依存関係の解決と、独立した環境へのパッケージセットのインストールのためにMambaを使用するように移行しました。Mambaはパッケージ解決においてCondaよりも速度の向上とエラーメッセージの可読性の向上といういくつかの利点を提供します。
このページでは最も重要な概念を紹介し、環境作成プロセスの概要を説明します。詳細については、公式Condaドキュメンテーション↗およびMambaドキュメンテーション↗をご覧ください。
重要な用語
パッケージ
パッケージはメタデータ、ライブラリ、および/またはバイナリを通常含むファイルの集合です。Code Workbookは広範なパッケージの選択肢（例えばnumpy）を提供し、コア言語機能を補完します。
パッケージはバージョン管理されており、ほぼ常に依存関係セット、つまり、適切に機能するためにもインストールされていなければならない他のパッケージがあります。依存関係は特定のパッケージのバージョン、許容されるバージョンの範囲、または任意のバージョンである可能性があります。
チャンネル
チャンネル、別名リポジトリは、パッケージが保存されている任意の場所を指します。あるチャンネルはローカルファイルシステムのディレクトリで、別のチャンネルはウェブサーバー上のディレクトリである可能性があります。
タイプに関係なく、各チャンネルは、パッケージをプラットフォームアーキテクチャ別に分けるディレクトリツリーです。各プラットフォームのサブディレクトリには、そのサブディレクトリ内のすべてのパッケージのインデックスであるrepodata.jsonというファイルが含まれています。
Condaはパッケージを取得する必要があるたびに、事前に設定された一連のチャンネルを検索します。Foundryでのチャンネル管理についての詳細は、Code Repositoriesドキュメンテーションをご覧ください。
環境
Condaの環境は特定のパッケージの集合を含むディレクトリです。各Workbookの環境は、環境設定パネルで指定されたパッケージをCondaに渡すことで作成されます。Condaは設定とすべての依存関係を満たすパッケージのセットを構築し、これらのパッケージをWorkbookを支えるSparkモジュールにインストールします。
パフォーマンス
以下のパフォーマンスについての説明は、このAnacondaのブログ投稿↗に基づいています。このブログ投稿はCondaのパフォーマンスについて詳しく説明していますが、Mambaの実装にも同様に適用されます。次の二つのセクションでは、この素材を要約し、Code Workbookに最も関連するパフォーマンス要因を概説します。
環境の作成
環境作成は主に二つのステップ、解決ステップとインストールステップから成り立っています。
解決ステップ
解決ステップでは、指定されたパッケージマネージャー、CondaまたはMambaが、すべての過渡的な依存関係を満たすパッケージとバージョンを見つけようと試みます。過渡的な依存関係とは、環境設定パネルで指定されたパッケージの依存関係、それらの依存関係の依存関係、などです。このステップには四つの段階があります：
- パッケージのインデックスをダウンロードし、処理します。Condaは、各設定済みチャンネルから関連する
repodata.jsonファイルをダウンロードし、インデックスエントリをメモリ内のオブジェクトに変換します。 - インデックスを削減します。Condaは環境に可能性のあるすべてのパッケージのセットを構築します。これを行うために、アルゴリズムは提供されたパッケージ仕様から始まり、すべての依存関係を通じて再帰します。不要なパッケージ、主に依存関係グラフにないパッケージは削除されます。
- 依存関係の制約をブール満足性（SAT）問題として表現します。Condaは特定のタイプの解決策を好みます（例えば、可能な限り新しいバージョンのパッケージを使用する）、これらの偏りは節構築に組み込まれています。
- SATソルバーを実行します。
インストールステップ
解決が成功すると、次にインストールステップが続きます。ここでは、各作成物を適切なチャンネルから取得し、それを使って環境を構築します。このステップには三つの段階があります：
- 解決された環境のすべてのパッケージをダウンロードし、抽出します。
- パッケージの内容を確認します。設定により、Condaはチェックサムを使用するか、ファイルサイズが正しいことを確認します。
- パッケージを環境にリンクします。
制限事項
上記のステップはすべて、特定の状況で遅さに影響を受ける可能性があります。遅さの原因は通常、以下の三つのカテゴリのいずれかに分類されます：
上流の変更
遅さの大部分はFoundry外部の要因によって引き起こされます。
- チャンネルのインデックスをダウンロードし、処理する作業は、インデックスファイルの合計サイズに比例します。考慮する必要があるチャンネルが多く、それらのチャンネルが大きいほど、これらのステップにかかる時間は長くなります。
- インデックスの削減も過渡的な依存関係の数に比例します。過渡的な依存関係の数は、パッケージがどの依存関係を宣言するかによって決まります。
これらの要因は外部的で不透明なため、パフォーマンスの後退の根本原因分析を行うのは難しいことがあります。環境のロードに突然時間がかかるようになった場合、それは最近チャンネルのサイズが増えたため、またはパッケージが新しいリリースでいくつかの新しい依存関係を宣言したためかもしれません。
環境の仕様
より一般的には、初期化の遅さは直接環境の仕様に関連しています。解決ステップは環境のサイズに対して超線形にスケールするので、一般的な経験則として、パッケージが多い環境は、初期化に比例して長い時間がかかります。
これらの状況を改善するための二つの方法があります。
- まず、環境定義から不要なパッケージを削除します。大規模な汎用環境を持つよりも、小規模で特化した環境を持つ方がはるかにパフォーマンスが高いです。
- 次に、環境設定パネルの一部のパッケージにバージョン制約を追加してみてください。
pythonのような多くのビルドを持つパッケージや、scipyのような複雑な依存関係グラフを持つパッケージのバージョンを固定するのが最も効果的です。これにより、Condaはインデックスをより積極的に削減できるため、SATの解決が多くのパッケージバージョンを考慮する必要がなくなります。
パッケージのサイズ
パッケージのサイズは通常、このセクションの他の要素よりも問題にならないですが、一部のケースではそれでも関連があります。
たとえ一つのパッケージであっても、ダウンロードと抽出は容易なことではありません。例えば、pytorchパッケージのサイズは約460MBで、抽出には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設定ドキュメンテーションのPrewarmingセクションをご覧ください。
環境の初期化を待つ時間が長いと頻繁に遭遇する場合は、問題のプロファイルに対してウォームモジュールキューを設定することを検討してください。
上記の最適化はCode Workbookが既に保存している環境に利益をもたらします。カスタム環境をリクエストするとき、Code Workbookは標準の初期化プロセスを実行する必要があり、最適化の恩恵を受けることはありません。その結果、カスタム環境は一般的に初期化時間が遅くなります。カスタムプロファイルの遅い初期化プロセスをトラブルシューティングするには、トラブルシューティングドキュメンテーションを参照してください。