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 at the Load Balancer's front end to back-end pool instances, according to specified rules and health probes.

パブリック ロード バランサー は、プライベート IP アドレスをパブリック IP アドレスに変換することによって、仮想ネットワーク内の仮想マシン (VM) の送信接続を提供できます。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 は 2 つの価格レベル (SKU) で使用でき、これらはBasic と Standard です。Azure Load Balancer is available in two pricing tiers or 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 differ slightly. Load Balancer について学習するときは、基礎および SKU 固有の違いを理解するようにしてください。As you learn about Load Balancer, familiarize yourself with the fundamentals and the 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 of these 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 要求によるアプリケーション レイヤーの処理が必要な場合は、「Azure Application Gateway とは」を参照してください。If you're looking for Transport Layer Security (TLS) protocol termination ("SSL offload") or per-HTTP/HTTPS request, application-layer processing, see What is Azure Application Gateway? グローバル DNS の負荷分散が必要な場合は、「Traffic Manager とは」を参照してください。If you're looking for global DNS load balancing, see What is Traffic Manager? 実際のエンド ツー エンドのシナリオでは、これらのソリューションを組み合わせると役に立つことがあります。Your end-to-end scenarios may benefit from combining these solutions.

Azure の負荷分散オプションの比較については、「Azure の負荷分散オプションの概要」を参照してください。For an Azure load-balancing options comparison, see Overview of load-balancing options in Azure.

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

Load Balancer リソースは、ユーザーが作成したいシナリオを実現するために Azure がそのマルチ テナント インフラストラクチャをプログラミングする方法を指定するオブジェクトです。Load Balancer resources are objects specifying how Azure should program its multi-tenant infrastructure to achieve the scenario that you want to create. Load Balancer リソースと実際のインフラストラクチャの間に直接的な関係はありません。There's 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.

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

