リクエストの処理フローと分散機構
コンシューマー側アプリケーションがダウンストリームAPIへ呼び出しを行う際、Ribbonがクライアントサイドの負荷分散として介入します。標準的なデータフローは以下の順序で進行します。
- 呼び出し元（例：注文処理サービス）がHTTPリクエストを発行し、Ribbonクライアントレイヤーで補足されます。
- Ribbonがサービスレジストリ（Eureka Serverなど）へ接続し、対象サービス名に紐づくアクティブなインスタンスリストをフェッチします。
- レジストリから返却されたノード情報をRibbonが保持し、内部の決定アルゴリズムに基づいて最適なエンドポイント（例：ポート8081のインスタンス）を抽出・選択します。
内部動作原理とソースコードの追跡
Ribbonの動作核心は、Springが提供するインターセプターチェーンとネフックス由来のロードバランサー実装にあります。処理経路を順に解説します。
@LoadBalancedアノテーションが付与されたHTTPクライアントの呼び出しは、LoadBalancerInterceptorによって自動的にフックされます。- インターセプターの
intercept()メソッド内では、要求されたURIからホスト名（サービスID）を抽出します。その後、RibbonLoadBalancerClientの実行メソッドへ処理が委譲され、動的サーバーリスト更新機構がレジストリとの同期およびサーバーリストの保持を行います。 - サーバー選択フェーズでは、
ZoneAwareLoadBalancerおよび基底クラスBaseLoadBalancerが連携します。ここで重要なのはchooseServer()メソッドであり、これにより設定されたアルゴリズム（IRule実装）のchoose()メソッドが実行されます。
これにより、抽象的なサービス名が実際のネットワークアドレスに置換され、物理的なTCP/HTTP呼び出しが行われます。
IRuleによる分散アルゴリズムの選択
負荷分散の振る舞いはIRuleインターフェースのサブクラスによって定義されます。標準で提供される主要な実装は以下の通りです。
- ZoneAvoidanceRule（デフォルト）: データセンターやラック単位（ゾーン）の健全性を評価し、同じゾーン内でラウンドロビンを行います。フェイルオーバー時のリソース枯渇やゾーン障害を緩和する設計です。
- RoundRobinRule: 単純な順次選択（ラウンドロビン）。均一なトラフィック分散に適しています。
- RandomRule: 完全なランダム選択。特定のインスタンスへの偏りを回避したい場合やテスト環境で利用されます。
ルールの変更とスコープ制御
環境に合わせて分散アルゴリズムをカスタマイズするには、アプリケーション全体への適用と個別サービスへの適用の2つのアプローチがあります。
グローバルスコープでのコード定義
設定クラス内でBeanとして登録すると、アプリ起動時に解決されるすべてのダウンストリーム呼び出しに反映されます。
@Configuration
public class GlobalLoadBalancerConfig {
@Bean
public IRule applicationWideRule() {
// 選択アルゴリズムの切り替え
return new RandomRule();
}
}
プロパティファイルによる個別指定
特定のサービスに対してのみルールを上書きする場合は、設定ファイルへ追加します。これにより、他のサービスの分散挙動には影響を与えずにローカルな最適化が可能です。
customer-api:
ribbon:
NFLoadBalancerRuleClassName: com.netflix.loadbalancer.RandomRule
初期化戦略：遅延読み込みから早期初期化へ
Ribbonクライアントはデフォルトで遅延初期化（Lazy Loading）が採用されています。初めてリクエストが到達した際にクライアントコンテキストが構築されるため、最初の応答時間に顕著な遅延が生じる可能性があります。
この現象を解消し、サービス起動直後から安定したレスポンスタイムを確保するには、早期初期化（Eager Loading）を有効化します。対象となるサービス名を明示的にリスト化することで、メモリ効率と起動時の性能バランスを制御できます。
ribbon:
eager-load:
enabled: true
clients:
- customer-api
- inventory-service