Azure Load Balancer の概要What is Azure Load Balancer?

Azure Load Balancer を使うと、アプリケーションを拡張し、サービスを高可用性にすることができます。With Azure Load Balancer, you can scale your applications and create high availability for your services. Load Balancer は受信と送信のどちらのシナリオもサポートし、低遅延と高スループットを実現できるだけでなく、あらゆる TCP アプリケーションと UDP アプリケーションの数百万ものフローにスケールアップできます。Load Balancer supports inbound and outbound scenarios, provides low latency and high throughput, and scales up to millions of flows for all TCP and UDP applications.

Load Balancer は、ロード バランサーのフロントエンドで到着した新しい受信フローを、ルールと正常性プローブに従って、バックエンド プールのインスタンスに分配します。Load Balancer distributes new inbound flows that arrive on the Load Balancer's frontend to backend pool instances, according to rules and health probes.

さらに、パブリック ロード バランサー は、プライベート IP アドレスをパブリック IP アドレスに変換することによって、仮想ネットワーク内の仮想マシン (VM) の送信接続を提供できます。Additionally, a public Load Balancer can provide outbound connections for virtual machines (VMs) inside your virtual network by translating their private IP addresses to public IP addresses.

Azure Load Balancer は、Basic と Standard の 2 種類の SKU で使用できます。Azure Load Balancer is available in two SKUs: Basic and Standard. 両者の間には、スケール、機能、および料金の違いがあります。There are differences in scale, features, and pricing. Basic Load Balancer で可能なシナリオをすべて、Standard Load Balancer でも作成できますが、アプローチは若干異なる場合があります。Any scenario that's possible with Basic Load Balancer can also be created with Standard Load Balancer, although the approaches might differ slightly. Load Balancer について学習するときは、基礎および SKU 固有の違いを理解することが重要です。As you learn about Load Balancer, it is important to familiarize yourself with the fundamentals and SKU-specific differences.

ロード バランサーを使用する理由Why use Load Balancer?

Azure Load Balancer を使って次のことができます。You can use Azure Load Balancer to:

  • 受信インターネット トラフィックを VM に負荷分散します。Load-balance incoming internet traffic to your VMs. この構成は、パブリック ロード バランサーと呼ばれます。This configuration is known as a Public Load Balancer.
  • 仮想ネットワーク内の VM 間にトラフィックを負荷分散します。Load-balance traffic across VMs inside a virtual network. ハイブリッド シナリオでは、オンプレミスのネットワークから Load Balancer フロントエンドに到達することもできます。You can also reach a Load Balancer front end from an on-premises network in a hybrid scenario. どちらのシナリオでも、内部ロード バランサーと呼ばれる構成が使われます。Both scenarios use a configuration that is known as an Internal Load Balancer.
  • 受信ネットワーク アドレス変換 (NAT) 規則を使って、特定の VM 上の特定のポートに、トラフィックをポート転送します。Port forward traffic to a specific port on specific VMs with inbound network address translation (NAT) rules.
  • パブリック ロード バランサー を使って、仮想ネットワーク内の VM に送信接続を提供します。Provide outbound connectivity for VMs inside your virtual network by using a public Load Balancer.

注意

Azure では、ユーザーのシナリオのためにフル マネージドの負荷分散ソリューションのスイートが提供されます。Azure provides a suite of fully managed load-balancing solutions for your scenarios. トランスポート層セキュリティ (TLS) プロトコル終端 ("SSL オフロード") または HTTP/HTTPS 要求によるアプリケーション レイヤーの処理が必要な場合は、「Application Gateway」をご覧ください。If you are looking for Transport Layer Security (TLS) protocol termination ("SSL offload") or per-HTTP/HTTPS request, application-layer processing, review Application Gateway. グローバル DNS の負荷分散が必要な場合は、「Traffic Manager」をご覧ください。If you are looking for global DNS load balancing, review Traffic Manager. 実際のエンド ツー エンドのシナリオでは、必要に応じてこれらのソリューションを組み合わせると役に立つことがあります。Your end-to-end scenarios might benefit from combining these solutions as needed.

Load Balancer リソースとはWhat are Load Balancer resources?

ロード バランサー リソースは、パブリック ロード バランサーまたは内部ロード バランサーとして存在できます。A Load Balancer resource can exist as either a public Load Balancer or an internal Load Balancer. Load Balancer リソースの機能は、フロントエンド、ルール、正常性プローブ、バックエンド プール定義として表されます。The Load Balancer resource's functions are expressed as a front end, a rule, a health probe, and a backend pool definition. VM からバックエンド プールを指定することにより、VM をバックエンド プールに配置します。You place VMs into the backend pool by specifying the backend pool from the VM.