ロード バランサーの基本機能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 the front end to back-end pool instances. 受信フローの分配にはハッシュ アルゴリズムが使われ、バックエンド プール インスタンスへのフローのヘッダーが書き換えられます。Load Balancer uses a hashing algorithm for distribution of inbound flows and rewrites the headers of flows to back-end pool instances. バックエンド エンドポイントが正常であることを正常性プローブが示している場合、サーバーは新しいフローを受信できます。A server is available to receive new flows when a health probe indicates a healthy back-end endpoint.

    既定では、Load Balancer は 5 タプル ハッシュを使用します。By default, Load Balancer uses a 5-tuple hash. ハッシュには、ソース IP アドレス、ソース ポート、接続先 IP アドレス、接続先ポート、IP プロトコル番号が含まれ、使用可能なサーバーにフローをマップします。The hash includes 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 create affinity to a source IP address by using 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 is changed. 結果として得られる 5 タプルのハッシュにより、トラフィックは異なるバックエンド エンドポイントに送られることがあります。As a result, the 5-tuple hash might cause the traffic to go to a different back-end endpoint.

    詳細については、「Azure Load Balancer の分散モードを構成する」を参照してください。For more information, see Configure the distribution mode for Azure Load Balancer. 次の図は、ハッシュベースの分散を示しています。The following image displays the hash-based distribution:

    ハッシュベースの分散

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

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

    Load Balancer では、受信 NAT 規則を作成できます。With Load Balancer, you can create an inbound NAT rule. この NAT 規則により、特定のフロントエンド IP アドレスの特定のポートから、仮想ネットワーク内の特定のバックエンド インスタンスの特定のポートにトラフィックをポート転送することができます。This NAT rule forwards traffic from a specific port of a specific front-end IP address to a specific port of a specific back-end instance inside the virtual network. この転送も、負荷分散と同じハッシュ ベースの分散によって実行されます。This forwarding is done 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 an Azure Virtual Network.

    複数の内部エンドポイントを、同じフロントエンド IP アドレスのポートにマップできます。You can map multiple internal endpoints to ports on the same front-end IP address. フロントエンド IP アドレスを使用すると、ジャンプ ボックスを追加しなくても VM をリモート管理できます。You can use the front-end IP addresses to remotely administer your VMs without an additional jump box.

  • アプリケーションの独立と透明性Application independence and transparency

    Load Balancer は、TCP、UDP、またはアプリケーション レイヤーと直接やり取りしません。Load Balancer doesn't directly interact with TCP or UDP or the application layer. TCP または UDP アプリケーションのシナリオがサポートされています。Any TCP or UDP application scenario can be supported. Load Balancer がフローを終了または開始したり、フローのペイロードと対話したり、アプリケーション レイヤーのゲートウェイ機能を提供したりすることはありません。Load Balancer doesn't terminate or originate flows, interact with the payload of the flow, or provide any application layer gateway function. プロトコル ハンドシェイクは、常にクライアントとバックエンド プール インスタンスの間で直接発生します。Protocol handshakes always occur directly between the client and the back-end 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.

    • すべてのエンドポイントは、VM によってのみ応答されます。Every endpoint is only answered by a VM. たとえば、TCP ハンドシェイクは常に、クライアントと選択されたバックエンド VM の間で行われます。For example, a TCP handshake always occurs between the client and the selected back-end VM. フロントエンドへの要求に対する応答は、バックエンドの VM によって生成される応答です。A response to a request to a front end is a response generated by a back-end VM. フロントエンドへの接続を正常に検証するときは、少なくとも 1 つのバックエンド仮想マシンへのエンド ツー エンドの接続を検証していることになります。When you successfully validate connectivity to a front end, you're validating the end-to-end connectivity to at least one back-end virtual machine.
    • アプリケーション ペイロードは Load Balancer に対して透過的です。Application payloads are transparent to Load Balancer. 任意の UDP または TCP アプリケーションをサポートできます。Any UDP or TCP application can be supported. HTTP 要求ごとの処理またはアプリケーション レイヤー ペイロードの操作を必要とするワークロードの場合 (たとえば、HTTP URL の解析)、Application Gateway のようなレイヤー 7 のロード バランサーを使う必要があります。For workloads that require per HTTP request processing or manipulation of application layer payloads, like parsing of HTTP URLs, you should use a layer 7 load balancer like Application Gateway.
    • Load Balancer は TCP ペイロードとやり取りせず、TLS オフロードを提供しているため、エンドツーエンドの暗号化されたシナリオを構築できます。Because Load Balancer doesn't interact with the TCP payload and provide TLS offload, you can build end-to-end encrypted scenarios. Load Balancer を使用すると、VM 自体で TLS 接続を終了することで、TLS アプリケーションの大規模なスケールアウトを実現できます。Using Load Balancer gains 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 back-end pool. SSL オフロード、アプリケーション レイヤーの処理、または Azure への証明書管理の委任を必要とする場合は、Azure のレイヤー 7 ロード バランサーである Application Gateway を代わりに使用します。If you require SSL offloading, application layer treatment, or want to delegate certificate management to Azure, 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 リソースの追加操作なしに、ロード バランサーが再構成されます。Adding or removing VMs from the back-end 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 back-end 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. プローブの失敗は、既存の接続には影響しません。A probe failure doesn't affect existing connections. アプリケーションがフローを終了するか、アイドル タイムアウトが発生するか、VM がシャットダウンするまで接続は続行されます。The connection continues until the application terminates the flow, an idle timeout occurs, or the VM shuts down.

    ロード バランサーは、TCP、HTTP と HTTPS エンドポイント用に別の正常性プローブの種類を提供します。Load Balancer provides different health probe types for TCP, HTTP, and HTTPS endpoints. 詳細については、「プローブの種類」を参照してください。For more information, see Probe types.

    Classic クラウド サービスを使用している場合、追加の種類であるゲスト エージェントが許可されます。When using Classic cloud services, an additional type is allowed: Guest agent. ゲスト エージェントは、最後の手段の正常性プローブとして考慮する必要があります。A guest agent should be considered to be a health probe of last resort. 他のオプションが使用可能な場合、Microsoft はこの使用を推奨しません。Microsoft doesn't recommend them if other options are available.

  • 送信接続 (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 front-end IP address of the Load Balancer. パブリック フロントエンドが負荷分散規則によってバックエンドの VM に関連付けられていると、Azure は送信接続をパブリック フロントエンドの IP アドレスに変換します。When a public front end is tied to a back-end VM by way of a load-balancing rule, Azure translates outbound connections to the public front-end IP address. この構成には次の利点があります。This configuration has the following advantages:

    • フロントエンドを別のサービス インスタンスに動的にマップできるため、サービスのアップグレードやディザスター リカバリーが簡単にできます。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. フロントエンド IP として表される ACL は、サービスをスケールアップ、スケールダウン、または再デプロイしても変更されません。ACLs expressed as front-end IPs don't change as services scale up or down or get redeployed. 送信接続をマシンより少ない数の IP アドレスに変換すると、安全な受信者リストの実装負荷を軽減できます。Translating outbound connections to a smaller number of IP addresses than machines reduces the burden of implementing safe recipient lists.

    詳しくは、「Azure の送信接続」を参照してください。For more information, see Outbound connections in Azure.

Standard Load Balancer には、以下に示すような、これらの基礎には含まれない追加の SKU 固有機能があります。Standard Load Balancer has additional SKU-specific capabilities beyond these fundamentals, as described below.

Load Balancer の SKU の比較Load Balancer SKU comparison

Load Balancer は、Basic SKU と Standard SKU の両方をサポートしています。Load Balancer supports both Basic and Standard SKUs. これらの SKU の間には、シナリオのスケール、機能、および料金の違いがあります。These SKUs differ 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. 両方の SKU の API は似ており、SKU を指定することによって呼び出されます。The APIs for both SKUs are similar and are 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 share the same general API and structure.

SKU によって、完全なシナリオ構成が若干異なる場合があります。The complete scenario configuration might differ slightly depending on SKU. 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 Azure 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 が一致していなければなりません。Load Balancer and the public IP address SKU must match when you use them with public IP addresses. Load Balancer とパブリック IP の SKU は変更できません。Load Balancer and public IP SKUs aren't mutable.

SKU を明示的に指定することをお勧めします。The best practice is to specify the SKUs explicitly. 現時点では、必要な変更は最小限に抑えられています。At this time, required changes are being kept to a minimum. SKU が指定されていない場合の既定値は、Basic SKU の 2017-08-01 API バージョンです。If a SKU isn't specified, the default is the 2017-08-01 API version of the Basic SKU.

重要

Standard Load Balancer は新しい Load Balancer 製品です。Standard Load Balancer is a new Load Balancer product. これは主に Basic Load Balancer のスーパーセットですが、2 つの製品には重要な違いがあります。It is largely a superset of Basic Load Balancer, but there are important 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 と比較して、動作における最新の変更点を理解してください。If you're already used to Basic Load Balancer, compare it with Standard Load Balancer to understand the latest changes in their behavior.

Standard SKUStandard SKU Basic SKUBasic SKU
バックエンド プールのサイズBack-end pool size 最大 1,000 インスタンスをサポート。Supports up to 1000 instances. 最大 100 インスタンスをサポート。Supports up to 100 instances.
バックエンド プールのエンドポイントBack-end pool endpoints 仮想マシン、可用性セット、仮想マシン スケール セットの組み合わせを含む、単一の仮想ネットワーク内の任意の仮想マシン。Any virtual machine in a single virtual network, including blends of virtual machines, availability sets, and 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 an instance probe down and on all probes down. インスタンス プローブがダウンしても TCP 接続は存続。TCP connections stay alive on an instance probe down. すべてのプローブがダウンした場合、すべての TCP 接続は終了。All TCP connections terminate when all probes are down.
可用性ゾーンAvailability Zones 受信トラフィックと送信トラフィック用のゾーン冗長およびゾーン フロントエンド。Zone-redundant and zonal front ends for inbound and outbound traffic. 送信フローのマッピングは、ゾーンの障害が発生しても保持されます。Outbound flows mappings survive zone failure. クロスゾーン負荷分散Cross-zone load balancing. 使用できません。Not available
診断Diagnostics Azure Monitor。Azure Monitor. バイト カウンターとパケット カウンターを含む多次元メトリック。Multi-dimensional metrics including byte and packet counters. 正常性プローブの状態。Health probe status. 接続試行 (TCP SYN)。Connection attempts (TCP SYN). 送信接続の正常性 (SNAT 成功および失敗のフロー)。Outbound connection health (SNAT successful and failed flows). アクティブなデータ プレーン測定。Active data plane measurements. パブリック ロード バランサーに対する Azure Log Analytics のみ。Azure Log Analytics for public Load Balancer only. SNAT 枯渇アラート。SNAT exhaustion alert. バックエンド プール正常性カウント。Back-end pool health count.
HA ポートHA Ports 内部ロード バランサーInternal Load Balancer 使用できません。Not available
既定でのセキュリティ保護Secure by default パブリック IP、パブリック ロード バランサー エンドポイント、内部ロード バランサー エンドポイントへのインバウンド フローは、ネットワーク セキュリティ グループによって許可されない限り禁止されます。Public IP, public Load Balancer endpoints, and internal Load Balancer endpoints are closed to inbound flows unless allowed by a network security group. 既定で開いています。Open by default. ネットワーク セキュリティ グループはオプションです。Network security group optional.
送信接続 (アウトバウンド接続)Outbound connections 送信規則を使用して、プールに基づく送信 NAT を明示的に定義できます。You can explicitly define pool-based outbound NAT with outbound rules. 負荷分散規則のオプトアウトごとに複数のフロントエンドを使用できます。仮想マシン、可用性セット、または仮想マシン スケール セットが送信接続 (アウトバウンド接続) を使用するためには、送信シナリオを明示的に作成する "必要があります"。You can use multiple front ends with per load-balancing rule opt-out. An outbound scenario must be explicitly created for the virtual machine, availability set, or virtual machine scale set to use outbound connectivity. 仮想ネットワーク サービス エンドポイントは、送信接続 (アウトバウンド接続) を定義しなくても到達でき、処理されたデータにはカウントされません。Virtual network service endpoints can be reached without defining outbound connectivity and don't count towards data processed. 仮想ネットワーク サービス エンドポイントとして使用できない Azure PaaS サービスなどのすべてのパブリック IP アドレスは、送信接続を使用して到達する必要があり、処理されたデータにカウントされます。Any public IP addresses, including Azure PaaS services not available as virtual network service endpoints, must be reached by using outbound connectivity and count towards data processed. 仮想マシン、可用性セット、または仮想マシン スケール セットの負荷分散を担うのが内部ロード バランサーだけであるときは、既定の SNAT による送信接続は利用できません。When only an internal Load Balancer serves virtual machine, availability set, or virtual machine scale set, outbound connections over default SNAT aren't available. 代わりに送信規則を使用してください。Use outbound rules instead. 送信 SNAT プログラミングは、受信負荷分散ルールのトランスポート プロトコルによって異なります。Outbound SNAT programming depends on the transport protocol of the inbound load-balancing rule. 単一のフロントエンド。複数のフロントエンドが存在する場合は、ランダムに選ばれます。Single front end, selected at random when multiple front ends are present. 仮想マシン、可用性セット、または仮想マシン スケール セットの負荷分散を担うのが内部ロード バランサーだけであるときは、既定の SNAT が使用されます。When only internal Load Balancer serves a virtual machine, availability set, or virtual machine scale set, default SNAT is used.
送信規則Outbound Rules パブリック IP アドレスまたはパブリック IP プレフィックスまたはその両方を使用した、宣言型の送信 NAT 構成。Declarative outbound NAT configuration, using public IP addresses or public IP prefixes or both. 構成可能な送信アイドル タイムアウト (4 ~ 120 分)。Configurable outbound idle timeout (4-120 minutes). ポートの割り当てをカスタマイズする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 front ends 受信および送信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. 適用不可Not applicable
価格Pricing ルールの数、リソースに関連付けられた受信および送信で処理されたデータに基づいて課金。Charged based on number of rules, data processed inbound and outbound associated with resource. 課金なしNo charge

詳細については、「Load Balancer の制限」を参照してください。For more information, see Load balancer limits. Standard Load Balancer について詳しくは、概要価格SLA に関するページもご覧ください。For Standard Load Balancer details, see overview, pricing, and SLA.

概念Concepts

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

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

注意

可用性セットごとに 1 つのパブリック ロード バランサーと 1 つの内部ロード バランサーのみを実装できます。You can implement only one public Load Balancer and one internal Load Balancer per availability set.

次の図は、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: Balancing web traffic by using a public Load Balancer

インターネット クライアントは Web ページの要求を、TCP ポート 80 の Web アプリのパブリック IP アドレスに送信します。Internet clients send webpage requests to the public IP address of a web app on TCP port 80. Azure Load Balancer は、負荷分散セット内の 3 つの VM 全体に要求を分散させます。Azure Load Balancer distributes the requests across the three VMs in the load-balanced set. ロード バランサーのアルゴリズムの詳細については、「ロード バランサーの基本機能」を参照してください。For more information about Load Balancer algorithms, see Fundamental Load Balancer features.

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

内部ロード バランサーInternal 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 contrast to a public Load Balancer. Azure インフラストラクチャでは、仮想ネットワークの負荷分散フロントエンド IP アドレスへのアクセスが制限されます。Azure infrastructure restricts access to the load-balanced front-end IP addresses of a virtual network. フロントエンド IP アドレスと仮想ネットワークは、インターネット エンドポイントに直接公開されることはありません。Front-end 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 are in the same virtual network.
  • クロスプレミス仮想ネットワークの場合: オンプレミスのコンピューターから、同じ仮想ネットワーク内に存在する一連の VM に負荷を分散する。For a cross-premises virtual network: Load balancing from on-premises computers to a set of VMs that are in the same virtual network.
  • 多層アプリケーションの場合: バックエンド層がインターネットに接続しない、インターネットに接続する多層アプリケーションの負荷を分散する。For multi-tier applications: Load balancing for internet-facing multi-tier applications where the back-end tiers aren't internet-facing. バックエンド層では、インターネットに接続する層からのトラフィックを負荷分散する必要があります。The back-end 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: Balancing multi-tier applications by using both public and internal Load Balancer

価格Pricing

Standard Load Balancer の使用量は課金されます。Standard Load Balancer usage is charged.

  • 構成された負荷分散および送信規則の数。Number of configured load-balancing and outbound rules. 受信 NAT 規則は規則の合計数にカウントされません。Inbound NAT rules don't count in the total number of rules.
  • 規則に関係なくインバウンドとアウトバウンドで処理されたデータの量。Amount of data processed inbound and outbound independent of rules.

Standard Load Balancer の価格の情報については、「Load Balancer の価格」を参照してください。For Standard Load Balancer pricing information, see Load Balancer pricing.

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, see SLA for Load Balancer.

制限事項Limitations

  • Load Balancer は特定の TCP または UDP プロトコルに対する負荷分散とポート フォワーディングを行います。Load Balancer provides load balancing and port forwarding for specific TCP or UDP protocols. 負荷分散規則と受信 NAT 規則は TCP および UDP をサポートしますが、ICMP を含む他の IP プロトコルはサポートしていません。Load-balancing rules and inbound NAT rules support TCP and UDP, but not other IP protocols including ICMP.

    Load Balancer は、UDP または TCP のフローのペイロードを終了したり、それに応答したり、それ以外の対話を行うことはありません。Load Balancer doesn't terminate, respond, or otherwise interact with the payload of a UDP or TCP flow. プロキシではありません。It's not a proxy. フロントエンドへの接続の正常な検証は、負荷分散規則または受信 NAT 規則で使用されているプロトコルと同じプロトコルを使用して帯域内で行う必要があります。Successful validation of connectivity to a front end must take place in-band with the same protocol used in a load balancing or inbound NAT rule. フロントエンドからの応答を確認するには、少なくとも 1 つの仮想マシンがクライアントに対して応答を生成する必要があります。At least one of your virtual machines must generate a response for a client to see a response from a front end.

    Load Balancer フロントエンドからの帯域内応答を受け取らない場合は、仮想マシンが応答できないことを示します。Not receiving an in-band response from the Load Balancer front end indicates no virtual machines could respond. 応答できる仮想マシンがない状態で、Load Balancer フロントエンドと対話することはできません。Nothing can interact with a Load Balancer front end without a virtual machine able to respond. この原理は、ポート マスカレード SNAT が TCP および UDP に対してのみサポートされている送信接続にも当てはまります。This principle also applies to outbound connections where port masquerade SNAT is only supported for TCP and UDP. ICMP などの他の IP プロトコルも失敗します。Any other IP protocols, including ICMP, fail. この問題を軽減するには、インスタンスレベルのパブリック IP アドレスを割り当てます。Assign an instance-level public IP address to mitigate this issue. 詳細については、「SNAT と PAT の理解」を参照してください。For more information, see Understanding SNAT and PAT.

  • 内部ロード バランサーは、送信接続を内部ロード バランサーのフロントエンドに変換しません。これは、両方ともプライベート IP アドレス空間にあるためです。Internal Load Balancers don't translate outbound originated connections to the front end of an internal Load Balancer because both are in private IP address space. パブリック ロード バランサーは、仮想ネットワーク内のプライベート IP アドレスからパブリック IP アドレスへの送信接続を提供します。Public Load Balancers provide outbound connections from private IP addresses inside the virtual network to public IP addresses. 内部ロード バランサーの場合、この方法を使用すると、変換が必要ない固有内部 IP アドレス空間内で SNAT ポートの枯渇が発生する可能性が回避されます。For internal Load Balancers, this approach avoids potential SNAT port exhaustion inside a unique internal IP address space, where translation isn't required.

    副作用として、バックエンド プール内の VM からの送信フローが、そのプール内の内部ロード バランサーのフロントエンドへのフローを試み、"かつ"、それ自体にマップバックされている場合、フローの 2 つのレッグは一致しません。A side effect is that if an outbound flow from a VM in the back-end pool attempts a flow to front end of the internal Load Balancer in its pool and is mapped back to itself, the two legs of the flow don't match. これらは一致しないため、フローは失敗します。Because they don't match, the flow fails. フローが、フロントエンドへのフローを作成したバックエンド プール内の同じ VM にマップバックしなかった場合、フローは成功します。The flow succeeds if the flow didn't map back to the same VM in the back-end pool that created the flow to the front end.

    フローがそれ自体にマップバックする場合、送信フローは VM からフロントエンドに発信されるように見え、対応する受信フローは VM からそれ自体に発信されるように見えます。When the flow maps back to itself, the outbound flow appears to originate from the VM to the front end and the corresponding inbound flow appears to originate from the VM to itself. ゲスト オペレーティング システムの観点からは、同じフローの受信部分と送信部分は、仮想マシン内と一致しません。From the guest operating system's point of view, the inbound and outbound parts of the same flow don't match inside the virtual machine. TCP スタックは、同じフローのこれらの半分を、同じフローの一部と認識しません。The TCP stack won't recognize these halves of the same flow as being part of the same flow. 送信元と送信先が一致しないためです。The source and destination don't match. フローがバックエンド プール内の他の VM にマップする場合、フローの半分は一致し、VM はフローに応答できます。When the flow maps to any other VM in the back-end pool, the halves of the flow do match and the VM can respond to the flow.

    このシナリオの現象は、フローがそのフロー自体の発生元と同じバックエンドに返されるときの、断続的な接続のタイムアウトです。The symptom for this scenario is intermittent connection timeouts when the flow returns to the same back end that originated the flow. 一般的な回避策としては、内部ロード バランサーの背後にプロキシ レイヤーを挿入し、Direct Server Return (DSR) スタイル ルールを使用することなどが挙げられます。Common workarounds include insertion of a proxy layer behind the internal Load Balancer and using Direct Server Return (DSR) style rules. 詳細については、「Azure Load Balancer の複数のフロントエンド」を参照してください。For more information, see Multiple Front ends for Azure Load Balancer.

    ユーザーは、内部ロード バランサーを任意のサード パーティ製プロキシと組み合わせるか、HTTP/HTTPS を使用したプロキシ シナリオに内部の Application Gateway を使用することができます。You can combine an internal Load Balancer with any third-party proxy or use internal Application Gateway for proxy scenarios with HTTP/HTTPS. この問題はパブリック ロード バランサーを使って軽減できますが、結果として得られるシナリオでは SNAT の枯渇が発生しやすくなります。While you could use a public Load Balancer to mitigate this issue, the resulting scenario is prone to SNAT exhaustion. 慎重に管理しない限り、この 2 番目のアプローチは避けてください。Avoid this second approach unless carefully managed.

  • 一般に、転送 IP フラグメントは、負荷分散規則ではサポートされていません。In general, forwarding IP fragments isn't supported on load-balancing rules. UDP パケットと TCP パケットの IP の断片化は負荷分散規則ではサポートされていません。IP fragmentation of UDP and TCP packets isn't supported on load-balancing rules. 高可用性ポートの負荷分散規則を使用すると、既存の IP フラグメントを転送できます。High availability ports load-balancing rules can be used to forward existing IP fragments. 詳細については、「高可用性ポートの概要」を参照してください。For more information, see High availability ports overview.

次の手順Next steps

Load Balancer の使用を始めるには、「Basic Load Balancer を作成する」を参照して、Load Balancer を 1 つ作成し、カスタム IIS 拡張機能がインストールされている VM を作成して、Web アプリを VM 間で負荷分散します。See Create a Basic Load Balancer 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.