分散システムにおける負荷分散

1. 負荷分散とは何ですか?

負荷分散とは何ですか?

私が初めて Nginx に触れたのは研究室だったことを覚えています。当時は、サーバーに Web サイトを展開するために Nginx が必要でした。 Nginx は、リバース プロキシ、負荷分散、HTTP キャッシュなどに使用されるサービス コンポーネントです。では、ここでの負荷分散とは何でしょうか?

負荷分散 (LB) は技術的なソリューションです。複数のリソース (通常はサーバー) 間で負荷を分散し、リソースの使用率を最大化して過負荷を回避するために使用されます。

リソースは、各サービス インスタンスの実行操作単位に相当します。負荷分散とは、大量のデータ処理操作を複数の操作ユニットに分散して実行することであり、インターネット分散システムの大量トラフィック、高同時実行性、高可用性の問題を解決するために使用されます。では、高可用性とは何でしょうか?

2. 高可用性とは何ですか?

まず、高可用性とは何でしょうか?

これは CAP 定理であり、分散システムの基礎であり、分散システムの 3 つの指標でもあります。

1. 一貫性
2. 可用性
3. パーティション耐性

では、高可用性とは何でしょうか?高可用性 (略して HA) は、システムの特性または指標であり、通常は、一定レベルのパフォーマンスを提供し、平均的な通常の期間よりも長いサービス実行時間を指します。逆に、システム サービスが利用できない時間を排除します。

システムが高可用性を満たしているかどうかの基準は、1 台以上のサーバーがダウンしても、システム全体とサービスが正常に利用可能であるかどうかです。

たとえば、有名な Web サイトの中には、4 9 以上の可用性を保証しているところもあります。これは、可用性が 99.99% 以上であることを意味します。この 0.01% が、いわゆる故障時間の割合です。例えば、電子商取引サイト「Youzan」の場合、サービスが利用できなくなると、商店主はお金とユーザーを失うことになります。すると、可用性が向上しながら、システムのダウンタイムやサービスの利用不可が補償されることになります。

たとえば、注文サービスの場合、単一の注文サービス インスタンスではなく、負荷分散を備えた複数の注文サービス インスタンスを使用できます。つまり、冗長性を使用して信頼性を向上させることができます。

つまり、負荷分散は、分散システム アーキテクチャの設計で考慮する必要がある要素の 1 つです。一般的に、分散システムにおける大量のトラフィック、高い同時実行性、高可用性の問題は、同じサービス インスタンスの負荷分散と冗長性によって解決されます。負荷分散の鍵は、分散が均等であるかどうかです。

3. 一般的な負荷分散のケース

シナリオ 1: マイクロサービス アーキテクチャでは、ゲートウェイは特定のサービス インスタンス hello にルーティングします。

• 2 つの同一のサービス インスタンス hello サービス。1 つはポート 8000、もう 1 つはポート 8082 にあります。
• Kong の負荷分散 LB 機能により、リクエストは 2 つの hello サービス インスタンスに均等に分散されます。
• Kong には、デフォルトの加重ラウンドロビン アルゴリズムや、ハッシュ アルゴリズムの入力値としてのコンシューマー: コンシューマー ID など、多くの負荷分散戦略があります。

シナリオ 2: マイクロサービス アーキテクチャでは、サービス A がサービス B のクラスターを呼び出します。リボン クライアント負荷分散コンポーネントを通じて次の処理が行われます。

• 負荷分散戦略アルゴリズムは高度なものではなく、単純なランダム選択とポーリングです。

4. インターネット分散システムソリューション

一般的なインターネット分散システム アーキテクチャは、一般的に次のように複数のレイヤーに分かれています。

• クライアント層: ユーザーブラウザ、APPエンドなど
• リバース プロキシ レイヤー: テクノロジーの選択 Nignx または F5 など
• Web層:フロントエンドとバックエンドを分離するシナリオでは、Web側はNodeJS、RN、Vueを使用できます。
• ビジネスサービス層: Java、Go、一般的なインターネット企業、技術ソリューションの選択はSCまたはSpring Boot + Dubboサービス
• データ保存層：DB選択型MySQL、キャッシュ選択型Redis、検索選択型ESなど。

リクエストは、レイヤー 1 からレイヤー 4 までのすべてのレイヤーで負荷分散する必要があります。つまり、各アップストリームが複数のダウンストリーム ビジネス パーティを呼び出す場合、呼び出しは均等に行う必要があります。このようにして、システム全体の負荷分散が強化されます。

レイヤー 1: クライアント レイヤー -> リバース プロキシ レイヤー ロード バランシング

クライアント層からリバース プロキシ層への負荷分散を実装するにはどうすればよいですか?

答えは、DNS ポーリングです。 DNS は、A (アドレス、ドメイン名が指す IP アドレスを返す) を通じて複数の IP アドレスを設定できます。たとえば、ここで bysocket.com にアクセスするための DNS は、ip1 と ip2 で構成されています。リバース プロキシ層の高可用性を確保するには、少なくとも 2 つの A レコードが必要です。このようにして、2 つの IP に対応する 2 つの冗長 nginx サービス インスタンスが単一障害点を防止します。

bysocket.com ドメイン名が要求されるたびに、DNS ポーリングを通じて対応する IP アドレスが返されます。各 IP は、リバース プロキシ層のサービス インスタンス (nginx の外部 IP) に対応します。これにより、各リバース プロキシ インスタンスがバランスの取れたリクエストの分散を受信できるようになります。

