アプリと API を拡張するためのアプリ配信パターン

負荷分散アルゴリズムは、リソース プール全体に負荷を分散して可用性を確保し、パフォーマンスを向上させるプログラム的なアプローチです。

負荷分散アルゴリズムは、特定のリソースがどのように選択されるか、およびどの変数が考慮されるかを指定します。

ラウンドロビンは最も単純なアルゴリズムであり、既知のリソース セットを順番に反復するだけです。 A、B、C の 3 つのリソースがある場合、ラウンドロビンでは最初のリクエストが A に、2 番目のリクエストが B に、3 番目のリクエストが C にルーティングされます。その後、選択プロセスが再び開始されます。

最小接続は、「負荷が増加するとパフォーマンスが低下する」という 2 番目の運用公理に基づいたアルゴリズムです。 したがって、最小接続アルゴリズム 接続 (負荷) が最も少ないリソースを選択します。 このアルゴリズムにはさまざまなバリエーションがあり、最も顕著なのは、リソース間の容量の違いを許容する重み付け最小接続です。

パフォーマンスが最優先される場合は、最速の応答時間が使用されます。 ロード バランサは、受動的または能動的に各リソースからの応答時間を決定し、すべての要求に対して最も速いものを選択します。 このアルゴリズムはラストマイルやユーザーネットワークの状態に影響を与えないため、ユーザー応答時間を保証するものではありません。

ソース IP は、ソース (クライアント) IP の単純なハッシュ値を使用してリソースを選択する、ネットワーク負荷分散から残ったアルゴリズムです。 このアルゴリズムは、特定のソース IP に対して常に同じリソースを選択します。 このアルゴリズムは、単一のプロキシ/IP アドレスから発信されたすべてのユーザーが同じリソースに誘導される「メガ プロキシ」問題の影響を受けるため、人気がなくなりました。 これにより、ターゲット リソースが過負荷になり、パフォーマンスが低下し、最終的には障害が発生する傾向があります。

負荷分散アルゴリズムは、アプリ配信アーキテクチャの重要な部分ですが、全体的なアーキテクチャアプローチに比べると、アプリやデジタル サービスのパフォーマンスと規模に与える影響は小さくなります。

アプリ配信は、アプリ、API、デジタル サービス向けにスケーラブルで高性能なアーキテクチャを設計する分野です。 コアコンポーネントとして負荷分散に大きく依存していますが、レイヤー 7 ルーティングなどの最新機能を組み込み、一般的なアーキテクチャ パターンを活用してパフォーマンスを最適化し、リソースを効率的に利用します。

私たちは、実装の詳細である負荷分散と、設計プロセスであるアーキテクチャの間に意図的に線を引くために、「アプリ配信」という用語を使用しています。

スケールとは、ビジネス成果に対する技術的な対応です。 つまり、顧客満足度スコア、コンバージョン率、収益の創出を向上させるために、デジタル サービスを構成するワークロードの可用性とパフォーマンスを維持する必要があるということです。 この最後の部分は特に重要です。当社の調査によると、現在、企業の大多数 (58%) が収益の少なくとも半分をデジタル サービスから得ているからです。

また、たとえば、ビジネス継続性 (BC) のためにパブリック クラウドを使用することも検討してください。 BC はパブリック クラウドの主な用途であり、その中核となるのはグローバル スケールの実装、つまりグローバル ロード バランシングです。 フェイルオーバーは、アプリ配信のコア機能であり、サイト全体に適用すると、ある場所から別の場所にリクエストを迅速にリダイレクトできるようになります。  企業のデジタルプレゼンスの継続的な可用性は、技術的な対応によって実現されるビジネス成果です。

この質問に答えることから、アプリ配信アーキテクチャに関する技術的な旅が始まります。 スケールには、垂直 (上) と水平 (外) の 2 つのモデルがあります。

垂直スケールは、システムに処理能力を追加すると容量が増加するという原則に基づいています。 このスケーリング方法は、主にモノリシック アプリケーションと自己完結型のシステムに役立ちます。 インフラストラクチャとは別に、ほとんどの組織は、CPU や RAM の追加、ネットワーク容量の拡張など、物理環境の変更が必要になるため、垂直スケールには依存しなくなりました。 仮想化によって垂直方向の拡張は大幅に高速化されますが、特にパブリック クラウド環境では、ソフトウェアとシステムを新しい仮想マシンに移行する必要性によって混乱が生じる可能性があります。

水平スケールは、利用可能なリソースの合計を増やすことで処理能力を高めるアーキテクチャ上のアプローチです。 これは、アプリケーション、サービス、またはシステムの複数のインスタンスに処理能力を分散することによって実現されます。 これは、リソースを移行するのではなく複製することに依存するため、現在最も一般的なスケーリング方法です。 さらに、水平スケールでは垂直スケールよりも多様なアーキテクチャ オプションが提供されるため、すべてのアプリケーションと API に適しています。  

したがって、最新のアプリ配信パターンが水平スケールの原則に基づいていることは驚くべきことではありません。

単に水平スケールを選択するだけでは議論は終わりません。

決定が下されると (通常はデフォルトの決定です)、追加の考慮事項に基づいて実装に関するアーキテクチャ上の決定が行われる必要があります。 その決定に取り組む最も簡単な方法は、 『The Art of Scalability』という本で説明されているスケール キューブのレンズを使用することです。

簡単に言えば、スケール キューブには x、y、z の 3 つの軸があります。 それぞれが負荷分散アーキテクチャ パターンにマッピングされます。 これらの各パターンは、さまざまな種類のアプリケーションと API を前提として、パフォーマンスと可用性に関連する特定の結果を満たすのに適しています。

デジタル サービスでは、パフォーマンスとリソース消費を同時に最適化するために、複数のパターンを組み込んだアーキテクチャが使用される可能性があります。 このアプローチでは、すべてのコンポーネント、それらの相互作用、ユーザーからアプリへのリクエストの流れ方などを考慮する必要があるため、システム思考が必要です。

X 軸パターンは最も基本的なパターンです。 これは水平複製に基づいており、作業の大部分は負荷分散アルゴリズムによって実行されます。 これは最も単純なパターンであり、私が「Plain Old Load Balancing (POLB)」と呼んでいる結果になります。

このように呼ぶのは、アーキテクチャが単純で、アプリケーション層でリクエストやレスポンスとやり取りする最新のロード バランサーの高度な機能を活用していないためです。

このパターンは機能分解に基づいており、アプリ配信のアプリケーション層 (レイヤー 7) 機能を活用して、システム全体ではなく機能に基づいてスケーリングします。 Y 軸パターンは、レイヤー 7 ルーティングがアプリ配信アーキテクチャ ツールボックスの重要なツールとなる最初のパターンです。

一般に、y ベースおよび z ベースのパターンでは、レイヤー 7 ルーティングを利用してプールを選択し、次に負荷分散アルゴリズムを使用して特定のリソースを選択します。 これは、レイヤー 7 ルーティングが使用されない基本的な x パターンとは異なります。

Z 軸パターンは、ソーシャル メディアとインターネット全体の爆発的な成長により、必要性から人気が出ました。 これは本質的には、通常はユーザー名やデバイス識別子などの特定の変数に基づいて追加のセグメンテーションが適用された Y 軸のスケーリング パターンです。

このパターンでは、データシャーディングから派生した手法を使用してアーキテクチャの差別化が可能になります。