負荷分散のオプション

負荷分散という用語は、複数のコンピューティング リソース間での処理の分散を指します。 負荷を分散して、リソースの使用を最適化し、スループットを最大化し、応答時間を最小限に抑え、単一のリソースの過負荷を回避します。 負荷分散では、冗長コンピューティング リソース間でワークロードを共有することで、可用性を向上させることもできます。

Azure には、ワークロードを複数のコンピューティング リソースに分散するために使用できるさまざまな負荷分散サービスが用意されています。 これらのサービスには、Azure API Management、Azure Application Gateway、Azure Front Door、Azure Load Balancer、Azure Traffic Manager が含まれます。

この記事では、ワークロードのニーズに適した負荷分散ソリューションを決定するのに役立つ考慮事項について説明します。

サービスの分類

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 の負荷分散サービスをまとめたものです。

Azure の負荷分散サービス

Azure で現在使用できる主な負荷分散サービスを次に示します。

• API Management は、HTTP (S) API の発行、セキュリティ保護、変換、保守、監視を可能にするマネージド サービスです。 API のゲートウェイを提供し、指定された負荷分散されたバックエンド プール内のノード間でトラフィックを負荷分散できます。 ラウンド ロビン、重み付け、優先度ベースの 3 つの異なる負荷分散方法から選択できます。

• Application Gateway は、 Layer 7 の負荷分散機能、Web Application Firewall 機能を提供するサービスとしてのアプリケーション配信コントローラーです。 Application Gateway を使用して、パブリック ネットワーク空間から、リージョン内のプライベート ネットワーク空間でホストされている Web サーバーにトラフィックを切り替えます。

• Front Door は、Web アプリケーションのグローバル負荷分散とサイト アクセラレーションを提供するアプリケーション配信ネットワークです。 SSL オフロード、パスベースのルーティング、高速フェールオーバー、キャッシュなどのレイヤー 7 機能をアプリケーションに提供して、パフォーマンスと高可用性を向上させます。

• Load Balancer は、すべての UDP と TCP プロトコル向けの高パフォーマンス、超低待機時間のレイヤー 4 負荷分散サービス (受信および送信) です。 これは、ソリューションの高可用性を保証しながら、1 秒あたり数百万の要求を処理するように構築されています。 Azure Load Balancer は、ゾーン冗長であるため、可用性ゾーン全体で高可用性を確保します。 リージョン デプロイ トポロジと リージョン間トポロジの両方をサポートします。

• Traffic Manager は、世界中の Azure リージョン間でサービスへのトラフィックを最適に配分しつつ、高可用性と応答性を実現する DNS ベースのトラフィック ロード バランサーです。 Traffic Manager は DNS ベースの負荷分散サービスであるため、負荷分散はドメイン レベルでのみ行われます。 そのため、DNS キャッシュに関する一般的な課題や、DNS Time to Live (TTL) 値を受け入れないシステムが原因で、Azure Front Door ほど迅速にフェールオーバーすることはできません。

Azure での負荷分散のデシジョン ツリー

負荷分散ソリューションを選択するときは、次のような要因を考慮してください。

• トラフィックの種類: Web HTTP(S) アプリケーションですか? パブリック向けまたはプライベートのアプリケーションか。
• グローバルとリージョン: 1 つの仮想ネットワーク内の VM またはコンテナーの負荷分散、またはリージョン間でのスケール ユニット/デプロイの負荷分散、またはその両方が必要ですか?
• 可用性：サービス レベル アグリーメントとは
• 費用： 詳細については、Azure の 価格に関するページを参照してください。 サービス自体のコストに加えて、そのサービスに基づいて構築されたソリューションを管理するための運用コストも考慮してください。
• 機能と制限: 各サービスはどのような機能をサポートし、各 サービスのサービスの制限 は何ですか?

次のフローチャートは、アプリケーションの負荷分散ソリューションを選択するのに役立ちます。 このフローチャートは、推奨事項を導き出すための一連の主要な意思決定基準を示しています。

すべてのアプリケーションには、単純なデシジョン ツリーにキャプチャされない固有の要件があります。 このフローチャートまたは Azure Copilot の推奨事項を出発点として扱います。 次に、より詳細な評価を実行します。

ワークロードに負荷分散を必要とする複数のサービスが含まれている場合は、各サービスを個別に評価します。 効果的なセットアップでは、多くの場合、複数の種類の負荷分散ソリューションが使用されます。 これらのソリューションは、ワークロードのアーキテクチャのさまざまな場所に組み込み、それぞれが一意の機能またはロールを提供する場合があります。

定義

• Web アプリケーション (HTTP/HTTPS): この指定とは、URL パスなどのレイヤー 7 データのルーティング決定、通信ペイロードの検査 (HTTP 要求本文など) のサポート、または TLS 機能の処理を行う機能を必要とすることを意味します。

• インターネットに接続するアプリケーション: インターネットからパブリックにアクセスできるアプリケーション。 ベスト プラクティスとして、アプリケーション所有者は、制限の厳しいアクセス ポリシーを適用します。または、Web アプリケーション ファイアウォールや DDoS 保護などのサービスをセットアップすることによってアプリケーションを保護します。

