分散 |知っておくべき負荷分散

[[378668]]

最近、友人がバックグラウンドでメッセージを残し、負荷分散に関する記事を書くように依頼しました。インターネットには実はたくさんの記事があって、そのたびに「いい記事だな」と思っても、しばらくすると何も思い出せなくなる、という話でした。そこで今日は、実際の事例を使って負荷分散についてお話します。少し長い部分もあるかと思いますが、皆様に分かりやすくお伝えできるよう、精一杯努力しました。皆さんにぜひ知識を習得してもらいたいです。

負荷分散とは何ですか?

ロードバランシング（英語名は Load Balance）とは、負荷（作業タスク）を均衡化し、FTP サーバー、Web サーバー、エンタープライズコアアプリケーションサーバー、その他の主要なタスクサーバーなどの複数の運用ユニットに分散して操作し、共同で作業タスクを完了することを意味します。

負荷分散には通常、負荷を均等に分散することと冗長性 (バックアップとも呼ばれる) を提供することの 2 つの目的があります。

ライフケース

上記がまだ理解できない場合は、実際の例を使って説明を続けましょう。

高速道路の出口に、出口が一つしかなく、ある日突然大量の車両（ETCを申請している人はいないと仮定）が現れて、例えばこの出口で高速道路を降りるとしたら、この時間に高速道路を降りなければならない人は何百人もいるのに、高速道路を降りるには通行料を払わなければならず、各車は少なくとも数分は遅れることになります。何百台もの車!!!つまり、後ろにいる人は数時間待たなければならない可能性があるということです。出口が複数ある場合はどうなりますか?そうすれば、そんなに長く待つ必要はありません。

出口をもう 1 つ追加すると、高速道路から出る車両の数を均等に分散する出口が 2 つになります。料金徴収員は料金徴収員の速度も判断する必要があります。車両 3 は車両 1 が速く走っているのを確認して、車両 1 に追いつきます。

n をさらに追加すると、その効果は想像できます。しかし、数が多すぎると、リソースの無駄遣いになるようです。多くの出口では、1 日に数台の車両しか出入りしません。多すぎると無駄になりませんか？そのため、ほとんどの人は 2 つ持っているのが普通ですが、これは緊急時のバックアップとして理解できます。

「私たちはドライバーを、前方の道路状況に基づいてどの出口を利用するかを決定するロードバランサーとみなしています。その決定を行う方法は、ロードバランシングアルゴリズムとして理解できます。」

私たちの技術分野で使用される用語は冗長性と呼ばれます。料金徴収機の速度は、当社のシステムにおけるサービスのパフォーマンスとして理解できます。

技術分野

次の図は、当社の技術分野における負荷分散を示しています。

生活の場面とテクノロジー分野の場面を組み合わせて理解すると、より新鮮になります。

注: クラスターとは、同じ App アプリケーション サービスに対して複数のノードを展開することを指します。クラスターの主な目的は圧力を分散することです。ロードバランサー（システム）は、司令官として理解できます。リクエストが届くと、コマンダーは特定の方法に従ってそのリクエストをクラスター内のサービスに渡します。その後、コマンダーはさまざまな方法でクラスター内のサービスにリクエストを割り当てることができます。ランダムに与える、キューイングで与える、より早く応答した人に与えるなどの方法により、負荷分散アルゴリズムが形成されます。

上記の比喩は、あくまでも私の個人的な理解です。

負荷分散の種類

ドメイン名

(ドメインネームシステム) ドメイン名と IP アドレスを相互にマッピングする分散データベースとして、人々がより便利にインターネットにアクセスできるようにします。 DNS は TCP および UDP ポート 53 を使用します。現在、ドメイン名の各レベルの長さ制限は 63 文字で、ドメイン名の合計長は 253 文字を超えることはできません。 DNS は最も単純かつ最も一般的な負荷分散方法であり、通常は「地理レベル」の負荷分散を実現するために使用されます。たとえば、北の人々は北京のコンピューター室を訪れ、南の人々は広州のコンピューター室を訪れ、西の人々は成都のコンピューター室を訪れます。 DNS ロード バランシングの本質は、同じドメイン名の DNS 解決で異なる IP アドレスが返される可能性があることです。たとえば、https://www.sina.com.cn/ を北部のユーザーが使用する場合、10.210.1.12 (北京データセンター) として解決され、南部のユーザーが使用する場合、14.213.164.27 (広州データセンター) として解決されます。

