分散アーキテクチャにおける「負荷分散」について 1 つの記事で学ぶ

ウェブサイトの初期の頃は、集中的なサービスを提供するために一般的に 1 台のマシンを使用していましたが、ビジネス量が増加するにつれて、パフォーマンスと安定性の両方が困難になりました。この度、容量拡大により、より良いサービスの提供を検討してまいります。

[[228834]]

負荷分散とは

通常、外部サービスを提供するために複数のマシンをクラスターにグループ化します。ただし、当社のウェブサイトでは、www.taobao.com など、外部へのアクセス ポータルを 1 つだけ提供しています。

では、ユーザーがブラウザに www.taobao.com と入力すると、そのユーザーのリクエストはどのようにしてクラスター内の異なるマシンに分散されるのでしょうか?これが負荷分散の機能です。

現在のインターネット システムのほとんどは、複数のサーバーに同じサービスを展開して全体としてクラスターを形成し、外部にサービスを提供するサーバー クラスター テクノロジを使用しています。

これらのクラスターには、Web アプリケーション サーバー クラスター、データベース サーバー クラスター、分散キャッシュ サーバー クラスターなどがあります。

実際のアプリケーションでは、Web サーバー クラスターの前に常に負荷分散サーバーが存在します。負荷分散デバイスの役割は、Web サーバー トラフィックの入り口として機能し、最適な Web サーバーを選択し、クライアントの要求をそのサーバーに転送して処理し、クライアントから実際のサーバーへの透過的な転送を実現することです。

近年、非常に人気が高まっている「クラウドコンピューティング」や分散アーキテクチャは、本質的には、バックエンドサーバーをコンピューティングリソースやストレージリソースとして使用し、管理サーバーによってサービスとしてパッケージ化されて外部に提供されるというものです。

クライアントは、実際にどのマシンがサービスを提供するかを気にする必要はありません。その観点から見ると、ほぼ *** の機能を備えたサーバーに直面しているように見えますが、本質的には、実際にサービスを提供するのはバックエンド クラスターです。

ソフトウェア ロードが解決する 2 つの主要な問題は、誰を選択するかと転送であり、最も一般的なのは LVS (Linux Virtual Server) です。

一般的なインターネット アプリケーション トポロジは次のとおりです。

負荷分散分類

負荷分散は、複数のコンピューター (コンピューター クラスター)、ネットワーク接続、CPU、ディスク ドライブ、またはその他のリソース間で負荷を分散して、リソース使用率を最大化し、スループットを最大化し、応答時間を最小化し、過負荷を回避するために使用されるコンピューター ネットワーク テクノロジであることがわかっています。

さて、このコンピューター技術を実装する方法はたくさんあります。大まかに以下の種類に分けられますが、その中で最もよく使われるのは 4 層と 7 層の負荷分散です。

レイヤー2負荷分散

1. 負荷分散サーバーは引き続き外部に VIP (仮想 IP) を提供します。クラスター内の異なるマシンは同じ IP アドレスを使用しますが、マシンの MAC アドレスは異なります。
2. 負荷分散サーバーは要求を受信すると、メッセージのターゲット MAC アドレスを書き換えて要求をターゲット マシンに転送し、負荷分散を実現します。

レイヤー3負荷分散

• レイヤー 3 の負荷分散は、レイヤー 2 の負荷分散に似ています。負荷分散サーバーは引き続き外部に VIP (仮想 IP) を提供しますが、クラスター内の異なるマシンは異なる IP アドレスを使用します。
• 負荷分散サーバーは要求を受信すると、さまざまな負荷分散アルゴリズムに従って、IP 経由でさまざまな実サーバーに要求を転送します。

レイヤー4負荷分散

• レイヤー 4 負荷分散は、OSI モデルのトランスポート層で機能します。トランスポート層には、TCP/UDP プロトコルのみが存在します。これら 2 つのプロトコルには、送信元 IP とターゲット IP に加えて、送信元ポート番号と宛先ポート番号も含まれます。
• 4 層ロード バランシング サーバーは、クライアント要求を受信すると、データ パケットのアドレス情報 (IP + ポート番号) を変更してトラフィックをアプリケーション サーバーに転送します。

レイヤー7負荷分散

