- 単一のサーバーがどのように最適化されていても、優れたハードウェアが使用されていても、常にパフォーマンスの上限があります。単一のサーバーのパフォーマンスがビジネスニーズを満たせない場合は、システムの全体的な処理パフォーマンスを向上させるように高性能クラスターを設計する必要があります。
- 高性能クラスターの本質は非常にシンプルで、サーバーを追加してシステムの全体的な処理能力を向上させます。計算自体には特徴があります。どのサーバーが実行されても、同じ入力データとロジックは同じ出力を取得する必要があります。したがって、高性能クラスター設計の複雑さは主にタスク割り当てに反映され、合理的なタスク割り当て戦略を設計し、実行のために複数のサーバーに計算タスクを割り当てる必要があります。
- 高性能クラスターの複雑さは、主にタスクアロケーターを追加し、タスクに適切なタスク割り当てアルゴリズムを選択する必要性に反映されます。タスクディストリビューターの場合、より一般的な一般用語は "ロードバランサー"です。ただし、この名前は誤解を招く可能性があります。タスクの割り当ての目的は、各コンピューティングユニットの負荷をバランスの取れた状態に保つことであると無意識に思わせることになります。実際、タスクの割り当てでは、コンピューティングユニットの負荷分散だけが考慮されるわけではありません。タスク割り当てアルゴリズムが異なれば目標も異なります。一部は負荷の考慮に基づいており、一部はパフォーマンス（スループット、応答時間>）に基づいており、一部はビジネスの考慮に基づいています。負荷分散は、コンピューティングユニットの負荷が平衡状態に到達するためだけのものではありません。
負荷分散分類
一般的な負荷分散システムには、DNS負荷分散、ハードウェア負荷分散、ソフトウェア負荷分散の3つのタイプがあります。
DNS負荷分散
DNSは最も単純で最も一般的なロードバランシングの方法であり、一般に地理レベルのバランスを達成するために使用されます。たとえば、北のユーザーは北京のコンピュータルームを訪問し、南のユーザーは深センのコンピュータルームを訪問します。DNSロードバランシングの本質は、同じドメイン名のDNS解決が異なるIPアドレスを返す可能性があることです。たとえば、www.baidu.comでもあります。取得されたアドレスは61.135.165.224で、サザンユーザーが分析後に取得したアドレスは14.2 15.177.38です。
DNSロードバランシング
DNSロードバランシングは、実装が簡単で低コストですが、粒度が高すぎる、ロードバランシングアルゴリズムが少ないなどの欠点もあります。
- シンプルで低コスト：負荷分散作業はDNSサーバーによって処理されるため、負荷分散装置を自分で開発または保守する必要はありません
- アクセス速度を向上させるための近くのアクセス：DNS解決は、要求のソースIPに基づいて、ユーザーに最も近いサーバーアドレスに解決できます。これにより、アクセスを高速化し、パフォーマンスを向上させることができます。
- 更新はタイムリーではありません：DNSキャッシュ時間が比較的長いです。DNS構成を変更した後、キャッシュのために、多くのユーザーが変更前のIPにアクセスし続けます。そのようなアクセスは失敗し、ロードバランシングの目的が達成されず、影響も及ぼしますユーザーは通常ビジネスを使用します
- スケーラビリティの低下：DNS負荷分散はドメイン名プロバイダーによって制御されており、ビジネス特性に基づいて、カスタマイズされた機能や拡張機能をさらに実行することは不可能です
- 分散戦略は比較的単純です。DNSロードバランシングはいくつかのアルゴリズムをサポートします。サーバーの違いを区別できません（システムとサービスのステータスに従って負荷を判断できません）。バックエンドサーバーのステータスも認識できません。
DNSロードバランシングのいくつかの欠点を考慮して、遅延および障害の影響を受けやすいサービスのために、一部の企業はHTTP-DNS自体の機能を実装しています。つまり、HTTPプロトコルを使用してプライベートDNSシステムを実装しています。このスキームは、一般的なDNSの利点と欠点の逆です。
ハードウェアロードバランシング
ハードウェアロードバランシングとは、個別のハードウェアデバイスを通じてロードバランシング機能を実現することです。このタイプのデバイスは、ルータースイッチに似ており、ロードバランシングのための基本的なネットワークデバイスとして理解できます。現在、業界にはFSとA10の2つの一般的なハードウェアロードバランシングデバイスがあります。このタイプの機器は、強力な機能と強力な機能を備えていますが、価格は安くありません。一般に、「地元の専制君主」企業のみがこのような機器の使用を検討します。通常のビジネスレベルの企業はそれを買う余裕がなく、ビジネスボリュームはそれほど大きくないので、これらの機器を使用することは無駄です。
ハードウェアロードバランシングの利点と欠点は次のとおりです。
- 強力な機能：すべてのレベルでのロードバランシングの完全サポート、包括的なロードバランシングアルゴリズムのサポート、およびグローバルロードバランシングのサポート
- 強力なパフォーマンス：比較すると、10万レベルまでのソフトウェアロードバランシングサポートはすでに非常に強力であり、ハードウェアロードバランシングは100万以上の同時実行性をサポートできます。
- 高い安定性：商用ハードウェアのロードバランス、大規模な使用後、良好で厳密なテストに合格、高い安定性
- セキュリティ保護のサポート：ロードバランシング機能に加えて、ハードウェアバランシング機器にはファイアウォールやDDOS攻撃などのセキュリティ機能もあります。
- 高価：数十万から数百万
- スケーラビリティが低い：ハードウェアデバイスはビジネスに応じて構成できますが、拡張やカスタマイズはできません
ソフトウェア負荷分散
- ソフトウェア負荷分散は、負荷分散ソフトウェアを介して負荷分散機能を実装します。一般的なものはNginxとLVSです。Nginxはソフトウェアの7層の負荷分散であり、LVSはLinuxカーネルの4層の負荷分散です。レイヤー4とレイヤー7の違いは、プロトコルと柔軟性にあります。NginxはHTTPおよび電子メールプロトコルをサポートしていますが、LVSは4層のロードバランシングであり、プロトコルとは関係なく、チャットやデータベースなど、ほとんどすべてのアプリケーションを実行できます。
- ソフトウェアとハードウェアの主な違いはパフォーマンスで、ハードウェアロードバランシングのパフォーマンスはソフトウェアロードバランシングのパフォーマンスよりもはるかに高くなります。Ngxinのパフォーマンスは10,000であり、一般的なLinuxサーバー上のNginxは1秒あたり50,000に達する可能性があります。LVSのパフォーマンスは100,000であり、これは1秒あたり800,000に達すると言われ、自己パフォーマンスは200から数百万です毎秒1万から毎秒800万、もちろん、ソフトウェアロードバランシングの最大の利点は安価です。
- ロードバランシングにオープンソースシステムを使用することに加えて、ビジネスが特別な場合は、オープンソースシステム（たとえば、Nginxプラグイン）に基づいてカスタマイズしたり、自己調査したりすることもできます。
Nginxの負荷分散アーキテクチャ
ソフトウェアロードバランシングの利点と欠点は次のとおりです。
- シンプル：導入とメンテナンスはどちらも比較的シンプルです
- 安い：Linuxサーバーを購入してソフトウェアをインストールするだけ
- 柔軟性：レイヤー4およびレイヤー7のロードバランシングはビジネスに応じて選択できます。たとえば、ビジネスに基づいて簡単に拡張できます。たとえば、Nginxプラグインを使用してビジネスカスタマイズ機能を実現できます。
- 平均パフォーマンス：1つのNginxで約50,000の同時実行をサポートできます
- ハードウェアロードバランシングほど強力ではない
- 通常、ファイアウォールやアンチDDOS攻撃などのセキュリティ機能はありません
負荷分散アーキテクチャ
DNSロードバランシング、ハードウェアロードバランシング、ソフトウェアロードバランシング、それぞれの方法にはいくつかの長所と短所がありますが、実際のアプリケーションでは、長所と短所に基づいてどちらか一方しか選択できないという意味ではなく、それらに基づいています。長所と短所を組み合わせて使用します。具体的には、組み合わせの基本原則は次のとおりです。地理的レベルのロードバランシングを実現するためにDNSロードバランシングが使用されます。クラスターレベルのロードバランシングを実現するためにハードウェアロードバランシングが使用されます。マシンレベルのロードバランシングを実現するためにソフトウェアロードバランシングが使用されます。
負荷分散アルゴリズム
多数の負荷分散アルゴリズムがあり、それらはいくつかのビジネス特性に従ってカスタマイズおよび開発できます。詳細の違いに関係なく、アルゴリズムの予想される目標に応じて、それらは大まかに次のカテゴリに分類できます。
- タスクレベルの分類：負荷分散システムは、受信したタスクをサーバーに均等に分散して処理します。ここでの「平均」は、絶対数の平均、または比率や重みの平均にすることができます。
- 負荷分散：サーバーの負荷に従って負荷分散システムが分散されます。ここでの負荷は、システムの圧力を測定するための通常の意味での接続数、I / O使用率、ネットワークカードのスループットとは限りません。
- 最適なパフォーマンスカテゴリ：負荷分散システムは、サーバーの応答時間に従ってタスクを割り当て、新しいタスクを最も速い応答でサーバーに優先順位付けします。
- ハッシュの種類：負荷分散システムは、タスクのいくつかの重要な情報に基づいてハッシュ計算を実行し、同じハッシュ値の要求を同じサーバーに分散します。共通のソースアドレスハッシュ、ターゲットアドレスハッシュ、セッションIDハッシュ、ユーザーIDハッシュなど。
ポーリング
負荷分散システムがリクエストを受信すると、順番にサーバーに割り当てられます。ポーリングは、サーバー自体のステータスに注意を払うことなく、最も簡単な方法です。次に例を示します。
- 特定のサーバーは現在、プログラムのバグのために無限ループに入り、高いCPU負荷を引き起こします。負荷分散システムはそれを認識していないか、継続的に要求を送信し続けます
- 32コアの新しいマシンと16コアの古いマシンがあります。負荷分散システムは関係ありません。新しいマシンと古いマシンに割り当てられるタスクの数は同じです。
なお、負荷分散システムは「サーバー自体の状態」に注意を払う必要はありません。ここでのキーワードは「それ自体」です。つまり、サーバーが稼働している限り、稼働状況は関係ありませんが、サーバーが直接ロックされている場合、またはサーバーと負荷分散システムが切断されている場合、負荷分散システムはそれを認識しており、それに応じて処理する必要があります。 。たとえば、割り当て可能なサーバーのリストからサーバーを削除することは明らかに不合理です。そうしないと、サーバーはすべてロックマシンであり、タスクが継続的に割り当てられているように見えます。全体として、「単純」はポーリングアルゴリズムの利点と欠点です。
加重ポーリング
負荷分散システムは、サーバーの重みに基づいてタスクを割り当てます。ここでの重みは、通常、ハードウェア構成に基づいて静的に構成されます。動的計算はビジネスにより適していますが、複雑さも高くなります。加重ポーリングは特別な形式のポーリングであり、その主な目的は、さまざまなサーバー処理機能の問題を解決することです。たとえば、クラスターに32コアの新しいマシンと16コアの古いマシンがある場合、理論的には、新しいマシンの処理能力は古いマシンの2倍であり、負荷分散システムは2：1の比率に基づいていると想定できます。新しいマシンにさらにタスクを割り当てて、新しいマシンのパフォーマンスを最大限に活用します。
重み付けポーリングは、サーバー構成の違いに基づいてポーリングアルゴリズムがタスク割り当てを実行できないという問題を解決しますが、サーバーステータスの違いに基づいてタスク割り当てを実行できないという問題もあります。
最初に最低負荷
負荷分散システムは、現在の負荷が最も低いサーバーにタスクを割り当てます。ここでの負荷は、さまざまなタスクタイプやビジネスシナリオに応じて、さまざまなインジケーターで測定できます。例えば：
- LVSは4層のネットワーク負荷分散デバイスであり、サーバーのステータスを「接続数」で判断できます。サーバー接続の数が多いほど、サーバーのプレッシャーは高くなります
- 7層のネットワーク負荷システムであるNginxは、「HTTP要求の数」に基づいてサーバーのステータスを判断できます。CNginxに組み込まれている負荷分散アルゴリズムは、この方法をサポートしていないため、拡張する必要があります）
- 独自の負荷分散システムを開発する場合、ビジネス特性に基づいてシステム圧力を測定するための指標を選択できます。CPU集中型の場合、「CPU負荷」を使用してシステム圧力を測定できます。I/ O集中型の場合、「IIO負荷」を使用してシステム圧力を測定できます。
最小負荷優先アルゴリズムは、ポーリングアルゴリズムでサーバーの状態を認識できないという問題を解決しますが、そのコストは非常に複雑です。例えば：
- 最小接続数のアルゴリズムでは、最初に負荷分散システムが各サーバーによって現在確立されている接続をカウントする必要があります。そのアプリケーションシナリオは、負荷分散によって受信された接続要求に限定され、処理のためにサーバーに転送されます。それ以外の場合、負荷分散システムとサーバーが固定されている場合接続プール方式は、このアルゴリズムの採用には適していません。たとえば、LVSはこのアルゴリズムを負荷分散に採用できますが、接続プールを介してMySQLクラスタに接続する負荷分散システムは、このアルゴリズムを負荷分散に採用するのには適していません。
- 最も低いCPU負荷優先度のアルゴリズムでは、負荷分散システムが各サーバーのCPU負荷を何らかの方法で収集する必要があり、1分の負荷が標準であるか15分の負荷であるかを判断する必要があります。1分間がない場合は、確実に15を超えます。分は良いか悪いかです。ビジネスによって最適な時間間隔は異なります。時間間隔が短すぎると頻繁に変動し、長すぎるとピークが発生したときに応答が遅くなる可能性があります。
最低負荷優先度アルゴリズムは基本的にポーリングアルゴリズムの欠点を完全に解決できます。これは、このアルゴリズムを採用した後、負荷分散システムがサーバーの現在の実行ステータスを認識する必要があるためです。もちろん、価格は複雑さの大幅な増加です。簡単に言えば、ポーリングは5行のコードで実装できるアルゴリズムである可能性がありますが、最低負荷優先度アルゴリズムは実装に1,000行かかる可能性があり、負荷分散システムとサーバー用のコードの開発も必要です。最低負荷優先度アルゴリズム自体が適切に設計されていないか、ビジネスの運用特性に適していない場合、アルゴリズム自体がパフォーマンスのボトルネックになるか、多くの不可解な問題を引き起こす可能性があります。したがって、最低負荷優先度アルゴリズムの効果は非常によく見えますが、実際には、実際に使用されるポーリング（加重ポーリングを含む）シナリオはそれほど多くありません。
最高のパフォーマンスクラス
負荷が最も低い優先度アルゴリズムはサーバーの観点から割り当てられ、パフォーマンスが最も高い優先度アルゴリズムはクライアントの観点から割り当てられます。タスクは、最初に処理速度が最も速いサーバーに割り当てられます。クライアントへの最速の応答を実現する方法。
最低負荷の優先度アルゴリズムと同様に、最高のパフォーマンスの優先度アルゴリズムは基本的にサーバーのステータスを認識し、応答時間の外部標準を通じてのみサーバーのステータスを測定します。したがって、最適なパフォーマンス優先度アルゴリズムの問題は、最低の負荷優先度アルゴリズムの問題と同様であり、主に以下に反映されるように複雑さが高くなります。
- 負荷分散システムは、各サーバーの各タスクの応答時間を収集および分析する必要があります。多数のタスク処理シナリオでは、この収集と統計自体がより多くのパフォーマンスを消費します。
- この統計的消費を削減するために、統計はサンプリングによって取得できます。つまり、すべてのタスクの応答時間をカウントするのではなく、一部のタスクの応答時間をサンプリングして、全体的なタスクの応答時間を推定します。 、しかし、それは複雑さをさらに増大させます。適切なサンプリングレートを決定するために、サンプルレートが低すぎると不正確な結果につながり、サンプリングレートが高すぎるとパフォーマンスの消費が多くなり、適切なサンプルレートを見つけることも複雑な問題です。
- すべての統計またはサンプリング統計に関係なく、適切な期間を選択する必要があります。10秒で最高のパフォーマンス、1分で最高のパフォーマンス、または5分で最高のパフォーマンス...すべてに適合するサイクルはありません。実際の業務に基づいて判断・選択する必要があり、これも比較的煩雑なことであり、システムがオンラインになった後も継続的にチューニングを行い、最適な設計を行う必要があります。
ハッシュクラス
負荷分散システムは、タスクのいくつかの重要な情報に従ってハッシュ操作を実行し、同じハッシュ値を持つ要求を同じサーバーに割り当てます。これは、特定のビジネス要件を満たすことを目的としています。例えば：
- 送信元アドレスハッシュ
は、同じ送信元IPアドレスから発生したタスクを同じサーバーに割り当てて処理します。これは、トランザクションとセッションを持つビジネスに適しています。たとえば、ブラウザからオンラインバンキングにログインすると、セッション情報が生成されますが、このセッションは一時的なものであり、ブラウザを閉じると無効になります。オンラインバンキングのバックエンドでセッション情報を保持する必要はありません。特定のサーバーにセッションを一時的に保存するだけですが、ユーザーがセッションの存在中に毎回同じサーバーにアクセスできることを確認する必要があります。この種のビジネスシナリオを使用できます。達成する送信元アドレスハッシュ - IDハッシュは
、IDで識別されるサービスを同じサーバーに割り当てて処理します。ここでのIDは、通常、一時データのID（たとえば、セッションID）です。たとえば、上記のオンラインバンキングログインの例では、セッションIDハッシュも使用できます。同じセッション中に、ユーザーは毎回同じサーバーにアクセスします