シンプルなDNS図

アドバンテージ

• シンプルな構成、コストなし
• 負荷分散タスクは DNS サーバーに引き継がれるため、管理の手間が省けます。

欠点

• レコードの追加や変更が有効になるまでには、一定の時間がかかります (DNS が A レコードをキャッシュするため)。サーバーが故障してオフラインにする必要がある場合、A レコードを変更しても、それが有効になるまでに長い時間がかかります。この期間中、DNS はドメイン名をオフライン サーバーに解決し続けるため、最終的にはユーザー アクセスが失敗します。
• 負荷は要求に応じて分散できません。 DNS は各サーバーの実際の負荷を認識しないため、負荷効果はあまり良くありません。

実際の状況: 実際のプロジェクト展開では、通常、一部のサーバーに対して DNS 解決を使用し、ドメイン名解決を負荷分散の最初のレベルとして使用します。次に、サーバーの負荷分散の第 2 レベルとして nginx 負荷分散を使用します。

ハードウェア負荷分散

ハードウェア負荷分散では、別のデバイスを使用して負荷分散機能を実現します。このタイプのデバイスはルータ スイッチに似ており、負荷分散のための基本的なネットワーク デバイスとして理解できます。現在、業界には F5 と A10 という 2 つの主要なハードウェア ロード バランサーがあります。このタイプの機器は性能が優れており、機能が強力ですが、価格は高価であると言えます。一般的に、銀行、国営企業、その他の大規模で裕福な企業のみが、会議にこのタイプの機器を使用することを検討します。 F5 は銀行でしか見たことがありません。 A10に関しては、接触していない限り撤回しません。

アドバンテージ

強力な機能: すべてのレベルでの負荷分散を完全にサポートし、さまざまな負荷分散アルゴリズムをサポートし、グローバル負荷分散をサポートします。

優れたパフォーマンス: 一般に、ソフトウェア ロード バランシングは 10w 以上の同時実行をサポートできますが、これはすでに非常に優れています。しかし、ハードウェア ロード バランシングは 100w 以上の同時実行をサポートできます。

高い安定性：市販品なので、十分に厳格にテストされ、大規模に使用されているため、非常に安定しています。

高いセキュリティ: 負荷分散に加えて、ハードウェア負荷分散デバイスにはファイアウォールと DDoS 攻撃対策機能も備わっています。

欠点

高価：ある銀行がF5を購入するのに数百万を費やしたと記憶しており、さらに高価なものもあると言われているので、価格が想像できます。

スケーラビリティが低い: ハードウェア デバイスはビジネスに応じて構成できますが、拡張またはカスタマイズすることはできません。

ソフトウェア負荷分散

ソフトウェア ロード バランシングは、ロード バランシング ソフトウェアを通じてロード バランシング機能を実装します。一般的な負荷分散ソフトウェアには、LVS や Nginx などがあります。 LVS は、Linux カーネルの 4 層負荷分散です。 4 層と 7 層の違いは、プロトコルと柔軟性の違いにあります。 Nginx は HTTP と電子メール プロトコルをサポートする 7 層の負荷分散ですが、LVS は 4 層の負荷分散であるため、プロトコルとは関係なく、基本的にチャット、データベースなど、すべてのアプリケーションで使用できます。

以下は、Nginx の負荷分散の簡単な図です。

アドバンテージ

• Nginx は C で書かれています。リソースとメモリの使用量が少なく、パフォーマンスの高い Web サーバーです。
• nginx サーバーが起動すると、マスター プロセスが生成されます。マスター プロセスは複数のワーカー プロセスをフォークし、ワーカー スレッドはクライアント要求を処理します。
• nginx は高い同時実行性をサポートします。各ワーカー サブプロセスは独立しており、同等です。クライアントからのリクエストがあると、ワーカー プロセスは公平に競合します。リクエストを取得したワーカー プロセスは、そのリクエストをバックエンド サーバーに送信します。バックエンド サーバーが時間内に応答しない場合、ワーカー プロセスは次の要求を受信し続けます。前のリクエストに応答があると、イベントがトリガーされます。ワーカー プロセスは、応答が終了するまで前の実行を継続します。 1 つのリクエストは 2 つのワーカー プロセスによって実行されることはありません。
• nginx はリバース プロキシ (YouTube へのアクセスなど、ユーザーが認識するアクセスはフォワード プロキシと呼ばれ、負荷分散など、ユーザーが認識しないアクセスはリバース プロキシと呼ばれます) をサポートし、7 層の負荷分散 (負荷分散の利点の拡張) をサポートします。
• Nginx は、epollandqueue モードを使用する非同期の非ブロッキング リクエスト処理方式 (3 番目のポイントで確認) ですが、Apache はブロッキング リクエスト処理方式です。
• Nginxは静的ファイルを高速に処理します（理由：
• Nginx は高度にモジュール化されており、設定が簡単です。
• nginx は複数のスレッドを持つ単一のプロセスです。

