分散クラスタの負荷分散について - saliva

[[204999]]

1 分散クラスターとは何ですか?

分散クラスターの概念を理解するために、まず「クラスター」と「分散」という 2 つの概念について説明します。芸術は生命から生まれます。コンピュータサイエンスも同様です。まず、例を使って、現実の生活における「クラスター」と「分布」の概念を理解しましょう。

レストランを開店することから始めましょう。あなたはレストランを開店し、キッチンのシェフ（つまり、料理をする人）になります。ビジネスが拡大するにつれて、私は忙しすぎて対応できなくなってしまいました。そこで、シェフを 2 人雇い、3 人のシェフで「クラスター」を形成します。主な仕事は、野菜を洗うこと、おかずを準備すること、調理することです。あなたの関係は次のとおりです:

ビジネスが改善し続けるにつれて、キッチンの生産性を高める方法は2つあります。(1) シェフを追加し続けること。これはクラスターの拡大に相当します。 （２）分業体制を整備するために組立ラインの仕組みを導入する。野菜を洗ったり、おかずを準備したりといったシェフの仕事を分担してくれる人を探します。下の写真のような感じです。

実際、組立ラインは分割統治の考え方を体現しています。つまり、大きなタスクを複数の小さなタスクに分割し、小さなタスクの生産性を向上させて、全体の生産性を向上させるということです。 「分散型」問題解決の考え方は、大きなタスクを複数の小さなタスクに分割し、地域間の分散を通じて大きな問題を解決できるようにすることです。

問題解決の観点から、分散とクラスタリングとの違いについて説明します。

• 分散コンピューティングは、単一のタスクの実行時間を短縮することで効率を向上させます。
• クラスタリングにより、単位時間あたりに実行されるタスクの数が増え、効率が向上します。

ソフトウェアの展開の観点から、分散とクラスタリングの関係について説明します。

• 分散型とは、さまざまな事業がさまざまな場所に分散していることを意味します。
• クラスターは、複数のサーバーをまとめて同じビジネスを実装します。
• ディストリビューション内のすべてのノードはクラスター化できます。
• クラスターは必ずしも分散されるわけではありません。

まとめると、理想的な分散クラスターは次のようになります。分散システムは複数のノードで構成され、各ノードはクラスター化され、各クラスターも分散されます。

2 負荷分散とは何ですか?

サーバーの処理能力は、主にサーバー自体のスケーラブルなハードウェア機能によって制限されます。したがって、大量のユーザー要求を処理する必要がある場合、通常、ロードバランサーが導入され、複数の通常のサーバーをシステムに結合して、高同時要求処理タスクを完了します。

負荷分散といえば何を思い浮かべますか? DNS、LVS、nginx、HAProxy、リバースプロキシ、それとも有名なF5でしょうか?以下は、これらの負荷分散テクノロジの分類と概要です。

実際、上で説明したソリューションは通常、インターネット Web アクセス ソリューションの負荷分散です。 Web サービス方式は、シンプルで覚えやすいドメイン名を通じて、内部ネットワークの実際のサービスの IP アドレスを保護し、内部サーバーのセキュリティと信頼性を確保するというものです。このサービス モードに基づいて、サービス プロバイダーは次の 2 つの場所で負荷分散を実行できます。

1. DNS 解決 (クエリ タイプ): ドメイン ネーム サーバーがドメイン名からサービス IP への逆解決を実行すると、ユーザーのネットワーク アクセス特性 (テレコム、ネットコムなど) に基づいて、最も近いサービス IP リストがユーザーに返されます。

Tencent GSLB はこの分野のリーダーです。興味があれば、自分で調べてみてください。

2. 転送タイプは、上記の DNS 近隣アクセスの後、ユーザーが最も近いサービスの IP を要求した場合です。通常の方法は、転送ノード (通常は lvs または nginx) を導入し、バランス戦略を通じて複数の RS (実サーバー) にデータを送信することです。

Web ロードバランシングの技術を紹介した後、こんな疑問はありませんか?分散システム内のノード間のクラスターはどのようにして負荷分散を実行するのでしょうか?分散ノード間で Web 負荷分散を適用できますか?等々。

実際、さまざまなシナリオで問題を解決するために、さまざまなテクノロジが使用されます。次の図は、一般的に使用される負荷分散の使用シナリオを示しています。

上の図では、さまざまなシナリオでの負荷分散を示すために 3 つの色 (アイコンと線を含む) が使用されています。

• 青い部分: ユーザーは DNS クエリを通じて最も近いアクセス サービス (GSLB) を取得します。
• 緑色の部分: ユーザー要求を集中的に転送する方法により、ビジネス アクセス レイヤーの負荷分散が完了します。 （LVS）
• 赤い部分: 一般的な分散システムにおけるノード間の負荷分散を示しています。

このうち、青い部分と緑の部分が上で紹介した Web 負荷分散部分です。次の章では、分散ノード間の負荷分散を考慮する方法の分析に焦点を当てます。

3 分散クラスタの負荷分散

分散ノード間でクラスターの負荷を分散する場合は、Web 負荷分散方式、つまりクエリと転送を参照できます。しかし、通常バックエンドを開発するPipixia開発者は、基本的にこれを行いません。根本的な理由は、シナリオが異なれば考慮の焦点が異なり、バランスをとる方法に大きな違いが生じるからです。