Load Balancer リソースはオブジェクトであり、その中では、ユーザーが作成したいシナリオを実現するために Azure がそのマルチ テナント インフラストラクチャをプログラミングする方法を表すことができます。Load Balancer resources are objects within which you can express how Azure should program its multi-tenant infrastructure to achieve the scenario that you want to create. Load Balancer リソースと実際のインフラストラクチャの間に直接的な関係はありません。There is no direct relationship between Load Balancer resources and actual infrastructure. Load Balancer を作成してもインスタンスは作成されず、容量は常に利用できます。Creating a Load Balancer doesn't create an instance, and capacity is always available.

ロード バランサーの基本機能Fundamental Load Balancer features

ロード バランサーは、TCP および UDP アプリケーションに対して次の基本機能を提供します。Load Balancer provides the following fundamental capabilities for TCP and UDP applications:

  • 負荷分散Load balancing

    Azure Load Balancer では、負荷分散規則を作成して、フロントエンドに到着したトラフィックをバックエンド プールのインスタンスに分散させることができます。With Azure Load Balancer, you can create a load-balancing rule to distribute traffic that arrives at frontend to backend pool instances. 受信フローの分配にはハッシュ アルゴリズムが使われ、バックエンド プール インスタンスへのフローのヘッダーが適宜書き換えられます。Load Balancer uses a hash-based algorithm for distribution of inbound flows and rewrites the headers of flows to backend pool instances accordingly. バックエンド エンドポイントが正常であることを正常性プローブが示している場合、サーバーは新しいフローを受信できます。A server is available to receive new flows when a health probe indicates a healthy backend endpoint.

    既定では、Load Balancer はソース IP アドレス、ソース ポート、接続先 IP アドレス、接続先ポート、IP プロトコル番号から成る 5 タプル ハッシュを使って、使用可能なサーバーにフローをマップします。By default, Load Balancer uses a 5-tuple hash composed of source IP address, source port, destination IP address, destination port, and IP protocol number to map flows to available servers. 特定の規則に 2 または 3 タプルのハッシュをオプトインすることにより、特定のソース IP アドレスにアフィニティを作成できます。You can choose to create affinity to a specific source IP address by opting into a 2- or 3-tuple hash for a given rule. 同じパケット フローのすべてのパケットは、負荷分散されたフロントエンドの背後にある同じインスタンスに到着します。All packets of the same packet flow arrive on the same instance behind the load-balanced front end. クライアントが同じソース IP アドレスから新しいフローを開始すると、ソース ポートが変化します。When the client initiates a new flow from the same source IP, the source port changes. 結果として得られる 5 タプルにより、トラフィックは異なるバックエンド エンドポイントに送られることがあります。As a result, the 5-tuple might cause the traffic to go to a different backend endpoint.

    詳しくは、Load Balancer の分散モードに関するページをご覧ください。For more information, see Load Balancer distribution mode. 次の図は、ハッシュベースの分散を示しています。The following image displays the hash-based distribution:

    ハッシュベースの分散

    図; ハッシュベースの分散Figure: Hash-based distribution

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

    Load Balancer では、受信 NAT 規則を作成して、特定のフロントエンド IP アドレスの特定のポートから、仮想ネットワーク内の特定のバックエンド インスタンスの特定のポートに、トラフィックをポート転送できます。With Load Balancer, you can create an inbound NAT rule to port forward traffic from a specific port of a specific frontend IP address to a specific port of a specific backend instance inside the virtual network. これも、負荷分散と同じハッシュ ベースの分散によって実現されます。This is also accomplished by the same hash-based distribution as load balancing. この機能の一般的なシナリオは、Azure Virtual Network 内の個別の VM インスタンスへのリモート デスクトップ プロトコル (RDP) または Secure Shell (SSH) セッションです。Common scenarios for this capability are Remote Desktop Protocol (RDP) or Secure Shell (SSH) sessions to individual VM instances inside the Azure Virtual Network. 複数の内部エンドポイントを、同じフロントエンド IP アドレスのさまざまなポートにマップできます。You can map multiple internal endpoints to the various ports on the same frontend IP address. フロントエンド IP アドレスを使って、追加のジャンプ ボックスがなくても、インターネット経由で VM をリモート管理できます。You can use the fronend IP addresses to remotely administer your VMs over the internet without the need for an additional jump box.

  • アプリケーションに対する独立性と透過性Application agnostic and transparent

    ロード バランサーは、TCP、UDP、またはアプリケーション レイヤーとは直接対話せず、任意の TCP または UDP アプリケーション シナリオをサポートできます。Load Balancer does not directly interact with TCP or UDP or the application layer, and any TCP or UDP application scenario can be supported. Load Balancer は、フローを終了または開始することはなく、フローのペイロードとやり取りせず、アプリケーション レイヤーのゲートウェイ機能を提供せず、プロトコルのハンドシェイクは常にクライアントとバックエンド プール インスタンス間で直接行われます。Load Balancer does not terminate or originate flows, interact with the payload of the flow, provides no application layer gateway function, and protocol handshakes always occur directly between the client and the backend pool instance. 受信フローへの応答は常に、仮想マシンからの応答です。A response to an inbound flow is always a response from a virtual machine. 仮想マシンにフローが到着するときは、元のソース IP アドレスも保持されます。When the flow arrives on the virtual machine, the original source IP address is also preserved. 以下は透過性を示す他の例です。A couple of examples to further illustrate transparency:

    • すべてのエンドポイントは、VM によってのみ応答されます。Every endpoint is only answered by a VM. たとえば、TCP ハンドシェイクは常に、クライアントと選択されたバックエンド VM の間で行われます。For example, a TCP handshake always occurs between the client and the selected backend VM. フロントエンドへの要求に対する応答は、バックエンドの VM によって生成される応答です。A response to a request to a front end is a response generated by backend VM. フロントエンドへの接続を正常に検証するときは、少なくとも 1 つのバックエンド仮想マシンへのエンド ツー エンドの接続を検証していることになります。When you successfully validate connectivity to a frontend, you are validating the end to end connectivity to at least one backend virtual machine.
    • アプリケーション ペイロードは Load Balancer に対して透過的であり、任意の UDP または TCP アプリケーションをサポートすることができます。Application payloads are transparent to Load Balancer and any UDP or TCP application can be supported. HTTP 要求ごとの処理またはアプリケーション レイヤー ペイロードの操作を必要とするワークロードの場合 (たとえば、HTTP URL の解析)、Application Gateway のようなレイヤー 7 のロード バランサーを使う必要があります。For workloads which require per HTTP request processing or manipulation of application layer payloads (for example, parsing of HTTP URLs), you should use a layer 7 load balancer like Application Gateway.
    • Load Balancer は TCP ペイロードに依存せず、TLS のオフロード ("SSL") は提供されないので、Load Balancer を使ってエンド ツー エンドの暗号化シナリオを構築し、VM 自体において TLS 接続を終了することによって TLS アプリケーションの大規模なスケールアウトを実現できます。Because Load Balancer is agnostic to the TCP payload and TLS offload ("SSL") is not provided, you can build end to end encrypted scenarios using Load Balancer and gain large scale-out for TLS applications by terminating the TLS connection on the VM itself. たとえば、TLS セッションのキー容量は、バックエンド プールに追加する VM の数と種類によってのみ制限されます。For example, your TLS session keying capacity is only limited by the type and number of VMs you add to the backend pool. "SSL オフロード"、アプリケーション レイヤーの処理、または Azure への証明書管理の委任を必要とする場合は、Azure のレイヤー 7 ロード バランサーである Application Gateway を代わりに使う必要があります。If you require "SSL offloading", application layer treatment, or wish to delegate certificate management to Azure, you should use Azure's layer 7 load balancer Application Gateway instead.
  • 自動再構成Automatic reconfiguration

    Load Balancer は、インスタンスがスケール アップまたはスケール ダウンされると、すぐに自身を再構成します。Load Balancer instantly reconfigures itself when you scale instances up or down. バックエンド プールの VM を追加または削除すると、Load Balancer リソースの追加操作なしに、Load Balancer が再構成されます。Adding or removing VMs from the backend pool reconfigures the Load Balancer without additional operations on the Load Balancer resource.

  • 正常性プローブHealth probes

    バックエンド プール内のインスタンスの正常性を判断するため、Load Balancer はユーザーが定義した正常性プローブを使います。To determine the health of instances in the backend pool, Load Balancer uses health probes that you define. プローブで応答できない場合、Load Balancer は異常なインスタンスへの新しい接続の送信を停止します。When a probe fails to respond, the Load Balancer stops sending new connections to the unhealthy instances. 既存の接続は影響を受けず、アプリケーションがフローを終了するか、アイドル タイムアウトが発生するか、または VM がシャットダウンするまで続けられます。Existing connections are not affected, and they continue until the application terminates the flow, an idle timeout occurs, or the VM is shut down.

    ロード バランサーは、TCP、HTTP と HTTPS エンドポイント用に別の正常性プローブの種類を提供します。Load Balancer provides different health probe types for TCP, HTTP, and HTTPS endpoints.

    さらに、Classic クラウド サービスを使用している場合、追加の種類であるゲスト エージェントが許可されます。Additionally, when using Classic cloud services, an additional type is allowed: Guest agent. これは、最終手段の正常性プローブとなるように検討されるべきであり、他のオプションが有効な場合は推奨されません。This should be considered to be a health probe of last resort and is not recommended when other options are viable.

  • 送信接続 (SNAT)Outbound connections (SNAT)

    仮想ネットワーク内のプライベート IP アドレスから、インターネット上のパブリック IP アドレスへのすべての送信フローは、Load Balancer のフロントエンド IP アドレスに変換できます。All outbound flows from private IP addresses inside your virtual network to public IP addresses on the internet can be translated to a frontend IP address of the Load Balancer. パブリック フロントエンドが負荷分散規則によってバックエンドの VM に関連付けられていると、Azure は送信接続がパブリック フロントエンドの IP アドレスに自動的に変換されるようにプログラムします。When a public front end is tied to a backend VM by way of a load balancing rule, Azure programs outbound connections to be automatically translated to the public frontend IP address.

    • フロントエンドを別のサービス インスタンスに動的にマップできるため、サービスのアップグレードやディザスター リカバリーが簡単にできます。Enable easy upgrade and disaster recovery of services, because the front end can be dynamically mapped to another instance of the service.
    • 容易なアクセス制御リスト (ACL) の管理。Easier access control list (ACL) management to. フロントエンド IP で表わされる ACL は、サービスをスケールアップ、スケールダウン、または再デプロイしても変更されません。ACLs expressed in terms of frontend IPs do not change as services scale up or down or get redeployed. 送信接続をマシンより少ない数の IP アドレスに変換すると、ホワイトリストの作業負荷を軽減できます。Translating outbound connections to a smaller number of IP addresses than machines can reduce the burden of whitelisting.

      詳しくは、送信接続に関するページをご覧ください。For more information, see outbound connections.

