ハイパフォーマンスなロードバランシング設計を理解していないのですか? アーキテクトはあなたを飛躍させます
ソフトウェア システムのアーキテクチャ設計において、クラスターの負荷分散設計は、高性能システムの最適化に不可欠なソリューションです。負荷分散は基本的にユーザー トラフィックのバランスを取り、圧縮を解除するために使用されるため、インターネット上の大規模なトラフィックのプロジェクトではその重要性は自明です。
1. 負荷分散とは何ですか?
初期のインターネット アプリケーションでは、ユーザー トラフィックが比較的少なく、ビジネス ロジックが比較的単純であるため、多くの場合、単一サーバーで負荷需要を満たすことができました。インターネットのトラフィックがますます増大するにつれて、少しでも優れたシステムへのアクセス数が非常に多くなり、システムの機能がますます複雑化しているため、単一のサーバーのパフォーマンスがどれほど最適化されていても、大量のトラフィックをサポートできないため、ユーザー数によるアクセス圧力が増加すると、複数のマシンを使用し、それに対応する高性能クラスターを設計する必要があります。
では、複数のサーバーがトラフィックのバランスをとり、高パフォーマンスのクラスターを形成するにはどうすればよいでしょうか?
このとき「ロードバランサー」を持ち出す必要があります。
ロードバランサとは、ユーザーのアクセストラフィックを一定の転送戦略に従って複数のバックエンドサーバーに均等に分散する「ロードバランサー」を指し、各バックエンドサーバーが独立してリクエストに応答・処理することで負荷を分散する効果を実現します。負荷分散テクノロジーは、システムのサービス機能を向上させ、アプリケーションの可用性を高めます。
（写真を見ればわかりますが、写真はインターネットからのものです）
2. 負荷分散ソリューションはいくつありますか?
現在市場には、主に 3 種類の負荷分散テクノロジー ソリューションがあります。
- DNS負荷分散に基づく
- ハードウェアベースの負荷分散
- ソフトウェアベースの負荷分散
3 つのソリューションには、それぞれ独自の長所と短所があります。DNS 負荷分散は、地域のトラフィック分散を実現できます。ハードウェア負荷分散は主に大規模なサーバー クラスタの負荷要件を満たすために使用されますが、ソフトウェア負荷分散は主にマシン レベルのトラフィック分散に基づいています。実際のシナリオでは、これら 3 種類を組み合わせて使用できます。それについて詳しく話しましょう:
DNS負荷分散に基づく
(ネットワーク図)
DNS に基づく負荷分散は、実際には最も簡単な実装ソリューションであり、DNS サーバー上で簡単な構成を行うだけで実現できます。
原則として、ユーザーがドメイン名にアクセスすると、まずそのドメイン名に対応する IP アドレスが DNS サーバーに解決されますが、このとき、DNS サーバーは地理的に異なる場所にいるユーザーに応じて異なる IP を返すことができます。例えば、南からのユーザーが来たら広州の業務サーバーのIPを返し、北からのユーザーが来たら北京の業務サーバーのIPを返します。
このモードでは、ユーザーは「近接原理」に従ってリクエストのオフロードを実現することと同等であり、単一クラスターの負荷圧力が軽減されるだけでなく、ユーザーのアクセス速度も向上します。
DNS を負荷分散ソリューションとして使用することの当然の利点は、構成が簡単で、実装コストが非常に低く、追加の開発作業やメンテナンス作業が必要ないことです。
ただし、明らかな欠点もあります。構成を変更しても、それが時間内に反映されないということです。これは DNS の特性によるもので、DNS は一般に多層キャッシュを備えているため、DNS 設定を変更すると、キャッシュのせいで IP 変更が適時に行われず、負荷分散効果に影響を及ぼします。
さらに、負荷分散に DNS を使用する場合、そのほとんどはリージョンに基づいているか、単純に IP ポーリングを直接実行しますが、これ以上高度なルーティング戦略がないため、これも DNS ソリューションの制限となります。
ハードウェアベースの負荷分散
(ネットワークの写真)
ハードウェアの負荷分散は、有名な F5 Network Big-IP など、非常に強力です。これは、私たちがよく F5 と呼ぶものです。これはネットワーク デバイスです。単純にネットワーク スイッチに似たものとして理解できます。完全にハードウェアによる圧力に耐え、そのパフォーマンスは非常に優れています。1 秒あたりに処理できるリクエストの数は数百万、つまり数百万/秒の負荷に達します。もちろん、価格も非常に高価です。数十万から数十万、1万元もあります。
なぜなら、このタイプの機器は一般に、大手インターネット企業のトラフィックポータルのフロントエンドで使用されており、政府、国有企業、その他資金に余裕のある企業によって使用されているからです。一般の中小企業は利用に消極的です。
F5 などのハードウェアを負荷分散に使用する場合、主な目的は心配と手間を省くためであり、1 つ購入するだけで完了します。強力なパフォーマンスを備えており、一般的な業務を処理できます。また、負荷分散アルゴリズムに関して多くの柔軟な戦略をサポートしており、ファイアウォールなどのセキュリティ機能も備えています。しかし欠点も明らかで、一言で言えば「高価」です。
ソフトウェアベースの負荷分散
(ネットワーク図)
ソフトウェア ロード バランシングとは、ソフトウェアを使用してトラフィックを分散し、バランスをとることを指します。ソフトウェア負荷分散は、レイヤー 7 プロトコルとレイヤー 4 プロトコルに分かれています。
ネットワーク プロトコルには 7 つの層があり、トラフィック分散のための第 4 層のトランスポート層に基づくソリューションは LVS などのレイヤー 4 ロード バランシングと呼ばれ、トラフィック分散のための第 7 層のアプリケーション層に基づくソリューションはレイヤー 7 ロード バランシングと呼ばれます。 Nginxなど。パフォーマンスと柔軟性の点で、この 2 つにはいくつかの違いがあります。
レイヤ 4 に基づくロード バランシングのパフォーマンスはより高く、通常は数十万/秒の処理能力に達しますが、レイヤ 7 に基づくロード バランシングの処理能力は通常、わずか数万/秒です。
ソフトウェアベースの負荷分散の特徴も明らかであり、安価です。通常のサーバーに導入でき、追加購入の必要がなく、少しの技術投資だけで最適化できるため、インターネット企業の間では最もよく使われている方法です。
3. 一般的に使用される等化アルゴリズムは何ですか?
一般的な負荷分散技術ソリューションについては上で説明しました。では、実際のソリューション アプリケーションで一般的に使用できる分散アルゴリズムを見てみましょう。
ポーリング戦略
ロード戦略
レスポンス戦略
ハッシュ戦略
これらのバランシング アルゴリズム/戦略の特徴を紹介しましょう。
ポーリング戦略
ポーリング戦略は非常にわかりやすく、ユーザーからのリクエストが来ると、「ロードバランサー」がそのリクエストをバックエンドの業務サーバーに順番に転送します。この戦略は DNS ソリューションでよく使用されます。バックエンド サービスのステータスに注意を払う必要はありません。リクエストがある限り、リクエストは順番にバックエンドに転送されます。非常にシンプルで、実用的。
実際のアプリケーションでは、シーケンシャル ポーリング、ランダム ポーリング、重みベースのポーリングなど、さまざまなポーリング方法があります。最初の 2 つは理解しやすく、3 番目は重みに応じてポーリングすることで、バックエンド サービスごとに重み値を設定することを意味します。このように設定すると、トラフィックを割り当てる際に、重みの高いトラフィックに多くのトラフィックを割り当てることで、バックエンド マシンのパフォーマンスを最大限に活用できます。
負荷ポリシー
負荷ポリシーとは、「ロード バランサー」がトラフィックをバックエンドに転送するときに、最初に各バックエンド サーバーの負荷圧力を評価し、より負荷の高いバックエンド サーバーにはより少ないリクエストを転送することを意味します。負荷が低いバックエンド サーバーの場合は、さらに多くのリクエストを転送できます。
この方法は、バックエンド サーバーの実行ステータスを完全に組み合わせてトラフィックを動的に割り当てるため、ポーリング方法よりも科学的です。
ただし、この方法には、バックエンド サーバーの負荷圧力を動的に評価する必要があるため、いくつかの欠点も生じます。この「ロード バランサー」は、リクエストの転送に加えて、リクエストの収集など、多くの追加作業も実行する必要があります。接続数やリクエスト数、CPU 負荷指標、IO 負荷指標などを計算して比較することで、どのバックエンド サーバーの負荷が大きいかを判断できます。
したがって、この方法は効果はあるものの、「ロードバランサ」の導入難易度や保守コストが増加してしまいます。
応答戦略
応答戦略とは、ユーザーがリクエストを行うと、「ロード バランサー」が現時点で最も速い応答を持つバックエンド サーバーにリクエストを優先的に転送することを意味します。
つまり、バックエンドサーバーの負荷が高くても低くても、どのような構成であっても、現時点でユーザーのリクエストに最も早く応答できると思われるサーバーであれば、そうすれば、リクエストは最初に転送され、ユーザーにとって最高のエクスペリエンスが得られます。
では、「ロードバランサー」は、現時点でどのバックエンドサービスが最も優れた応答能力を持っているかをどのようにして知るのでしょうか?
これには、「ロード バランサ」が各バックエンド サーバーのリクエストの処理速度を継続的に (たとえば、1 分に 1 回) カウントして、バックエンド サーバーの処理速度のランキングを生成する必要があります。次に、「ロード バランサー」は、このランキングに基づいてサービスを転送します。
ここで問題となるのが統計コストですが、これらの統計計算を常に行うとある程度のパフォーマンスを消費し、「ロードバランサ」の実装難易度や保守コストも増加します。
ハッシュ戦略
ハッシュ戦略も理解しやすいです。リクエスト内の特定の情報をハッシュし、バックエンド サーバーの数に応じた剰余を取得して値を取得します。同じ値を持つリクエストは、同じバックエンドサーバーです。
一般的な使用法は、このポリシーをユーザーの IP または ID に実装することで、「ロード バランサー」によって、同じ IP ソースまたは同じユーザーが常に同じバックエンド サーバーに送信されるようにすることができます。ハンドル キャッシュ。会話などの機能に特に役立ちます。
上記は、高パフォーマンスの負荷分散を実現するための一般的な技術ソリューションと戦略です。これらについて議論することは歓迎です。
元のリンク: https://blog.csdn.net/jsjwk/article/details/82466989