スマートプレースメント
ベータデフォルトでは、WorkersおよびPages Functionsは、リクエストが受信された場所に最も近いデータセンターで呼び出されます。ワーカーでバックエンドロジックを実行している場合、エンドユーザーではなく、バックエンドインフラストラクチャに近い場所でそのワーカーを実行する方がパフォーマンスが向上する可能性があります。スマートプレースメントは、レイテンシを最小限に抑え、アプリケーションの速度を向上させる最適な場所にワークロードを自動的に配置します。
ワーカーで中央集権的なデータベース、API、またはオリジンサーバーに対して複数回の往復を行っている場合、スマートプレースメントの恩恵を受けることができます。
以下の例は、ワーカーをバックエンドサービスの近くに移動させることでアプリケーションのレイテンシがどのように減少するかを示しています：
オーストラリアのシドニーにいるユーザーが、ワーカー上で実行されているアプリケーションにアクセスしています。このアプリケーションは、ユーザーのリクエストに応じるために、ドイツのフランクフルトにあるデータベースに対して複数回の往復を行います。
問題は、ワーカーがデータベースに対して複数回の往復を行うのにかかる時間です。リクエストがユーザーの近くで処理されるのではなく、スマートプレースメントが有効な場合、Cloudflareネットワークはリクエストをデータベースに最も近いデータセンターで処理します。
スマートプレースメントは、ワーカーごとに有効化されます。有効化されると、ワーカーからのフェッチリクエスト（サブリクエストとも呼ばれます）が定期的に分析されます。スマートプレースメントアルゴリズムは、ワーカーとワーカーが通信しているバックエンドサービス間の往復時間（RTT）を最小限に抑える最適な配置を決定します。
スマートプレースメントは、バックエンドインフラストラクチャに対して1回以上の往復を行うワーカーに対してのみアクティブです。ワーカーが平均して1回未満のサブリクエストを行う場合、スマートプレースメントはユーザーに最も近いデータセンターでワーカーを実行します。
スマートプレースメントは、最善の努力を試みるものです。スマートプレースメントは、デフォルト（ユーザーに最も近いデータセンターでワーカーを実行すること）よりもパフォーマンスが向上しない限り、アクションを起こしません。
スマートプレースメントは、fetch event handlersの実行にのみ影響します。フェッチイベントハンドラーを持たないワーカーは、スマートプレースメントによって無視されます。フェッチと非フェッチのイベントハンドラーの両方を持つワーカーの場合、スマートプレースメントはフェッチイベントハンドラーの実行にのみ影響します。
D1バインディングを持つワーカーは、常にバインドされているD1データベースの近くのデータセンターに配置されます。この場合、他のバックエンドサービスへのサブリクエストはスマートプレースメントによって無視されます。
スマートプレースメントアルゴリズムによって考慮されないバックエンドサービスがあります：
-
グローバルに分散されたサービス：ワーカーが通信するサービスが多くの地域に地理的に分散されている場合（例：CDN、分散データベース、分散API）、スマートプレースメントは適していません。これらは自動的にスマートプレースメントの最適化から除外されます。
- 例：Google APIs、FastlyやAkamaiのCDNを使用するサービス。
-
分析またはロギングサービス：分析またはロギングサービスへのリクエストは、アプリケーションのクリティカルパスに含まれるべきではありません。
waitUntil()を使用して、コードの計測中にユーザーへの応答がブロックされないようにする必要があります。waitUntil()はユーザーの視点からリクエストの期間に影響を与えないため、分析およびロギングサービスは自動的にスマートプレースメントの最適化から除外されます。- 例：New Relic、Datadog、Tinybird、Grafana、Amplitude、Honeycomb。
スマートプレースメントは、すべてのワーカープランのユーザーが利用できます。
Wranglerを介してスマートプレースメントを有効にするには：
-
wrangler@2.20.0以降がインストールされていることを確認します。 -
ワーカープロジェクトの
wrangler.tomlファイルに以下を追加します：[placement]mode = "smart" -
ワーカーに初期トラフィック（約20-30リクエスト）を送信します。トラフィックをワーカーに送信してから、スマートプレースメントが効果を発揮するまでに数分かかります。
-
ワーカーのリクエスト期間分析を確認します。
ダッシュボードを介してスマートプレースメントを有効にするには：
- Cloudflareダッシュボード ↗にログインし、アカウントを選択します。
- アカウントホームで、Workers & Pagesを選択します。
- 概要で、ワーカーを選択します。
- 設定 > 一般を選択します。
- 配置の下で、スマートを選択します。
- ワーカーに初期トラフィック（約20-30リクエスト）を送信します。トラフィックをワーカーに送信してから、スマートプレースメントが効果を発揮するまでに数分かかります。
- ワーカーのリクエスト期間分析を確認します。
ワーカーのメタデータには、ワーカーの配置ステータスに関する詳細が含まれています。以下のWorkers APIエンドポイントを通じてワーカーの配置ステータスを照会します：
curl -X GET https://api.cloudflare.com/client/v4/accounts/{ACCOUNT_ID}/workers/services/{WORKER_NAME} \-H "Authorization: Bearer <TOKEN>" \-H "Content-Type: application/json" | jq .可能な配置状態には以下が含まれます：
- (存在しない): ワーカーはまだスマートプレースメントの分析を受けていません。
INSUFFICIENT_INVOCATIONS: スマートプレースメントが配置決定を行うためのリクエストが不十分です。NO_VALID_HOSTS: ワーカーはスマートプレースメントによってサポートされているバックエンドサービスにサブリクエストを送信しません。INSUFFICIENT_SUBREQUESTS: ワーカーは有効なバックエンドサービスに対して十分なサブリクエストを送信しません。SUCCESS: ワーカーは正常に分析され、スマートプレースメントによって最適化されます。
スマートプレースメントが有効になると、リクエスト期間に関するデータが収集されます。リクエスト期間は、エンドユーザーに最も近いデータセンターで測定されます。
デフォルトでは、リクエストの1%（1%）はスマートプレースメントを使用せずにルーティングされません。これらのリクエストは比較の基準として機能します。
スマートプレースメントが有効になると、Cloudflareはすべてのリクエストにcf-placementヘッダーを追加します。これを使用して、リクエストがスマートプレースメントを使用してルーティングされたかどうか、またワーカーがリクエストを処理している場所（データセンターに最も近い空港コードとして表示されます）を確認できます。
例えば、cf-placement: remote-LHRヘッダーのremote値は、リクエストがスマートプレースメントを使用してロンドン近くのCloudflareデータセンターにルーティングされたことを示します。cf-placement: local-EWRヘッダーのlocal値は、リクエストがスマートプレースメントを使用せずにルーティングされ、ワーカーがリクエストが受信された場所に最も近いデータセンターで呼び出されたことを示します。これはニューアーク・リバティ国際空港（EWR）に近いです。
ワーカー上でフルスタックアプリケーションを構築している場合、フロントエンドとバックエンドのロジックを異なるワーカーに分割し、サービスバインディングを使用してフロントエンドロジックとバックエンドロジックのワーカーを接続することをお勧めします。
バックエンドワーカーでスマートプレースメントを有効にすると、バックエンドサービスの近くで呼び出され、フロントエンドワーカーはユーザーに近い場所でリクエストを処理します。このアーキテクチャは、迅速で反応の良いフロントエンドを維持しつつ、バックエンドワーカーが呼び出されたときのレイテンシを改善します。
スマートプレースメントはベータ版です。スマートプレースメントに関するあなたの考えや体験を共有するには、Cloudflare Developer Discord ↗に参加してください。