Standard Load Balancer には、これらの基礎には含まれない追加の SKU 固有機能があります。Standard Load Balancer has additional SKU-specific capabilities beyond these fundamentals. 詳しくは、この記事の残りの部分をご覧ください。Review the remainder of this article for details.

Load Balancer の SKU の比較Load Balancer SKU comparison

Load Balancer は、Basic と Standard 両方の SKU をサポートし、シナリオのスケール、機能、価格はそれぞれ異なります。Load Balancer supports both Basic and Standard SKUs, each differing in scenario scale, features, and pricing. Basic Load Balancer で可能なシナリオをすべて、Standard Load Balancer でも作成できます。Any scenario that's possible with Basic Load Balancer can be created with Standard Load Balancer as well. 実際、両方の SKU の API は似ており、SKU を指定することによって呼び出されます。In fact, the APIs for both SKUs are similar and invoked through the specification of a SKU. Load Balancer の SKU とパブリック IP をサポートするための API は、2017-08-01 API から使用できるようになりました。The API for supporting SKUs for Load Balancer and the public IP is available starting with the 2017-08-01 API. 一般的な API と構造は、どちらの SKU でも同じです。Both SKUs have the same general API and structure.

ただし、どちらの SKU を選ぶかにより、完全なシナリオ構成は若干異なる可能性があります。However, depending on which SKU you choose, the complete scenario configuration might differ slightly. Load Balancer のドキュメントでは、記事が特定の SKU だけに適用される場合は、そのことが示されています。Load Balancer documentation calls out when an article applies only to a specific SKU. 違いを比較して理解するには、次の表をご覧ください。To compare and understand the differences, see the following table. 詳しくは、「Azure Standard Load Balancer の概要」をご覧ください。For more information, see Standard Load Balancer overview.