欠点

• Apacheと比較すると不安定です。これは単一プロセスのマルチスレッド プログラムであるため、プロセスの終了は多くのユーザーに影響を及ぼします。

負荷分散は何に使用されますか?

• 「トラフィック分散」負荷分散により、複数のホストにトラフィックを分散し、ユーザーシステムの業務処理能力を向上させ、サービスの可用性を向上させることができます。
• 「セッション永続性」セッション サイクル中、セッション永続性により、同じ IP またはネットワーク セグメントからのリクエストを同じバックエンド サーバーに分散できます。
• 「ヘルスチェック」は、カスタムヘルスチェックの方法と頻度をサポートし、バックエンドホストの実行状態を定期的にチェックし、フェイルオーバーを提供し、高可用性を実現します。
• 「負荷分散」は同時実行のプレッシャーを解決し、アプリケーション処理のパフォーマンスを向上させます（スループットを向上させ、ネットワーク処理機能を強化します）。
• ウェブサイトのスケーラビリティ（拡張性）を実現するためにサーバーの数を増やしたり減らしたりすることで、スケーラビリティを向上させます。
• ロード バランサーでフィルタリング、ブラックリストとホワイトリスト、リーチング防止処理を実行することで、セキュリティと保護を強化します。

一般的な負荷分散アルゴリズム

ローテーショントレーニング

負荷分散システムは、リクエストを受信すると、特定の順序でリクエストをサーバーに配布します。ラウンドロビンは、サーバーの状態を考慮しない単純な負荷分散アルゴリズム戦略です。

利点: すべてのサーバーが正常である場合、ラウンドロビン トレーニングは、各サービスが「均等に分散」されたと表現できる同量のリクエストを受信することを保証するため、理想的です。

デメリット：上記の点は理想的ですが、現実はそうではないことがよくあります。現実は依然として非常に厳しい。オンラインシステムにはさまざまな問題が発生することがよくあります。たとえば、サーバーがダウンした場合、ラウンドロビン アルゴリズムはサーバーの状態を考慮しないため、すでにハングアップしているサーバーに大量の要求が送信され、システムが使用できなくなり、ユーザーが失われることになります。もう 1 つのよくある問題は、一部のサーバーは応答が速く、一部のサーバーは応答が遅いことです (32 コアのサーバーと 16 コアのサーバーなど)。ラウンドロビン アルゴリズムは応答速度を考慮しないため、多くのサービス要求の応答が遅くなり、ユーザー エクスペリエンスが悪くなります。応答時間が遅いと、他のシステムにも影響が出る可能性があります。

加重ラウンドロビン

負荷分散システムは、サーバーの重みに基づいて、要求タスクを対応するサーバーにディスパッチします。ここでの重みは通常、システムのハードウェア構成に基づいて静的に構成されます。動的計算はビジネスに適していますが、単純なラウンドロビンよりも複雑性がはるかに高くなります。

加重ラウンドロビントレーニングは、ラウンドロビントレーニングの特別な形式です。その主な目的は、サーバーの処理能力の違いの問題を解決することです。たとえば、クラスター内の一部のサーバーには 32 個のコアがありますが、一部の古いシステムには 16 個のコアがあります。理論的には、重みを設定できます。つまり、32 コア サーバーの処理能力は 16 コア サーバーの 2 倍になります。負荷分散アルゴリズムの重み比は 2:1 に調整され、より多くのリクエストを 32 コア サーバーに分散できるようになります。

加重ラウンドロビンは、サーバー構成の違いに基づいてタスクがより適切に割り当てられるというラウンドロビン アルゴリズムの問​​題を解決します。しかし、サーバーの状態の違いに応じてリクエストタスクを割り当てることができないという問題が残っています。

最も負荷の少ないものから

