Python 3.7以前は、開発者はリクエスト特有のデータ（ユーザーセッションやデータベース接続など）を保存するために、threading.local()に完全に依存していました。しかし、asyncioの普及は根本的な欠陥を明らかにしました。スレッドローカルストレージは同じイベントループスレッドで実行されるすべてのコルーチンによって共有されます。ある非同期タスクが制御を譲ると、他のタスクが最初のタスクの約束された隔離された状態に予期せずアクセスまたは変更する可能性があり、それがセキュリティの脆弱性やデータ破損につながります。PEP 567は、OSスレッドに依存しない論理実行コンテキストの隔離を提供するためにcontextvarsを導入し、この概念はC#やErlangの同様のメカニズムをモデル化しています。
同期的なPythonでは、各HTTPリクエストは通常、自身のスレッドで実行されるため、threading.local()はリクエストコンテキストを保存するのに十分です。しかし、非同期アーキテクチャでは、数千の同時リクエストがイベントループによって管理される単一のスレッドにマルチプレックスされる可能性があります。二つの非同期タスクが実行を交互に行うと（ひとつがawaitで一時停止する間に、もうひとつが再開する場合）、彼らは同じスレッドローカル辞書を共有します。タスクスイッチ時にコンテキストをスナップショットして復元するメカニズムがない場合、論理的に分離された操作間でグローバル状態が漏れ出します。これにより、タスクAの認証トークンがタスクBに見えるようになったり、データベーストランザクションの境界が無関係なリクエストの間で混ざったりする競合状態が発生します。
Pythonは、スレッド状態に保存された不変マップへのキーとしてContextVarを実装しています。各非同期タスクは、自身のContextオブジェクトへの参照を保持します。これは、変更が共有状態を変異させるのではなく、新しいバージョンを作成する持続的なデータ構造です。asyncioがタスクをawaitで一時停止すると、現在のコンテキストをキャプチャします。再開する際にそのコンテキストを復元し、OSスレッドが移動してもContextVar.get()が特定のタスクにバインドされた値を返すことを保証します。このコピーオンライトのセマンティクスは、ロックオーバーヘッドなしに隔離を保証します。
import contextvars import asyncio request_id = contextvars.ContextVar('request_id', default='unknown') async def process_task(task_name): # この特定のタスクコンテキストに値を設定 token = request_id.set(task_name) try: await asyncio.sleep(0.01) # 制御を譲る、他のタスクが実行される可能性がある current = request_id.get() print(f"タスク {task_name} が読み取った: {current}") finally: request_id.reset(token) # 前のコンテキストを復元 async def main(): # 同じスレッドで二つのタスクを同時に実行 await asyncio.gather(process_task('Alpha'), process_task('Beta')) asyncio.run(main())
高スループットのAPIゲートウェイを構築しているチームは、スレッド型のFlaskアプリケーションから非同期のFastAPIサービスに移行しました。彼らは、現在のユーザーをthreading.local()に保存する認証ミドルウェアが、負荷がかかるとユーザーAのアイデンティティをユーザーBのリクエストにランダムに割り当てていることを発見しました。初期のデバッグは競合状態を示唆しましたが、ログは単一のワーカーデプロイ中にも割り当てが発生していることを示しました。根本的な原因は、asyncioの協調的マルチタスクであり、リクエストハンドラーがデータベース呼び出し中に譲ることで、同じスレッド上で別のハンドラーが実行され、スレッドローカルストレージを引き継いでしまうことでした。
チームは最初、threading.get_ident()でグローバル辞書にキーを付けることを試み、これがリクエストを隔離するだろうと考えました。このアプローチは、古いコードベースからのシンプルな移行を提供しましたが、外部依存関係を導入することはありませんでした。しかし、uvicornの下でasyncioを使用すると、同じスレッドが複数のリクエストを逐次処理するため、辞書は前のリクエストからの古いデータを保持し、無関係なリクエスト間で不正アクセスバグを引き起こしました。
彼らは、ミドルウェアからデータベース層までのコールスタック全体を通じてcontext辞書パラメータを受け入れるようにすべての関数シグネチャをリファクタリングしました。この明示的なデータフローは隠れた状態を排除し、同期と非同期の境界を越えました。残念ながら、これには数千の関数に触れ、大規模なリファクタリングが必要であり、グローバルな構成オブジェクトを期待するサードパーティライブラリとの統合が壊れ、結果としてコードの冗長性が大幅に増加し、メンテナンスの負担と開発者エラーのリスクが増加しました。
チームは、認証ユーザーオブジェクトを保存するためにcontextvars.ContextVarを採用し、ミドルウェアがリクエストエントリ時に変数を設定できるようにし、下流の関数が.get()を介してアクセスできるようにしました。これにより、アーキテクチャのオーバーホールは不要で、同時タスク間の自動隔離が提供されましたが、長時間実行されるプロセスでのメモリリークを防ぐためにreset()トークンの注意深い管理が必要でした。また、状態がスタックトレースでは見えず、実行コンテキストに暗黙的に存在するため、デバッグがさらに困難になりました。
彼らは最終的に、プロトタイピングによって、ミドルウェアレイヤーにのみ変更を必要とし、明示的なコンテキスト渡しに関連する大規模なリファクタリングを回避できることが示されたため、contextvarsを選択しました。リクエストハンドラーをtry/finallyブロックでラップしてトークンがリセットされることを保証し、メモリリークを防ぎながら、クリーンな関数シグネチャを維持しました。ゲートウェイは現在、各ワーカープロセスで50,000の同時接続を処理し、リクエスト間のデータ漏洩を防ぎ、インスタンスあたりのOSスレッド数を100から4に削減し、メモリ使用量を80%削減し、全体のスループットを300%向上させました。
なぜthreading.local()は非同期コードでは失敗し、スレッドコードでは機能するのですか？
スレッド型のPythonでは、オペレーティングシステムがスレッドを事前にスケジュールし、各スレッドは独自のCスタックとPyThreadState構造を維持します。threading.local()はこれらのOSレベルのスレッド識別子に変数をマッピングし、隔離を確保します。asyncioでは、イベントループがタスクを協調的に単一スレッド上でスケジュールし、キューを使用します。タスクが譲渡されると、ループは即座に同じスレッドで別のタスクを実行し、PyThreadStateを切り替えません。その結果、threading.local()は両方のタスクに対して同じキーを参照し、状態の漏洩を引き起こします。contextvarsは、タスクスイッチ時にイベントループがスワップするPyThreadState内でコンテキストマッピングのスタックを維持することで、OSスレッドに依存しない論理的隔離を作成します。
ContextVarトークンをリセットするのを忘れた場合はどうなりますか？
ContextVar.set()は、以前の状態を表すTokenオブジェクトを返し、以前の値を復元するためにreset()に渡す必要があります。これを忘れると、たとえばtry/finallyブロックを省略することで、変数は意図したスコープを超えてその値を保持します。非同期サーバーが長時間実行される場合、これは古いリクエストコンテクストがコンテキストチェーンに蓄積され、適切に復元されていない場合、 subsequent tasks on that thread may inherit stale values. Unlike traditional stack variables that disappear when functions return, context variables persist in the execution context until explicitly reset or until the task concludes, making cleanup mandatory.
コンテキスト変数は子タスクやスレッドにどのように伝播しますか？
asyncio.create_task()を使用すると、子タスクは親の現在のコンテキストのコピーを自動的に受け取り、コンテキスト変数が非同期コールグラフを自然に流れることを保証します。しかし、concurrent.futures.ThreadPoolExecutorやloop.run_in_executor()を使用すると、呼び出し可能はデフォルトで空のコンテキストで始まる別のOSスレッドで実行されます。候補者はしばしば、スレッド境界を越えてコンテキストが伝播すると仮定しますが、contextvarsは論理的な非同期コンテキストに特有です。スレッドに値を伝播させるには、コンテキストを明示的にキャプチャしてcontextvars.copy_context()を使用し、context.run()を介してその中で関数を実行するか、手動で変数を引数として渡す必要があります。