1. 背景
検索および推奨アルゴリズム アーキテクチャは、JD.com のすべての検索および推奨ビジネスにサービスを提供し、処理結果をリアルタイムで上流に返します。部門の各サブシステムは CPU ベースの適応型電流制限を実装していますが、クライアントからサーバーへの呼び出しは依然として RR ポーリングであり、下流のマシンのパフォーマンスの違いが考慮されておらず、システム全体の CPU の使用を最大化できません。クラスター。CPU 不均衡の問題を終了します。
JD の広告部門がビジネス シナリオ向けに開発した負荷分散手法は非常に参考になります。彼らが提案した RALB (Remote Aware Load Balance) アルゴリズムは、下流のサービス クラスター マシンの CPU リソース効率を向上させ、CPU ショートボード効果を回避し、より多くのトラフィックを処理できるパフォーマンスの高いマシン。私たちはその中心となるアイデアをシステムに適用し、良い結果を得ました。
この記事の構成は次のとおりです。
1. RALB の概要
◦アルゴリズムの原理を簡単に紹介します。
2. 機能検証
◦検索レコメンデーションアーキテクチャシステムにRALB負荷分散技術を適用し、機能検証を行います。
3. スループットテスト
◦主に RALB と RR の負荷分散テクノロジーを比較します。電流制限なしのクラスタとフル電流制限のあるクラスタ間でスループットに大きな差がないことが確認されています。RR 部分電流制限の場合、両者の間にはスループットに差があり、最大スループット差が生じる点があります。RALB の場合、サーバー側で無制限のフロー制限から完全なフロー制限への転換点となり、部分的なフロー制限になるケースはほとんどありません。
4. 境界テスト
◦さまざまな境界条件をシミュレーションすることで、システムをテストし、RALB の安定性と信頼性を検証しました。
5.機能開始
◦ RALB ロード バランシング モードは、すべてのサーバー側クラスタで完全に有効になっています。ローンチ前後でサーバー側のQPSが徐々に階層化され、サーバー側のCPUも徐々に統合される傾向にあることが分かります。
2. RALB の概要
RALB は、CPU バランシングをターゲットとした高性能ロード バランシング アルゴリズムです。
2.1 アルゴリズムの目標
1. 各ノードの CPU が相対的にバランスがとれるようにサーバー側の CPU 使用率を調整し、過剰な CPU 使用率によって引き起こされるクラスターの電流制限を回避します。
2. QPS は CPU 使用率と線形関係があり、QPS を調整することで CPU 使用率のバランスをとるという目標を達成できます。
2.2 アルゴリズム原理
2.2.1 アルゴリズムのステップ
1. トラフィックを割り当てるとき、重みに従って分散します (重み付きランダム アルゴリズム、wr)
2. CPU 使用率の収集: サーバーは RPC を通じて CPU 使用率 (平均 1 秒) をクライアントにフィードバックします。
3. 重み調整: クラスターと各ノードの CPU 使用率 (ウィンドウ内の平均値) に応じて重みを定期的に (3 秒ごと) 調整し、各ノードの CPU のバランスをとります。
2.2.2 インデックスの依存性
| シリアルナンバー | 索引 | 効果 | ソース |
|---|---|---|---|
| 1 | IP | 利用可能なIPリスト | メンテナンス用のサービス レジストリ検出および障害マスキング モジュール |
| 2 | リアルタイムの健康状態 | IP の可用性ステータスはリアルタイムで変化し、アルゴリズムの境界条件を提供します | RPCフレームワークのヘルスチェック機能のメンテナンス |
| 3 | 過去の健康状態 | ヘルス履歴値。IP 障害や回復などの境界条件を判断するために使用されます。 | 指標 2 の過去の値 |
| 4 | 動的ターゲット (CPU 使用率) | イコライゼーションアルゴリズムの最も直接的なターゲットベースを提供します | サーバー側のタイミング統計、RPC フレームワークが RPC を介して返す |
| 5 | 重量重量 | に基づくリアルタイムの負荷分散 | アルゴリズムのアップデート |
2.2.3 重み調整アルゴリズム
2.2.4 境界処理
境界 1: フィードバック ウィンドウ (3 秒) 内で、ダウンストリーム IP がアクセスされない場合、その平均 CPU 値は 0 になり、重み調整アルゴリズムはノードのパフォーマンスが優れているとみなして、重みを増やします。
境界 2: ネットワークに障害が発生すると、RPC フレームワークは障害が発生したノードを使用不可に設定し、CPU と重みは 0 になります。ネットワークが復元された後、RPC フレームワークは IP を使用可能に設定しますが、重みが 0 のノードは使用できません。トラフィックを共有するため、ノードが使用不可のままになります
処理: 重みの更新はタイマーによってトリガーされ、ノードの使用可能状態が記録され、ノードが使用不可から使用可能に回復したときに、低い重みが与えられ、徐々に回復します。
2.3 着陸の鍵
迅速かつ安定して行動し、いかなる状況でも行き詰まりや雪崩を回避し、特に境界条件に対処する
アルゴリズムのポイント:
1. 式内の各依存因子の更新は独立した意味を維持し、アルゴリズムの信頼性と単純さを維持する更新メカニズムを維持します。
◦ IP リストの更新は、サービス登録検出と RPC フレームワークによって共同で保証されます。
◦RPC更新CPU
2. 連続値を区別する必要がある境界値の意味に注意する
◦ CPU = 0、不明を意味し、CPU パフォーマンスが良好であることを意味しません
◦ w = 0、これはトラフィックが割り当てられないことを意味し、それが使用できない場合にのみ 0 になります。使用可能な場合は、RPC を確実にトリガーできるように、少なくともより小さい値が必要です。その後、重みが付けられます。更新できる
3. アルゴリズム更新の重み。RPC トリガーに依存せず、定期的に更新する必要があります。
3. 機能検証
3.1 圧力試験の準備
| モジュール | IP | CPU |
|---|---|---|
| クライアント | 10.173.102.36 | 8 |
| サーバ側 | 11.17.80.238 | 8 |
| 11.18.159.191 | 8 | |
| 11.17.191.137 | 8 |
3.2 圧力測定データ
| 索引 | RR ロード バランシング | RALB ロード バランシング |
|---|---|---|
| SWC | ||
| CPU | **** |
|
| TP99 |
マシンのパフォーマンスの差が小さいため、プレッシャー テストの CPU 効果は明らかではありません。CPU 効果をより明確にするために、ノード「11.17.80.238」に初期負荷が適用されます (つまり、トラフィックなし、CPU 使用率は 12.5%)
| 索引 | LAロードバランシング | RR ロード バランシング | RALB ロード バランシング |
|---|---|---|---|
| SWC | |||
| CPU | |||
| TP99 |
3.3 圧力試験の結論
圧力テスト後、RR と LA の両方に CPU の不均衡の問題が発生し、マシン リソースの性能差によりショート ボード効果が発生し、リソースを最大限に活用するという目的を達成できません。
RALB は CPU をバランス目標として使用するため、ノードの CPU に応じてノードが実行する QPS をリアルタイムに調整し、CPU バランスの目標を達成します。機能検証が可能であり、CPU パフォーマンスは期待どおりです。 。
4. スループットテスト
4.1 圧力測定対象
RALB は、CPU 使用率を動的指標として使用する負荷分散アルゴリズムであり、CPU 不均衡の問題を解決し、CPU ショートボード効果を回避し、パフォーマンスの良いマシンでより多くのトラフィックを処理できるようにします。したがって、RALB ロード バランシング戦略は、RR ポーリング戦略と比較して、ある程度のスループット向上を達成できると予想されます。
4.2 圧力試験の準備
サーバー側にはテスト用のマシンが 100 台あり、サーバー側では純粋な CPU 適応型電流制限が使用され、電流制限しきい値は 55% に設定されています。
4.3 圧力測定データ
RALB と RR の 2 つの負荷分散モードでの圧力テストを通じて、サーバー側のスループットがトラフィックの傾向に応じて変化し、クラスターのスループットに対する 2 つの負荷分散戦略の影響を比較します。
4.3.1 RALB
4.3.1.1 スループットデータ
次の表は、負荷分散モードが RALB に設定されている、テストによってクライアント側に送信されるサーバー側のスループット データです。18時17分、先ほどサーバー側の状況が電流制限に近づきました。ストレス テストの全段階で、非制限流量、部分流量制限、および完全な流量制限の 3 つの状況がテストされました。
| 時間 | 17:40 | 17:45 | 17:52 | 18:17 | 18:22 |
|---|---|---|---|---|---|
| 総流量 | 2270 | 1715年 | 1152 | 1096 | 973 |
| トラフィックを処理する | 982 | 1010 | 1049 | 1061 | 973 |
| 交通量が制限されている | 1288 | 705 | 103 | 35 | 0 |
| 電流制限比 | 56.74% | 41% | 8.9% | 3.2% | 0% |
| 平均CPU使用率 | 55% | 55% | 54% | 54% | 49% |
4.3.1.2 指標の監視
サーバー側マシンが受信するトラフィックはパフォーマンスに応じて分散され、CPU のバランスが保たれます。
| SWC | CPU |
|---|---|
4.3.2 RR
4.3.2.1 スループットデータ
次の表は、負荷分散モードが RR に設定されている、テストによってクライアント側に送信されるサーバー側のスループット データです。18:46 のサーバー側の全体的なトラフィックは、18:17 のサーバー側の全体的なトラフィックに近いです。以下では、これら 2 つの重要な瞬間におけるデータの比較に焦点を当てます。
| 時間 | 18:40 | 18:46 | 19:57 | 20:02 | 20:04 | 20:09 |
|---|---|---|---|---|---|---|
| 総流量 | 967 | 1082 | 1149 | 1172 | 1263 | 1314 |
| トラフィックを処理する | 927 | 991 | 1024 | 1036 | 1048 | 1047 |
| 交通量が制限されている | 40 | 91 | 125 | 136 | 216 | 267 |
| 電流制限比 | 4.18% | 8.4% | 10.92% | 11.6% | 17.1% | 20.32% |
| 平均CPU使用率 | 45%（部分限流） | 51%（部分限流） | 53%（部分限流） | 54%（接近全部限流） | 55%（全部限流） | 55%（全部限流） |
4.3.2.2 指标监控
Server端收到的流量均衡，但是CPU有差异。
| QPS | CPU |
|---|---|
4.4 压测分析
4.4.1 吞吐曲线
根据4.3节的压测数据，进行Server端吞吐曲线的绘制，对比RALB和RR两种负载均衡模式下的吞吐变化趋势。
import matplotlib.pyplot as plt
import numpy as np
x = [0,1,2,3,4,5,6,7,8,9,9.73,10.958,11.52,17.15,22.7]
y = [0,1,2,3,4,5,6,7,8,9,9.73,10.61,10.49,10.10,9.82]
w = [0,1,2,3,4,5,6,7,8,9.674,10.823,11.496,11.723,12.639,13.141,17.15,22.7]
z = [0,1,2,3,4,5,6,7,8,9.27,9.91,10.24,10.36,10.48,10.47,10.10,9.82]
plt.plot(x, y, 'r-o')
plt.plot(w, z, 'g-o')
plt.show()
4.4.2 曲线分析
| 负载均衡策略 | RALB | RR |
|---|---|---|
| 阶段一：所有机器未限流 | 接收QPS=处理QPS，表现为y =x 的直线 | 接收QPS=处理QPS，表现为y =x 的直线 |
| 阶段二：部分机器限流 | 不存在RALB根据下游CPU进行流量分配，下游根据CPU进行限流，理论上来讲，下游的CPU永远保持一致。所有的机器同时达到限流，不存在部分机器限流的情况。 所以在图中，不限流与全部机器限流是一个转折点，没有平滑过渡的阶段。 | RR策略，下游的机器分配得到的QPS一致，由于下游根据CPU进行限流，所以不同机器限流的时刻有差异。 相对于RALB，RR更早地出现了限流的情况，并且在达到限流之前，RR的吞吐是一直小于RALB的。 |
| 阶段三：全部机器限流 | 全部机器都达到限流阈值55%之后，理论上，之后无论流量怎样增加，处理的QPS会维持不变。图中显示处理的QPS出现了一定程度的下降，是因为处理限流也需要消耗部分CPU | RR达到全部限流的时间要比RALB更晚。在全部限流之后，两种模式的处理的QPS是一致的。 |
4.5 压测结论
临界点：吞吐差异最大的情况，即RALB模式下非限流与全限流的转折点。
通过上述分析，可以知道，在RALB不限流与全部限流的临界点处，RR与RALB的吞吐差异最大。
此时，计算得出RALB模式下，Server集群吞吐提升7.06%。
五、边界测试
通过模拟各种边界条件，来判断系统在边界条件的情况下，系统的稳定性。
| 边界条件 | 压测情形 | 压测结论 |
|---|---|---|
| 下游节点限流 | CPU限流 | 惩罚因子的调整对于流量的分配有重要影响 |
| QPS限流 | 符合预期 | |
| 下游节点超时 | Server端超时每个请求，固定sleep 1s | 请求持续超时期间分配的流量基本为0 |
| 下游节点异常退出 | Server端进程被杀死直接kill -9 pid | 杀死进程并自动拉起，流量分配快速恢复 |
| 下游节点增减 | Server端手动Jsf上下线 | jsf下线期间不承接流量 |
| Server端重启stop + start | 正常反注册、注册方式操作Server端进程，流量分配符合预期 |
六、功能上线
宿迁机房Client端上线配置，在所有Server端集群全面开启RALB负载均衡模式。可以看出，上线前后，Server端的QPS逐渐出现分层，Server端的CPU逐渐趋于统一。
| 上线前后Server端QPS分布 | 上线前后Server端的CPU分布 |
|---|---|
参考资料
1.负载均衡技术
2.深入浅出负载均衡
作者：京东零售 胡沛栋
来源：京东云开发者社区