負荷システムは、現在の負荷が最も低いサーバーにリクエストを分散します。ここでの負荷は、さまざまなリクエスト タイプとビジネス処理シナリオに応じて、さまざまな指標で測定できます。たとえば、次のシナリオ:

• 4 層ネットワーク負荷分散デバイスである LVS は、接続数に基づいてサーバーの状態を判断できます。サーバー接続の数が増えるほど、サーバーにかかる負荷が大きくなります。
• 7 層のネットワーク負荷分散システムである Nginx は、HTTP リクエストの数に基づいてサーバーの状態を判断できます (Nginx の組み込み負荷分散アルゴリズムはこの方法をサポートしていないため、自分で拡張する必要があります)。
• 負荷分散システムを自社で開発する場合、業務特性に応じてシステム負荷を測定する指標を選択できます。システムが CPU を集中的に使用する場合は、CPU 負荷を使用してシステムのストレスを測定できます。システムが IO を集中的に使用する場合は、IO 負荷を使用してシステムのストレスを測定できます。

最も低い負荷優先度のアルゴリズムは、ラウンドロビン アルゴリズムがサーバーの状態を認識できないという問題を解決しますが、次のような複雑さが大幅に増加するという代償があります。

• 最小数のリンクを優先するアルゴリズムでは、ロード システムが各サーバーの現在のリンクをカウントする必要があります。その適用シナリオは、ロード バランサによって受信されたすべての要求が処理のためにサーバーに転送されるということに限定されます。それ以外の場合、負荷分散システムとサービスに固定の接続プールがある場合、このアルゴリズムは適していません。 LVS は負荷分散にこのアルゴリズムを使用できますが、接続プールを介してデータベース MySQL クラスターに接続する負荷分散システムは、負荷分散にこのアルゴリズムを使用するのに適していません。
• CPU 負荷分散の最も優先度の低いアルゴリズムでは、負荷分散システムが何らかの方法で各サーバーの特定の CPU 負荷状況を収集し、同時に 1 分間の負荷標準、10 分間の負荷標準、または 15 分間の負荷標準のいずれに基づくかを決定する必要があります。 1 分が 15 分よりも確実に優れている、あるいは劣っているということはあり得ません。業務によって最適な時間間隔も異なります。時間間隔が短すぎると頻繁な変動が発生しやすくなり、長すぎるとピークが来たときに応答が遅くなる可能性があります。

最も低い負荷優先度のアルゴリズムは、ラウンドロビン アルゴリズムの欠点を完全に解決できます。ただし、最も低い負荷優先度のアルゴリズムを採用した後は、負荷分散システムがサーバーの現在の動作状態を感知する必要があり、これもコストの大幅な増加を引き起こします。開発者にとって、ラウンドロビン アルゴリズムを実装するには数行のコードしか必要ありませんが、最も低い負荷優先度のアルゴリズムを実装するには大量のコードが必要になります。

最も低い負荷優先度のアルゴリズムは、ラウンドロビン トレーニングの欠点を解決するようです。ただし、複雑さが増すため、実際の使用率はラウンドロビン トレーニングやラウンドロビン トレーニングの加重アルゴリズムよりもさらに低くなります。

最適なパフォーマンス

最も低い負荷優先度アルゴリズムはサーバーの観点からリクエストを割り当てますが、最も高いパフォーマンス アルゴリズムはクライアントの観点からリクエストを割り当て、処理速度が速いサーバーを優先します。このようにして、クライアントにとって最速の応答が実現されます。

パフォーマンス優先度は、実際には最小負荷優先度に似ています。どちらもサーバーの状態を認識する必要があります。違いは、応答時間標準を通じてサーバーの状態を外部から感知することで、最高のパフォーマンスが実現されることです。実装の複雑さも非常に高く、主に次の側面に反映されています。

• 負荷分散システムでは、各リクエストの応答時間を収集する必要があります。大量のリクエストが処理される場合、この収集と応答時間の統計自体がシステム パフォーマンスを消費します。
• この統計的消費を削減するために、統計にサンプリングを使用することができます。つまり、すべてのサーバーのすべてのリクエスト時間を完全にカウントする代わりに、一部のタスクの応答時間に関するサンプリング統計を使用して、リクエスト全体の応答時間を推定できます。サンプリング統計はパフォーマンスの消費を削減できますが、適切なサンプリング レートを決定する必要があるため、実装の複雑さが大幅に増加します。サンプリング レートが低すぎるとデータの精度に影響し、サンプリング レートが高すぎるとパフォーマンスの低下も引き起こします。適切なサンプリング レートを見つけることの複雑さも想像できます。
• すべての統計であっても、サンプリング統計であっても、適切な期間を選択する必要があります。 30秒と1分のどちらがベストでしょうか?現時点では標準的な期間は存在せず、具体的なビジネスシナリオに基づいて決定を行う必要があります。その複雑さを感じますか?特に、オンライン システムは、比較的適切な標準を見つけるために継続的にデバッグする必要があります。

