負荷分散アプリと API: アルゴリズムとアーキテクチャ

ほとんどの場合、アプリと API のスケーリングはほぼ同じことです。 どちらも何らかのロード バランサ (通常はプロキシ) を必要とし、リソース プール全体にリクエストを分散する必要があります。

しかし、これらのリクエストがリソース間でどのように分散されるかには、かなり大きな違いがあります。 アルゴリズムの場合は実際に負荷を分散しますが、アーキテクチャの場合は負荷を管理します。 さて、それは学問の世界に任せておくのが最善の、衒学的区別のように思えるかもしれません。 実際のところ、アルゴリズムとアーキテクチャの選択は、規模とパフォーマンスに大きな影響を与えます。 どちらも負荷分散を使用する理由の一種であるため、その区別は重要になります。

昔ながらの負荷分散

アルゴリズムベースの負荷分散は、単に負荷分散とも呼ばれ、私が好んで呼ぶように、 Plain Old Load Balancing とも呼ばれます。 これは、世紀の変わり目以前から使用されてきた尺度の方法です。 古くなったからといって、放棄すべきというわけではありません。むしろその逆です。 多くの場合、スケールとパフォーマンスのバランスをとるには、従来の単純な負荷分散が最適な選択肢です。

昔ながらの単純なアルゴリズムによる負荷分散では、ご想像のとおり、意思決定プロセスでアルゴリズムが使用されます。 つまり、ラウンドロビン、最小接続、最速応答、およびそれらの重み付けされた同等物などの分散アルゴリズムを使用して、特定の要求に応答するリソースが選択されます。

これは率直な決断です。 ハチドリと同様に、アルゴリズムは利用可能なデータに基づいて実行すること以外は何も気にしません。 利用可能なリソースが 5 つある場合、アルゴリズムに基づいてその 5 つのうちの 1 つが選択されます。 期間。

アルゴリズムベースの負荷分散は、ご想像のとおり、非常に高速です。 今日の処理能力を使用すれば、適切なアルゴリズムを実行して決定を下すのにそれほど時間はかかりません。 ラウンドロビンと特定の加重分散アルゴリズムを除き、アルゴリズムはステートフルです。 つまり、「現在、リソース A、B、C への接続はいくつありますか?」や「最後のリクエストに最も速く応答したリソースはどれですか?」などの変数を追跡する必要があります。 ロードバランサーはこの情報を追跡する必要があります。 この情報は非常に大きくなる可能性があり、複数の長時間の接続を必要とする従来のモノリシックapplicationsを拡張する環境では、管理するためにより多くのリソースが必要になります。

従来の単純な負荷分散が優れているのは、マイクロサービスのスケーリングです。 これは、各マイクロサービスが 1 つの機能を持っている (または理想的なアーキテクチャでは持っている必要がある) ためです。 これらのサービスは、一般的に容量とパフォーマンスが同等であるため、基本的なアルゴリズム (通常はラウンドロビン) を使用することで簡単にスケーリングできます。 マイクロサービス アーキテクチャの性質上、単一のユーザー要求を満たすために複数のサービス呼び出しが必要になる場合があり、迅速な意思決定が必須となります。 そのため、このような環境では、基本的なアルゴリズム ベースの負荷分散が適切な選択肢となります。

基本的な経験則は次のとおりです。限られた機能セットを持つ単純なサービスをスケーリングする場合、パフォーマンスの点ではすべてが一般的に同等であるため、従来の単純な負荷分散で十分です。 これはコンテナ環境内で見られるもので、ネイティブ スケーリング機能の多くが単純なアルゴリズムに基づいている理由です。  

その他のapplicationsや状況では、アーキテクチャベースの負荷分散を検討する必要があります。

HTTP 負荷分散