• 7 層の負荷分散は、OSI モデルのアプリケーション層で機能します。 http、radius、DNS など、アプリケーション層プロトコルは多数あります。
• 7 層の負荷はこれらのプロトコルに基づいて行うことができます。これらのアプリケーション層プロトコルには、多くの意味のあるコンテンツが含まれています。

たとえば、同じ Web サーバーに対して、IP とポートに基づく負荷分散に加えて、7 層の URL、ブラウザー カテゴリ、言語に基づいて負荷分散を実行するかどうかを決定することもできます。

一般的なアプリケーションの場合、Nginx で十分です。 Nginx はレイヤー 7 の負荷分散に使用できます。ただし、一部の大規模な Web サイトでは、DNS + 4 層負荷分散 + 7 層負荷分散を使用して、マルチレベルの負荷分散が一般的に実行されます。

一般的な負荷分散ツール

ハードウェア負荷分散は、優れた性能と包括的な機能を備えていますが、高価であり、一般的には富裕層企業による初期使用または長期使用に適しています。

そのため、ソフトウェア負荷分散はインターネット分野で広く使用されています。一般的に使用されるソフトウェア負荷分散ソフトウェアには、LVS、Nginx、HAProxy などがあります。LVS/Nginx/HAProxy は、最も広く使用されている 3 つの負荷分散ソフトウェアです。

LVS の

LVS (Linux Virtual Server) は、Zhang Wensong 博士が始めたフリー ソフトウェア プロジェクトです。

LVS テクノロジを使用する目的は、LVS と Linux オペレーティング システムによって提供される負荷分散テクノロジを通じて、高性能で可用性の高いサーバー クラスタを実装することです。

信頼性、拡張性、操作性に優れており、低コストで高品質なサービスパフォーマンスを実現します。 LVS は主にレイヤー 4 の負荷分散に使用されます。

LVSアーキテクチャ

LVS によって構築されるサーバー クラスター システムは、次の 3 つの部分で構成されます。

• フロントエンドの負荷分散レイヤー (Loader Balancer)。
• 中央のサーバー グループ レイヤーは、サーバー アレイによって表されます。
• 最上位層のデータ共有ストレージ層は、共有ストレージで表されます。

ユーザーにとって、すべてのアプリケーションは透過的であり、ユーザーは仮想サーバーによって提供される高性能なサービスのみを使用します。

LVS の各レベルの詳細な紹介:

ロード バランサ層:クラスタ システム全体のフロント エンドに位置し、1 つ以上のロード スケジューラ (Director Server) で構成されます。 LVS モジュールは Director Server にインストールされます。

Director の主な機能はルーターの機能と似ています。 LVS 機能を完了するために設定されたルーティング テーブルが含まれており、これらのルーティング テーブルを通じて、ユーザー要求をサーバー アレイ層のアプリケーション サーバー (実サーバー) に配布します。

同時に、リアル サーバー サービス監視モジュール Ldirectord をディレクター サーバーにインストールする必要があります。このモジュールは、各リアルサーバー サービスのヘルス状態を監視するために使用されます。実サーバーが使用できない場合は、LVS ルーティング テーブルから削除し、復元されたら再度追加します。

サーバー アレイ層:実際にアプリケーション サービスを実行するマシンのグループで構成されます。実サーバーは、Web サーバー、メール サーバー、FTP サーバー、DNS サーバー、ビデオ サーバーのうち 1 つ以上のサーバーになります。

各実サーバーは、高速 LAN または分散 WAN を介して接続されます。実際のアプリケーションでは、Director Server は実サーバーとしても機能します。

共有ストレージ層:すべてのリアルサーバーに共有ストレージスペースとコンテンツの一貫性を提供するストレージ領域です。通常、物理的にはディスク アレイ デバイスで構成されます。

コンテンツの一貫性を保つために、通常は NFS ネットワーク ファイル システムを介してデータを共有できますが、NFS のパフォーマンスは、処理量の多いビジネス システムではあまり良くありません。

このとき、Red Hat の GFS ファイル システム、Oracle の OCFS2 ファイル システムなどのクラスタ ファイル システムを使用できます。

LVS 全体の構造から、Director Server が LVS 全体の中核であることがわかります。現在、Director Server に使用できるオペレーティング システムは Linux と FreeBSD のみです。

Linux2.6 カーネルは設定なしで LVS 機能をサポートできますが、FreeBSD は Director Server として広く使用されていないため、パフォーマンスはあまり良くありません。

