プロンプトとコンテキスト
このコーディング面接の質問では、Python 3.14の複数インタープリタ（multiple interpreters）機能を並行処理コードに適用できるかどうかをテストします。主な論点は、独立したランタイム状態、インタープリタごとのインタープリタロック、タスクと結果のシリアル化、共有データの境界、およびリソースと例外の管理です。
面接官がテストしていること
- スレッドプール、InterpreterPoolExecutor、プロセスプールの並列処理モデルを区別できるか。
- インタープリタの分離によって、共有される可変（mutable）オブジェクトや多くの競合状態がどのように回避されるかを説明できるか。
- pickle、メモリ、起動時間、サードパーティ製拡張モジュールの互換性にかかるコストを特定できるか。
- 投入数制限（bounded submission）、タイムアウト、キャンセル、シャットダウン、例外の伝播を備えたコードを作成できるか。
明確化のための質問
処理がCPUバウンドかI/Oバウンドか、入力と結果のサイズ、必要な共有キャッシュや接続、ランタイムがPython 3.14および分離されたインタープリタをサポートしているかを確認します。複数インタープリタにまだ対応していないC拡張モジュールの有無、レイテンシ目標、メモリ制限、リトライのセマンティクス、タスクの冪等性を確認します。タスクが主にネットワーク待ちである場合は、スレッドや非同期コードの方が一般的にシンプルです。広範な共有可変状態が必要な場合は、プロセス境界またはサービス境界の方が適している可能性があります。
30秒で答えるためのフレームワーク
まずCPUのボトルネックをベンチマークし、スレッドプール、InterpreterPoolExecutor、プロセスプール間でのエンドツーエンドのコストを比較します。InterpreterPoolExecutorの各ワーカースレッドは独自のインタープリタ、したがって独自のインタープリタロックを実行するため、Pythonコードを複数のコアにわたって実行できます。その代償としてモジュールの状態が分離されるため、タスク、引数、結果をシリアル化する必要があり、可変オブジェクトを直接共有することはできません。シリアル化可能な小さな入力と制限されたタスク投入でパイロット実装を行い、タイムアウト、キャンセル、例外クラス、グレースフルシャットダウンを追加した上で、スループット、テールレイテンシ、メモリ、復旧処理を検証します。
ステップ別の実装
1. 並列処理モデルの確認
ThreadPoolExecutorは、I/O処理やインタープリタロックを解放する処理に適しています。InterpreterPoolExecutorは、1つのプロセス内のスレッドで複数のインタープリタを実行します。各インタープリタが独自のロックを持つため、純粋なPythonのCPU処理で複数コアを活用できます。ProcessPoolExecutorは、より強力な分離のために別々のプロセスを使用しますが、通常は起動とプロセス間通信が重くなります。APIが似ていても、共有セマンティクスが同一であるとは限りません。
2. シリアル化可能なタスク境界の定義
インタープリタプールに渡される呼び出し可能オブジェクト、引数、イニシャライザ、イニシャライザ引数、および戻り値はシリアル化されます。小さな不変（immutable）値、ファイル識別子、またはオブジェクトストレージのキーを使用するのが望ましいです。接続、ロック、ジェネレータ、プロセス状態を保持するオブジェクトは渡さないでください。各インタープリタは、イニシャライザ内でモジュールをインポートし、読み取り専用の設定やローカルキャッシュを準備する必要があります。
3. コードでの分離と結果収集の表現
この例では、CPU処理を純粋に保ち、シリアル化可能な値を渡し、フューチャー（future）の完了に合わせてメインインタープリタで結果を収集します。
from concurrent.futures import InterpreterPoolExecutor, as_completed
def score_chunk(values: tuple[int, ...]) -> int:
return sum(value * value for value in values)
chunks = [(1, 2, 3), (4, 5), (6, 7, 8)]
with InterpreterPoolExecutor(max_workers=3) as pool:
futures = [pool.submit(score_chunk, chunk) for chunk in chunks]
total = sum(future.result(timeout=5) for future in as_completed(futures))本番環境のコードでは、タスク識別子を付与し、タイムアウト、キャンセル、ビジネスエラーを区別し、インタープリタ内のタスクが同じプール内の別のタスクを待機しないようにする必要があります。
4. 共有データと通信の処理
インタープリタ間で同一の可変オブジェクトを同時に使用することはできません。共有状態の更新は、キュー、データベース、または外部キャッシュを通じて送信されるメッセージに変換します。大容量の読み取り専用データについては、有効期間と並行アクセス規則を検証した上で、共有メモリやメモリマップトファイルを検討します。PEP 734はインタープリタ間通信の方向性を規定していますが、具体的な設計には依然としてシリアル化、バックプレッシャー、順序付けに関する決定が必要です。
5. 拡張モジュールとイニシャライザ障害の処理
標準ライブラリの拡張モジュールはPython 3.14向けに適応されていますが、サードパーティ製パッケージは単一のインタープリタまたはプロセス全体でグローバルな状態を前提としている場合があります。依存関係のインベントリを作成し、イニシャライザでインポートしてフェイルファスト（早期失敗）にします。イニシャライザのエラーが発生した場合は、暗黙的に共有スレッドにフォールバックさせるのではなく、保留中のフューチャーを明示的に失敗させる必要があります。分離できないパッケージには、プロセスプールまたはサービス境界を使用します。
6. リソース、キャンセル、シャットダウンポリシーの設定
コア数、タスクあたりのメモリ、シリアル化コストからmax_workersを選択します。無制限の投入を防ぐために有限のバッチを使用します。フューチャーにデッドラインを設定し、開始されていないタスクをキャンセルし、障害を分類して、操作が冪等である場合にのみリトライします。コンテキストマネージャまたは明示的なシャットダウンを使用して、実行中のタスクを待機し、ファイル、一時ディレクトリ、外部接続を解放します。
質の高い回答サンプル
純粋なPythonのCPUボトルネックを確認するためにまずベンチマークを実施し、スレッドプール、InterpreterPoolExecutor、プロセスプール間でスループット、テールレイテンシ、メモリ、起動コストを比較します。InterpreterPoolExecutorは、独自のインタープリタロックを持つ独立したインタープリタで各スレッドを実行し、マルチコア実行を可能にしますが、モジュール状態は分離され、関数、引数、結果はシリアル化可能である必要があります。タスクを小さく純粋な関数にし、不変値やストレージキーを渡し、各インタープリタで依存関係を個別に初期化し、投入数制限、タイムアウト、キャンセル、分類された例外でメインフローを保護します。リリース前にサードパーティ製拡張モジュールの互換性を検証します。依存関係を分離できない場合、共有状態が大半を占める場合、または通信コストがメリットを上回る場合は、プロセスプールまたは独立したサービスを使用します。
よくある間違い
- 複数のインタープリタをグローバル変数を共有するスレッドとして扱い、それらの間でリストや辞書を変更してしまう。
- 関数の実行時間のみを測定し、シリアル化、初期化、メモリ、テールレイテンシを無視する。
- InterpreterPoolExecutorがサードパーティ製C拡張モジュールの互換性を自動的に解決すると思い込む。
- キュー、メモリ、コンテキストスイッチが破綻するまで無制限にタスクを投入する。
- 初期化、ビジネス、タイムアウト、キャンセルの各障害を分類せず、1つの汎用例外でまとめて捕捉する。
- 冪等性のない処理をリトライし、二重書き込みや外部への副作用を引き起こす。
フォローアップの質問と回答
ProcessPoolExecutorに対する主なトレードオフは何ですか？
複数インタープリタは1つのプロセス内に留まりながらインタープリタ状態を分離するため、多くの場合起動がより軽量です。プロセスプールはより強力な障害分離を提供します。どちらもタスクデータをシリアル化します。拡張モジュールのクラッシュや独立したリソース制限が懸念される場合はプロセスを選択します。依存関係を分離でき、マルチコア実行の恩恵を受けられる短いCPUタスクにはインタープリタを検討します。
ワーカーにデータベース接続を渡せないのはなぜですか？
接続は通常シリアル化できず、インタープリタ、スレッド、ファイルディスクリプタの状態を保持しているためです。各インタープリタが初期化中に独自の接続を作成するか、中央サービスがクエリを実行している間にクエリパラメータのみを受け取る必要があります。接続プールのサイズは、ワーカー数およびデータベースの制限に合わせて調整してください。
1つの遅いタスクがすべての結果を遅延させるのを防ぐにはどうすればよいですか？
各フューチャーにデッドラインを設定し、完了したものから順次処理し、開始前のタスクをキャンセルし、タイムアウト後に実行中のタスクを分離します。バッチ全体を再計算するのではなく、部分的な結果とタスク識別子を保持しながら、冪等性に応じてリトライまたは補償処理をキューに入れます。
どのような場合にスレッドプールの方が優れていますか？
処理が主にネットワークやディスクを待機している場合、またはC拡張モジュールがすでにインタープリタロックを解放している場合は、オブジェクトの共有や通信コストの低さからスレッドプールの方がシンプルです。CPUのコア数だけでなく、エンドツーエンドのベンチマークと保守性に基づいて判断します。
複数のインタープリタで読み取り専用の大規模なモデルやデータセットを共有できますか？
デフォルトでは同一の可変Pythonオブジェクトとして共有することはできません。メモリマッピング、共有メモリ、または外部サービスを検討しますが、バッファ、有効期間、参照カウント、セキュリティ境界を検証する必要があります。各インタープリタに個別のコピーをロードすると、並列処理のメリットを打ち消すほどのメモリを消費する可能性があります。