負荷分散という用語は、複数のコンピューティング リソース間での処理の分散を指します。 負荷分散を行うと、リソースの使用量を最適化し、スループットを最大化し、応答時間を最小限に抑え、単一のリソースの過負荷を回避できます。 負荷分散では、冗長コンピューティング リソース間でワークロードを共有することで、可用性を向上させることもできます。
Azure には、複数のコンピューティング リソースにワークロードを分散するために使用できるさまざまな負荷分散サービスが用意されています。 これらのサービスには、Azure API Management、Azure Application Gateway、Azure Front Door、Azure Load Balancer、Azure Traffic Manager が含まれます。
この記事では、ワークロードのニーズに適した負荷分散ソリューションを決定するのに役立つ考慮事項について説明します。
Azure 負荷分散サービス
Azure では、次の主な負荷分散サービスと負荷分散機能を備えたサービスを利用できます。
API Management は、HTTP (S) API の発行、セキュリティ保護、変換、保守、監視に使用できるマネージド サービスです。 API 用のゲートウェイを提供し、指定された負荷分散されたバックエンド プール内のノード間でトラフィックを負荷分散するように構成できます。 ラウンドロビン、加重、優先度ベースの3つの負荷分散方法から選択できます。
Von Bedeutung
API Management は、従来の汎用ロード バランサーではありません。 これは HTTP API 専用に設計されており、その負荷分散機能は、より広範な API 管理機能内では省略可能です。 API Management は、特定の API ホスティング トポロジに負荷分散機能を提供するため、この記事では完全に説明します。 ただし、その主な目的は、負荷分散ではなく API ゲートウェイ機能です。
Application Gateway は、Web トラフィック ロード バランサーです。 マネージド サービスとしてアプリケーション配信コントローラー機能を提供します。 また、さまざまなレイヤー 7 負荷分散機能と Web アプリケーション ファイアウォール機能も提供します。 Application Gateway を使用して、パブリック ネットワーク空間から、リージョン内のプライベート ネットワーク空間でホストされている Web サーバーにトラフィックを切り替えます。
Azure Front Door は、Web アプリケーションのグローバル負荷分散とサイト アクセラレーションを提供するアプリケーション配信ネットワークです。 Secure Sockets Layer (SSL) オフロード、パスベースのルーティング、高速フェールオーバー、キャッシュなどのレイヤー 7 機能をアプリケーションに提供して、パフォーマンスと高可用性を向上させます。
Load Balancer は、すべてのユーザー データグラム プロトコル (UDP) および伝送制御プロトコル (TCP) プロトコル間の受信トラフィックと送信トラフィックを処理するレイヤー 4 サービスです。 これは、高パフォーマンスで超低遅延を実現するように設計されています。 これは、ソリューションの高可用性を確保しながら、1 秒あたり数百万の要求を処理するように構築されています。 Load Balancer はゾーン冗長であるため、可用性ゾーン間の高可用性が確保されます。 リージョンデプロイ トポロジと リージョン間トポロジの両方をサポートします。
Traffic Manager は、ドメイン ネーム システム (DNS) ベースのトラフィック ロード バランサーであり、トラフィックをグローバル Azure リージョン全体のサービスに最適に分散しながら、高可用性と応答性を提供できます。 Traffic Manager は DNS ベースの負荷分散サービスであるため、負荷分散はドメイン レベルでのみ行われます。 そのため、Azure Front Door ほど迅速にフェールオーバーすることはできません。 DNS キャッシュと、DNS の有効期間 (TTL) の値を無視するシステムでは、多くの場合、この遅延が発生します。
注
Azure Container Apps や Azure Kubernetes Service (AKS) などのクラスタリング テクノロジには、負荷分散コンストラクトが含まれています。 これらのコンストラクトは、主に独自のクラスター境界のスコープ内で動作します。 準備と正常性プローブに基づいて、使用可能なアプリケーション インスタンスにトラフィックをルーティングします。 この記事では、これらの負荷分散オプションについては説明しません。
サービスの分類
Azure 負荷分散サービスは、グローバルとリージョン、HTTP(S) と非 HTTP (S) の 2 つのディメンションに沿って分類できます。
グローバルかリージョンか
グローバル： これらの負荷分散サービスは、リージョンバックエンド、クラウド、またはハイブリッドオンプレミスサービス間でトラフィックを分散します。 これらは、使用可能なバックエンドにユーザー トラフィックをグローバルにルーティングする単一のコントロール プレーンを提供します。 これらのサービスは、サービスの信頼性やパフォーマンスの変化に対応して、可用性とパフォーマンスを最大化します。 アプリケーション スタンプ、エンドポイント、または異なるリージョンまたは地域でホストされているスケール ユニット間で負荷を分散するシステムと考えることができます。
リージョナル： これらの負荷分散サービスは、仮想ネットワーク内のトラフィックを、リージョン内の仮想マシン (VM) またはゾーン冗長およびゾーン冗長サービス エンドポイントに分散します。 仮想ネットワークにあるリージョン内の VM、コンテナー、またはクラスター間で負荷を分散するシステムと考えることができます。
HTTP(S) か非 HTTP(S) か
HTTP(S): これらの負荷分散サービスは、HTTP(S) トラフィックのみを受け入れる レイヤー 7 ロード バランサーです。 Web アプリケーションまたはその他の HTTP (S) エンドポイント用に設計されています。 機能には、SSL オフロード、Web アプリケーション ファイアウォール、パスベースの負荷分散、セッション アフィニティが含まれます。
非 HTTP(S): これらの負荷分散サービスには、 レイヤー 4 の TCP および UDP サービス、または DNS ベースの負荷分散サービスが含まれます。
次の表に、Azure 負荷分散サービスの概要を示します。
| サービス | グローバルまたは地域 | 推奨されるトラフィック |
|---|---|---|
| API Management | リージョンまたはグローバル | HTTP(S) API のみ |
| Application Gateway | リージョン | HTTP(S) |
| Azure Front Door | グローバル | HTTP(S) |
| Load Balancer | リージョンまたはグローバル | Non-HTTP(S) |
| Traffic Manager | グローバル | Non-HTTP(S) |
注
Traffic Manager と Load Balancer は、HTTP(S) を含む任意のトラフィックの種類を分散できます。 ただし、これらのサービスではレイヤー 7 の機能は提供されません。 Load Balancer とは異なり、Traffic Manager はトラフィックを直接処理しません。 Traffic Manager は DNS を使用して、クライアントを適切なエンドポイントに転送します。
シナリオに合わせて負荷分散ソリューションを選択する
負荷分散ソリューションを選択するときは、次の要因を考慮してください。
トラフィックの種類: Web HTTP(S) アプリケーションかどうか、および公開アプリケーションかプライベート アプリケーションかを判断します。
グローバルとリージョン: 1 つの仮想ネットワーク内の VM またはコンテナーの負荷分散、リージョン間でのスケール ユニットまたはデプロイの負荷分散、またはその両方を行う必要があるかどうかを明確にします。
可用性：サービス レベル アグリーメント (SLA) を確認します。
費用： サービス自体のコストと、そのサービスに基づいて構築されたソリューションを管理するための運用コストを考慮します。 詳細については、 Azure の価格設定 を参照してください。
機能と制限: 各サービスでサポートされている機能と、該当する サービスの制限を特定します。
次のフロー チャートは、アプリケーションの負荷分散ソリューションを選択するのに役立ちます。 フローチャートでは、一連の主要な決定基準をガイドして推奨事項に到達します。
ヒント
Azure portal で Microsoft Copilot を使用すると、フロー チャートと同様に、この決定をガイドできます。 Copilot で、「 ロード バランサーの選択に関するヘルプ 」と入力します。Copilot からの質問に答えることで、負荷分散オプションを絞り込むことができます。
すべてのアプリケーションには、単純なデシジョン ツリーにキャプチャされない固有の要件があります。 このフロー チャートまたは Copilot の推奨事項を開始点として扱います。 次に、より詳細な評価を実行します。
ワークロードに負荷分散を必要とする複数のサービスが含まれている場合は、各サービスを個別に評価します。 効果的なセットアップでは、多くの場合、複数の種類の負荷分散ソリューションが使用されます。 これらのソリューションは、ワークロードのアーキテクチャのさまざまな場所に組み込んで、固有の機能やロールを提供できます。
定義
Web アプリケーション (HTTP/HTTPS) は、次の機能のうち少なくとも 1 つを必要とするアプリケーションを指します。
- URL パスなど、レイヤー 7 データのルーティング決定を行います
- HTTP 要求本文などの通信ペイロードの検査をサポートします
- トランスポート層セキュリティ (TLS) 機能を処理する
インターネットに接続するアプリケーション とは、インターネットからパブリックにアクセスできるアプリケーションを指します。 ベスト プラクティスとして、アプリケーション所有者は制限付きアクセス ポリシーを適用するか、Web アプリケーション ファイアウォールや分散型サービス拒否保護などのオファリングを設定してアプリケーションを保護します。
グローバルまたは複数のリージョンにデプロイされている ということは、ロード バランサーに、グローバルに分散されたアプリケーション上のパブリック エンドポイントにトラフィックをルーティングする、可用性の高い単一のコントロール プレーンが必要であることを意味します。 この構成では、リージョン間でアクティブ/アクティブトポロジまたはアクティブ/パッシブ トポロジをサポートできます。
注
Application Gateway などのリージョン サービスを使用して、複数のリージョンにまたがるバックエンド間で負荷分散を行い、単一のコントロール プレーンを介したルーティングを制御できます。 これは、 リージョン間のプライベート リンク、グローバル仮想ネットワーク ピアリング、または他のリージョンのサービスのパブリック IP アドレスを使用して機能します。
このシナリオは、この決定の主要なポイントではありません。
グローバルに分散されたバックエンドのルーターとしてリージョン リソースを使用すると、リージョンの単一障害点が発生します。 また、トラフィックは別のリージョンに移動してから再び戻る前に強制的に通過するため、余分な待機時間が発生します。
サービスとしてのプラットフォーム (PaaS) は、VM やネットワーク リソースを管理しなくてもアプリケーションをデプロイできるマネージド ホスティング環境を提供します。 この場合の PaaS は、統合された負荷分散をリージョン内で提供するサービスを指します。 詳細については、「 スケーラビリティのためにコンピューティング サービスを選択する」を参照してください。
AKS を使用すると、コンテナー化されたアプリケーションをデプロイおよび管理できます。 AKS は、サーバーレス Kubernetes、統合された継続的インテグレーションと継続的デリバリー (CI/CD) エクスペリエンス、エンタープライズ レベルのセキュリティとガバナンスを提供します。 詳細については、「 AKS アーキテクチャの設計」を参照してください。
サービスとしてのインフラストラクチャ (IaaS) は、必要な VM と、関連付けられているネットワークおよびストレージ コンポーネントをプロビジョニングするコンピューティング オプションです。 IaaS アプリケーションでは、Load Balancer を使用して、仮想ネットワークの内部で負荷を分散する必要があります。
アプリケーション層処理 とは、仮想ネットワーク内の特別なルーティングを指します。 たとえば、VM または仮想マシン スケール セット間のパスベースのルーティングが挙げられます。 詳細については、「 Azure Front Door の背後に Application Gateway をデプロイする」を参照してください。
API のみが 、Web アプリケーションではない HTTP (S) API を負荷分散する必要があることを意味します。 この場合、ワークロードでゲートウェイ機能に既に API Management が使用されている場合は、オプションの負荷分散機能を検討して、別のメカニズムによってまだ負荷分散されていない API バックエンド間でトラフィックを転送できます。 ワークロードで API Management を使用しない場合は、負荷分散にのみ使用しないでください。
パフォーマンス高速化 とは、Web アクセスを高速化する機能を指します。 パフォーマンス高速化は、コンテンツ配信ネットワークを使用するか、宛先ネットワークへの高速クライアント オンボード用に最適化されたポイント オブ プレゼンス イングレスを使用して実現できます。 Azure Front Door では、 コンテンツ配信ネットワーク と Anycast トラフィックアクセラレーションの両方がサポートされています。 アーキテクチャ内の Application Gateway の有無にかかわらず、両方の機能の利点を得ることができます。
その他の考慮事項
各負荷分散サービスには、考慮する必要がある機能のサポートまたは実装の詳細もあります。 負荷分散シナリオに関連する可能性のあるいくつかの例を次に示します。
- WebSocket のサポート
- サーバー送信イベントのサポート
- HTTP/2 のサポート (バックエンド ノードの受信と継続の両方)
- スティッキー セッションのサポート
- バックエンド ノードの正常性監視メカニズム
- 異常なノードの検出とルーティング ロジックからの削除によって生じるクライアント エクスペリエンスへの影響や遅延
ロード バランサーに機能をオフロードする
Azure の一部の負荷分散オプションでは、バックエンド ノードからロード バランサーに機能をオフロードできます。 これらのオプションは、 ゲートウェイ オフロード クラウド設計パターンを実装します。 たとえば、Application Gateway は TLS をオフロードできるため、ワークロードの公開証明書はバックエンド ノード間ではなく 1 つの場所で管理されます。 API Management は、JSON Web トークン (JWT) アクセス トークンでの要求の検証など、いくつかの基本的な承認の問題をオフロードするように構成できます。 横断的な問題をオフロードすると、バックエンドのロジックの複雑さを軽減し、パフォーマンスを向上させることができます。
例示
次の表に、ソリューションで使用される負荷分散サービスに基づくさまざまな記事を示します。
| サービス | [アーティクル] | 説明 |
|---|---|---|
| Load Balancer | 可用性ゾーン間での VM の負荷分散 | 可用性ゾーン間の負荷分散 VM は、データセンター全体に及ぶ珍しい障害や損失からアプリとデータを保護するのに役立ちます。 ゾーン冗長では、1 つまたは複数の可用性ゾーンで障害が発生しても対応可能であり、リージョン内に正常なゾーンが 1 つでも残っていれば、データ パスは存続します。 |
| Traffic Manager | 高可用性と障害復旧用にビルドされた多層 Web アプリケーション | 高可用性とディザスター リカバリー用にビルドされた、回復性がある多層 Web アプリケーションをデプロイします。 プライマリ リージョンが使用できなくなった場合、Traffic Manager はセカンダリ リージョンへのフェールオーバーを実行します。 |
| Application Gateway と API Management | API Management ランディング ゾーンのアーキテクチャ | Application Gateway を使用して、Web アプリケーション ファイアウォールと TLS をオフロードします。 API Management を使用して、API バックエンド間で負荷分散を行います。 |
| トラフィックマネージャーとアプリケーションゲートウェイ | Traffic Manager と Application Gateway を使用したマルチリージョンの負荷分散 | 高可用性と堅牢なディザスター リカバリー インフラストラクチャを実現するために、Web ワークロードを提供し、回復性の高い多層アプリケーションを複数の Azure リージョンにデプロイする方法について説明します。 |