この記事は、ワークロードに適した負荷分散サービスAzure選択するのに役立ちます。 リージョンとグローバルのトラフィック分散のAzure Load Balancer、Application Gateway、およびAzure Front Doorを比較します。 また、それらを組み合わせるタイミングについても説明します。 サービスごとの短い概要については、「 ロードバランシングとコンテンツデリバリーとは何か?」をご覧ください。
この記事の内容
アプリケーションデリバリーには、ネットワークがネットワークの境界に到達した後、トラフィックがバックエンドリソース間でどのように分配されるかが含まれます。 この記事では、レイヤー 4 とレイヤー 7 の負荷分散とグローバル トラフィックアクセラレーションについて説明します。 また、3 つのプライマリ Azure負荷分散サービスから選択するための決定基準についても説明します。
Note
この記事では、 インターネットイングレスを補完します。アプリケーションをインターネットに公開します。これは、トラフィックがネットワーク に到達する方法 に焦点を当てています。 この記事では、そのトラフィックのバランスを取ってアプリケーション バックエンドに配信する 方法について説明 します。
この記事が必要なユーザー
次の場合は、この記事をお読みください。
- 複数のバックエンド インスタンス間で高可用性を必要とする Web アプリケーションまたは API をホストします。
- HTTP/HTTPSトラフィックに対してSSL/TLSオフロード、URLベースのルーティング、またはWeb Application Firewall(WAF)保護が必要です。
- パフォーマンスまたはディザスター リカバリーのために、複数のAzure リージョンにトラフィックを分散します。
- 正常性プローブによるリージョン負荷分散を必要とする HTTP 以外のワークロード (TCP/UDP) を実行します。
- トラフィックの種類、地理的範囲、およびセキュリティ要件に適合するロード バランサーを理解したい。
リフトアンドシフトフォーカス: リホストされた内部アプリの多くは、リージョンのロード バランサーのみを必要とします。 アプリを顧客に発行するときに、インターネットに接続する配信サービスを追加します。
フォーカスを最新化する:アプリの種類別に配信を選択します。グローバル Web アプリの場合はAzure Front Door、非 Web アプリの場合は Traffic Manager を選択し、アクティブ/アクティブなリージョン エンドポイントを前面に配置します。
クラウド間のフォーカス:他のクラウドからロード バランサーを同等のAzureにマップし (たとえば、AWS ALB から Application Gateway、NLB から Azure Load Balancer)、ハブ ファイアウォールの背後にあるスポークを介して配信します。
Azureサービスと機能
次の表は、3 つのプライマリ Azure負荷分散サービスをまとめたものです。
| サービス | 提供される内容 | いつ使用するか | キー制約 |
|---|---|---|---|
| Azure Standard Load Balancer | リージョン内のレイヤー 4 (TCP/UDP) 負荷分散。 正常性確認プローブ、ゾーン冗長性、送信 SNAT ルール、およびネットワーク仮想アプライアンスの HA ポート。 | 仮想マシン スケール セット、AKS の内部トラフィック、非 HTTP/HTTPS のリージョン ワークロード、NVA の高可用性。 | SSL/TLS 終了なし。WAF なし。URL ベースのルーティングなし。リージョン スコープのみ。 |
| Azure Application Gateway | レイヤー 7 (HTTP/HTTPS) リージョンの負荷分散。 SSL/TLS 終了、URL パスベースのルーティング、マルチサイト ホスティング、Cookie ベースのセッション アフィニティ、およびオプションの WAF 統合。 | SSL オフロード、URL ルーティング、WebSocket サポート、または WAF 保護を必要とするリージョン Web アプリケーション。 | 地域のみ。専用サブネットが必要です。は、グローバル ルーティングや CDN のシナリオには適していません。 |
| Azure Front Door | グローバル エニーキャスト負荷分散と CDN。 エッジでの TLS 終端、統合 WAF、オリジン ヘルスプローブ、トラフィック分割、そして世界 190 か所以上の PoP にまたがるキャッシュ。 | グローバル Web アプリケーション、マルチリージョンのアクティブ/アクティブデプロイ、CDN とキャッシュ、グローバル WAF の適用。 | HTTP/HTTPSのみ;オリジンは公開されているか、Private Link(プレミアム層)を通じてアクセス可能でなければなりません。 |
ゾーン冗長性
ゾーン冗長性により、データセンターの障害からアプリケーション配信層が保護されます。 各サービスは、可用性ゾーンを異なる方法で処理します。
- Standard Load Balancer (パブリック) は、Standard パブリック IP アドレスが既定でゾーン冗長構成になっているため、既定でゾーン冗長です。 1 つの可用性ゾーンで障害が発生した場合でも、トラフィックは流れ続けます。 Standard Load Balancer (内部) では、明示的なゾーン冗長フロントエンド構成が必要です。フロントエンド IP を作成するときは、複数のゾーンを選択する必要があります。
- Application Gateway v2 では、複数の可用性ゾーンにインスタンスをデプロイする場合のゾーン冗長性がサポートされます。 デプロイ中にゾーンを指定します。 ゾーン冗長 Application Gateway は、選択したゾーンにインスタンスを分散し、1 つのゾーンがオフラインになった場合でも可用性を維持します。
- Azure Front Doorは、本質的にグローバル エニーキャスト サービスとしてゾーン冗長です。 190 を超えるエッジ POP は世界中の複数のリージョンにまたがるため、単一のゾーンまたはリージョンの障害がグローバル トラフィック ルーティングに影響を与える可能性はありません。
Autoscaling
各サービスは、異なる方法でスケーリングを処理します。
- Application Gateway v2 (Standard_v2 層と WAF_v2 層) では、トラフィックの負荷に基づく自動スケールがサポートされます。 最小インスタンス数と最大インスタンス数を構成し、ゲートウェイはこれらの境界内でスケーリングします。 価格では、容量ユニット (1 秒あたりの新しい接続、永続的な接続、スループットの複合メジャー) が使用されます。 トラフィックスパイク時のコールドスタート遅延を避けるため、本番ワークロードのインスタンス数を最低2つに設定しましょう。
- Azure Front Doorは、マネージド グローバル サービスとして自動的にスケーリングされます。 容量計画やインスタンスのサイズ設定は必要ありません。
- Standard Load Balancerは、手動による介入や構成の変更なしで、数百万の TCP/UDP フローにスケーリングされます。 インスタンスの概念のないフル マネージド プラットフォーム サービスです。
ヘルスプローブ
3 つのサービスはすべて、正常性プローブを使用して異常なバックエンドを検出し、それらのバックエンドへのトラフィックのルーティングを停止します。
- Standard Load Balancerでは、TCP、HTTP、および HTTPS の正常性プローブがサポートされます。 フェールオーバー速度を制御するために、プローブの間隔と異常なしきい値を構成します。 間隔を短くすると、障害の検出速度が速くなりますが、プローブ トラフィックが増えます。
-
Application Gateway では、カスタマイズ可能なパス、ホスト名、応答照合を使用して HTTP/HTTPS 正常性プローブを使用します。 カスタム プローブを使用すると、アプリケーション ロジックを検証できます (たとえば、データベース接続を検証する
/healthエンドポイントを確認します)。 - Front Door は、オリジンに対して HTTP/HTTPS 正常性プローブを使用します。 構成可能なプローブ パス、間隔、応答コードの照合がサポートされています。 Front Door は複数の POP からのオリジンをプローブし、分散型の正常性検証を提供します。
選択する方法
次のフローチャートは、Azure負荷分散サービスを選択するための主要な決定パスをまとめたものです。
次のデシジョン テーブルを使用して、シナリオに適した負荷分散サービスを選択します。
どのロードバランサーが必要ですか?
| 必要事項 | Use |
|---|---|
| 1 つのリージョン内で TCP/UDP トラフィックを負荷分散する | Azure Standard Load Balancer: 正常性プローブ、ゾーン冗長、および HA ポートを含むレイヤー 4 の分散。 |
| SSL/TLS を終了し、URL パスまたはホスト名でルーティングし、リージョン Web アプリの WAF を追加する | Azure Application Gateway: 統合 WAF (v2 SKU) を使用したレイヤー 7 リージョンの負荷分散。 |
| HTTP/HTTPSトラフィックをグローバルにルーティングしたり、エッジキャッシュでレイテンシを削減したり、リージョンをまたいでフェイルオーバーしたり | Azure Front Door: CDN、WAF、マルチリージョン配信元の正常性プローブを使用したグローバル エニーキャスト。 |
キー制約の比較
| サービス | レイヤー | Scope | 主な制限 |
|---|---|---|---|
| Standard Load Balancer | レイヤー 4 (TCP/UDP) | 地域 | アプリケーション認識なし: HTTP ヘッダー、URL、または Cookie を検査できません。 |
| Application Gateway | レイヤー 7 (HTTP/HTTPS) | 地域 | 専用サブネットが必要です (/24 をお勧めします)。では、トラフィックをグローバルにルーティングできません。 |
| Front Door | レイヤー 7 (HTTP/HTTPS) | グローバル | オリジンは公開またはPrivate Link経由でアクセス可能(プレミアムティアのみ)でなければなりません。TCP/UDPのサポートはありません。 |
サービスの組み合わせ
多くの運用アーキテクチャでは、チェーン内の複数の負荷分散サービスが組み合わせられます。 各サービスは、それぞれ最も得意な処理を担当します。
- Front Door + Application Gateway: グローバル トラフィック分散とエッジ WAF には Front Door を使用し、URL パスベースのルーティングとバックエンド プール管理のためにリージョンの Application Gateway インスタンスにルーティングします。 Front Door Premium は、Application Gateway をプライベートに保ち、Private Link経由で Application Gateway に接続できます。 このパターンは、各リージョンに複雑な URL ルーティング要件があるマルチリージョンデプロイに適しています。
- Front Door + Load Balancer: Front Door を使用してグローバルな HTTP/HTTPS トラフィックを分散し、その背後に内部 Standard Load Balancer を配置して、1 つのリージョン内の Virtual Machine Scale Sets または NVA 間でトラフィックを分散します。 Front Door はグローバル ルーティングとキャッシュを処理しますが、Load Balancerはコンピューティング インスタンスにレイヤー 4 の分散を提供します。
- Application Gateway + Load Balancer: フロントエンドでの HTTP/HTTPS トラフィック管理に Application Gateway を使用し、同じデプロイ内の HTTP 以外のバックエンド層 (データベース、メッセージ キュー) に対してLoad Balancerします。 このパターンにより、レイヤー7の知能はエッジに留まり、内部には軽量なレイヤー4の分布が維持されています。
ルーティング機能
ルーティング機能を理解すると、選択肢を絞り込むことができます。
| 能力 | Standard Load Balancer | Application Gateway | Front Door |
|---|---|---|---|
| URL パスベースのルーティング | No | Yes | Yes |
| マルチサイト (ホスト ヘッダー) ルーティング | No | Yes | Yes |
| クッキーを使用したセッションの親和性 | No | Yes | Yes |
| 加重トラフィックの分割 | No | No | Yes |
| 地理ルーティング | No | No | Yes |
| SSL/TLS オフロード | No | Yes | Yes |
| WebSocket のサポート | パススルー | Yes | Yes |
| HTTP/2 のサポート | No | Yes | Yes |
Tip
Application Gateway v2 では、最小インスタンス数と最大インスタンス数の間で自動スケーリングが行われ、トラフィックがアイドル状態の場合でも、少なくとも最小容量に対して料金が発生します。 最小インスタンス数をピークではなくベースライン負荷に設定し、自動スケールでスパイクを吸収します。 最小限の過剰プロビジョニングは、回避可能な Application Gateway コストの一般的なソースです。
設計上の考慮事項
リフトアンドシフトアプリケーション配信設計の焦点
- 再ホストされたアプリの層間の東西トラフィックに対して内部Azure Load Balancerを使用します。これは、アプリが既に依存している負荷分散と一致します。
- インターネットに公開するアプリに対してのみパブリック配信サービスを追加する。移行された内部ワークロードの多くは何も必要ありません。
- 最初のリホスト中は、配信設計をシンプルで単一リージョンに保ちます。
- ワークロードに到達する前に、ハブ ファイアウォールを経由して受信インターネット トラフィックをルーティングします。
アプリケーション配信設計の焦点を最新化する
- アプリケーションの種類で選択します。グローバル Web アプリ (エッジターミネーション、WAF) のAzure Front Doorと、DNS ベースのリージョン配布を必要とする非 Web アプリのAzure Traffic Manager。
- 地域間でアクティブ-アクティブを展開し、各地域のパブリックエンドポイント(ハブファイアウォールの背後にあるSNATおよびDNATとして機能)にトラフィックを分散させます。
- グローバル配信が必要な場合は、Front Doorの裏側で地域のLayer 7ルーティングとTLS終端にApplication Gatewayを使いましょう。
- Front Door と Traffic Manager の両方を同じフローにデプロイしないでください。アプリが Web か Web 以外かに基づいて 1 つ選択します。
クロスクラウド アプリケーション配信の設計に重点を置く
- 他のクラウドからの配信サービスをAzureにマップします。AWS Application Load Balancer または Google Cloud Application Load Balancing to Azure Application Gateway、ネットワーク ロード バランサーを Azure Load Balancer にマップします。
- スポーク内のホスト 層 7 の配信 (WAF を使用した Application Gateway) を使用して、パブリック IP を仮想マシンに直接アタッチしないようにします。
- 移行されたワークロードに到達する前に、セキュリティで保護されたハブ ファイアウォールを介してパブリック イングレスをルーティングします。
- 複数のAzure リージョンでワークロードを実行した後は、複数リージョンの配信に Front Door または Traffic Manager を使用します。
前提条件
アプリケーション配信サービスを実装する前に、次の手順を実行します。
- デプロイされた仮想ネットワーク: サブネットを持つ仮想ネットワークが少なくとも 1 つ必要です。 サブネット計画のガイダンスについては、 仮想ネットワークとサブネットの設計 に関するページを参照してください。
- 識別されるワークロード トラフィックの種類: ワークロードで HTTP/HTTPS (レイヤー 7) と TCP/UDP (レイヤー 4) のどちらを使用しているかを把握します。 このトラフィックタイプが、あなたの主要なロードバランサーの選択を決定します。
- 地理的範囲の定義: ユーザーが 1 つのリージョンにいるか、グローバルに分散されているかを判断します。 グローバルユーザーベースは、Front Doorのエニーキャストアクセラレーションの恩恵を受けます。
- Application Gateway のサブネット容量: Application Gateway には、他のリソースのない専用サブネットが必要です。 /24サブネットは最大125インスタンスと5つのAzure予約アドレスをサポートします。
セキュリティに関する考慮事項
負荷分散サービスは、セキュリティ境界の一部です。 これらは、受信トラフィックを処理する最初のコンポーネントであり、セキュリティ構成が重要になります。 アプリケーション配信レベルを保護するには、次のプラクティスに従います。
Web アプリケーション ファイアウォール (WAF)
すべての運用 Web ワークロードに対して、Application Gateway または Front Door で 防止モード で WAF を有効にします。 検出モードでは、脅威をブロックせずにログに記録するだけです。 初期チューニング時にこれを使用して偽陽性を特定し、その後、本番トラフィックが流れる前に防止モードに切り替えます。
WAF は、次のような一般的な Web 攻撃から保護します。
- SQL インジェクションとクロスサイト スクリプティング (XSS)
- プロトコル異常とリクエストスマグリング
- ボットとクローラー (ボット保護規則付き)
- マネージド ルール セットを使用した OWASP の上位 10 件の脆弱性
Application Gateway WAF と Front Door WAF はどちらも同じルール エンジンを使用しますが、スコープは異なります。 Application Gateway WAF はリージョンデプロイを保護しますが、Front Door WAF はトラフィックが配信元に到達する前にグローバル エッジでポリシーを適用します。 WAF のチューニングと規則セットの構成の詳細については、Web Application Firewallを参照してください。
DDoS 保護
ロードバランシングサービスに関連するすべてのパブリックIPアドレスでAzure DDoS保護を有効にしてください。 Standard Load Balancerパブリック フロントエンド IP と Application Gateway パブリック IP は、ボリューム攻撃の主なターゲットです。 これらの IP は、アプリケーションのエントリ ポイントを表します。
Azure DDoS Protection には次の機能があります。
- 適応型チューニングによる常時稼働のトラフィック監視。
- トラフィックがしきい値を超えたときの自動攻撃の軽減。
- Azure Monitorによる攻撃テレメトリとアラート。
- DDoS攻撃が引き起こすリソーススケーリングのためのコスト保護(サービスクレジット)。
DDoS 保護の計画と構成については、 DDoS 保護を参照してください。
配信元へのプライベート リンク (Front Door Premium)
Azure Front Door Premium では、配信元へのPrivate Link接続がサポートされます。 この機能により、パブリックにアクセス可能なバックエンド サーバーが不要になります。 Front Door は、パブリック インターネットではなく、Azure バックボーン ネットワークを介して配信元に接続します。 Private Link オリジンを使用するのは次の場合です。
- バックエンドは、パブリック IP アドレスを持つべきではない内部サービスです。
- Front Door トラフィックへの配信元アクセスのみをロックダウンする必要があります。
- コンプライアンス要件では、アプリケーション サーバー上のパブリック エンドポイントが禁止されています。
- パブリックに公開された配信元の攻撃対象領域を削除する必要があります。
サポート対象の Private Link 配信元には、App Service、Azure Storage、Application Gateway、内部 Standard Load Balancer、ならびに Private Link サービスを使用するカスタム配信元が含まれます。
Private Linkアーキテクチャ パターンについては、「Azure PaaS サービスへのプライベート アクセス」を参照してください。
Important
Front Door Standard レベルでは、配信元へのPrivate Linkはサポートされていません。 Front Door Premium のみがこの機能を提供します。
相互 TLS (mTLS)
Application Gateway v2 では、バックエンド認証用の相互 TLS がサポートされています。 バックエンド サーバーでゲートウェイからの証明書ベースのクライアント認証が必要な場合は、mTLS を使用します。 この認証により、信頼検証のレイヤーが追加されます。 バックエンドは、トラフィックがゲートウェイを迂回した悪意ある者からではなく、正当なアプリケーションゲートウェイインスタンスから来ていることを確認できます。
関連資料
- ロードバランシングとコンテンツデリバリーとは何か?:Azure Application Gateway、Load Balancer、Front Doorのサービスごとの概要。
- インターネットイングレス: アプリケーションをインターネットに公開する:トラフィックがAzureネットワーク境界に到達する方法。
- 仮想ネットワークとサブネットの設計: Application Gateway 専用サブネットのサイズ設定を含むサブネット計画。
- Azure PaaS サービスへのプライベート アクセス: Front Door Premium から配信元への Private Link パターンを含む。
- 地域横断接続:Front Doorをグローバルなエントリーポイントとするマルチリージョンアーキテクチャ。
- 送信インターネット エグレス: 負荷分散されたバックエンドからのエグレス トラフィック向けの SNAT、アウトバウンド規則、および NAT ゲートウェイ。
詳細情報
- Azure Load Balancerは何ですか?
- Azure Application Gateway とは
- Azure Front Door とは何ですか？
- Azure Front Door の都市圏別エッジ ロケーション
- Azure Load Balancer の信頼性
- Application Gateway インフラストラクチャ構成
- Azure Front Door Premium で Private Link を使用してオリジンを保護します
次のステップ
Tip
あなた自身で探検? 概要ナビゲーターに戻り、機能別に次の記事を見つけます。
リフトアンドシフト体験の次の手順:
インターネットへの送信トラフィックを制御: ハブ ファイアウォールを経由して送信アクセスを一元化し、既定のアウトバウンドを無効にします。
次に、最新化の取り組みを行います。
PaaS サービスへのプライベート接続を設定する: AKS、ASE、およびマネージド データベース ワークロードの各スポーク VNet にPrivate Linkサブネットを作成します。
マルチクラウドへの移行における次のステップ:
クラウド間のトランジット パスをセキュリティで保護する: セキュリティで保護された仮想ハブにAzure Firewallをデプロイして、クラウド間およびインターネットにバインドされたすべてのトラフィックを検査します。