可用性と速度のためのAIサービスのロードバランシング
Pinecone は、LLM や埋め込みモデルなどの異なる AI サービス特性に応じた動的ルーティングを実現する「2 つの選択肢」アルゴリズムに基づくサービス意識型ロードバランサを開発し、可用性とレイテンシを同時に最適化した。
キーポイント
静的戦略の限界と動的対応の必要性
従来のリージョン近接性に基づく静的ルーティングでは、バックエンドの過負荷や部分的な障害、クォータ圧力などの変化に対応しきれず、リアルタイムでの適応が求められた。
"2 つの選択肢"アルゴリズムの実装
グローバルコントローラーに依存せず、ランダムに 2 つのバックエンドをサンプリングしてより良い方を選択する分散型アプローチを採用し、複雑な調整コストを削減した。
サービス固有のスコーリングポリシー
LLM と埋め込みモデルでは最適化要件が異なるため、各サービスタイプごとに独自のスコアリングポリシーを適用し、適切なルーティング判断を行っている。
影響分析・編集コメントを表示
影響分析
このアプローチは、大規模な AI アプリケーションにおいて、単一プロバイダやリージョンへの依存リスクを軽減し、複雑なマルチプロバイダ環境下でも安定したパフォーマンスを提供する標準的なアーキテクチャパターンを示している。特に、LLM の非決定的な挙動やレイテンシ変動が頻発する現代の AI サービス開発において、実用的かつ即座に適用可能な解決策として業界全体に影響を与える可能性がある。
編集コメント
AI サービスの信頼性を高める上で、単純なフェイルオーバーではなく、リアルタイムの性能指標に基づいた動的ルーティングが不可欠であることが示された。Pinecone の実装は、マルチプロバイダ戦略を採る企業にとって非常に参考になる実践的な事例です。
TLDR: Pinecone Assistant は、埋め込みモデル、再ランク付け器、LLM へのリクエストを、それぞれ複数のプロバイダーとリージョンにまたがるバックエンド間でルーティングします。静的なルーティング戦略ではリアルタイムのバックエンド状況に対応しきれないため、「2 つの選択肢の力」アルゴリズム（power of two choices）の上にサービス認識型ロードバランサーを構築しました。これは、2 つのバックエンドをサンプリングしてより優れた方を選択し、これを繰り返す仕組みです。その結果、グローバルなコーディネーターを必要としない適応型ルーティング、アップストリーム障害時の自動フェイルオーバー、構造化された AI 呼び出しにおける有意なレイテンシ低下が実現しました。異なるサービスタイプには異なるスコアリングポリシーが適用されます。なぜなら、LLM と埋め込みモデルはルーティングの問題として同じではないからです。
現代の AI プロダクトは、単一のモデルエンドポイントに依存することはほとんどありません。Pinecone Assistant では、1 つのユーザーリクエストが埋め込みモデル、再ランク付け器、LLM にまたがり、それぞれがリージョンやプロバイダーを跨ぐ複数のバックエンドを持ちます。これらは一部がサードパーティによって管理され、他は社内運営されています。
これらのバックエンドは異なる目的を果たします：クォータ拡大のためのものもあれば、可用性向上のためのものもあり、両方の役割を担うものもあります。実務上、すべてのリクエストはルーティングの問題です：今この呼び出しを処理するのはどのバックエンドが適切か？
Pinecone Assistant 向けに、この選択を自動で行うサービス認識型ロードバランサーを構築しました。目的は、アップストリームの問題発生時にプロダクトの可用性を維持し、レイテンシが有効なルーティング信号となる場所で遅延を削減することです。
The Problem（課題）
サードパーティの AI サービスに依存する場合、障害は二値的（単なる成功/失敗）ではありません。
- バックエンドが致命的な障害を起こし、エラーを返すことがあります。
- リージョンは稼働していても、大幅に遅延することがあります。
- プロバイダー全体としては健全でも、特定のエンドポイントが過負荷になることがあります。
- クォータの圧力により、通常なら優先するエンドポイントへのトラフィックを迂回させざるを得ない場合があります。
- バックエンドは回復しても、静的ルーティングではそれを十分に迅速に検知できません。
Pinecone Assistant でもすでにこの状況を目撃していました。障害やレイテンシの急上昇、そして手動で迂回経路を設定するための運用作業です。このアプローチ以前も、レイテンシを抑えるためにリージョン間の近接性に基づいてルーティングを調整していましたが、それでもバックエンドの状態が絶えず変化するシステムにおいて静的な戦略に過ぎませんでした。私たちはリアルタイムで反応するルーティングが必要でした。
私たちが目指したもの
私たちは同時にいくつかの特性を最適化しようとしていました：
- 高い可用性：不健全なバックエンドは速やかにトラフィックの受信を停止すべきです。
- 低レイテンシ：レイテンシが予測可能で最適化の対象となる場合、手動調整ではなくライブ条件からその恩恵を受けるべきです。
- 低い調整オーバーヘッド：すべての決定を行う複雑なグローバルコントローラーは不要です。
- 優雅な回復：回復したバックエンドは自動的にトラフィックに再参加すべきです。
- サービス固有の動作：埋め込み（embeddings）、ランク付け器（rerankers）、大規模言語モデル（LLMs）はすべて同じように扱うべきではありません。
最後の点が最も重要でした。ある種類の AI 呼び出しに対して最適なポリシーが、別の種類にとっては全く逆の結果をもたらす可能性があります。
私たちが検討したアプローチ
設計を確定する前に、私たちはいくつかのよく知られた技術を検討しました。
負荷の少ないルーターは、アクティブな接続数が最も少ないバックエンドに各リクエストをルーティングします。これは、接続数が負荷の信頼できる指標となる長寿命の TCP 接続やファイル転送にはよく機能します。しかし、AI サービス呼び出しやベクトルデータベースクエリではこれらの前提が崩れます。キュー深度、リクエストの複雑さ、現在のメモリ圧力によっては、アクティブな接続が 2 つしかないバックエンドの方が、20 個あるバックエンドよりも遅くなる可能性があります。接続数は表面だけの指標であり、バックエンド内部で実際に何が起こっているかを明らかにするものではありません。
レイテンシ対応型ルーティングは、測定されたレイテンシに基づいてグローバルに最適なバックエンドを選択します。その魅力は明白ですが、2 つの問題を引き起こします。第一に、すべての呼び出し元間で調整と継続的な計測コストが必要となり、避けたいオーバーヘッドが生じます。より致命的なのは、構造的に不安定である点です。すべての呼び出し元が同じレイテンシ推定量を共有すると、同時に同じ勝者に収束してしまいます。その勝者は過負荷になり、レイテンシが急騰し、全員が次の勝者へと切り替わり、このサイクルが繰り返されます。指数加重移動平均（EWMA）追跡はこれをある程度緩和しますが、群れ行動はグローバルランキング方式に本質的に組み込まれており、完全に消えることはありません。
ラウンドロビンと加重ラウンドロビンは、バックエンドを順番に巡回し、必要に応じて重み付けを行うことでトラフィックを不均等に分散します。両方ともシンプルで予測可能であり、公平性を促進しますが、その制限として重みが静的である点が挙げられます。バックエンドが低速化したり部分的に故障したりした場合でも、重みは動的に変更されません。あるマシンが故障した場合、公平性の原則により、すべての呼び出し元はその影響の一部を構成が手動で更新されるまで吸収し続けることになります。
一貫性ハッシュは、リクエストをユーザー ID などのキーに基づいてバックエンドに決定論的にマッピングします。これはキャッシュの局所性に価値があります：同じユーザーは常に同じバックエンドにアクセスするため、キャッシュがウォームアップされ、重複した作業が削減されます。特にプロンプトキャッシングが重要な LLM（大規模言語モデル）ワークロードにおいて、この手法を評価しました。問題は、一貫性ハッシュが適応しない点です。割り当てられたバックエンドが低速化したり故障したりした場合でも、そのユーザーは構成変更が行われるまで引き続きそこに留まり続けます。手動オーバーライドを伴うステッキルーティングではなく、自動的な適応が必要です。
ランダム選択は、バックエンドを均一にランダムに選びます。これは安価でステートレスであり、実装も極めて簡単ですが、状況認識がなく、変動がある場合でも負荷を均等に分散させることができません。例えば、繰り返し発生する障害を検知し、不健全なバックエンドを一時的にプールから除外して、それらへのリクエストがさらに集中しないようにする必要があります。その後、一定の冷却期間を経て、バックエンドは再びプールに戻ります。この健康状態の追跡とプールの管理は非常に複雑になり、結果としてロードバランサー本来が提供するはずだった適応ロジックの多くをハードコーディングすることになってしまいます。
2 つの選択肢のパワー
これらのアプローチすべてが失敗する根本的な理由は同じです：ある問題を別の問題に置き換えているだけです。ランダム選択は盲目であり、グローバルランキングは不安定で、静的ポリシーは適応できません。解決策は、「無知」と「全知」の間で二択を迫る考え方をやめることです。1996 年、Mitzenmacher は、中間的な道が存在することを示しました。ランダムに選ぶかグローバルにランキングするのではなく、2 つのバックエンドをランダムにサンプリングし、その中からより優れたものを選ぶのです。この単なる追加の比較により、最大負荷は logn/loglogn から loglogn に低下します。これは 1 つの追加の選択肢による指数関数的な改善です。
この考え方は通常「2 つの選択肢のパワー（p2c）」として知られており、私たちのバランサーの中核を成しています：
- ランダムに 2 つの候補バックエンドを選択します。
- 直近の評価スコアを用いて比較します。
- より優れた方のバックエンドへリクエストを送信します。
この決定は単純で、局所的かつ低コストです。これにより、群れ行動（herding）を回避するのに十分なランダム性を保ちつつ、最も混雑しているホットスポットからのトラフィックを回避できます。分散状態の維持も、グローバルコントローラーも不要です。リクエストごとに 1 回の比較を行うだけです。
私たちが構築したもの
各リクエストは同じパターンに従います：
これは意図的にシンプルに設計されています。私たちは未来を完璧に予測しようとしているわけではありません。新しい信号を用いて良質なルーティング決定を行い、ロードバランサー自体が複雑な分散システムになることを防ぎたいのです。
1 つのサービスタイプに 1 つの方針
最も重要な設計上の選択は、すべての場所で単一のスコアリングルールを使用しないことです。
| サービスタイプ | レイテンシを支配する要因 | ルーティング信号 |
|---|---|---|
| Embeddings（埋め込みベクトル生成） | エンドポイントの健全性、キューイング、ネットワーク経路 | 直近のレイテンシと信頼性 |
| Rerankers（再ランク付け） | エンドポイントの健全性、キューイング、ネットワーク経路 | 直近のレイテンシと信頼性 |
| LLMs（大規模言語モデル） | プロンプトサイズ、キャッシュ、モデルの挙動、出力長 | レイテンシではなく、信頼性と負荷 |
Embeddings と Rerankers の場合、レイテンシは有用な信号となります。これらの呼び出しは構造化されており比較的高速であり、バックエンド間の性能差が明確に現れるため、直近のレイテンシに基づくルーティングには実質的なメリットがあります。
LLM は異なります。エンドツーエンドのレイテンシは、リクエスト自体によって大きく形成されます：プロンプトの長さ、キャッシュの挙動、モデル内部の仕組み、トークン数など。この数値に基づくルーティングはノイズが多く、キャッシュの局所性を損ないます。特定のバックエンドに限定されたキャッシュを活用できる LLM 呼び出しも存在するため、常に測定される最小レイテンシを追求することは、その恩恵と相反します。短寿命のスティッキー（固定）ルーティングの方が優れています。
ストリーミングワークロードにおいては、完全な完了時間よりも最初のトークン到達時間がより良い指標となります。しかし一般的に、LLM のルーティングは純粋な速度ではなく、可用性と負荷分散を最適化すべきです。
探索と回復
p2c（Power of Two Choices）は、直近のスコアに基づいてルーティングを行うことで機能します。これが同時に弱点でもあります：バックエンドが継続してトラフィックを受け取らない限り、スコアは鮮度を保てないからです。
解決策はシンプルです：探索用のトラフィックを継続的に割り当てることです。パフォーマンスを損なうほど多くなくとも、状況を新鮮に保つのに十分な量で構いません。優れたロードバランシングとは、単にトラブルから回避するだけでなく、トラブルが終了したことに気づくことでもあります。
結果
バランサーは段階的に展開されました：まず rerankers（再ランク付け器）がプロバイダーへの直接呼び出しから p2c バランスされたパスへ移行し、次に embeddings（埋め込みベクトル）のスコアリング戦略がラウンドロビンからレイテンシ重み付き p2c へと切り替えられました。以下の指標は各移行を追跡しています。
Reranker latency (direct provider calls → balanced path)
ロールアウト前、reranker 呼び出しは Provider A に対して直接行われ、クライアント側のタイムアウトは 10 秒でした。ロールアウト後、呼び出しは複数のレプリカを経由する p2c バランスされたパス（統合推論サービスを含む）を流れるようになりました。
メトリック Before After Change
p50 138 ms 135 ms −3%
p95 7,577 ms 953 ms −87%
p99 10,621 ms 1,917 ms −82%
ロールアウト前の遅延尾部（tail）はタイムアウトに起因していましたが、新しいパスの尾部は単にネットワーク遅延とモデル処理遅延の合計であり、健全なレプリカに対するものです。
Embedder latency (round-robin → latency-weighted p2c)
埋め込みベクトル生成（Embeddings）にはすでにロードバランサーが存在していましたが、それはラウンドロビン方式による選択を行っていました。今回の戦略変更では、上記で説明した p2c スコアリングを導入しました。
メトリック Before After Change
p50 368 ms 298 ms −19%
p95 3,802 ms 1,793 ms −53%
p99 4,377 ms 3,171 ms −28%
バッチ取り込みスループットも、同じ週に約 4.5 倍向上しました。リコンサイラー（reconciler）は低速な埋め込み呼び出しによってボトルネックに陥っていましたが、より賢いルーティングによりその制約が解消されました。
エンベディングにおける導入前と導入後
レイテンシの低下はルーティングの問題です。ラウンドロビン方式では、パフォーマンスに関係なく 6 つのプロバイダーエンドポイントすべてに均等なトラフィック（それぞれ約 17%）が割り当てられていました。一方、レイテンシ重み付けされた p2c（Power of Two Choices）方式では、ロードバランサーがレプリカを継続的にスコアリングし、より高速なノードにトラフィックを集中させます。
2 つのエンドポイントは大幅なトラフィックシェアを失いましたが、残りの 2 つはそれを獲得しました。ロードバランサーは、低トラフィックのエンドポイントをプール内に維持し、予備容量および探索用トラフィックとして活用します。具体的には、リクエストのごく一部でこれらのエンドポイントにプローブ（探査）を行い、パフォーマンスが回復したタイミングを検知できるようにしています。上記の表で示された p75 および p95 の改善は、上位 2 つのエンドポイントへの集中によって生じたものです。
アップストリーム障害時の可用性
ロールアウト期間中に、4 つの重要なバックエンド劣化事象を観測しました。ロードバランサーは短く局所的な事象を完全に吸収し、広範囲かつ数日間にわたる劣化においてはユーザーへの影響を軽減しましたが、完全には排除できませんでした。
急性のスパイク（急増）は教科書的なケースです。あるプロバイダー A のリージョンで劣化が発生した際、ロードバランサーがそれを迂回し、そのクラスター内では 6,580 回の呼び出しに対してわずか 6 件の失敗した再ランク付けのみが発生しました。
Provider A の 2 つの複数日にわたるインシデントは、ロードバランサーの吸収能力が限界に達する地点を示しています。同じアップストリームプロバイダーのレプリカが同時に遅延したりエラーを発生させたりする場合、どのロードバランサーも劣化を完全に隠すことはできず、最善の策として「最も悪い状態ではない方」を選ぶことしかできません。
Provider B のインシデントは、継続性の観点での明確な勝利であり、LLM 固有の方針選択を検証した事例です。当社の LLM ロードバランサーは、エンドツーエンドのレイテンシーではなく、信頼性と負荷に基づいてスコアリングされます。12 日間にわたる持続的な地域的な劣化（単一日で最大 1,288 の不健全なシグナルに達した期間）を通じて、チャットの処理量は 1 日あたり 3.4〜6.2k リクエストで横ばいを維持し、アラートによるページングも発生しませんでした。顧客は劣化に気づきませんでした。
オペレーションへの影響
ロードバランサー導入後、手動のルーティング介入は週約 3 回からほぼゼロまで減少しました。継続的なメンテナンスを必要としていた手動調整された地域優先設定も廃止されました。
大きな教訓
AI の負荷分散は単一の課題ではありません。それは関連する問題群です。適切な戦略は、呼び出し背後にどのようなサービスが存在するか、どのシグナルが信頼できるか、そしてどれだけの調整コストを払うかを希望するかによって異なります。
当社にとっての勝利パターンはシンプルでした：不健全なバックエンドを迂回させ、p2c（Power of Two Choices）を活用して複雑さを最小限に抑えつつスマートルーティングの大部分の恩恵を受け、すべての AI サービスが同じように最適化されるべきだと偽り続けるのをやめることです。
原文を表示
TLDR: Pinecone Assistant routes requests across embeddings, rerankers, and LLMs, each backed by multiple providers and regions. Static routing strategies couldn't keep up with real-time backend conditions, so we built a service-aware load balancer on top of the "power of two choices" algorithm: sample two backends, pick the better one, repeat. The result is adaptive routing with no global coordinator, automatic failover during upstream incidents, and meaningfully lower latency on structured AI calls. Different service types get different scoring policies, because LLMs and embeddings are not the same routing problem.
Modern AI products rarely depend on a single model endpoint. In Pinecone Assistant, a single user request may reach across embeddings, rerankers, and LLMs, each with multiple backends across regions and providers, some managed by third parties and others operated in-house.
Those backends serve different purposes: some exist to expand quota, some exist to improve availability, some do both. In practice, every request is also a routing problem: which backend should handle this call right now?
We built a service-aware load balancer for Pinecone Assistant to make that choice automatically. The goal: keep the product available during upstream issues, and reduce latency where latency is a useful routing signal.
The Problem
When you rely on third-party AI services, failure is not binary.
- A backend can fail hard and return errors.
- A region can stay up but get much slower.
- A provider can be healthy overall while one endpoint is overloaded.
- Quota pressure can force traffic away from the endpoint you would normally prefer.
- A backend can recover, but static routing will not notice quickly enough.
We had already seen this in Pinecone Assistant: outages, latency spikes, and the operational work of routing around them manually. Before this approach, we also tuned routing by region proximity to keep latency down. That helped, but it was still a static strategy in a system where backend conditions changed continuously. We needed routing that reacted in real time.
What We Wanted
We were optimizing for a few properties at once:
- High availability: unhealthy backends should stop receiving traffic quickly.
- Low latency: when latency is predictable enough to optimize, we should get that benefit from live conditions rather than manual tuning.
- Low coordination overhead: no complex global controller making every decision.
- Graceful recovery: backends that recover should rejoin traffic automatically.
- Service-specific behavior: embeddings, rerankers, and LLMs should not all be treated the same way.
That last point mattered most. A good policy for one kind of AI call can be exactly the wrong policy for another.
Approaches We Considered
Before settling on our design, we looked at several well-known techniques.
Least loaded routes each request to the backend with the fewest active connections. This works well for long-lived TCP connections or file transfers, where connection count is a reliable proxy for load. AI service calls and vector database queries break those assumptions. A backend with two active connections can be slower than one with twenty, depending on queue depth, request complexity, and current memory pressure. Connection count is a surface metric; it does not expose what is actually happening inside the backend.
Latency-aware routing selects the globally best backend by measured latency. The appeal is clear, but it introduces two problems. First, it requires coordination and continuous metering costs across all callers, adding overhead we wanted to avoid. More critically, it is structurally unstable. When all callers share the same latency estimates, they converge on the same winner simultaneously. That winner gets overloaded, its latency spikes, everyone shifts to the next winner, and the cycle repeats. Exponentially Weighted Moving Average (EWMA) tracking dampens this somewhat, but the herding behavior is inherent to any globally-ranked scheme and does not fully go away.
Round-Robin and Weighted Round-Robin cycle through backends in order, with optional weighting to distribute traffic unevenly. Both are simple, predictable, and promote fairness. The limitation is the weights are static. They do not change dynamically when a backend slows down or partially fails. When one machine fails, fairness means every caller absorbs its share of the impact until the configuration is manually updated.
Consistent Hashing maps requests to backends deterministically, typically on a key like user ID. This is valuable for cache locality: the same user always hits the same backend, which warms up caches and reduces redundant work. We evaluated this specifically for LLM workloads where prompt caching matters. The problem is that consistent hashing does not adapt. If the assigned backend slows down or fails, that user stays on it until the configuration changes. We need automatic adaptation, not sticky routing with manual overrides.
Random Selection picks a backend uniformly at random. It is cheap, stateless, and trivial to implement, but it has no situational awareness and does not balance load evenly under variance. For example, we must detect repeated failures and remove unhealthy backends from the pool to prevent them from getting more requests. Then, after a cooldown, backends re-enter the pool. This health tracking and pool management turns out to be very complex, and it ends up hardcoding much of the adaptive logic the load balancer was supposed to provide in the first place.
The Power of Two Choices
Each of those approaches fails for the same underlying reason: they trade one problem for another. Random selection is blind. Global ranking is unstable. Static policies don't adapt. The fix is to stop treating this as a binary choice between "ignorant" and "omniscient." In 1996, Mitzenmacher showed there is a middle path. Instead of choosing randomly or ranking globally, sample two backends at random and pick the better one. That single extra comparison drops the maximum load from lognloglogn\frac{\log n}{\log \log n} to loglogn\log \log n, an exponential improvement from one additional choice.
This idea is usually known as “power of two choices” (p2c) and is the backbone of our balancer:
- Pick two candidate backends at random.
- Compare them using a recent score.
- Send the request to the better one.
The decision is simple, local, and cheap. It preserves enough randomness to avoid herding while still steering traffic away from the worst hot spots. No distributed state, no global controller, just one comparison per request.
What We Built
Each request follows the same pattern:
This is intentionally simple. We are not trying to predict the future perfectly. We are trying to make a good routing decision using fresh signals, without turning the balancer itself into a complicated distributed system.
One Service Type, One Policy
The most important design choice was not using a single scoring rule everywhere.
Service type What dominates latency Routing signal
Embeddings Endpoint health, queueing, network path Recent latency + reliability
Rerankers Endpoint health, queueing, network path Recent latency + reliability
LLMs Prompt size, caching, model behavior, output length Reliability and load, not end-to-end latency
For embeddings and rerankers, latency is a useful signal. Those calls are structured and comparatively fast, and performance differences across backends show up clearly enough that routing on recent latency gives a real benefit.
LLMs are different. End-to-end latency is heavily shaped by the request itself: prompt length, cache behavior, model internals, and token count. Routing on that number is noisy, and it breaks cache locality. Some LLM calls benefit from caching that is local to a specific backend; constantly chasing the lowest measured latency works against that. Short-lived sticky routing outperforms it.
For streaming workloads, time-to-first-token is a better signal than full completion time. But in general, LLM routing should optimize for availability and load, not raw speed.
Exploration and Recovery
p2c works because it routes on recent scores. That is also its vulnerability: scores only stay fresh if backends keep receiving traffic.
The fix is small: continuous allocation of exploratory traffic — not enough to hurt performance, but enough to keep the picture fresh. Good load balancing is not just about steering away from trouble; it is about noticing when the trouble is over.
Results
The balancer rolled out in stages: rerankers migrated first from direct provider calls onto a p2c-balanced path, then embeddings had a scoring-strategy swap from round-robin to latency-weighted p2c. The metrics below track each transition.
Reranker latency (direct provider calls → balanced path)
Before rollout, reranker calls went directly to Provider A with a 10-second client timeout. After rollout, calls flow through a p2c-balanced path across multiple replicas including integrated inference services.
Metric Before After Change
p50 138 ms 135 ms −3%
p95 7,577 ms 953 ms −87%
p99 10,621 ms 1,917 ms −82%
The pre-rollout tail was timeout-bound; the new path's tail is simply network plus model latency against a healthy replica.
Embedder latency (round-robin → latency-weighted p2c)
Embeddings already had a balancer, but it used round-robin selection. The strategy swap introduced the p2c scoring described above.
Metric Before After Change
p50 368 ms 298 ms −19%
p95 3,802 ms 1,793 ms −53%
p99 4,377 ms 3,171 ms −28%
Bulk ingest throughput also rose about 4.5× the same week. The reconciler had been bottlenecked on slow embedder calls; smarter routing unblocked it.
Before → after for embeddings
The latency drop is a routing story. Under round-robin, all six provider endpoints received equal traffic regardless of performance — roughly 17% each. Under latency-weighted p2c, the balancer scores replicas continuously and concentrates traffic on the faster ones.
Two endpoints lost significant share; two gained it. The balancer keeps lower-traffic endpoints in the pool as overflow capacity and for exploratory traffic — probing them with a small fraction of requests so it detects when performance recovers. The concentration toward the top two endpoints is what produced the p75 and p95 improvements in the table above.
Availability during upstream incidents
Across the rollout window we observed four material backend degradations. The balancer absorbed short, narrow incidents fully; on broad, multi-day degradations it reduced but did not eliminate user impact.
The acute spike is the textbook case: one Provider A region degraded, the balancer routed around it, and users saw 5 failed reranks out of 6,580 calls that day in this cluster.
The two multi-day Provider A incidents show where the balancer's absorption runs out. When most replicas of the same upstream provider are simultaneously slow or erroring, no balancer can fully mask the degradation — the best it can do is pick "least bad”.
The Provider B incident is the clearest continuity win, and the one that validates the LLM-specific policy choice. Our LLM balancer scores on reliability and load rather than end-to-end latency. Through 12 days of sustained regional degradation (peaking at 1,288 unhealthy signals on a single day), chat throughput stayed flat at 3.4–6.2k requests/day and no alerts paged. Customers did not notice.
Operational impact
Manual routing interventions dropped from roughly 3 per week to near zero after the balancer was deployed. The hand-tuned regional preference configuration that had required ongoing maintenance was also eliminated.
The Bigger Lesson
AI load balancing is not one problem. It is a family of related problems. The right strategy depends on what kind of service sits behind the call, what signals are trustworthy, and how much coordination you want to pay for.
For us, the winning pattern was simple: keep unhealthy backends out of the way, use p2c to get most of the benefit of smart routing with very little complexity, and stop pretending every AI service should be optimized the same way.
関連記事
今日のまとめ
AI日報で今日の重要ニュースをまとめ読み