まず、Web サービスの 2 つの基礎であるシンプルさとセキュリティについて説明します。

• シンプルさ: ドメイン名ウェブサービスを使用すると、ユーザーは IP アドレスの代わりにシンプルで覚えやすいドメイン名を通じてサービスにアクセスできることになります。そのため、「シンプルさ」はユーザーの要求であると言えます。
• セキュリティ: 「セキュリティ」はサービスプロバイダーの要求です。つまり、外部にサービスを提供する際に、内部サーバーの IP アドレスとネットワーク展開を可能な限り遮蔽し、内部サービスのセキュリティを確保します。

上記 2 点を考慮すると、Web サービスを提供する際には、対応するノード サポートを展開する必要があります。 DNS 解決、LVS 転送、ngnix リバース プロキシなど。これらのノードは、サービスのシンプルさとセキュリティを確保する一方で、システム サービスへのクリティカル パスも導入し、システム サービスの複雑さを増大させます。

考えてみてください。分散システム間の負荷分散の問題を解決するために、これほど多くのノードを導入する必要があるのでしょうか?

シャコの答えは「必要ない」でしょう☺。より多くのノードを導入すると、システムの安定性と信頼性を確保することがより困難になります。なぜそんなことを言うのですか？

まず、集中型システムと比較して、分散型システムはノード間でメッセージを渡すことによって作業を調整します。分散システムでは、ノード間の通信の信頼性の低さと不安定さが当たり前です。つまり、システムを設計および開発する際には、通信例外ごとに独自の再試行および回復ソリューションを用意する必要があります。したがって、より多くのノードを導入すると、再試行、災害復旧、その他のコストが複雑になります。

友人の皆さん、自分の使命を達成する前に死ぬような気持ちになったことはありませんか?何てことだ。負荷分散はまだ考慮されていません。分散システム間の安定性と信頼性だけでもすでに頭痛の種ですよね？だから、分配されたシャコは惨めで、寂しく、そして気高いのです。 （あなたの周りのシャコたちをみんな大切にしてください☺）

バカなこと言うなよ、エビ野郎。 Da Sima が質問しました。

Da Sima: 敵のジャングラーが小さなマップの視野内にいない場合、分散システムの負荷分散はどのように実装すればよいでしょうか?

Da Sima の「スクエア ジャングル」、「エッジ OB」、「好きなだけいたずらしてもいい」という言葉を学んだ後、私はこの問題を次のように捉えています。

私: より少ないノードと、よりシンプルで信頼性の高い通信モードによってのみ、負荷分散をより適切に実現できます。

Da Sima: 私のクラスメイト、君はとてもスピリチュアルな人だね。 (ジョークが分からない場合は太字の部分を読んでください☺)

負荷分散をうまく行うにはどうすればよいでしょうか?上記の段落を一文でまとめると、「シンプルは美しい」となります。 （聞いていると耳にタコができてしまいます）。

• ノード数の削減: 分散ビジネス ノードの数は、ビジネス自体の特性に基づいて決定する必要があります。原則は、「少ないが十分」です。
• シンプルで信頼性の高い通信モード: UDP 要求の送信 + UDP サービスの確認というシンプルな通信方法です。このモードでは、TCP リンク管理によって発生するサーバー リソースの消費を削減できます。

独自のシステムがまだ非常に複雑な場合は、実際に追跡すべき痕跡があります。負荷分散を検討する際に考慮すべき重要なポイントを整理してみましょう。誰もが自分のビジネスの特性に基づいてもっとよく考え、選択をすれば、最終的には良好な負荷分散結果が得られるでしょう。

もうひとつ重要な点を強調させてください。まず、システム内のバランスの重要なポイントが何であるかを把握する必要があります。ここでは、リクエスト残高とデータ残高（上記画像の右下隅）について説明します。

リクエスト分散の理想的な効果は、各 RS サービスによって処理されるリクエストが類似していることです。

データ バランシングの理想的な効果は、各 RS サービスによって処理/保存されるデータの量が同程度になることです。

同社には、l5/cmlb (ご自身でご確認ください) などの非常に優れたバランシング アルゴリズム コンポーネントもあり、UDP 要求のバランシングをより適切にサポートできます。このコンポーネントを使用する場合、いくつかの制限があります。お使いのシステムに適しているかどうかを確認してください。

最後に、負荷分散の本質を確認しましょう。負荷分散のためにバランスを取らないでください:

• 機能: 単一サーバーの容量には制限があります。多数のユーザー要求を処理する場合、高同時要求処理を完了するためのシステムを形成するために複数のサーバーが必要になります。
• 説明: N 個のクライアントが M 個のサーバーにアクセスする問題。 (通常: M>1、N>>M)
• 難易度: N 個のリクエスト/データを複数の M 個の操作ユニットに均等に分散して実行します。重要なのは均一性です。

クラスメイトたち、授業は終わったから出て行ってください！

オリジナルリンク: https://cloud.tencent.com/community/article/999792

著者: ユー・ヤン

[この記事は、51CTOコラムニスト「Tencent Cloud Technology Community」によるオリジナル記事です。転載の許可を得るには、51CTOを通じて原著者に連絡してください。

この著者の他の記事を読むにはここをクリックしてください