分散アーキテクチャでは負荷分散はどのように機能しますか?

負荷分散とは何ですか?

ウェブサイトの初期の頃は、プラットフォームに集中サービスを提供するために 1 台のマシンを使用するのが一般的でしたが、ビジネス量が増加するにつれて、パフォーマンスと安定性の両方が課題になりました。この度、容量拡大により、より良いサービスの提供を検討してまいります。通常、外部サービスを提供するために複数のマシンをクラスターにグループ化します。ただし、当社のウェブサイトが外部に提供するアクセスポータルは、www.taobao.com などと同じです。では、ユーザーがブラウザに www.taobao.com と入力すると、そのユーザーのリクエストはどのようにしてクラスター内の異なるマシンに分散されるのでしょうか?これが負荷分散の機能です。

[[224446]]

現在、ほとんどのインターネットシステムでは、サーバークラスターテクノロジが使用されています。これは、複数のサーバーに同じサービスを展開して、全体としてクラスターを形成し、外部にサービスを提供することを意味します。これらのクラスターには、Web アプリケーションサーバークラスター、データベースサーバークラスター、分散キャッシュサーバークラスターなどがあります。

実際のアプリケーションでは、Web サーバークラスターの前に常に負荷分散サーバーが存在します。負荷分散デバイスの役割は、Web サーバートラフィックの入り口として機能し、最適な Web サーバーを選択し、クライアントの要求をそのサーバーに転送して処理し、クライアントから実際のサーバーへの透過的な転送を実現することです。近年非常に人気がある「クラウドコンピューティング」や分散アーキテクチャは、基本的にバックエンドサーバーをコンピューティングリソースやストレージリソースとして使用し、管理サーバーによってサービスとしてカプセル化されて外部に提供されます。クライアントは、実際にどのマシンがサービスを提供するかを気にする必要はありません。その観点から見ると、ほぼ *** 機能を備えたサーバーに直面しているように見えますが、本質的には、実際のサービスプロバイダーはバックエンドクラスターです。

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

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

負荷分散分類

負荷分散は、複数のコンピューター (コンピュータークラスター)、ネットワーク接続、CPU、ディスクドライブ、またはその他のリソース間で負荷を分散して、リソース使用率を最大化し、スループットを最大化し、応答時間を最小化し、過負荷を回避するために使用されるコンピューターネットワークテクノロジであることがわかっています。さて、このコンピューター技術を実装する方法はたくさんあります。大まかに以下のタイプに分けられますが、最も一般的に使用されるのは 4 層および 7 層の負荷分散です。

レイヤー2負荷分散

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

レイヤー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 層負荷分散を使用して、マルチレベルの負荷分散が一般的に実行されます。

一般的な負荷分散ツール

ハードウェア負荷分散は、優れた性能と包括的な機能を備えていますが、高価であり、一般的には富裕層企業による初期使用または長期使用に適しています。そのため、ソフトウェア負荷分散はインターネット分野で広く使用されています。一般的に使用されるソフトウェア負荷分散ソフトウェアには、Nginx、LVS、HaProxy などがあります。

Nginx/LVS/HAProxy は、最も広く使用されている 3 つの負荷分散ソフトウェアです。

1. レベルV

LVS (Linux Virtual Server) は、Zhang Wensong 博士が始めたフリーソフトウェアプロジェクトです。 LVS テクノロジを使用する目的は、LVS と Linux オペレーティングシステムによって提供される負荷分散テクノロジを通じて、優れた信頼性、スケーラビリティ、および操作性を備えた高性能で可用性の高いサーバークラスタを実装することです。これにより、低コストで最高のサービスパフォーマンスを実現します。

LVS は主にレイヤー 4 の負荷分散に使用されます。

LVSアーキテクチャ

LVS によって構築されるサーバークラスターシステムは、フロントエンドの負荷分散層 (Loader Balancer)、サーバーアレイで表される中間サーバーグループ層、および共有ストレージで表される最上位のデータ共有ストレージ層の 3 つの部分で構成されます。ユーザーにとって、すべてのアプリケーションは透過的であり、ユーザーは仮想サーバーによって提供される高性能なサービスのみを使用します。

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

ロードバランサ層: クラスタシステム全体のフロントエンドに位置し、1 つ以上のロードスケジューラ (Director Server) で構成されます。 LVS モジュールは Director Server にインストールされ、Director の主な機能はルーターの機能に似ています。 LVS 機能を実行するために設定されたルーティングテーブルが含まれており、これらのルーティングテーブルを通じて、ユーザー要求をサーバーアレイ層のアプリケーションサーバー (実サーバー) に配布します。同時に、リアルサーバーサービス監視モジュール Ldirectord をディレクターサーバーにインストールする必要があります。このモジュールは、各リアルサーバーサービスのヘルス状態を監視するために使用されます。実サーバーが使用できない場合は、LVS ルーティングテーブルから削除し、復元されたら再度追加します。

サーバーアレイ層: 実際にアプリケーションサービスを実行するマシンのグループで構成されます。実サーバーは、Web サーバー、メールサーバー、FTP サーバー、DNS サーバー、ビデオサーバーのうち 1 つ以上のサーバーになります。各リアルサーバーは、さまざまな場所に分散された高速 LAN または WAN を介して接続されます。実際のアプリケーションでは、Director Server は同時に Real 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 シリーズはすべて十分にサポートされています。

2. エングス

Nginx (エンジン x と同じ発音) は、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 番目のモジュールはデータの圧縮のみを担当し、それぞれのタスクを順番に完了します。作品全体を完成させる。

ホットデプロイメントをどのように実現するのでしょうか?それは正しい。先ほど、主人は特定の仕事に対して責任を負わず、労働者に仕事を依頼すると述べました。構成ファイルの読み取りのみを担当します。そのため、モジュールが変更されたり、設定ファイルが変更されたりすると、マスターによって読み取られるため、この時点ではワーカーの動作には影響しません。マスターは構成ファイルを読み取った後、変更された構成ファイルをワーカーにすぐに通知しません。代わりに、変更されたワーカーは古い構成ファイルを使用して動作を続けます。ワーカーが作業を終了すると、子プロセスは直接終了され、新しいルールを使用する新しい子プロセスに置き換えられます。

3. HAプロキシ

HAProxy も広く使用されている負荷分散ソフトウェアです。 HAProxy は、TCP および HTTP アプリケーションに基づく高可用性、負荷分散、プロキシを提供し、仮想ホストをサポートする、無料かつ高速で信頼性の高いソリューションです。特に負荷の高い Web サイトに適しています。ランタイムモードを使用すると、Web サーバーがインターネットに公開されるのを防ぎながら、現在のアーキテクチャに簡単かつ安全に統合できます。

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

Haproxy は主に 7 層の負荷分散に使用されます。

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

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

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

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

ラウンドロビン方式で、異なるサーバーに順番にスケジュールを要求します。実装時には、通常、サーバーに重みが与えられます。これには 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 はサーバーキューからそのサーバーを削除し、サーバーが正常に戻るまで次のユーザー要求の割り当てに参加できないようにします。

監視モード: 接続数と応答時間の最適なバランスに基づいて、新しい要求に対してサーバーが選択されます。サーバーの 2 番目から 7 番目の層で障害が発生すると、BIG-IP はサーバーキューからそのサーバーを取り出し、正常に戻るまでユーザー要求の次の割り当てに参加できないようにします。

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

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

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

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

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

ルールモード: ユーザーはさまざまなデータフローのガイダンスルールを設定できます。

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