クラウドコンピューティングで企業が直面する3種類の負荷分散

負荷分散は、グローバル インターネットとほぼ同時に登場しました。ネットワーク層から TCP および HTTP までの着信パケット、接続、および要求は通常、アプリケーションのパフォーマンスと可用性を確保するためにリソース全体に分散されます。

これらの違いは些細なことのように思えるかもしれませんが、企業が実現できる展開モデルの種類に直接影響するため、実際には非常に重要です。結局のところ、企業が HTTP を可視化できなければ、URI やコンテンツ タイプに依存するより高度なパターンを採用することはできません。

[[226642]]

すべての負荷分散では、パケット/要求を転送する場所を決定する必要があり、ここでネットワーク、接続、およびアプリケーションの負荷分散の区別が重要になります。それぞれは、企業が特定のタイプの展開モデルを実装する上で役立つか妨げになる可能性のある特性に基づいて決定を下します。

適切なネットワーク負荷分散は、ネットワーク層の情報に依存します。送信元と宛先の IP と TCP ポート (場合によっては) が決定の基準となります。

ネットワーク負荷分散サービスは、要求を受信すると、通常、送信元と宛先の IP アドレス (および TCP ポート) をハッシュし、ターゲット リソースを選択します。このリクエストはリソースに送信されます。

ネットワーク負荷分散は、すべての負荷分散アルゴリズムの中で最も高速な意思決定が可能という利点がありますが、トラフィックを分散できないという欠点もあります。つまり、ネットワーク負荷分散 (NLB) は、リソース間でトラフィックを分散することよりも、トラフィックのルーティングに重点を置いています。試行は行われますが、「スーパーエージェント」の問題により失敗する場合もあります。

スーパー プロキシ問題は、大量のトラフィックが同じ範囲のネットワーク アドレスから発生した場合に発生します。これにより、ハッシュ変数間の差別化が不十分で複数のリソースに分散されないため、すべてのトラフィックが同じリソースに送信されます。知識豊富な開発者は、これが衝突であり、ハッシュベースのアルゴリズムでよく見られる問題であることを認識します。ターゲット リソースの負荷によってパフォーマンスが影響を受けるため、競合の問題が悪化します。負荷が増加すると（どのシステムでも）、パフォーマンスが低下します。

したがって、企業がこの消費を利用しようとする場合、配布が不十分になり、パフォーマンスが低下する可能性があります。これは、ほとんどの企業トラフィックが同じ範囲の IP アドレスから発生するためです。しかし、消費者にとってこれは問題ではないはずです。

また、URI や Cookie などの HTTP ベースの変数を考慮できないため、アプリケーション (または API) のバージョンに基づいてトラフィックを誘導したり、複数のサービス間で API トラフィックをセグメント化したりすることもできません。

プレーン オールド ロード バランシング (POLB) は、企業に馴染みのある実際のロード バランシング アルゴリズムが機能する、ロード バランシングの元の形式です。ラウンドロビン、最小接続、最速応答はすべて、現在でも使用されている大規模なアルゴリズムです。

POLB はプロトコルベースであり、UDP (ストリーミング用) と TCP (接続指向) をサポートします。その決定は選択されたアルゴリズムに基づいて行われ、それ以上のものではありません。

プレーン オールド ロード バランシング (POLB) は、要求を受信し、アルゴリズムに基づいてリソース プール (サーバー ファームまたはクラスターと呼ばれることもあります) からリソースを選択します。その後、リクエストを転送して終了します。

このタイプの負荷分散の利点は、比較的高速であり、さまざまなアルゴリズム オプションから選択できることです。パフォーマンスが重要な場合は、「最速応答」を選択します。ビジネスを迅速かつ簡単に拡張したい場合は、ラウンドロビンを選択してください。

従来の単純な負荷分散 (POLB) の欠点は、決定が Cookie や URI などの HTTP ヘッダー内の何かに基づいている場合にのみ、デプロイメント パターンを実装できることです。負荷分散サービスに応じて、時間やカウンターなどの変数を使用して選択するリソースを決定する A/B テストなどのパターンを実装できます。 HTTP ロード バランシングを使用するほど簡単ではありませんが、同じ結果を得ることができます。

プレーン オールド ロード バランシング (POLB) は、構成に応じて透過的または不透明になります。ネットワーク負荷分散 (NLB) を使用すると、組織は、アプリケーションが受信するクライアント (ユーザーとデバイス) の IP アドレスがクライアントの実際の IP アドレスであることを確信できます。 POLB の一部の構成では、企業のアプリケーションが受信する IP アドレスは、実際には負荷分散サービスを提供するプロキシの IP アドレスになります。つまり、そのアプリケーションでは、実際のクライアント IP アドレスを探し出すために、より多くの作業が必要になります。したがって、組織がこの情報を必要とする場合、それを見つけるために HTTP ヘッダー内を調べる必要がある可能性があることを知っておく必要があります。

HTTP ロード バランシングには HTTP リクエストが必要であり、ほとんどの場合、実際には 2 つの異なる決定が行われます。1 つ目は HTTP 変数に基づき、2 つ目はアルゴリズムに基づきます。

正確に言うと、HTTP ロード バランシングは、ルーティングと転送の組み合わせです。つまり、最初にリクエストをルーティングし、次にアルゴリズムによるリソースの選択に基づいてリクエストを転送します。ここで、カナリアやブルー/グリーン デプロイメントなどのデプロイメント モードや、より強力な A/B テストが登場します。

このタイプの負荷分散の問題は、方程式に遅延が追加されることです。 HTTP リクエストが深くなるほど、遅延が大きくなります。一部のロード バランサーには、この問題を修正するために、HTTP ヘッダーのみに基づいて負荷分散を可能にする「高速」モードがありますが、HTTP ペイロードの奥深くに埋め込まれた POST 変数に基づいて決定を下そうとすると、決定に時間がかかることに注意してください。

従来の単純な負荷分散 (POLB) に共通するもう 1 つの問題は、透明性です。組織はリクエストごとにクライアントの実際の IP アドレスを受け取る場合と受け取らない場合があるので、その情報がアプリケーションで必要かどうかを必ず確認してください。

アプリケーション アーキテクチャと、規模と速度に関する特定の目標に合わせてロード バランサーを選択します。間違った負荷分散とアルゴリズムを選択すると、組織がこれらの目標を達成する能力に大きな影響を与える可能性があります。