注意

新しい設計では、Standard Load Balancer の採用をお勧めします。New designs should adopt Standard Load Balancer.

スタンドアロン VM、可用性セット、および仮想マシン スケール セットは、どちらか一方の SKU にのみ接続でき、両方には接続できません。Standalone VMs, availability sets, and virtual machine scale sets can be connected to only one SKU, never both. パブリック IP アドレスで使うときは、Load Balancer とパブリック IP アドレスの SKU が一致していなければなりません。When you use them with public IP addresses, both Load Balancer and the public IP address SKU must match. Load Balancer とパブリック IP の SKU は変更できません。Load Balancer and public IP SKUs are not mutable.

"まだ必須ではありませんが、SKU を明示的に指定するのが最善の方法です。"It is a best practice to specify the SKUs explicitly, even though it is not yet mandatory. 現時点では、必要な変更は最小限に抑えられています。At this time, required changes are being kept to a minimum. SKU を指定しないと、Basic SKU の 2017-08-01 API バージョンを使用する意図があるものと解釈されます。If a SKU is not specified, it is interpreted as an intention to use the 2017-08-01 API version of the Basic SKU.

重要

Standard Load Balancer は新しい Load Balancer 製品であり、基本的に Basic Load Balancer のスーパーセットです。Standard Load Balancer is a new Load Balancer product and largely a superset of Basic Load Balancer. 2 つの製品の間には重要で意図的な違いがあります。There are important and deliberate differences between the two products. Basic Load Balancer で可能なエンド ツー エンドのシナリオはすべて、Standard Load Balancer でも作成できます。Any end-to-end scenario that's possible with Basic Load Balancer can also be created with Standard Load Balancer. Basic Load Balancer を既に使ったことがある場合は、Standard Load Balancer に使い慣れて、Standard と Basic の動作での最新の変更と、その影響を理解する必要があります。If you're already used to Basic Load Balancer, you should familiarize yourself with Standard Load Balancer to understand the latest changes in behavior between Standard and Basic and their impact. このセクションの内容を慎重に検討してください。Review this section carefully.

