Azure Load Balancer の概要

Azure Load Balancer は、アプリケーションに高可用性と優れたネットワーク パフォーマンスを提供します。 Azure Load Balancer は、負荷分散セットで定義されているサービスの正常なインスタンス間で着信トラフィックを分散する、レイヤー 4 (TCP、UDP) ロード バランサーです。

Azure Load Balancer は次のように構成できます。

  • 仮想マシンへの着信インターネット トラフィックを負荷分散します。 この構成は、 インターネットに接続する負荷分散と呼ばれます。
  • 仮想ネットワーク内の仮想マシン間、クラウド サービス内の仮想マシン間、クロスプレミスの仮想ネットワーク内のオンプレミスのコンピューターと仮想マシン間で、トラフィックを負荷分散します。 この構成は、 内部負荷分散と呼ばれます。
  • 外部トラフィックを特定の仮想マシンに転送します。

インターネットから到達できるようにするには、クラウド内のすべてのリソースにパブリック IP アドレスが必要です。 Azure のクラウド インフラストラクチャでは、ルーティング不可能な IP アドレスをリソースに使用します。 インターネットとの通信には、ネットワーク アドレス変換 (NAT) とパブリック IP アドレスが使用されます。

Azure のデプロイメント モデル

Azure クラシック デプロイメント モデルと Resource Manager デプロイメント モデルの違いを理解することが重要です。 各モデルで Azure Load Balancer の構成方法が異なります。

Azure クラシック デプロイ モデル

クラウド サービス境界内にデプロイされた仮想マシンは、ロード バランサーを使用するためにグループ化できます。 このモデルでは、パブリック IP アドレスと完全修飾ドメイン名 (FQDN) がクラウド サービスに割り当てられます。 ロード バランサーはポート変換を実行し、クラウド サービスのパブリック IP アドレスを使用して、ネットワーク トラフィックの負荷を分散します。

負荷分散されるトラフィックは、エンドポイントで定義されています。 ポート変換エンドポイントでは、パブリック IP アドレスに割り当てられたパブリック ポートと、特定の仮想マシンでサービスに割り当てられたローカル ポート間の 1 対 1 の関係を持ちます。 負荷分散エンドポイントでは、パブリック IP アドレスと、クラウド サービス内の仮想マシンでサービスに割り当てられたローカル ポート間の 1 対多の関係を持ちます。

クラシック デプロイ モデルの Azure Load Balancer

図 1 - クラシック デプロイ モデルの Azure Load Balancer

このデプロイ モデルでロード バランサーが使用するパブリック IP アドレスのドメイン ラベルは、<クラウド サービス名>.cloudapp.net です。 次の図は、このモデルの Azure Load Balancer を示しています。

Azure Resource Manager デプロイ モデル

Resource Manager デプロイメント モデルでは、クラウド サービスを作成する必要はありません。 複数の仮想マシン間でトラフィックを明示的にルーティングするためにロード バランサーが作成されます。

パブリック IP アドレスは、ドメイン ラベル (DNS 名) を持つ個別のリソースです。 パブリック IP アドレスは、ロード バランサー リソースに関連付けられます。 ロード バランサー規則と着信 NAT 規則では、負荷分散されたネットワーク トラフィックを受信するリソースのインターネット エンドポイントとしてパブリック IP アドレスを使用します。

プライベートまたはパブリック IP アドレスは、仮想マシンに接続されたネットワーク インターフェイス リソースに割り当てられます。 ネットワーク インターフェイスがロード バランサーのバックエンド IP アドレス プールに追加されると、ロード バランサーは作成された負荷分散規則に基づいて、負荷分散されたネットワーク トラフィックを送信できます。

次の図は、このモデルの Azure Load Balancer を示しています。

リソース マネージャーの Azure Load Balancer

図 2 - Resource Manager の Azure Load Balancer

ロード バランサーは、Resource Manager ベースのテンプレート、API、ツールを使用して管理できます。 Resource Manager の詳細については、Resource Manager の概要に関する記事をご覧ください。