Real Server では、ほぼすべてのシステム プラットフォームが使用可能であり、Linux、Windows、Solaris、AIX、BSD シリーズはすべて十分にサポートされています。

エンギンクス

Nginx は、HTTP、HTTPS、SMTP、POP3、IMAP プロトコル リンクをリバース プロキシできる Web サーバーであり、ロード バランサーと HTTP キャッシュとしても機能します。 Nginx は主に 7 層の負荷分散に使用されます。

同時実行パフォーマンス:公式サポートは 1 秒あたり 50,000 同時接続ですが、実際の国内サポートは 1 秒あたり 20,000 同時接続が一般的です。 1 秒あたり 100,000 の同時接続に最適化できます。具体的なパフォーマンスは、アプリケーションのシナリオによって異なります。

特徴：

• モジュール設計:優れたスケーラビリティを備え、モジュールを通じて機能拡張を実行できます。
• 高い信頼性:マスター プロセスとワーカーは同期的に実装されます。 1 つのワーカーに問題が発生した場合、別のワーカーがすぐに起動されます。
• メモリ消費量が少ない: 10,000 のキープアライブ接続で消費されるメモリはわずか 2.5 MB です。
• ホット デプロイメントをサポート:サーバーを停止せずに、構成ファイルの更新、ログ ファイルの置き換え、サーバー プログラムのバージョンの更新を行います。
• 強力な同時実行機能:公式データによると、1 秒あたり 50,000 件の同時接続をサポートしています。
• 豊富な機能:優れたリバース プロキシ機能と柔軟な負荷分散戦略。

Nginx の基本的な動作モードは次のとおりです。

マスター プロセスは 1 つ以上のワーカー プロセスを生成します。ただし、ここでは、Nginx がポート 80 で動作する必要があるため、マスターはルート ID を使用して起動されます。

1023 未満のポートを起動する権限を持つのは管理者のみです。マスターの主な機能は、ワーカーを起動し、構成ファイルを読み込み、システムのスムーズなアップグレードを担当することです。残りの作業は労働者に引き継がれます。

ワーカーが起動されると、ワーカーは最も単純な Web タスクの一部のみを担当し、その他のタスクはワーカー内で呼び出されるモジュールによって実装されます。

モジュール間の機能はパイプライン方式で実装されます。パイプラインとは、複数のモジュールの機能を組み合わせて順番に実装されるユーザー要求を指します。

たとえば、最初のモジュールはリクエスト ヘッダーの分析のみを担当し、2 番目のモジュールはデータの検索のみを担当し、3 番目のモジュールはデータの圧縮のみを担当します。彼らは順番にそれぞれのタスクを完了し、タスク全体を完了します。

ホットデプロイメントをどのように実現するのでしょうか?先ほど、主人は特定の仕事に対して責任を負っているのではなく、労働者に仕事を依頼しているのだと言いました。構成ファイルの読み取りのみを担当します。

したがって、モジュールが変更されたり、構成ファイルが変更されたりすると、それはマスターによって読み取られ、ワーカーの作業には影響しません。

マスターは構成ファイルを読み取った後、変更された構成ファイルをワーカーにすぐに通知しません。

代わりに、変更されたワーカーは古い構成ファイルを使用して引き続き動作します。ワーカーが作業を終了すると、子プロセスは直接シャットダウンされ、新しいルールを使用する新しい子プロセスに置き換えられます。

HAプロキシ

HAProxy も広く使用されている負荷分散ソフトウェアです。 HAProxy は、TCP および HTTP アプリケーションに高可用性、負荷分散、プロキシを提供し、仮想ホストをサポートする、無料かつ高速で信頼性の高いソリューションです。

非常に負荷の高い Web サイトに特に適しています。ランタイム モードを使用すると、Web サーバーがインターネットに公開されるのを防ぎながら、現在のアーキテクチャに簡単かつ安全に統合できます。

HAProxy は、C で書かれた無料のオープンソース ソフトウェアであり、TCP および HTTP ベースのアプリケーションに高可用性、負荷分散、プロキシ機能を提供します。 HAProxy は主に 7 層の負荷分散に使用されます。

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

上記で負荷分散技術を紹介した際に、負荷分散サーバーは負荷分散アルゴリズムを使用して、どの実サーバーにリクエストを転送するかを決定すると説明しました。

負荷分散アルゴリズムは、次の 2 つのカテゴリに分けられます。