Standard SKUStandard SKU Basic SKUBasic SKU
バックエンド プールのサイズBackend pool size 最大 1000 インスタンスをサポートSupports up to 1000 instances 最大 100 インスタンスをサポートSupports up to 100 instances
バックエンド プール エンドポイントBackend pool endpoints 仮想マシン、可用性セット、仮想マシン スケール セットの組み合わせを含む、単一の仮想ネットワーク内の任意の仮想マシン。Any virtual machine in a single virtual network, including blend of virtual machines, availability sets, virtual machine scale sets. 単一の可用性セットまたは仮想マシン スケール セット内の仮想マシン。Virtual machines in a single availability set or virtual machine scale set.
正常性プローブHealth probes TCP、HTTP、HTTPSTCP, HTTP, HTTPS TCP、HTTPTCP, HTTP
正常性プローブ ダウン動作Health probe down behavior インスタンス プローブがダウンし、かつ すべてのプローブがダウンしても TCP 接続は存続。TCP connections stay alive on instance probe down and on all probes down. インスタンス プローブがダウンしても TCP 接続は存続。TCP connections stay alive on instance probe down. すべてのプローブがダウンすると、すべての TCP 接続が終了。All TCP connections end when on all probes are down.
可用性ゾーンAvailability Zones Standard SKU では、受信と送信に対するゾーン冗長とゾーン フロントエンド、送信フロー マッピングによりゾーン障害に耐久、ゾーン間の負荷分散。In Standard SKU, zone-redundant and zonal frontends for inbound and outbound, outbound flows mappings survive zone failure, cross-zone load balancing. 利用不可Not Available
診断Diagnostics Azure Monitor、バイト カウンターとパケット カウンターを含む多次元メトリック、正常性プローブの状態、接続試行 (TCP SYN)、送信接続の正常性 (SNAT 成功および失敗のフロー)、アクティブなデータ プレーン測定Azure Monitor, multi-dimensional metrics including byte and packet counters, health probe status, connection attempts (TCP SYN), outbound connection health (SNAT successful and failed flows), active data plane measurements パブリック ロード バランサーに対する Azure Log Analytics のみ、SNAT 枯渇アラート、バックエンド プール正常性カウント。Azure Log Analytics for public Load Balancer only, SNAT exhaustion alert, backend pool health count.
HA ポートHA Ports 内部ロード バランサーInternal Load Balancer 使用できません。Not available
既定でのセキュリティ保護Secure by default パブリック IP とロード バランサー エンドポイントに対して受信を拒否する既定設定を使用して、トラフィックが流れるようにネットワーク セキュリティ グループでホワイトリストに明示的に登録できる。Use default inbound closed for public IP and Load Balancer endpoints and a network security group to explicitly whitelist for traffic to flow. 既定でオープン、ネットワーク セキュリティ グループは任意。Default open, network security group optional.
送信接続 (アウトバウンド接続)Outbound connections 送信規則を使用して、プールに基づく送信 NAT を明示的に定義できます。You can explicitly define pool-based outbound NAT with outbound rules. 負荷分散規則のオプトアウトごとに複数のフロントエンドを使用できます。仮想マシンが送信接続 (アウトバウンド接続) を使用するためには、送信シナリオを明示的に作成する 必要がありますYou can use multiple frontends with per load balancing rule opt-out. An outbound scenario must be explicitly created for the virtual machine to use outbound connectivity. 仮想ネットワーク サービス エンドポイントには送信接続 (アウトバウンド接続) なしで到達でき、処理されたデータにはカウントされません。Virtual Network Service Endpoints can be reached without outbound connectivity and don't count towards data processed. VNet サービス エンドポイントとして使用できない Azure PaaS サービスなどのすべてのパブリック IP アドレスは、送信接続 (アウトバウンド接続) を介して到達する必要があり、処理されたデータにカウントされます。Any public IP addresses, including Azure PaaS services not available as VNet Service Endpoints, must be reached via outbound connectivity and count towards data processed. 内部ロード バランサーだけが仮想マシンに対応しているときは、既定の SNAT による送信接続は利用できません。代わりに アウトバウンド規則を使用してください。When only an internal Load Balancer is serving a virtual machine, outbound connections via default SNAT aren't available; use outbound rules instead. 送信 SNAT プログラミングは、受信負荷分散ルールのプロトコルに基づくトランスポート プロトコル固有です。Outbound SNAT programming is transport protocol specific based on protocol of the inbound load balancing rule. 単一のフロントエンド。複数のフロントエンドが存在する場合は、ランダムに選ばれます。Single frontend, selected at random when multiple frontends are present. 内部ロード バランサーだけが仮想マシンに対応している場合は、既定の SNAT が使われます。When only internal Load Balancer is serving a virtual machine, default SNAT is used.
送信規則Outbound Rules 宣言型の NAT 構成、どのパブリック IP アドレスまたはパブリック IP プレフィックスを含めるか、構成可能な送信アイドル タイムアウト、カスタム SNAT ポートの割り当てDeclarative outbound NAT configuration, including which public IP address or public IP prefix, configurable outbound idle timeout, custom SNAT port allocation 使用できません。Not available
アイドルの TCP リセットTCP Reset on Idle 任意のルールの TCP アイドル タイムアウト に対する TCP リセット (TCP RST) を有効にするEnable TCP Reset (TCP RST) on Idle Timeout on any rule 使用できません。Not available
複数のフロントエンドMultiple frontends 受信および送信Inbound and outbound 受信のみInbound only
管理操作Management Operations ほとんどの操作は 30 秒未満Most operations < 30 seconds 一般に 60 ~ 90 秒以上。60-90+ seconds typical.
SLASLA 2 つの正常な仮想マシンが存在するデータ パスで 99.99%。99.99% for data path with two healthy virtual machines. VM SLA で暗黙Implicit in VM SLA.
価格Pricing ルールの数、リソースに関連付けられた受信または送信で処理されたデータに基づいて課金。Charged based on number of rules, data processed inbound, or outbound associated with resource. 課金なしNo charge