レイヤー2: リバースプロキシレイヤー -> Webレイヤーの負荷分散

リバース プロキシ層から Web 層への負荷分散を実装するにはどうすればよいですか?

これは、リバース プロキシ層の負荷分散モジュールによって処理されます。たとえば、nginx には複数のバランス調整方法があります。

1. ポーリングを要求します。リクエストは時系列順に 1 つずつ Web 層サービスに割り当てられ、このサイクルが繰り返されます。 Web レイヤー サービスがダウンしている場合は、自動的に削除されます。

アップストリームウェブサーバー {
 サーバー ip3;
 サーバー ip4;
 }

2.ipハッシュ。 IP のハッシュ値に応じて、対応する Web レイヤーへのルートを決定します。ユーザーの IP が均一である限り、Web 層へのリクエストも均一になります。

3. もう 1 つの利点は、同じ IP アドレスからのリクエストが同じ Web レイヤー サービスに分散されることです。この方法では、各ユーザーが固定の Web レイヤー サービスにアクセスし、セッションの問題を解決できます。

アップストリームウェブサーバー {
 ip_ハッシュ;
 サーバー ip3;
 サーバー ip4;
 }

4.weight、fair、url_hashなど

レイヤー3: Webレイヤーの負荷分散 -> ビジネスサービスレイヤー

Web レイヤーからビジネス サービス レイヤーへの負荷分散を実装するにはどうすればよいですか?

たとえば、Dubbo は、サービス登録、サービス低下、アクセス制御、ルーティング ルールの動的構成、重み調整、負荷分散を含むサービス ガバナンス ソリューションです。機能の 1 つはインテリジェントな負荷分散です。複数の負荷分散戦略が組み込まれており、下流ノードの正常性状態をインテリジェントに感知し、通話の遅延を大幅に短縮し、システムのスループットを向上させます。

単一障害点を回避し、サービスの水平拡張をサポートするために、通常、サービスは複数のインスタンス、つまり Dubbo クラスター展開で展開されます。複数のサービス インスタンスが 1 つのサービス プロバイダーに結合され、構成されたランダム ロード バランシング戦略に基づいて、20 個のプロバイダーのうち 1 つがランダムに選択されて呼び出されます。 7 番目のプロバイダーがランダムに選択されたとします。 LoadBalance コンポーネントは、バランス調整戦略を使用して、プロバイダー アドレス リストからプロバイダーを選択し、呼び出しを行います。通話が失敗した場合は、別のプロバイダーが通話に選択されます。

Dubbo には 4 つの負荷分散戦略が組み込まれています。

• RandomLoadBalance: ランダムな負荷分散。ランダムに1つ選択してください。これは Dubbo のデフォルトの負荷分散戦略です。
• RoundRobinLoadBalance: ラウンドロビン負荷分散。投票して 1 つを選択します。
• LeastActiveLoadBalance: アクティブ コールの最小数。アクティブ コールの数が同じ場合はランダム。アクティブ カウントとは、通話前と通話後のカウントの差を指します。プロバイダーが遅いほど、呼び出しの前後のカウントの差が大きくなるため、遅いプロバイダーが受信するリクエストの数が少なくなるようにします。
• ConsistentHashLoadBalance: 一貫性のあるハッシュ負荷分散。同じパラメータを持つリクエストは常に同じマシンに送信されます。

同様に、ビジネスニーズに応じて、独自の負荷分散戦略を実装することもできます。

レイヤー4: ビジネスサービスレイヤー -> データストレージレイヤーの負荷分散

データ ストレージ層での負荷分散は、通常、DBProxy を通じて実現されます。たとえば、MySQL シャーディング。

単一のデータベースまたはテーブルへのアクセスが多すぎてデータ量が多すぎる場合は、垂直分割と水平分割が必要になります。たとえば、水平方向のセグメンテーション ルールは次のようになります。

• 範囲、時間
• ハッシュ係数、店舗IDに基づく順序など。

ただし、この負荷によって次の問題が発生し、解決する必要があります。

• 分散トランザクション
• データベース間の結合など

シャーディングには、Dangdang Sharding-JDBC、Alibaba Cobar など、多くの製品ソリューションがあります。

V. 要約

外部の観点から見ると、負荷分散はシステムまたはソフトウェア全体です。内部の観点から見ると、アップストリーム呼び出しとダウンストリーム呼び出しのレイヤーが存在します。呼び出しがある限り、負荷分散を考慮する必要があります。したがって、負荷分散は、分散システム アーキテクチャの設計で考慮する必要がある要素の 1 つです。主な考慮事項は、ダウンストリームで受信したリクエストを均等に分散させる方法です。

• レイヤー 1: クライアント レイヤー -> リバース プロキシ レイヤーでの負荷分散。 DNSポーリングを通じて
• レイヤー 2: リバース プロキシ レイヤー -> Web レイヤーの負荷分散。 Nginxの負荷分散モジュールを通じて
• レイヤー 3: Web レイヤー -> ビジネス サービス レイヤーの負荷分散。サービスガバナンスフレームワークの負荷分散モジュールを通じて
• レイヤー 4: ビジネス サービス レイヤー -> データ ストレージ レイヤーの負荷分散。データを水平に分散することで、データが均等に分散され、理論的にはリクエストも均等に分散されます。たとえば、購入者IDによるシャーディングによって