Workers for Platforms

解決する課題

• 自社SaaSの顧客ごとにカスタムロジックを実行させたいが、顧客ごとにサーバーやコンテナを用意するのは非現実的
• 「顧客が書いたコード」を安全に隔離しつつ、大量にデプロイ・実行したい
• テナントが増えても運用負荷やコストを線形に増やしたくない
• 通常のWorkersアカウントにはデプロイ数の上限があり、そのままではマルチテナント向けに使えない

主要概念と用語

• User Worker: プラットフォーム利用者（顧客・テナント）が書いたコード。実際に処理を担う
• Dynamic Dispatch Worker: リクエストを受け取り、どのUser Workerを呼ぶか判断して振り分ける入り口のWorker
• Dispatch Namespace: User Workerをまとめてデプロイする論理的な入れ物。名前空間ごとに大量のWorkerを収容できる
• Outbound Worker: User Workerからの外部通信（fetchなど）を横取りし、監査やフィルタリングを行うための仕組み
• Tags: User Workerに付与するラベル。一括操作や絞り込みに使う
• Limits（Script単位の制限）: CPU時間やサブリクエスト数などをUser Workerごとに個別設定できる制御

仕様・制限・クォータ

• 通常のWorkersアカウントより桁違いに多いスクリプト数を1つのdispatch namespaceに収容できる
• User Workerの呼び出しはDynamic Dispatch Worker経由のバインディング呼び出しとして行われ、追加のネットワークホップは発生しない
• User Worker単位でCPU時間上限などのリソース制限を個別に上書きできる
• Outbound WorkerによりUser Workerからの外向き通信を一元的に検査・制限できる
• 通常のWorkers同様、リクエストごとの課金・計測はUser Worker単位で可能なため、テナントごとの利用量按分がしやすい

内部の仕組み

リクエストはまずプラットフォーム側が用意したDynamic Dispatch Workerに届きます。Dynamic Dispatch Workerは、リクエストのホスト名やパスなどからどの顧客のWorkerを呼ぶべきかを判断し、dispatcher.get()のようなAPIでdispatch namespace内の対象User Workerを取得して呼び出します。User Workerの実行はほかのWorkersと同じくV8のIsolateによる軽量な隔離で行われるため、コンテナやVMを都度起動するオーバーヘッドがありません。呼び出しの過程でOutbound Workerを介在させれば、User Workerが外部に出そうとする通信を検査・書き換え・拒否できます。

設計パターン / ベストプラクティス

• 顧客コードのアップロード・検証・デプロイは自動化パイプライン（CI/CDやAPI経由）で行い、手動運用を避ける
• テナントごとにTagsを付与し、一括での無効化・監査・棚卸しをしやすくする
• Outbound Workerで許可リストベースの外部通信制御を行い、あるテナントのコードが他システムへ不正アクセスするリスクを下げる
• User Worker単位のリソース制限を、契約プランや信頼度に応じて段階的に設定する
• User Worker内で例外が発生してもDynamic Dispatch Worker側やプラットフォーム全体に影響しないよう、呼び出し側でのエラーハンドリングを徹底する

運用・監視

• Workers標準のログ・可観測性機能（リアルタイムログ、Workers Analytics Engineなど）はUser Worker単位でも利用できる
• Dynamic Dispatch Worker側でリクエストごとにテナントIDなどをログへ埋め込み、テナント単位のトラブルシュートを可能にする
• デプロイ数やエラー率などをダッシュボード・APIで定期的に確認し、特定テナントの異常な挙動を早期検知する
• User Workerの更新はテナントの操作をトリガーに自動デプロイされる構成が多いため、デプロイ失敗時の通知・ロールバック手順を用意しておく

コスト

• 基本的な課金はリクエスト数とCPU時間に基づく点は通常のWorkersと同様だが、Workers for Platforms自体に追加の基本料金や大量スクリプト収容のための料金体系がある
• テナント数やUser Workerの呼び出し量に応じてコストが変動するため、プラットフォーム利用料をテナントへ転嫁する価格設計と組み合わせて検討する
• 具体的な料金・上限の数値は変動するため、契約前に公式ドキュメントで最新情報を確認する

セキュリティ

• User Worker同士はIsolateにより実行環境が分離されており、あるテナントのコードが別テナントのメモリやリクエストに直接アクセスすることはない
• Outbound Workerを使って、User Workerが呼び出せる外部ホストやプロトコルをプラットフォーム側で強制的に制御できる
• User Workerに渡すバインディング（KV・R2・環境変数など）はテナントごとに最小権限で individually 設定し、他テナントのリソースへのアクセスを避ける
• 顧客が自由にコードをアップロードできる構成のため、デプロイ前の静的検証やサイズ・API利用制限によるガードレールを設けることが望ましい

関連サービス・比較

ハンズオン / CLI例

# dispatch namespaceを作成する
wrangler dispatch-namespace create my-platform-tenants

# User Workerをdispatch namespaceへデプロイする
wrangler deploy --dispatch-namespace my-platform-tenants --name tenant-123-worker

# dispatch namespace内のWorker一覧を確認する
wrangler dispatch-namespace list