詳しくは、Load Balancer のサービスの制限に関する記事をご覧ください。For more information, see service limits for Load Balancer. Standard Load Balancer について詳しくは、概要価格SLA に関するページもご覧ください。For Standard Load Balancer details, see overview, pricing, and SLA.

概念Concepts

パブリック ロード バランサーPublic Load Balancer

パブリック ロード バランサー は、着信トラフィックのパブリック IP アドレスとポート番号を VM のプライベート IP アドレスとポート番号にマップし、VM からの応答トラフィックはその逆にマップします。A public Load Balancer maps the public IP address and port number of incoming traffic to the private IP address and port number of the VM, and vice versa for the response traffic from the VM. 負荷分散規則を適用することで、特定の種類のトラフィックを複数の VM やサービスに分散できます。By applying load-balancing rules, you can distribute specific types of traffic across multiple VMs or services. たとえば、複数の Web サーバー間で Web 要求のトラフィックの負荷を分散できます。For example, you can spread the load of web request traffic across multiple web servers.

次の図は、Web トラフィック用の負荷分散されたエンドポイントを示しています。このエンドポイントでは、3 台の VM でパブリックと TCP ポート 80 が共有されます。The following figure shows a load-balanced endpoint for web traffic that is shared among three VMs for the public and TCP port 80. この 3 台の VM は、1 つの負荷分散セット内にあります。These three VMs are in a load-balanced set.

パブリック ロード バランサーの例

図: パブリック ロード バランサー を使った Web トラフィックの負荷分散Figure: Load balancing web traffic by using a public Load Balancer

複数のインターネット クライアントが TCP ポート 80 で Web アプリのパブリック IP アドレスに Web ページ要求を送信すると、Azure Load Balancer は負荷分散セット内の 3 台の VM にこれらの要求を分散します。When internet clients send webpage requests to the public IP address of a web app on TCP port 80, Azure Load Balancer distributes the requests across the three VMs in the load-balanced set. Load Balancer のアルゴリズムの詳細については、この記事の Load Balancer の機能に関するセクションをご覧ください。For more information about Load Balancer algorithms, see the Load Balancer features section of this article.

既定では、Azure Load Balancer は、ネットワーク トラフィックを複数の VM インスタンスに均等に分散させます。By default, Azure Load Balancer distributes network traffic equally among multiple VM instances. セッション アフィニティを構成することもできます。You can also configure session affinity. 詳しくは、Load Balancer の分散モードに関するページをご覧ください。For more information, see Load Balancer distribution mode.

内部ロード バランサーInternal Load Balancer

