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

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

負荷分散とは何ですか?

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

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

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

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

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

これは CAP 定理であり、分散システムの基礎であり、分散システムの 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によるシャーディングによって

<<: IBM、AT&Tと複数年にわたる数十億ドル規模のクラウドコンピューティング契約を締結

>>: Kafka の設計原則を読んで忘れてしまい、もう一度読み返したことはありませんか?