ハッシュクラス

負荷分散システムは、リクエスト内の特定のキーワードに基づいてハッシュ操作を実行し、同じ値を同じサーバーに配布します。この主な目的は、次のような特定のビジネス ニーズを満たすことです。

• 送信元アドレス ハッシュ: 同じ IP アドレスからの要求を同じサーバーに割り当てて処理します。トランザクションやセッションのあるビジネスに適しています。たとえば、ブラウザ経由でオンラインバンキングにログインすると、セッション情報が生成されます。このセッションは一時的なものであり、ブラウザを閉じると無効になります。オンライン バンキングのバックエンドでは、セッション情報を保持する必要はありません。サーバー上でセッションを一時的に保持するだけで済みます。ただし、セッション中は、ユーザーがリクエストごとに同じサーバーにアクセスできることを確認する必要があります。このビジネス シナリオは、送信元アドレスのハッシュによって実現されます。
• ID ハッシュ: ユーザー ID セッション ID など、特定の ID で表されるビジネスを同じサーバーに割り当てて処理します。上記のオンライン バンキング ログインの例では、セッション ID ハッシュを使用して、ユーザーが同じセッション中に毎回同じサーバーにアクセスすることを保証できます。

負荷分散アルゴリズムの適用

Dubbo ではどのような負荷分散アルゴリズムが使用されていますか?

• ランダム ロードバランス (ランダム アルゴリズム、デフォルト)
• RoundRobin LoadBalance (重み付けラウンドロビンアルゴリズム)
• LeastAction LoadBalance (最もアクティブなコール数が少ないアルゴリズム)
• 一貫性ハッシュロードバランス

クラス図

nginx ではどのような負荷分散アルゴリズムが使用されていますか?

「ラウンドロビン (デフォルト)」: 各バックエンド サーバーに順番にリクエストを配布するポーリング方式。これはデフォルトの負荷分散方法です。バックエンド マシンのパフォーマンスが一貫している状況に適用できます。障害が発生したマシンはサービス リストから自動的に削除されます。

「重み」: 重みに基づいてリクエストを異なるマシンに分散し、ポーリング確率を指定します。重みはアクセス比率に比例し、バックエンド サーバーのパフォーマンスが不均一な場合に使用されます。例えば：

上流ベイクエンド{
サーバー 192.168.0.14 重み=10;
サーバー 192.168.0.15 重み=10;
 }

「IP_hash」: リクエスト元の IP アドレスのハッシュ値に基づいて、バックエンド サーバーにリクエストを送信します。これにより、同じ IP アドレスからのリクエストが固定のマシンに送信され、セッションの問題が解決されます。例えば：

上流ベイクエンド{
 ip_ハッシュ;
サーバー 192.168.0.14:88;
サーバー 192.168.0.15:80;
 }

「url_hash(サードパーティ)」: 要求された URL のハッシュ値に基づいて、リクエストを異なるマシンに分散します。バックエンド サーバーがキャッシュされている場合は、これがより効率的です。

たとえば、アップストリームにハッシュ ステートメントを追加する場合、重みなどの他のパラメーターをサーバー ステートメントに書き込むことはできず、使用されるハッシュ アルゴリズムは hash_method になります。

「公平 (サードパーティ)」: バックグラウンド応答時間に基づいてリクエストを分散し、応答時間が短いリクエストに多くのリクエストを分散します。例えば：

アップストリームバックエンド{
サーバー server1;
サーバー server2;
公平;
 }

要約する

私たちは実際のストーリーを使って、負荷分散とは何か、負荷分散の役割、負荷分散の種類、負荷分散アルゴリズムの種類、そして Dubbo と nginx での負荷分散アルゴリズムの適用について説明しました。

この記事はWeChat公開アカウント「Java Backend Technology Full Stack」から転載したものです。以下のQRコードからフォローできます。この記事を転載する場合は、Java Backend Technology Full Stack パブリック アカウントにお問い合わせください。