• グローバルまたは複数のリージョンにデプロイされている場合: このロード バランサーに、グローバル分散アプリケーション上のパブリック エンドポイントにトラフィックをルーティングする高可用性コントロール プレーンが 1 つ必要な場合。 これにより、リージョン間でアクティブ/アクティブトポロジまたはアクティブ/パッシブ トポロジをサポートできます。

  注

  Application Gateway や API Management などのリージョン サービスを使用して、複数のリージョンにまたがるバックエンド間で負荷分散を行い、1 つのコントロール プレーンを介したルーティングを制御できます。 このアーキテクチャは、 リージョン間の Private Link、グローバル仮想ネットワーク ピアリング、または他のリージョンのサービスのパブリック IP を使用することで可能です。

  このシナリオは、この決定の主要なポイントではありません。

  グローバルに分散されたバックエンドのルーターとしてリージョン リソースを使用すると、リージョンの単一障害点が発生し、トラフィックが別のリージョンを通過してから再び戻る前に強制的に送信されるため、追加の待機時間が発生します。

• サービスとしてのプラットフォーム (PaaS) は、マネージド ホスティング環境を提供します。この環境では、VM やネットワーク リソースを管理しなくてもアプリケーションをデプロイできます。 この場合の PaaS は、統合された負荷分散をリージョン内で提供するサービスを指します。 詳細については、コンピューティング サービスの選択 - スケーラビリティに関するページを参照してください。

• Azure Kubernetes Service (AKS) を使用すると、コンテナー化されたアプリケーションをデプロイおよび管理できます。 AKS からは、サーバーレスの Kubernetes、統合された継続的インテグレーションと継続的デリバリー エクスペリエンス、エンタープライズ レベルのセキュリティとガバナンスが提供されます。 AKS アーキテクチャ リソースの詳細については、Azure Kubernetes Service アーキテクチャ デザインに関するページを参照してください。

• サービスとしてのインフラストラクチャ (IaaS) は、関連するネットワークおよびストレージ コンポーネントと共に、必要な仮想マシンをプロビジョニングするコンピューティング オプションです。 IaaS アプリケーションでは、Load Balancer を使用して、仮想ネットワークの内部で負荷を分散する必要があります。

• アプリケーション層処理 とは、仮想ネットワーク内の特別なルーティングを指します。 たとえば、VM または仮想マシン スケール セット間のパスベースのルーティングが挙げられます。 詳細については、「Azure Front Door の背後に Application Gateway をデプロイする必要がある場合」を参照してください。

• API のみが 、Web アプリケーションではない HTTP (S) API を負荷分散する必要があることを意味します。 この場合は、別のメカニズムによってまだ負荷分散されていない API バックエンド間でトラフィックを負荷分散するように Azure API Management を検討する必要があります。

• パフォーマンス高速化 とは、Web アクセスを高速化する機能を指します。 パフォーマンスの高速化は、コンテンツ配信ネットワーク (CDN) または最適化されたポイント オブ プレゼンス イングレスを使用して、宛先ネットワークへの高速クライアント オンボードを行うことで実現できます。 Azure Front Door では、CDN と Anycast のトラフィックアクセラレーションの両方がサポートされています。 アーキテクチャ内の Application Gateway の有無にかかわらず、両方の機能の利点を得ることができます。

その他の考慮事項

各負荷分散サービスには、考慮する必要がある機能のサポートまたは実装の詳細もあります。 負荷分散シナリオに関連する可能性のあるいくつかの例を次に示します。

• WebSocket のサポート
• サーバー送信イベントのサポート
• HTTP/2 のサポート (バックエンド ノードの受信と継続の両方)
• スティッキー セッションのサポート
• バックエンド ノードの正常性監視メカニズム
• 異常なノード検出とルーティング ロジックからの削除の間のクライアント エクスペリエンスまたは遅延。

ロード バランサーに機能をオフロードする

Azure の一部の負荷分散オプションでは、クラウド設計パターンをオフロードするゲートウェイを実装するため、バックエンド ノードからロード バランサーに機能 をオフロード できます。 たとえば、Application Gateway は TLS をオフロードできるため、ワークロードの公開証明書はバックエンド ノード間ではなく 1 つの場所で管理されます。 API Management は、JWT アクセス トークンでの要求の検証など、いくつかの基本的な承認の問題をオフロードするように構成できます。 横断的な問題をオフロードすると、バックエンドのロジックの複雑さを軽減し、パフォーマンスを向上させることができます。

例

次の表に、ソリューションで使用される負荷分散サービスに基づくさまざまな記事を示します。

次のステップ

• VM の負荷を分散するパブリック ロード バランサーを作成する
• Application Gateway を使用して Web トラフィックを転送する
• グローバル DNS ベースの負荷分散用に Traffic Manager を構成する
• 高可用性グローバル Web アプリケーション向けの Azure Front Door を構成する