アーキテクチャベースの負荷分散は、ロードバランサーを使用して、スケーリングするapplicationのアーキテクチャに一致する方法でリクエストを細分化する技術 (はい、科学ではなく技術です) です。 アーキテクチャベースの負荷分散は、トラフィックを分散することよりも、トラフィックを誘導することに重点が置かれます。 これは、レイヤー 7 (通常は HTTP) を利用して、特定のリクエストをどこに送信する必要があるかを決定するためであり、これを HTTP ロード バランシング (他のより難解な (ネットワークに重点を置いた) 用語の中でも特に) と呼ぶ傾向があるのはこのためです。 

API によって公開され、マイクロサービス上に構築される世界では、リクエストを誘導する機能がますます重要になっています。 これは、バージョンに基づいて API リクエストを送信したり、ホスト名または URI パスを使用して特定のマイクロサービスにリクエストをディスパッチしたり、applicationを機能的に分解したりする必要があるためです。

ほとんどの組織は、使いやすい一貫性のある API を公開したいと考えています。 一般開発者が API を使用する新しいapplicationsを作成することを奨励するためでも、パートナーが簡単に接続して統合できるようにするためでも、一貫性のあるシンプルな API は採用を確実にするために不可欠です。

しかし、現実には API は複雑になることが多いです。 これらは複数のサービス (多くの場合はマイクロサービス) によってサポートされており、複数の場所に分散されている場合があります。 単一のサービスに限定されることはほとんどありません。 複雑なことに、以前の世代のアプリよりも頻繁に更新され、下位互換性が確実に保たれているわけではありません。 また、モバイル アプリは、Web アプリと画像を共有したり、他のアプリと同じ API を使用したりすることで、古いリソースと新しいリソースの両方を活用することができます。

これらの「アプリ」と API を拡張するには、負荷分散に対するアーキテクチャ的なアプローチが必要です。 トラフィックを分散する前に誘導する必要があります。つまり、レイヤー 7 (HTTP) 対応のロード バランサを使用して、URL ディスパッチ、データ パーティショニング、機能分解などのアーキテクチャ パターンを実装する必要があります。 これらの各パターンは本質的にアーキテクチャ的であり、従来のアプリよりもapplicationまたは API 設計に対するより高い親和性を必要とします。

HTTP ロード バランシングは、効率性と俊敏性のバランスを取りながらアプリを拡張し、API をサポートする上でますます重要になっています。 

スケーラビリティには両方が必要

現実世界では、1 種類のスケールだけを目にすることはほとんどありません。 これは、組織が数十年にわたる開発、アプリ アーキテクチャ、プラットフォーム、テクノロジーにわたる堅牢なapplicationsセットを提供することが増えているためです。 「最新の」applicationsのみをサポートしていると自慢できる組織はほとんどありません (メインフレームで実行されていないものはすべて最新のものに含まれる場合を除きます)。

したがって、さまざまなapplicationsを拡張するために、アルゴリズムとアーキテクチャの両方の負荷分散が見られ、使用される可能性が高くなります。 そのため、違いを理解することが重要です。一方がより適切な場合に他方を使用すると、パフォーマンスの低下や停止につながる可能性があり、どちらもユーザー、ビジネス、そしてあなたにとって良いことではありません。 

最新のapplicationsを拡張するために、これら 2 つのアプローチが組み合わされるケースが増えています。 場合によっては、これら 2 つは、論理的なもの (API) と物理的なもの (API の背後にある実際のサービス) を拡張するように設計された単一のサービスとして実際に存在することもあります。 application配信コントローラー (ADC) は、通常、両方を同じ速さで実行できるため、複合アプローチが実装されるプラットフォームです。

これらは 2 つの異なるシステムによって実行される場合もあります。 たとえば、コンテナ化された環境では、イングレス コントローラがアーキテクチャ上の負荷分散を担当し、内部のネイティブ サービスが通常、アルゴリズムによる負荷分散を使用してスケーリングを担当します。

実装と展開の詳細に関係なく、実際には、負荷分散に対するアルゴリズムベースとアーキテクチャベースの両方のアプローチが、アプリと API のスケーリングにおいて重要な役割を果たします。 これらの強みを最大限に活用するための鍵は、負荷分散をapplicationアーキテクチャに一致させることです。

スケールオン。