セッション履歴とセッション固定

セッション

Spark モジュール内の Code Workbook 環境を初期化すると、一連のメタデータがモジュールに付与されます。このメタデータは、計算情報と環境情報の二つのカテゴリーに分けることができます。セッションとは、これらの設定のインスタンス化であり、Spark モジュールのライフサイクルの一部であるか、非公式には「ある Spark モジュールの寿命中に何が真実であったか」を示します。

計算情報には、Spark モジュールに付与された Spark 設定の詳細、および jar 依存関係、リソース識別子、起動するモジュールの種類などの関連情報が含まれます。一方、環境情報はさらに二つのカテゴリー、要求された環境と解決された環境に分けることができます。要求された環境とは、pandas=2.* や python<3.10 のような conda の仕様のセットを要求すること、一方、解決された環境とは、要求された環境によって確立された制約を満たすパッケージの解決されたセットを指します。要求された環境は非決定的であることに注意が必要で、一方、解決された環境は、定義上、与えられた要求された環境の恒久的な解決策です。その結果、二つの同一の要求された環境は、異なる解決された環境につながることがあります。たとえば、2017年にpython>=3.6を要求すると、Python 3.6に解決する可能性が高く、今日では同じ要求がPython 3.10につながる可能性があります。

セッション履歴

Code Workbook は、Workbook のすべての最近のセッションに関する情報を提供します。Workbook のセッション履歴を確認するには、Code Workbook の Environment ドロップダウンを選択し、View session history を選択します。

Session history ウィンドウは、三つの異なるタブを通じて情報を提供します：Compute information、Requested environment、そして Resolved environment。左のペインはセッションの ID とセッションが初期化された時間を提供します。セッション ID の左のアイコンは、正常に初期化されたこと（緑）、失敗したこと（赤）、またはその他（青）を示します。青のセッションは、通常、セッションが初期化を完了していないことを意味し、したがって失敗状態または成功状態には達していません。

計算情報

Compute information タブは、特定のセッションのために要求された Spark モジュールの種類についての情報を提供します:

• moduleAssignmentInfo: 環境が特定のユーザーによってインタラクティブな Workbook の使用のために開始されたのか、またはバックグラウンドのジョブ、例えばスケジュールされたビルドによって開始されたのかについての一般的な情報。インタラクティブなモジュールとビルドモジュールの違いについては、batch builds and interactive builds をご覧ください。
• moduleLaunchInfo: Spark モジュール自体に割り当てられたプロパティについてのメタデータ。以下のフィールドが含まれます:
  • sparkModuleRid: Spark モジュールの一意の識別子。モジュールとセッションの間には 1:1 のマッピングがあるため、sparkModuleRid と sessionId が同じ一意の識別子を共有していることに気付くでしょう
  • profileRid: Spark モジュールが初期化されたプロファイルの一意の識別子。
  • isCustomEnv: セッションがカスタム環境を使用して初期化されたかどうか。Code Workbook のカスタム環境は、Code Workbook インターフェースの Environment 設定メニューで直接修正された任意の標準プロファイルとして定義されていることを思い出してください。
  • jarDependencies: Control Panelでプロファイルに手動で追加されたすべての jar 依存性のリスト。
  • moduleLaunchType: WARM_MODULEまたはON_DEMAND_MODULEのどちらかになります。セッションがウォームモジュールキューからすでに初期化されたモジュールを使用したか、または初期化プロセスを開始するために新しいモジュールを要求したかどうかを示します。
  • moduleResources: ドライバーとエグゼキューターのメモリ、エグゼキューターの量など、モジュールに関連するすべての計算情報。

要求された環境

Requested Environment タブは、初期化の開始前の所望の環境設定についての情報を提供します:

• Initialization Mode: そのセッションのために実行されるべき Code Workbook の初期化の種類。solve、 file、または docker のいずれかになります。Code Workbook の初期化の種類については、environment optimizations に関するドキュメンテーションを参照してください。
• Environment repository: 問題の環境が格納されているキー。カスタム環境でない場合、これはセッションで使用された profileRid になります。カスタム環境の場合、これはプロファイルがカスタマイズされたワークブックの workbookRid になります。
• Requested packages: 初期化プロセスのために提出された要求パッケージのリスト。このリストには、プロファイルが特に要求したパッケージと、Code Workbook が機能するために自動的に要求された追加のパッケージの両方が含まれます。
• Backing repositories: インストールされたパッケージがソースされたチャネルのリスト。

解決された環境

Resolved Environment タブは、初期化の一部として使用された環境パッケージについての情報を提供します。これには、環境の初期化にかかった時間、および最終的にモジュールにインストールされたパッケージとそのバージョンが含まれます。この情報は特に重要であり、なぜなら Code Workbook のセッションロールバック機能は、要求された環境ではなく、前のセッションの解決された環境を借用するからです。

セッションの比較

特定の環境がどのように変化したかを理解するために、二つのセッションを比較することがよく役立ちます。Session history ウィンドウは、現在のセッションと任意の歴史的なセッションを比較することを可能にします。セッション履歴比較タブにアクセスするには、セッション履歴ウィンドウの右上で Compare sessions を選択します。