• ラウンドロビン、比率、優先度などの静的負荷分散アルゴリズム。
• 動的負荷分散アルゴリズムには、最小接続数、最速応答速度、観察方法、予測方法、動的パフォーマンス割り当て、動的サーバー補充、サービス品質、サービス タイプ、ルール モードが含まれます。

ラウンドロビン:順次ループでは、順次ループ内で各サーバーに 1 回接続するように要求します。サーバーがレイヤー 2 からレイヤー 7 で障害を起こすと、BIG-IP はそれを順次循環キューから取り出し、正常に戻るまで次のポーリングに参加しません。

ラウンドロビン方式で順番に異なるサーバーにスケジュールを要求します。実装時に、サーバーには通常重みが与えられますが、これには 2 つの利点があります。

1. サーバーのパフォーマンスの違いに応じて異なる負荷を割り当てることができます。

2. ノードを削除する必要がある場合は、その重みを 0 に設定するだけです。

• 利点:シンプルで効率的な実装。水平方向に簡単に拡張できます。
• デメリット:宛先ノードへの要求が不確実であるため、書き込みシナリオ (キャッシュ、データベース書き込み) には適していません。
• アプリケーション シナリオ:データベースまたはアプリケーション サービス レイヤーのシナリオのみを読み取ります。

ランダム方式:リクエストは各ノードにランダムに分散されます。データが十分に大きいシナリオでは、バランスの取れた分散を実現できます。

• 利点:実装が簡単で、水平方向の拡張が容易です。
• デメリット:ラウンドロビンと同様、書かれたシーンでは使用できません。
• アプリケーション シナリオ:データベースの負荷分散。これも読み取り専用シナリオです。

ハッシュ方式:キーに基づいて配置する必要があるノードを計算します。これにより、同じキーが同じサーバー上に配置されることが保証されます。

• 利点:同じキーが同じノードに存在する必要があるため、書き込みと読み取りの両方のキャッシュ シナリオで使用できます。
• デメリット:ノードに障害が発生すると、ハッシュ キーが再配布され、攻撃率が大幅に低下します。
• 解決策:一貫性のあるハッシュまたは keepalived を使用して、任意のノードの高可用性を確保し、障害発生後に他のノードが引き継ぎます。
• アプリケーション シナリオ:読み取りと書き込みの両方のキャッシュ。

一貫性のあるハッシュ:サーバー ノードに障害が発生した場合、このノードのキーのみが影響を受けるため、可能な限り最高の成功率が保証されます。

たとえば、twemproxy の ketama ソリューション。実稼働実装では、ローカルで類似した機能を持つキーを同じサーバーに配布できるように、サブキー ハッシュを指定することも計画できます。

• 利点:ノード障害後の普及率の低下は限定的です。
• アプリケーションシナリオ:キャッシュ。

キー範囲に基づく負荷:キー範囲に基づいて負荷がかかり、最初の 1 億個のキーは最初のサーバー上に保存され、1 億～ 2 億個のキーは 2 番目のノード上に格納されます。

• 利点:水平方向の拡張が容易。ストレージが不足している場合は、後続の新しいデータを保存するためのサーバーを追加します。
• デメリット:負荷が不均一。データベースの不均一な分散。 (データはホットとコールドに分けられます。一般的に、最近登録されたユーザーはよりアクティブであるため、後続のサーバーは非常にビジー状態になり、一方、初期のノードはアイドル状態になります。)
• 適用可能なシナリオ:データベース シャーディング ロード バランシング。

サーバー ノードの数をキーで割った値に基づいて負荷をかけます。サーバー ノードの数をキーで割った値に基づいて負荷をかけます。たとえば、サーバーが 4 台ある場合、キー モジュロ 0 は最初のノードに、キー モジュロ 1 は 2 番目のノードに該当します。

• 利点:データはホットとコールドの間で均等に分散され、データベース ノードに均等に負荷がかかります。
• デメリット：水平方向の拡張が難しい。
• 適用可能なシナリオ:データベース シャーディング ロード バランシング。

純粋な動的ノード負荷分散: CPU、IO、ネットワークの処理能力に基づいて、次のリクエストをスケジュールする方法を決定します。

• 利点:サーバー リソースを最大限に活用して、複数のノードで負荷処理のバランスを確保します。
• デメリット:実装が複雑で、実際にはほとんど使用されません。