Load Balancer の機能

  • ハッシュベースの分散

    Azure Load Balancer は、ハッシュベースの分散アルゴリズムを使用します。 既定では、ソース IP、ソース ポート、接続先 IP、接続先ポート、プロトコルの種類から成る 5 タプル ハッシュを使用して、使用可能なサーバーにトラフィックをマップします。 これは、トランスポート セッション でのみ持続性を提供します。 同じ TCP セッションまたは UDP セッション内のパケットは、負荷分散されたエンドポイントの背後にある同じインスタンスに送信されます。 クライアントが接続を閉じてから開き直すか、同じソース IP から新しいセッションを開始すると、ソース ポートが変更されます。 そのため、トラフィックは別のデータセンターの別のエンドポイントに送信される可能性があります。

    詳細については、 ロード バランサーの分散モードに関するページをご覧ください。 次の図は、ハッシュベースの分散を示しています。

    ハッシュベースの分散

    図 3 - ハッシュベースの分散

  • ポート フォワーディング

    Azure Load Balancer では、受信通信の管理方法を制御できます。 この通信には、インターネット ホスト、他のクラウド サービス内の仮想マシン、または仮想ネットワークから開始されたトラフィックが含まれます。 この制御は、エンドポイントで表されます (入力エンドポイントとも呼ばれます)。

    入力エンドポイントはパブリック ポートでリッスンし、内部ポートにトラフィックを転送します。 内部エンドポイントと外部エンドポイントには同じポートをマップしたり、別のポートを使用することもできます。 たとえば、パブリック エンドポイントをポート 80 にマップしているときに、Web サーバーがポート 81 をリッスンするように構成できます。 パブリック エンドポイントを作成すると、ロード バランサー インスタンスの作成がトリガーされます。

    Azure ポータルを使用して作成した場合、リモート デスクトップ プロトコル (RDP) およびリモート Windows PowerShell セッションのトラフィック用に、仮想マシンのエンドポイントが自動的に作成されます。 これらのエンドポイントを使用して、インターネット経由で仮想マシンをリモートで管理することができます。

  • 自動再構成

    Azure Load Balancer は、インスタンスがスケール アップまたはスケール ダウンされると、すぐに自身を再構成します。 たとえば、クラウド サービス内の Web/worker ロールのインスタンス数を増やしたときや、同じ負荷分散セットに仮想マシンを追加したときに、この再構成が行われます。

  • サービスの監視

    Azure Load Balancer では、さまざまなサーバー インスタンスの正常性をプローブできます。 プローブで応答できない場合、ロード バランサーは異常なインスタンスへの新しい接続の送信を停止します。 既存の接続は影響を受けません。

    次の 3 種類のプローブがサポートされています。

    • ゲスト エージェント プローブ (サービスとしてのプラットフォーム仮想マシンの場合のみ): ロード バランサーは、仮想マシン内のゲスト エージェントを使用します。 ゲスト エージェントがリッスンし、インスタンスが準備完了状態の場合 (インスタンスがビジー、リサイクル中、停止中などの状態でない場合) にのみ、HTTP 200 OK 応答を返します。 エージェントが HTTP 200 OK で応答できない場合、ロード バランサーは、そのインスタンスを応答不能と見なし、インスタンスへのトラフィックの送信を停止します。 Load Balancer はインスタンスへの ping を続けます。 ゲスト エージェントが、HTTP 200 で応答する場合は、ロード バランサーはそのインスタンスへのトラフィックの送信を再開します。 Web ロールを使用する場合、Web サイト コードは通常、Azure ファブリックやゲスト エージェントでは監視されない w3wp.exe で実行されます。 つまり、w3wp.exe が失敗 (HTTP 500 応答など) してもゲスト エージェントにレポートされず、ロード バランサーはそのインスタンスがローテーションから除外されたことを認識しません。
    • HTTP カスタム プローブ: このプローブは、既定の (ゲスト エージェント) プローブを上書きします。 ユーザーはこれを使用して独自のカスタム ロジックを作成し、ロール インスタンスの正常性を判断できます。 ロード バランサーは、エンドポイントを定期的に調査します (既定では 15 秒ごと)。 タイムアウト期間内 (既定値は 31 秒) にインスタンスが TCP ACK または HTTP 200 で応答した場合は、ローテーション内にあると見なされます。 これは、ロード バランサーのローテーションからインスタンスを削除する、ユーザー独自のロジックを実装する場合に役立ちます。 たとえば、インスタンスが CPU の 90% を超えた場合に 200 以外の状態を返すように、インスタンスを構成できます。 w3wp.exe を使用する Web ロールの場合も、Web サイト コードが失敗するとプローブに 200 以外の状態が返されるため、Web サイトの自動監視が行われます。
    • TCP カスタム プローブ: このプローブは、定義済みプローブ ポートへの正常な TCP セッションの確立に依存します。

    詳細については、「 LoadBalancerProbe schema (LoadBalancerProbe スキーマ)」を参照してください。

  • Source NAT

    サービスからインターネットへのすべての送信トラフィックは、着信トラフィックと同じ VIP アドレスを使用してソース NAT (SNAT) 変換されます。 SNAT には重要な利点があります。

    • VIP を別のサービス インスタンスに動的にマップできるため、サービスのアップグレードや障害復旧が簡単にできます。
    • アクセス制御リスト (ACL) の管理が容易になります。 VIP で表現される ACL は、サービスをスケールアップ、スケールダウン、または再デプロイしても変更されません。

    ロード バランサーの構成では、UDP の Full cone NAT がサポートされます。 Full cone NAT は、ポートが (送信要求に応答して) 任意の外部ホストからの着信接続を許可する NAT の一種です。

    仮想マシンによって開始された新しい送信接続ごとに、送信ポートもロード バランサーによって割り当てられます。 外部ホストは、仮想 IP (VIP) の割り当てポートでトラフィックを認識します。 大量の送信接続が必要なシナリオでは、VM が SNAT 専用の送信 IP アドレスを使用できるように、 インスタンスレベル パブリック IP アドレスを使用することをお勧めします。 これにより、ポートの枯渇のリスクが軽減されます。

    VIP またはインスタンスレベル パブリック IP (PIP) で使用できるポートの最大数は、64,000 です。 これは TCP の標準的な限度です。

