Load Balancing

最終更新: 2022-07-21 00:23:46 +0800 +0800
原文は英語で書かれています。あなたはAI翻訳版を読んでいます。

ロードバランシングは、トランスポートとアプリケーションの意味論を保ちながら、需要を健全な容量へ割り当てます。 配置、ヘルス、再試行、過負荷ポリシーは 1 つのシステムを形成します。アルゴリズムでは、 ヘルスチェックが誤分類したり再試行が消費したりした容量を回復できません。

配置レイヤー #

  • DNS 配置はリージョンまたはサービスのアドレスを返します。リゾルバーとクライアントの キャッシュにより変更は粗い粒度になるため、DNS は個々の接続をドレインしたり、リクエストごとの負荷に反応したりできません。
  • Anycast 配置は複数サイトから同じアドレスを広告し、ルーティングにパスを選ばせます。 ルート変更によってフローが移動する可能性があり、最も近いネットワークパスがアプリケーション容量に余裕のあるサイトとは限りません。
  • トランスポートロードバランシングは、アプリケーションリクエストを解釈せず、TCP、UDP、QUIC フローの メタデータからバックエンドを選択します。ダイレクトサーバーリターンと接続追跡はトポロジーと障害動作に影響します。
  • リバースプロキシはアプリケーションプロトコルを終端し、オーソリティ、パス、ヘッダー、メソッド、Cookie によって HTTP をルーティングできます。終端により再試行と可観測性が可能になりますが、プロキシ容量を消費し、別の障害ドメインを作ります。
  • アプリケーション配置は、テナント、シャード所有権、キューのパーティション、アクセラレーターの可用性など、 ドメイン状態を使って処理を割り当てます。アプリケーションは所有権の変更と古いルーティングメタデータを処理しなければなりません。

大規模システムではレイヤーを組み合わせます。DNS または anycast がサイトを選び、L4 ロードバランサーがプロキシを選び、 プロキシがワークロードを選びます。

選択アルゴリズム #

ラウンドロビンは容量とリクエストコストが似たエンドポイントに適しています。重み付きラウンドロビンは既知の容量差を反映します。 最小接続数はアクティブ接続数を負荷信号として使いますが、長時間存続するアイドル接続や多重化された HTTP/2・HTTP/3 ストリームにより、 接続 1 つが不正確な単位になることがあります。最小リクエスト数やレイテンシー認識型の変種には、安定した測定とダンピングが必要です。 そうしないと、一時的に高速なエンドポイントへすべてのリクエストを送ってしまいます。

安定したキーによるハッシュはアフィニティを提供します。コンシステントハッシュまたはランデブーハッシュはメンバーシップ変更時の 再マッピングを減らしますが、ホットキーを集中させる可能性があり、フェイルオーバーをなくすものではありません。 局所性認識型アルゴリズムは同じゾーンまたはリージョンを優先してレイテンシーと転送コストを下げつつ、 ローカル不足に備えてスピルオーバー容量を保持します。

ヘルス、外れ値、ドレイン #

アクティブヘルスチェックは合成プローブを送信します。パッシブチェックは実際の接続エラー、リセット、タイムアウト、ステータスコードを観測します。 レディネスはトラフィック処理に必要な依存関係の境界を検証すべきであり、すべての一時的な下流障害を全体の除外に変えてはなりません。

フラッピングを避けるため、連続成功数と連続失敗数のしきい値を使います。外れ値検出は観測された動作がピアと異なるエンドポイントを 一時的に除外します。共有依存関係の 1 つの障害でサービス全体が除外されないよう、除外率に上限を設けます。

ドレインは新規選択からエンドポイントを外しつつ、確立済みのリクエストや接続を期限内に完了させます。 ロードバランサーのドレイン時間、アプリケーションのシャットダウンフック、オーケストレーションのレディネス、 プロトコルのキープアライブ動作を調整します。

アフィニティ、再試行、フェイルオーバー #

Cookie、送信元アドレス、ハッシュによるアフィニティは、キャッシュ局所性を改善したり従来型のセッション状態を保持したりできます。 アフィニティはバランシングの自由度を下げるため、選択したバックエンドが消えた場合の動作を定義する必要があります。 リクエストに透過的なフェイルオーバーが必要なら、外部化または複製されたセッション状態を優先します。

タイムアウトは呼び出し側が結果を受け取らなかったことを意味するだけで、バックエンドが処理を行わなかった証明ではありません。 再試行は呼び出し側の期限内かつ上限付きの再試行予算内でのみ行います。安全でべき等な操作は候補になりますが、 非べき等操作にはアプリケーションのべき等キーと永続的な重複排除が必要です。バックオフとジッターで再試行を分散し、 すでに飽和したピア集合へ過負荷応答を再試行しないようにします。

ゾーン間またはリージョン間のフェイルオーバーには、予約容量、互換性のあるデータ、明示的な整合性モデルが必要です。 ルーティングの切り替えだけでは、リモートサイトを書き込み受付可能にはできません。

容量と過負荷 #

エンドポイント数は容量ではありません。同時リクエスト数、キュー深度、制約資源の使用率、レイテンシーパーセンタイル、 エラー、受付拒否を追跡します。オートスケーリングは測定とプロビジョニングの遅延後に反応するため、 バーストと障害に備えて余裕を残します。

需要が容量を超えたら、キューに上限を設け、低優先度の処理を捨て、テナント単位の制限を適用し、 プロトコルが対応する場合は明確な再試行シグナルを返します。メモリや接続プールが枯渇する前に、 バックプレッシャーが呼び出し側へ到達する必要があります。ロードバランサーのメトリクスでは、健全なエンドポイントがない状態、 ローカルプロキシの飽和、バックエンドの過負荷、ポリシーによる拒否を区別します。それぞれ必要な対応が異なるためです。

参考資料 #

コメント

GitHub で閲覧・コメントする(投稿にはログインが必要です)