アクティブな負荷分散は不要:メッセージ キューを使用して非同期モデルに切り替えることで、負荷分散の問題を解消します。ロード バランシングは、データを継続的に送信するプッシュ モデルです。

次に、すべてのユーザー要求がメッセージ キューに送信され、アイドル状態のすべての下流ノードが起動して、処理するデータを取得できるようになります。プル モデルに切り替えると、下流ノードの負荷の問題が解消されます。

• 利点:メッセージ キューをバッファリングすることで、バックエンド システムが保護され、リクエスト数が大幅に増加してもバックエンド サーバーが過負荷になることはありません。水平拡張が容易で、新しいノードを追加した後、キューに直接アクセスできます。
• デメリット:リアルタイムではない。

アプリケーション シナリオ:リアルタイムの戻りが要求されないシナリオ。たとえば、12036 が注文を行うと、プロンプト メッセージがすぐに返されます: 注文はキューに入れられました... 処理されると、非同期で通知されます。

比率:各サーバーに重み付けされた値を比率として割り当て、この比率に基づいてユーザー要求を各サーバーに分散します。

いずれかのサーバーでレイヤー 2 ～ 7 の障害が発生すると、BIG-IP はそれをサーバー キューから取り出し、正常に戻るまでユーザー要求の次の割り当てに参加しません。

優先度:すべてのサーバーがグループ化され、グループごとに優先度が定義されます。 BIG-IP ユーザー要求は、最も優先度の高いサーバー グループに割り当てられます (同じグループ内では、ユーザー要求はラウンドロビンまたは比率アルゴリズムを使用して割り当てられます)。

最も優先度の高いグループ内のすべてのサーバーに障害が発生した場合、BIG-IP は次に優先度の高いグループのサーバー グループに要求を送信します。この方法は、実際にユーザーにホット バックアップ メソッドを提供します。

最小接続:最も少ない接続数を処理するサーバーに新しい接続を渡します。

サーバーがレイヤー 2 ～ 7 で障害を起こすと、BIG-IP はサーバー キューからそのサーバーを削除し、サーバーが正常に戻るまで次のユーザー要求の配布に参加できないようにします。

最速モード:最も速く応答するサーバーに接続を渡します。サーバーがレイヤー 2 ～ 7 で障害を起こすと、BIG-IP はサーバー キューからそのサーバーを削除し、サーバーが正常に戻るまで次のユーザー要求の配布に参加できないようにします。

監視モード (Observed):接続数と応答時間のバランスを取り、新しいリクエスト用のサーバーを選択します。

サーバーがレイヤー 2 ～ 7 で障害を起こすと、BIG-IP はサーバー キューからそのサーバーを削除し、サーバーが正常に戻るまで次のユーザー要求の配布に参加できないようにします。

予測モード: BIG-IP は、収集されたサーバーの現在のパフォーマンス指標を使用して予測分析を実行し、次のタイムスライス (BIG-IP によって検出) でユーザー要求に対するサーバー応答のパフォーマンスが最適になるサーバーを選択します。

Dynamic Ratio-APM: BIG-IP によって収集されたアプリケーションおよびアプリケーション サーバーのさまざまなパフォーマンス パラメータに基づいて、トラフィックの分散を動的に調整します。

動的サーバー動作:障害によりクラスター内のプライマリ サーバーの数が減少すると、バックアップ サーバーがプライマリ サーバー クラスターに動的に追加されます。

サービス品質 (QoS):さまざまな優先順位に従ってデータ フローを割り当てます。

サービス タイプ (ToS):負荷分散は、さまざまなサービス タイプ (フィールドのタイプで識別) に応じてデータ フローを分散します。

ルール モード:さまざまなデータ フローのガイダンス ルールを設定し、ユーザーが自分で調整できます。

いくつかの負荷分散アルゴリズムのJava実装コード

1. 投票

2. 重み付けランダム負荷分散アルゴリズム

3. ランダム負荷分散アルゴリズム

4. 負荷分散ip_hashアルゴリズム

著者: 陳千平

紹介: ソフトウェア開発における 13 年の経験、新しいことに対する素早い学習、自発的な卓越性の追求、問題や変更に対する積極的な対応。 .NET、Java サーバー側開発、iOS、BI データベース開発に精通している。モバイルプラットフォームおよびインターネットプラットフォームの研究開発管理において長年の経験を持っています。