1. 直面する問題
巨大なクラウドコンピューティング + 分散 + サービス システムでは、数万のサービス ノードから構成される大規模なネットワーク構造が含まれており、呼び出しリンクは複雑で、同じノード上のサービス間で上流と下流のリソース競合関係が存在します。ノード 圧力伝導の関係もあるため、各サービス ノードとその上の各サービスはトラフィック保護を実装する必要があります。
電流制限やヒューズなどの現在のトラフィック保護技術は比較的成熟していますが、実際のアプリケーションプロセスでは関連パラメータの設定が緩すぎて、外部トラフィックが突然増加した場合やサービスノードのリソース競合などの問題が発生した場合に理想的な保護の役割を果たせません。トランザクションタイムアウトは依然として頻繁に発生します。
したがって、サービスの現状の制限閾値をどのように合理的に評価し、設定するかがシステム保守担当者の頭を悩ませる問題となっており、本研究課題はその合理的な解決策を探ることを目的としています。
2. 解決のプロセス
共通サービス電流制限インジケーター
現在の制限は、トラフィックの突然の増加によってサービス ノードの主要なリソースが枯渇しないようにし、他の二次的な問題を回避するために、事前に設定されたしきい値を超えるリクエスト トラフィックに対するルールに従って一部のリクエストを拒否することです。
サービス ノードの場合、より一般的に使用される電流制限指標は、1 秒あたりに処理されるリクエスト数 (TPS) と最大同時実行数です。
ビジネス レベルでは、サービス ノードが特定のビジネス処理能力を達成する必要があります。これは、多くの場合、単位時間あたりに処理できるリクエストの数によって説明されます。企業が 1 秒あたりに処理されるリクエスト数 (TPS) の指標要件を明確にしている場合は、それに応じて現在の制限しきい値を設定できます。
システムの安定性と可用性を確保するという観点から見ると、最適な電流制限指標は同時実行の最大数です。サービス内の同時実行の最大数を制限することで、サービスがリソースを消費する同時プロセスが多すぎることを常に防ぐことができます。
理論的には、これら 2 つの指標は次の式を使用して大まかに変換できます。
并发数=TPS*服务平均响应时间この記事では、最大同時実行インジケーターの現在の制限しきい値を評価する方法に焦点を当てます。
ノード全体の電流制限閾値の評価
1. 理論的分析
電流制限パラメーターは、電流制限をトリガーするインジケーターのしきい値を指します。スロットリングのしきい値の設定が高すぎると、トラフィックが多いときにスロットルをトリガーできなくなり、アプリケーション サーバーが過負荷になり、パフォーマンスが低下し、サービスがタイムアウトになります。しきい値の設定が小さすぎると、リソース使用量は常に低レベルになり、サーバー リソースが無駄になります。サービス ノードの現在の制限しきい値を評価することは、サービス ノードが同時に処理できるリクエストの数、つまり同時サービスの最大数を評価することです。サービス ノードの場合、同時サービスの最大数はサービス スレッド プールのサイズによって決まります。
したがって、サービス スレッド プールのサイズは、サービス ノードの全体的な電流制限しきい値となり、サービス ノードの処理能力、リソース使用量、および動作の安定性を決定します。このような重要なパラメータについては、ストレス テストを通じて評価することをお勧めします。
ストレス テスト中に、リソース使用率が高いレベルにあり、対応する期間内にサービスのパフォーマンスが大幅に低下しない臨界点を見つけます。この臨界点では、1 秒あたりに処理されるリクエストの数 TPS または同時実行の最大数は、最適なサービス スレッド プール サイズです。
2. ストレス試験方法
より良い評価効果を達成するには、ストレス テスト環境を本番環境と可能な限り一致させる必要があります。まず、サービス ノードのハードウェア構成が本番環境と一致し、ノード内の各サービスのトランザクション量比率が一致している必要があります。本番環境と一致している必要があります。テストコストを考慮すると、トランザクション量の割合が多いサービスをテストサンプルとして選択することをお勧めします。
すでにオンラインで実行されているサービス ノードの場合、本番のピーク時の実際のトラフィックを再生テスト用に記録できれば、より理想的です。
ストレス テスト中は、サーバー リソースの使用率が高レベル (たとえば、CPU 使用率が約 80% に達する) に達するまでリクエストの同時実行数を徐々に増やします。このときのサービスの同時実行数は、ノードの同時電流制限のしきい値として使用できます。 、これはサービス スレッド プールです。サイズは、下の図に示されています ▼。
3. 注意事項
ストレス テスト中は、サービスの平均応答時間が悪化したかどうかを同時に観察する必要があります。上図の平均応答時間変化曲線は、同時実行数が電流制限しきい値に達する前は比較的安定しており、これが理想的な状況です。
テスト プロセス中、サービスの平均応答時間は低下する可能性がありますが、CPU やメモリなどのハードウェア リソースの使用率は高くありません。これは、データベース アクセス効率、解決するためにプログラムによって追加されたオブジェクト ロックなど、他のボトルネックがあることを示しています。スレッドの安全性など確認が必要な項目 ボトルネック問題を解決した後、ストレステストを継続します。
個々のサービスの電流制限しきい値の評価
1. 理論的分析
サービス ノードの全体的な電流制限しきい値により、ノードのリソース使用量を過負荷からある程度保護できます。ただし、リソースには限りがあり、各ノード上で複数のサービスが動作するため、サービス間でリソースの競合が発生するため、少数のサービスがリソースを占有しすぎないよう、サービスレベルの電流制限も考慮する必要があります。サービスが使用するリソースを制限するには、サービスの同時実行数が最も効果的な電流制限指標となります。
前のセクションのストレス テストの臨界点における各サービスの同時実行数を、各サービスの現在の制限しきい値として使用できますか? 実際の状況に基づくと、答えはノーです。ノード内の各サービスのトランザクション量の割合は常に変化し、絶えず増減するため、このような電流制限しきい値は一方的すぎて柔軟性に欠けます。
各サービスの電流制限しきい値を評価するには、各サービスに対してストレス テストを個別に実行する必要があります。まず、ストレス テストの臨界点を取得する際に、達成すべきリソース使用量の目標として、各サービスが使用できるリソースの割合を評価する必要があります。
サービスの重要性に応じて、占有できるリソースの使用量は異なります。たとえば、高速支払いサービス ノードでは、支払いサービスはノードのリソースのほとんどを消費できますが、他のクエリ サービスとメンテナンス サービスは許可されます。より少ないリソースを取得するため。
2. ストレス試験方法
各サービスの重要性に応じてリソースの最大使用量を設定し、ストレス テストを個別に実施します。各サービスの耐圧テスト中に、サーバーのリソース使用量が目標水位 (たとえば、CPU が約 50% に達する) に達するまで、リクエストの同時実行数を徐々に増やします。このとき、同時サービスの数は、同時実行サービスの数として使用できます。以下の図に示すように、ノードの同時電流制限しきい値▼ 。
3. 過去データの分析と予測手法
実際のアプリケーションでは、各サービス ノード上のサービスの数は数十から数百に及び、すべてのサービスの包括的なストレス テストには人的コストと時間のコストがかかりすぎます。一般に、ストレス テストできるのは少数の主要なサービスだけです。
ただし、サービス電流制限の目的は主に、重要でないサービスの同時実行を制限し、主要なサービスのリソース供給を確保することであり、主要なサービスの電流制限しきい値を設定するだけではこの目標を達成できません。したがって、ストレス テスト方法を使用してサービス電流制限しきい値を計算する場合、コストと利点の間に矛盾があり、他の解決策を見つける必要があります。
過去の期間におけるサービスの 1 日あたりの最大同時実行数を分析のために実稼働監視データから取得し、過去の最大同時実行数がサービス スロットリングのしきい値を評価する際の参考として重要であることがわかりましたが、次の問題を解決する必要があります。
質問 1 : 負荷分散アルゴリズムはランダム アルゴリズムであるため、同じサービス クラスター内の異なるノードの負荷は等しくなく、同時実行の最大数には一定のランダム性があり、一定の確率で不具合が発生します。
さらに、システム内の一部の障害によりサービスの処理が遅くなったり、停止したりすることがあり、これにより同時サービスの数が異常に増加する可能性もあります。これらの異常なデータはいずれも、電流制限しきい値を評価するための基礎として使用されるべきではありません。
質問 2 : ビジネスの推進に伴い、サービスのトランザクション量は増加し続け、将来の最大同時実行数は、当初の過去の最大同時実行数をすぐに超える可能性があります。
上記の問題に対応して、サービスの同時実行性の履歴データを処理して、現在の制限しきい値をより適切なものにすることができます。
1. 過去のデータに対してノイズリダクション処理を実行し、ランダム性や故障に起因する異常なデータを除去します。
毎年618やダブル11など、一部のビジネスプロモーションは周期的であることを考慮すると、分析の基礎として1年以上の履歴データを取得する必要があります。データが正規分布に従うと仮定すると、ほとんどのデータは平均から 3 標準偏差 (99.73%) 以内であるため、平均から 3 標準偏差を超えるデータはグリッチとして削除されます。
2. 過去のデータに基づいて傾向を予測し、将来のビジネス開発に向けて合理的な成長余地を確保します。
データ量と計算コストを考慮して、代表的な時系列分析モデルとして、自己回帰移動平均モデル ARMA を選択します。ARMA モデルは、自己回帰 (AR) と移動平均 (MA) の特性を組み合わせたものです。予測結果は、自己回帰 (AR) と移動平均 (MA) の特性を統合します。時系列データ、トレンドとボラティリティ。以下の図は、ARMA モデルを使用して描画した、今後 3 か月間における特定のサービスの同時実行数の変化傾向と信頼区間を示しています (信頼水準は 0.99 に設定されています)。信頼区間の上限は、信頼区間として使用できます。サービスの電流制限しきい値。
3. 練習する
上記の理論的研究とプログラムの議論に基づいて、サービス ノード全体の電流制限しきい値はストレス テスト手法を使用して評価する必要があり、単一サービスの電流制限しきい値については、ノイズ低減処理とトレンドを評価する必要があると結論付けることができます。過去の同時実行データを通じて実行され、低コストで推奨事項を予測して生成します。
研究プロジェクトの実施中に、過去の生産監視データから過去1年間のサービスの毎日の最大同時実行数を取得するトラフィック保護パラメータ管理および制御システムを開発し、以前の研究で述べたアルゴリズムに基づいて、これらのデータは、サービス電流制限パラメータの推奨値を取得するために、ノイズ低減処理や傾向予測などの分析計算を実行し、ユーザーにクエリおよびアクティブ プッシュ サービスを提供します。
このトラフィック保護パラメータ管理および制御システムは、数十のビジネス システムに対して電流制限パラメータを推奨しており、ユーザーからは、システムが推奨する電流制限しきい値がより合理的であり、トラフィックの突然の増加によって引き起こされるリスクをより効果的に防止し、安定したサービスを確保できると報告されています。サービスノードの操作。