内部 Load Balancer は、仮想ネットワーク内のリソースまたは VPN を使って Azure インフラストラクチャにアクセスするリソースにのみトラフィックを送信します。An internal Load Balancer directs traffic only to resources that are inside a virtual network or that use a VPN to access Azure infrastructure. この点で、内部ロード バランサーはパブリック ロード バランサーと異なります。In this respect, an internal Load Balancer differs from a public Load Balancer. Azure インフラストラクチャでは、仮想ネットワークの負荷分散フロントエンド IP アドレスへのアクセスが制限されます。Azure infrastructure restricts access to the load-balanced frontend IP addresses of a virtual network. フロントエンド IP アドレスと仮想ネットワークは、インターネット エンドポイントに直接公開されることはありません。frontend IP addresses and virtual networks are never directly exposed to an internet endpoint. 社内の基幹業務アプリケーションは Azure で実行され、Azure 内またはオンプレミス リソースからアクセスされます。Internal line-of-business applications run in Azure and are accessed from within Azure or from on-premises resources.

内部ロード バランサーにより、次の種類の負荷分散が可能になります。An internal Load Balancer enables the following types of load balancing:

  • 仮想ネットワーク内: 仮想ネットワーク内の VM から、同じ仮想ネットワーク内に存在する一連の VM に負荷を分散する。Within a virtual network: Load balancing from VMs in the virtual network to a set of VMs that reside within the same virtual network.
  • クロスプレミス仮想ネットワークの場合: オンプレミスのコンピューターから、同じ仮想ネットワーク内に存在する一連の VM に負荷を分散する。For a cross-premises virtual network: Load balancing from on-premises computers to a set of VMs that reside within the same virtual network.
  • 多層アプリケーションの場合: バックエンド層がインターネットに接続しない、インターネットに接続する多層アプリケーションの負荷を分散する。For multi-tier applications: Load balancing for internet-facing multi-tier applications where the backend tiers are not internet-facing. バックエンド層では、インターネットに接続する層からのトラフィックを負荷分散する必要があります (次の図を参照)。The backend tiers require traffic load-balancing from the internet-facing tier (see the next figure).
  • 基幹業務アプリケーションの場合: ロード バランサーのハードウェアやソフトウェアを追加せずに、Azure でホストされている基幹業務アプリケーションの負荷を分散する。For line-of-business applications: Load balancing for line-of-business applications that are hosted in Azure without additional load balancer hardware or software. このシナリオには、トラフィックが負荷分散されるコンピューターのセットに含まれるオンプレミスのサーバーが含まれます。This scenario includes on-premises servers that are in the set of computers whose traffic is load-balanced.

内部ロード バランサーの例

図: パブリック ロード バランサーと内部ロード バランサーの両方を使った、多層アプリケーションの負荷分散Figure: Load balancing multi-tier applications by using both public and internal Load Balancer

価格Pricing

Standard Load Balancer の使用には、構成済みの負荷分散規則の数と、処理された受信および送信データの量に基づいて課金されます。Standard Load Balancer usage is charged based on the number of configured load-balancing rules and the amount of processed inbound and outbound data. Standard Load Balancer の価格の情報については、Load Balancer の価格に関するページをご覧ください。For Standard Load Balancer pricing information, go to the Load Balancer pricing page.

Basic Load Balancer は無料で提供されます。Basic Load Balancer is offered at no charge.

SLASLA

Standard Load Balancer の SLA については、Load Balancer の SLA に関するページをご覧ください。For information about the Standard Load Balancer SLA, go to the Load Balancer SLA page.

