この記事では、ロード バランサーの展開に関する Azure のベスト プラクティスのコレクションについて説明します。 これらのベスト プラクティスは、Azure ネットワークに関する Microsoft の経験と、お客様の経験に基づいています。
それぞれのベスト プラクティスについて、この記事では以下のことを説明します。
- ベスト プラクティスとは
- そのベスト プラクティスを実践する理由
- ベスト プラクティスを実践できない場合に起こりうること
- このベスト プラクティスを実践する方法
これらのベスト プラクティスは、この記事の執筆時点における共通認識と、Azure プラットフォームの能力と機能に基づいています。
アーキテクチャのベスト プラクティス
次のアーキテクチャ ガイダンスは、Azure Load Balancer の展開の信頼性を確保するのに役立ちます。 これには、ゾーン冗長を使用した展開、バックエンド プールでの冗長性、グローバル ロード バランサーに関するベスト プラクティスが含まれています。 これは、Gateway Load Balancer の信頼性と組み合わせて、デュアル ロード バランサーの設定の代わりに NVA を使用する場合に推奨されます。
信頼性についてのベスト プラクティス
Azure Load Balancer の展開の信頼性を確保するには、次のベスト プラクティスをお勧めします。
ゾーン冗長を使用して展開する
ゾーン冗長は、ゾーン障害からデータ パスを保護することで、最適な回復性を実現します。 ロード バランサーの可用性ゾーンの選択は、フロントエンド IP のゾーン選択と同義です。 パブリック ロード バランサーについては、ロード バランサーのフロントエンドのパブリック IP がゾーン冗長である場合、ロード バランサーもゾーン冗長になります。
- 可用性ゾーンをサポートするリージョンにロード バランサーを展開し、フロントエンド IP 構成に使用する新しいパブリック IP アドレスを作成するときにゾーン冗長を有効にします。
- パブリック IP アドレスをゾーン冗長に変更することはできませんが、すべての非ゾーン標準パブリック IP が既定でゾーン冗長になるように更新されています。 詳細については、Microsoft Azure ブログ「Azure パブリック IP は既定でゾーン冗長になりました | Microsoft Azure ブログ」を参照してください。 ゾーン冗長標準パブリック IP を既定でサポートするリージョンの最新の一覧については、「Azure でのパブリック IP アドレス」を参照してください
- ゾーン冗長として展開できない場合は、次のオプションとしてゾーン ロード バランサーを展開します。
- バックエンドが特定のゾーンに集中している場合は、ゾーン フロントエンドが推奨されます。 ただし、ゾーン冗長のメリットを享受するために、バックエンド プール メンバーを複数のゾーンに展開することをお勧めします。
- 既存の展開をゾーンまたはゾーン冗長に移行する場合は、ドキュメント「Load Balancer を可用性ゾーンのサポートに移行する」を参照してください。
バックエンド プールの冗長性
バックエンド プールに 2 つ以上のインスタンスが含まれていることを確認してください。 バックエンド プールにインスタンスが 1 つしかなく、それが正常でない場合、冗長性が不足しているため、バックエンド プールに送信されるすべてのトラフィックが失敗します。 Standard Load Balancer SLA は、バックエンド プールごとに少なくとも 2 つの正常なバックエンド プール インスタンスがある場合にのみサポートされます。 詳細については、SLA のドキュメントを参照してください。
グローバル ロード バランサーを展開する
Standard Load Balancer では、リージョン間の負荷分散がサポートされており、グローバル ロード バランサーを既存のリージョン ロード バランサーにリンクすることで、リージョン冗長を実現できます。 グローバル ロード バランサーを使用すると、1 つのリージョンで障害が発生した場合、トラフィックは次の最も近い正常なリージョン ロード バランサーにルーティングされます。 詳細については、グローバル ロード バランサーのドキュメントを参照してください。
詳細については、Azure Load Balancer の信頼性に関するドキュメントを参照してください。
Gateway Load Balancer の信頼性
Gateway Load Balancer の展開の信頼性を確保するには、次のベスト プラクティスをお勧めします。
Gateway Load Balancer を Standard Public Load Balancer に連結する
Gateway Load Balancer を Standard Public Load Balancer に連結することをお勧めします。 この構成により、NVA とアプリケーション層の両方で高可用性と冗長性が実現します。 詳細については、「チュートリアル: ゲートウェイ ロード バランサーを作成する」を参照してください。
デュアル ロード バランサーの設定の代わりに NVA を使用する場合は、ゲートウェイ ロード バランサーを使用します。
パートナーのネットワーク仮想アプライアンス (NVA) を使用した North-South トラフィック シナリオでは、ゲートウェイ ロード バランサーを使用することをお勧めします。 ゲートウェイ ロード バランサーは、フローの持続性とフロー対称性を維持し、ユーザー定義ルート (UDR) などの追加の構成が必要ないため、展開が容易です。 NVA は簡単に追加および削除できるため、管理も簡単です。 詳細については、Gateway Load Balancer のドキュメントを参照してください。
構成ガイダンス
次の構成ガイダンスは、Azure Load Balancer の展開を構成するためのベスト プラクティスです。
ネットワーク セキュリティ グループ (NSG) を作成する
許可されたインバウンド トラフィックを明示的に許可するには、ネットワーク セキュリティ グループ (NSG) を作成する必要があります。 NSG は、VM のサブネットまたはネットワーク インターフェイス カード (NIC) 上に作成する必要があります。そうしないと、Standard 外部ロード バランサーへのインバウンド接続ができません。 詳細については、「Azure ネットワーク セキュリティ グループを作成、変更、削除する」を参照してください。
IP アドレス 168.63.129.16 のブロックを解除する
IP アドレス 168.63.129.16 が、Azure ネットワーク セキュリティ グループおよびローカル ファイアウォール ポリシーによってブロックされていないことを確認してください。 この IP アドレスにより、Azure Load Balancer の正常性プローブが VM の正常性状態を特定できるようになります。 許可されていない場合、正常性プローブはインスタンスに到達できないため失敗し、インスタンスがダウンしているとマークされます。 詳細については、「Azure Load Balancer の正常性プローブ」と「IP アドレス 168.63.129.16 とは」を参照してください。
手動ポート割り当によるアウトバウンド規則を使用する
SNAT の枯渇や接続エラーを防ぐために、既定のポート割り当ての代わりに手動ポート割り当てによるアウトバウンド規則を使用します。 既定のポート割り当てでは、保守的な数のポートが自動的に割り当てられるため、SNAT ポートが枯渇するリスクが高くなります。 手動ポート割り当てでは、バックエンド プール内の各インスタンスで使用できる SNAT ポートの数を最大化できるため、ポートの再割り当てによる接続への影響を防ぐことができます。 手動ポート割り当てには、"インスタンスあたりのポート数" または "バックエンド インスタンスの最大数" の 2 つのオプションがあります。 両方の考慮事項を理解するには、「アウトバウンド接続での送信元ネットワーク アドレス変換 (SNAT)」を参照してください。
分散モードを確認する
Azure Load Balancer では、既定で 5 タプル ハッシュ ベースの分散モードが使用され、2 タプルまたは 3 タプル ハッシュを使用したセッション永続化も提供されます。 同じクライアント IP または同じクライアント IP とプロトコルからの接続がバックエンド プール内の同じバックエンド インスタンスに送信されるセッション永続性 (セッション アフィニティとも呼ばれます) が、展開に有効かどうかを検討します。 また、セッション アフィニティを有効にすると、ほとんどの接続が同じクライアント IP から行われるか、同じクライアント IP とプロトコルが同じバックエンド VM に送信されるため、負荷分散が不均一になる可能性があることも考慮してください。 Azure Load Balancer の分散モードの詳細については、「Azure Load Balancer の分散モード」を参照してください。
TCP リセットを有効にする
Load Balancer で TCP リセットを有効にすると、アイドル タイムアウト時に双方向 TCP リセット パケットがクライアントとサーバーの両方のエンドポイントに送信され、接続がタイムアウトして使用できなくなったことがアプリケーション エンドポイントに通知されます。 TCP リセットを有効にしないと、フローのアイドル タイムアウトに達したときに、Load Balancer はフローを自動的に削除します。 接続がタイムアウトする場合は、アイドル タイムアウトを増やしたり、TCP キープアライブを使用したりすることも有効です。TCP リセット、アイドル タイムアウト、TCP キープアライブの詳細については、「Azure での Load Balancer の TCP リセットおよびアイドル タイムアウト」を参照してください。
フローティング IP の設定時にループ バック インターフェイスを構成する
フローティング IP を有効にする場合は、ゲスト OS 内にロード バランサーのフロントエンド IP アドレスで構成されたループバック インターフェイスがあることを確認してください。 複数の規則でバックエンド ポートを再利用するには、フローティング IP を有効にする必要があります。 ポートの再利用のユース ケースの例としては、高可用性のためのクラスタリングやネットワーク仮想アプライアンスなどがあります。 詳細については、「Azure Load Balancer のフローティング IP の構成」を参照してください。
Gateway Load Balancer 構成のベスト プラクティスを実装する
信頼されているおよび信頼されていないトラフィックを 2 つの異なるトンネル インターフェイスで分離します。信頼されていない/まだ検査または管理されていないトラフィックにはトンネル インターフェイスの種類 external を使用し、信頼されている/検査されているトラフィックにはトンネル インターフェイスの種類 internal を使用します。 セキュリティのベストプラクティスとして、これにより、信頼されているおよび信頼されていないトラフィックが分離され、よりきめ細かいトラフィック制御とトラブルシューティングが可能になります。
NVA の MTU 制限が少なくとも 1,550 に、またはジャンボ フレームが使用されるシナリオでは推奨制限である 4,000 まで引き上げられていることを確認してください。 MTU 制限を増やさないと、VXLAN ヘッダーによって生成される他のパケットのパケット サイズが大きくなるため、パケット ドロップが発生する可能性があります。
廃止のお知らせ
Azure Load Balancer に対する新しい機能強化と更新に加えて、機能の廃止もあります。 潜在的なサービスの中断を避けるためには、常に最新情報を入手し、必要な変更を確実に行うことが重要です。 廃止のお知らせの詳細な一覧については、Azure の最新情報ページを参照して [製品] の下の [ロード バランサー] と、[更新の種類] の下の [廃止] でフィルター処理してください。
Standard Load Balancer を使用する、またはアップグレードする
Basic Load Balancer は 2025 年 9 月 30 日に廃止されます。お客様はそれまでに Basic Load Balancer から Standard Load Balancer にアップグレードする必要があります。 Standard Load Balancer は、ハイ パフォーマンス、超低遅延、既定でのセキュリティ、99.99% の可用性の SLA など、大幅な改善を実現します。
既定のアウトバウンド アクセスを使用しない
今後は、既定のアウトバウンド アクセスを使用せず、すべての VM に明示的なアウトバウンド メソッドが定義されていることを確認してください。 これは、セキュリティを強化し、VM がインターネットに接続する方法をより詳細に制御するために推奨されます。 既定のアウトバウンド アクセスは 2025 年 9 月 30 日に廃止されます。この日以降に作成された VM は、インターネットとの通信に次のいずれかのアウトバウンド ソリューションを使用する必要があります。
- NAT GW をサブネットに関連付ける
- アウトバウンド規則を介してアウトバウンド用 Load Balancer のフロントエンド IP アドレスを 1 つ以上使用する
- VM にインスタンス レベルのパブリック IP アドレスを割り当てる