仮想マシンの複数の負荷分散された IP アドレスのサポート

負荷分散された複数のパブリック IP アドレスを、一連の仮想マシンに割り当てることができます。 この機能を使用して、複数の SSL Web サイトや複数の SQL Server AlwaysOn 可用性グループ リスナーを同じ仮想マシン セット上にホストすることができます。 詳細については、クラウド サービスごとの複数の VIP に関する記事をご覧ください。

Load Balancer の相違点

Microsoft Azure を使用してネットワーク トラフィックを分散するには、さまざまなオプションがあります。 これらのオプションはそれぞれ動作が異なり、さまざまな機能セットが含まれ、さまざまなシナリオをサポートします。 オプションは単独または組み合わせて使用することができます。

  • Azure Load Balancer は、トランスポート層で動作します (OSI ネットワーク参照モデルの第 4 層)。 これは、同じ Azure データ センターで実行するアプリケーションのインスタンス間で、トラフィックのネットワーク レベルの分散を提供します。
  • Application Gateway は、アプリケーション層で動作します (OSI ネットワーク参照モデルの第 7 層)。 これは、クライアント接続を終了して、バックエンドのエンドポイントへの要求を転送し、リバース プロキシ サービスとして機能します。
  • Traffic Manager は、DNS レベルで動作します。 これは、DNS 応答を使用して、エンドユーザーのトラフィックをグローバルに分散されたエンドポイントに送信します。 その後、クライアントは、それらのエンドポイントに直接接続します。

次の表では、各サービスで提供される機能についてまとめています。

サービス Azure Load Balancer Application Gateway Traffic Manager
テクノロジ トランスポート レベル (第 4 層) アプリケーション レベル (第 7 層) DNS レベル
サポート対象アプリケーション プロトコル 任意 HTTP、HTTPS、および WebSocket 任意 (HTTP エンドポイントはエンドポイントの監視に必要です)
エンドポイント Azure VM と Cloud Services のロール インスタンス 任意の Azure 内部 IP アドレス、パブリック インターネット IP アドレス、Azure VM、または Azure クラウド サービス Azure VM、Cloud Services、Azure Web Apps および外部エンドポイント
VNet のサポート インターネット接続と内部 (VNet) のアプリケーションの両方に使用できます インターネット接続と内部 (VNet) のアプリケーションの両方に使用できます インターネットに接続するアプリケーションのみをサポートします
エンドポイントの監視 プローブ経由でサポート プローブ経由でサポート HTTP/HTTPS GET 経由でサポート

Azure Load Balancer と Application Gateway では、ネットワーク トラフィックをエンドポイントに転送しますが、処理するトラフィックによってさまざまな使用シナリオがあります。 次の表は、2 つのロード バランサーの相違点を理解するために役立ちます。

Azure Load Balancer Application Gateway
プロトコル UDP/TCP HTTP、HTTPS、および WebSocket
IP Reservation サポートされています サポートされていません
負荷分散モード 5 組 (発信元 IP、発信元ポート、接続先 IP、接続先ポート、プロトコルの種類) ラウンド ロビン
URL に基づくルーティング
負荷分散モード (発信元 IP/スティッキー セッション) 2 組 (発信元 IP と接続先 IP)、3 組 (発信元 IP、接続先 IP、および接続先ポート)。 仮想マシンの数に基づいて、スケールアップまたはスケールダウンできます Cookie ベースのアフィニティ
URL に基づくルーティング
正常性プローブ 既定値: プローブ間隔 -15 秒。 循環から除外: 2 回連続のエラー。 ユーザー定義のプローブをサポートします アイドル状態のプローブ間隔 30 秒。 5 回連続するライブ トラフィック障害またはアイドル モードでの単一のプローブ障害の後に除外。 ユーザー定義のプローブをサポートします
SSL オフロード サポートされていません サポートされています
URL ベースのルーティング サポートされていません サポートされています
SSL ポリシー サポートされていません サポートされています

次のステップ

インターネットに接続するロード バランサーの概要

内部ロード バランサーの概要

インターネットに接続するロード バランサーの作成の開始