セッション比較メニューは、二つのウィンドウを隣に提供します。右側には、現在のセッションの情報が表示されます。左側には、Sessions リストから任意のセッションを表示して比較することができます。左側に表示する比較セッションを切り替えるには、Sessions リストから任意のセッションを選択します。ウィンドウの右上にある Exit comparison を選択することで、いつでも比較ビューを終了することができます。左側の選択されたセッションは選択されたままになります。 セッションは、利用可能なすべてのタブで比較することができます。2つのセッションの 計算情報 を比較すると、モジュールの利用可能メモリの変化を理解するのに役立ちます。 要求された環境 を比較すると、2つのセッション間で手動で変更された環境を理解するのに役立ちます。一方、 解決された環境 を比較すると、2つのセッション間でインストールされた異なるバージョンを理解するのに役立つかもしれません。

以下の例では、セッション比較の様々なタブを使用することで、2つのセッションについて以下の情報を明らかにします：

• 異なるプロファイルが使用されました。
• プロファイルはカスタマイズされました。
• モジュールではより少ないメモリ設定が使用されました。

• Python や pandas など、より新しいパッケージバージョンが要求されました。

• 環境には異なるバージョンの Python がインストールされました。

セッションのピン留め

特定の場合には、過去のセッションの設定とまったく同じ状態に一時的に戻したいことがあります。Code Workbook では、このような動作を可能にするために、セッションをピン留めする機会を提供します。セッションをピン留めするということは、過去のセッションと同じメタデータを使用して全く新しいセッションと Spark モジュールを初期化し、見かけ上同一の環境を再現することを意味します。ピン留めされたセッションは、新鮮なモジュールを初期化するために過去のセッションから 解決 情報を借ります。これは特に重要で、同じ解決環境を使用すると、インストールされたパッケージが同じであることが保証されます。一方、同じ要求環境を使用してもそうはなりません。その結果、セッションをピン留めすると、以前に正常に動作していた環境に戻る効果をシミュレートします。初期化モードなど、一部のメタデータは過去のセッションから借りられません。

セッションのピン留め方法

セッションをピン留めするには、 セッション履歴 ウィンドウに移動し、ピン留めしたいセッションを選択します。次に、パネルの右下にある セッションをピン留め を選択します。Workbook の現在のブランチには、最大24時間持続するピン留めされたセッションのオーバーライドがあります。バナーには、オーバーライドの残り時間と、ピンを削除するオプションが表示されます。その期間中、すべての後続の対話型環境の初期化は、ピン留めされたセッションの情報を借ります。期間が経過するか、セッションが手動でピン留め解除されると、Workbookは現在設定されている環境を使用するように戻ります。

セッションのピン留めの制限

セッションをピン留めする際には、一部の制限が適用されます。ピン留めされたセッションは無限に続かず、すべてのセッションをピン留めすることはできませんし、すべての初期化がピン留めされたセッションに影響を受けるわけではありません。以下に、セッションをピン留めすることを考慮する際に注意すべき制限の一覧を示します：

• セッションのピン留めは最大24時間続きます。この時間をさらに延ばすには、セッションを再ピン留めする必要があります。セッションを再ピン留めすると、新しいモジュールが起動され、モジュール上のすべてのローカル状態が失われます。
• ピン留めされたセッションは、その添付された歴史的なセッションからすべてのメタデータを借りるわけではありません。初期化モードなどの設定は異なる可能性があります。
• 成功した過去のセッションのみがピン留めされます。未完成または失敗したセッションは許可されません。さらに、Code Workbook は、互換性のないバージョン、ブラックリストに登録されたパッケージバージョン、API のブレイクなどのためにピン留めのバージョンの選択を防御的に防ぐかもしれません。ピン留めできないセッションについては、赤いバナーでユーザーに通知します。
• ピン留めされたセッションは対話型ジョブのみに影響します - ビルドジョブには影響しません。
• Artifacts Profiles を使用しているセッションのみがピン留めできます

上記の理由から、セッションのピン留めは、長期間、本番環境でのパイプラインに依存すべきではないデバッグ機能です。

セッション履歴を使用した環境のトラブルシューティング

上記で述べた セッション履歴、セッションの比較、セッションのピン留め の機能は、環境のトラブルシューティングにおいて非常に有用です。特に、以前に動作していた環境の失敗を対処するのに役立ちます。次のステップに従って、そのようなケースを修復してください：

1. 環境は過去に動作していましたか？

   • もしいいえの場合、環境トラブルシューティングガイドを参照してください。
   • もしはいだが現在は失敗している場合は、次のステップに進んでください。

2. セッションの比較機能を使用して、現在失敗しているセッションを以前に成功していたものと選択し、環境の違いを確認します。

   • 計算情報の詳細に変更がある場合、モジュールの設定はモジュールを正しく初期化するための十分なメモリを含んでいない可能性があります。
   • 要求された環境の詳細に変更がある場合、手動で環境に破壊的な変更が導入され、それが失敗につながった可能性があります。
   • 要求された環境の詳細に変更がないが、解決した環境に変更があり、それが失敗につながった場合、使用されているパッケージの新しいバージョンに破壊的な変更が含まれている可能性があります。これらのパッケージは一般的にオープンソースから来ています。ユーザーは、問題のあるパッケージを直接調査するか、環境を変更してそのパッケージやバージョンを要求しないようにすることができます。
   • 環境に明らかな変更がない、または上記のステップが役立たなかった場合は、環境トラブルシューティングガイドを参照するか、さらなる支援のために Palantir サポートに連絡してください。

3. (オプション) 前のステップでトラブルシューティングを行う間、セッションのピン留め機能を使用して、まずピン留めされたバージョンの環境が動作することを確認し、より恒久的な解決策が見つかるまでの間、Workbookの機能を一時的に解除します。

4. 環境が失敗する原因を発見した後、プロファイルの設定を適切に調整して、状況を恒久的に修復します。