ロードシェディング

ロードシェディングを使うと、リスクのあるエンドポイントが 不健全になる のを防ぎ、フェイルオーバーの開始を避けられます。

プールにロードシェディングを設定すると、そのプールはロードシェディングの設定とロードバランサーの ステアリングポリシー に従って、トラフィックをほかのプールへ回し始めます。

社内のメトリクスを使い、障害しきい値に近づいているエンドポイントを特定します。

• エンドポイントのトラフィックは増えているが、まだ障害のリスクがない場合は、ステップ 2 から始めます。
• エンドポイントがまもなく障害しそうな場合は、ステップ 4 から始めます。

リスクのあるエンドポイントを特定したら、そのエンドポイントのプールから Default トラフィックを少量削減します。このトラフィックは、既存の セッションアフィニティ セッションには属しません。

ロードシェディングは ダッシュボード または API で設定します。

ダッシュボードで特定のプールにロードシェディングを有効にするには:

1. Load Balancing を開きます。
2. Pools タブを選択します。
3. 対象のプールで Edit を選択します。
4. Configure Load Shedding のドロップダウンを開きます。
5. Default traffic で Policy と Shed % を選びます。

API で特定のプールにロードシェディングを有効にするには、プールの load_shedding オブジェクトの 値を更新 します。

curl --request PATCH \
"https://api.cloudflare.com/client/v4/accounts/{account_id}/load_balancers/pools/{pool_id}" \
--header "Authorization: Bearer <API_TOKEN>" \
--header "Content-Type: application/json" \
--data-binary '{
  "load_shedding": {
    "default_percent": 20,
    "default_policy": "random",
    "session_percent": 0,
    "session_policy": "hash"
  }
}'

シェディングポリシーの選び方の詳細は、シェディングポリシー を参照してください。

デフォルトトラフィックの削減を始めたら、負荷分散アナリティクスの Overview メトリクス を確認して効果を評価します。この数値と社内メトリクスから、プールから追加のトラフィックを回す必要があるかが分かります。

プールへのトラフィックが増えている場合は、さらに削減が必要になることがあります。プールは総トラフィックの割合を削減するため、総トラフィックが増えると、プールに届くトラフィックも増えます。

プールのトラフィックをさらに削減する必要がある場合:

1. ステップ 2 の手順を繰り返します。
   • ダッシュボードでは、Default traffic または Session affinity traffic の Shed % を上げます。
   • API では、default_percent または session_percent の値を上げます。

Session Affinity traffic の削減は 既存セッション を中断し、顧客体験を損なうことがあります。プールがまもなく不健全になる危険がある場合や、既存セッションに関連するトラフィックの割合が高い場合にだけ、このオプションを有効にします。詳細は シェディングポリシー を参照してください。

エンドポイントにリスクがなくなったら、プールからロードシェディングを外します。

ダッシュボードでロードシェディングを外すには、ダッシュボードでロードシェディングを設定する と同じ手順を行い、Default traffic と Session affinity traffic の両方で Shed % を 0 にします。

API でロードシェディングを外すには、API でロードシェディングを設定する と同じ手順を行い、load_shedding オブジェクトを null にします。

Default traffic では、シェディングポリシーを 2 つから選べます。

Random ポリシーは次のとおりです。

• Shed % で指定した割合のリクエストをランダムに削減します。
• リクエスト単位で削減するため、生リクエストの配分はより正確です。
• 同じ IP からのリクエストが別のエンドポイントに届くことがあり、キャッシュミス、レイテンシのばらつき、DNS 専用ロードバランサー でのセッション中断につながる場合があります。

IP hash ポリシーは次のとおりです。

• Shed % で指定した割合の IP アドレスハッシュ空間を削減します。
• 同じ IP からのリクエストは同じエンドポイントに届くため、キャッシュヒットが増え、レイテンシが安定し、セッションを維持できます。
• ハッシュは IP を完全に均等には配分せず、個別の IP が占めるリクエスト割合も異なるため、リクエストを過剰または過少に削減することがあります。

生リクエストをより正確に配分したいときは Random ポリシーを、1 つの IP がエンドポイント間を行き来しないようにしたいときは IP hash ポリシーを選びます。

Session Affinity traffic では、これらのリクエストが既存セッションに関連するため、IP hash ポリシーだけを使えます。Shed % を上げるのは、既存セッション の中断を許容できる場合に限ります。

ロードバランサー内のすべてのプールで Load shedding が有効な場合、一部のトラフィックはフォールバックプールへ行きます。フォールバックプールへトラフィックを一切届けたくない場合は、ロードバランサー内の少なくとも 1 つのプールで、ロードシェディングを有効にしないでください。

プールでロードシェディングを有効にすると、すべてのロードバランサーで同じ割合のトラフィックを削減します。エンドポイントごとに、ロードバランサーによって削減割合を変えたい場合は、そのエンドポイントを複数のプールに入れます。