負荷分散のオプション

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

Azure には、ワークロードを複数のコンピューティング リソースに分散するために使用できるさまざまな負荷分散サービスが用意されています。 これらのリソースには、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): これらの負荷分散サービスは、非 HTTP(S) トラフィック、主な TCP または UDP サービスを処理する Layer 4 ロード バランサーです。

次の表は、Azure の負荷分散サービスをまとめたものです。

Azure の負荷分散サービス

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

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

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

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

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

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

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

• トラフィックの種類 - web HTTP(S) アプリケーションか? パブリック向けまたはプライベートのアプリケーションか。
• グローバルとリージョンの比較: 単一仮想ネットワーク内の仮想マシンまたはコンテナーを負荷分散する必要はありますか。またはリージョン間でスケール ユニットとデプロイを負荷分散する必要はありますか。またはその両方ですか。
• 可用性: サービス レベル アグリーメントは何か。
• コスト: 詳細については、「Azure の価格」を参照してください。 サービス自体のコストのほか、そのサービスに構築されているソリューションを管理するための運用コストを考慮してください。
• 機能と制限: 各サービスでサポートされている機能と、各サービスのサービス制限は何ですか?

![ヒント] Azure Portal には、次のフローチャートのようなアンケートベースのガイドが用意されています。 Azure Portalで、「Load balancing - help me choose」と検索します。 質問に答えることで、負荷分散オプションを絞り込むことができます。

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

このフローチャートを原案として使用します。 すべてのアプリケーションには固有の要件があるため、推奨事項は原案として使用してください。 次に、より詳細な評価を実行します。

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

定義

• Web アプリケーション (HTTP/HTTPS): URL パスなどの Layer 7 データのルーティング決定、通信ペイロードの検査 (HTTP リクエスト本文など) のサポート、TLS 機能の処理を行う機能が必要です。

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

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

  Note

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

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

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

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

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

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

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

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

その他の考慮事項

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

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

例

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

次のステップ

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