Cloudflareは、Python Workersが一般提供され、Pythonが同社の開発者プラットフォームで一等言語として完全にサポートされるようになったと述べている。同社の発表では、Workers AI、R2、D1、Hyperdrive、Durable Objects、Queues、Workflowsといった各サービスへのネイティブアクセスが紹介されている。また、PythonアプリケーションでFastAPI、Django、Flaskなど、ASGIまたはWSGIインターフェースを基盤とする各種フレームワークを利用できるとしている。
Workers AI、R2、D1、Hyperdrive、Durable Objects、Queues、Workflowsへのネイティブアクセスに関する説明を補足しています。 出典・クレジット：blog.cloudflare.com。
中心的な設計思想は、すべてのWorker内で従来のPythonアプリケーションサーバーを動かすことではない。Cloudflareによると、Pyodideを基盤とするWebAssemblyへコンパイルされたPythonインタプリターを使用し、リクエストのルーティングとスケーリングはWorkersプラットフォームが担うという。同社のworkers.asgiおよびworkers.wsgiコネクターは、JavaScriptのリクエストオブジェクトをPythonフレームワークが想定する構造へ変換し、その後、アプリケーションからのレスポンスをWorkersランタイム向けに再び変換する。この設計により、開発者は慣れ親しんだフレームワークのコードを維持できる一方で、互換性は通常のオペレーティングシステム上のデプロイではなく、ランタイム、各コネクター、対応するPythonパッケージに依存することになる。
大きな変更の一つは、Cloudflareの各バインディング境界にあった、明示的なJavaScript変換コードを削除した点だ。Cloudflareによれば、Pythonの辞書、キュー、その他のプラットフォームオブジェクトを、Python SDKを通じて、よりPythonらしい方法で渡せるようになったという。今回の発表は、以前はRPC境界で開発者がPythonデータをJavaScriptオブジェクトへ手動で変換する必要があったコードと、新しい方法を対比している。プラットフォームを検討するチームにとって、これは構文だけよりも重要になる可能性がある。通常のPythonロジックの周囲で、ランタイム固有のコードをどれだけ保守する必要があるかに影響するからだ。
データベースへのアクセスにも、互換性レイヤーが関わっている。Cloudflareによると、Python Workersには以前、aiomysqlやasyncpgなどのドライバーが想定する低レベルのソケット操作が備わっていなかったという。今回紹介されたソケット実装は、Pythonのソケット呼び出しをWorkers connect APIの操作へ変換し、対応するドライバーがHyperdriveを介してPostgreSQLまたはMySQLと通信できるようにする。これはWebAssemblyの制約に対する狙いを絞った解決策であり、あらゆるデータベースドライバーや機能がLinux上とまったく同じ挙動をするという証拠ではない。
対応するPythonドライバーがHyperdriveを介してPostgreSQLまたはMySQLを利用できるようにするソケットブリッジを直接示しています。 出典・クレジット：blog.cloudflare.com。
パッケージをめぐる状況も同様に重要だが、なお不完全なままだ。Cloudflareは、ネイティブのC、C++、またはRust拡張を含むPythonパッケージは、WebAssembly向けにクロスコンパイルする必要があると説明している。承認されたPEP 783はPyEmscriptenプラットフォームを標準化する一方、Pyodideのビルドツールチェーンとcibuildwheelに関する作業により、対応ホイールの作成がメンテイナーにとって容易になるとしている。これらの取り組みにより、Cloudflareがパッケージを個別にコンパイルする必要性は下がる可能性があるが、同社はエコシステムの採用がまだ進行中であることも認めている。したがって、通常流通するPythonエコシステムにパッケージが存在するだけでは、利用可能なWebAssemblyビルドがあると判断できない。
さらにCloudflareは、HTTPクライアントがJavaScriptのfetch APIを利用できるようにする変更により、openai、langchain、mcpなどのライブラリーをPython Workersで使用できると主張している。Workers AIとAI Gatewayを組み合わせることで、同社はPythonを、エッジで実行するAIオーケストレーションやパイプラインに適した実用的な言語として位置づけている。この主張は想定されるワークロードを理解するうえで有用だが、あらゆるサードパーティー統合、プロトコル、依存関係が修正なしに動作することを保証するものと受け取るべきではない。
実運用上の未解決事項で最も重要なのは、実際のワークロードにおける性能だ。発表によると、CloudflareはPython Workersの処理速度とメモリ効率を向上させる予定だが、今回提供された情報源には、コールドスタートの測定値、メモリ比較、スループットデータ、代表的なアプリケーションの上限は含まれていない。そのため、Pyodideを基盤とするWorkerが低遅延を要するサービスに適しているか、特定の依存関係一式がどれほどメモリを消費するか、従来のコンテナやJavaScript Workerと比べて費用がどうなるかは明らかになっていない。こうした疑問には一般提供という名称からの推測ではなく、ワークロードに応じたテストが必要だ。
開発者にとって実用的な評価基準は、Pythonが今やCloudflareのプラットフォーム全体で動作するかという問いよりも狭い。確認すべきなのは、必要なPythonのバージョンとパッケージにWebAssemblyビルドがあるか、アプリケーションのフレームワークが対応するASGIまたはWSGIの経路を使用しているか、データベースとネットワークの依存関係が提供されたブリッジを通じて機能するか、そして結果として得られる遅延とメモリ使用量の特性がサービスの要件を満たすかだ。Cloudflareの発表は、同社が製品をどの方向へ進め、どのような仕組みを構築したかを示すものだが、すべての互換性と性能上の結果を独立的に検証するものではない。