制限事項Limitations

  • Load Balancer は TCP または UDP 製品であり、これらの特定の IP プロトコルに対する負荷分散とポート フォワーディングを行います。Load Balancer is a TCP or UDP product for load balancing and port forwarding for these specific IP protocols. 負荷分散規則と受信 NAT 規則は TCP および UDP についてサポートされており、ICMP を含む他の IP プロトコルについてはサポートされていません。Load balancing rules and inbound NAT rules are supported for TCP and UDP and not supported for other IP protocols including ICMP. Load Balancer は、UDP または TCP のフローのペイロードを終了したり、それに応答したり、それ以外の対話を行うことはありません。Load Balancer does not terminate, respond, or otherwise interact with the payload of a UDP or TCP flow. プロキシではありません。It is not a proxy. フロントエンドへの接続の検証が、負荷分散または受信 NAT 規則 (TCP または UDP) で使用されるのと同じプロトコルの帯域内で成功する必要があり、"かつ"、仮想マシンの少なくとも 1 つがクライアントに対するフロントエンドからの応答を生成する必要があります。Successful validation of connectivity to a frontend must take place in-band with the same protocol used in a load balancing or inbound NAT rule (TCP or UDP) and at least one of your virtual machines must generate a response for a client to see a response from a frontend. Load Balancer フロントエンドからの帯域内応答を受け取らない場合は、仮想マシンが応答できないことを示します。Not receiving an in-band response from the Load Balancer frontend indicates no virtual machines were able to respond. 応答できる仮想マシンがない状態で、Load Balancer フロントエンドと対話することはできません。It is not possible to interact with a Load Balancer frontend without a virtual machine able to respond. これは、ポート マスカレード SNAT が TCP および UDP に対してのみサポートされている送信接続にも当てはまります。ICMP などの他の IP プロトコルも失敗します。This also applies to outbound connections where port masquerade SNAT is only supported for TCP and UDP; any other IP protocols including ICMP will also fail. 軽減のためにインスタンスレベルのパブリック IP アドレスを割り当てます。Assign an instance-level Public IP address to mitigate.
  • 仮想ネットワーク内のプライベート IP アドレスからパブリック IP アドレスに遷移するときに送信接続を提供するパブリック ロード バランサーとは異なり、内部ロード バランサーは、内部ロード バランサーのフロントエンドへの送信発信接続を変換しません (両方ともプライベート IP アドレス空間内にあるため)。Unlike public Load Balancers which provide outbound connections when transitioning from private IP addresses inside the virtual network to public IP addresses, internal Load Balancers do not translate outbound originated connections to the frontend of an internal Load Balancer as both are in private IP address space. これにより、変換が必要ない固有内部 IP アドレス空間内で SNAT ポートの枯渇が発生する可能性が回避されます。This avoids potential for SNAT port exhaustion inside unique internal IP address space where translation is not required. 副作用として、バックエンド プール内の VM からの送信フローが、それが存在するプール内の内部ロード バランサーのフロントエンド サーバーへのフローを試み、"かつ"、それ自体にマップバックされている場合、フローの両方のレッグは一致せず、フローは失敗します。The side effect is that if an outbound flow from a VM in the backend pool attempts a flow to frontend of the internal Load Balancer in which pool it resides and is mapped back to itself, both legs of the flow don't match and the flow will fail. フローが、フロントエンドへのフローを作成したバックエンド プール内の同じ VM にマップバックしなかった場合、フローは成功します。If the flow did not map back to the same VM in the backend pool which created the flow to the frontend, the flow will succeed. フローがそれ自体にマップバックする場合、送信フローは VM からフロントエンドに発信されるように見え、対応する受信フローは VM からそれ自体に発信されるように見えます。When the flow maps back to itself the outbound flow appears to originate from the VM to the frontend and the corresponding inbound flow appears to originate from the VM to itself. ゲスト OS の観点からは、同じフローの受信部分と送信部分は、仮想マシン内と一致しません。From the guest OS's point of view, the inbound and outbound parts of the same flow don't match inside the virtual machine. 送信元と送信先が一致しないため、TCP スタックは、同じフローのこれらの半分を、同じフローの一部と認識しません。The TCP stack will not recognize these halves of the same flow as being part of the same flow as the source and destination don't match. フローがバックエンド プール内の他の VM にマップする場合、フローの半分は一致し、VM はフローに正常に応答できます。When the flow maps to any other VM in the backend pool, the halves of the flow will match and the VM can successfully respond to the flow. このシナリオの現象は、フローがそのフロー自体の発生元と同じバックエンドに返されるときの、断続的な接続のタイムアウトです。The symptom for this scenario is intermittent connection timeouts when the flow returns to the same backend which originated the flow. このシナリオを確実に実現するためのいくつかの一般的な回避策があり (バックエンド プールから、バックエンド プールのそれぞれの内部ロード バランサー フロントエンドへの送信フロー)、それには内部ロード バランサーの背後にあるプロキシ レイヤーの挿入、または DSR スタイル規則の使用が含まれます。There are several common workarounds for reliably achieving this scenario (originating flows from a backend pool to the backend pools respective internal Load Balancer frontend) which include either insertion of a proxy layer behind the internal Load Balancer or using DSR style rules. 顧客は、内部のロード バランサーを任意のサード パーティ製プロキシと組み合わせて、HTTP/HTTPS に制限されたプロキシ シナリオの代わりに内部の Application Gateway を使用できます。Customers can combine an internal Load Balancer with any 3rd party proxy or substitute internal Application Gateway for proxy scenarios limited to HTTP/HTTPS. パブリック ロード バランサーを使って軽減できますが、結果として得られるシナリオは、SNAT の枯渇が発生しやすいでの、慎重に管理されている場合を除き、回避する必要があります。While you could use a public Load Balancer to mitigate, the resulting scenario is prone to SNAT exhaustion and should be avoided unless carefully managed.

次の手順Next steps

これで、Azure Load Balancer の概要の説明が終わりました。You now have an overview of Azure Load Balancer. Load Balancer の使用を始めるには、1 つ作成し、カスタム IIS 拡張機能がインストールされている VM を作成して、Web アプリを VM 間で負荷分散します。To get started with using a Load Balancer, create one, create VMs with a custom IIS extension installed, and load-balance the web app between the VMs. 方法については、「Basic Load Balancer を作成する」クイック スタートをご覧ください。To learn how, see the Create a Basic Load Balancer quickstart.