Azure Standard Load Balancer の概要Azure Standard Load Balancer overview

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

この記事では、Standard Load Balancer について説明します。This article is focused on Standard Load Balancer. Azure Load Balancer の一般的な概要については、「Azure Load Balancer の概要」もご覧ください。For a more general overview for Azure Load Balancer, review Load Balancer Overview as well.

Standard Load Balancer とはWhat is Standard Load Balancer?

Standard Load Balancer は、すべての TCP アプリケーションと UDP アプリケーションのための新しい Load Balancer 製品であり、Basic Load Balancer よりいっそう広範囲で詳細な機能セットが提供されます。Standard Load Balancer is a new Load Balancer product for all TCP and UDP applications with an expanded and more granular feature set over Basic Load Balancer. 多くの類似点もありますが、この記事で説明する相違点をよく理解しておくことが重要です。While there are many similarities, it is important to familiarize yourself with the differences as outlined in this article.

Standard Load Balancer は、パブリック ロード バランサーまたは内部ロード バランサーとして使うことができます。You can use Standard Load Balancer as a public or internal Load Balancer. また、1 つの仮想マシンを、1 つのパブリック ロード バランサー リソースと 1 つの内部ロード バランサー リソースに接続できます。And a virtual machine can be connected to one public and one internal Load Balancer resource.

ロード バランサー リソースの機能は常に、フロントエンド、ルール、正常性プローブ、およびバックエンド プール定義として表されます。The Load Balancer resource's functions are always expressed as a frontend, a rule, a health probe, and a backend pool definition. リソースは、複数のルールを含むことができます。A resource can contain multiple rules. 仮想マシンの NIC リソースからバックエンド プールを指定することにより、仮想マシンをバックエンド プールに配置できます。You can place virtual machines into the backend pool by specifying the backend pool from the virtual machine's NIC resource. 仮想マシン スケール セットを使用していると、このパラメーターはネットワーク プロファイルによって渡されて展開されます。This parameter is passed through the network profile and expanded when using virtual machine scale sets.

1 つの重要な側面は、リソースの仮想ネットワークのスコープです。One key aspect is the scope of the virtual network for the resource. Basic Load Balancer が可用性セットのスコープ内に存在するのに対し、Standard Load Balancer は仮想ネットワークのスコープに完全に統合され、仮想ネットワークのすべての概念が適用されます。While Basic Load Balancer exists within the scope of an availability set, a Standard Load Balancer is fully integrated with the scope of a virtual network and all virtual network concepts apply.

ロード バランサー リソースはオブジェクトであり、その中では、ユーザーが作成したいシナリオを実現するために Azure がそのマルチ テナント インフラストラクチャをプログラミングする方法を表すことができます。Load Balancer resources are objects within which you can express how Azure should program its multi-tenant infrastructure to achieve the scenario you wish to create. ロード バランサー リソースと実際のインフラストラクチャの間に直接的な関係はありません。ロード バランサーを作成してもインスタンスは作成されず、容量は常に使用可能であり、考慮しなければならない起動時またはスケーリング時の遅延はありません。There is no direct relationship between Load Balancer resources and actual infrastructure; creating a Load Balancer doesn't create an instance, capacity is always available, and there are no start-up or scaling delays to consider.

Standard Load Balancer を使用する理由Why use Standard Load Balancer?

Standard Load Balancer を使用すると、アプリケーションをスケーリングし、小規模のデプロイから大規模で複雑なマルチゾーン アーキテクチャまで、高可用性を実現することができます。Standard Load Balancer enables you to scale your applications and create high availability for small scale deployments to large and complex multi-zone architectures.

Standard Load Balancer と Basic Load Balancer の違いの概要については、次の表をご覧ください。Review the table below for an overview of the differences between Standard Load Balancer and Basic Load Balancer:

注意

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

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

ロード バランサーのサービス制限価格SLA に関するページをご覧ください。Review service limits for Load Balancer, as well as pricing, and SLA.

バックエンド プールBackend pool

Standard Load Balancer バックエンド プールは、仮想ネットワーク内の任意の仮想マシン リソースまで広がります。Standard Load Balancer backend pools expand to any virtual machine resource in a virtual network. 最大 1,000 個のバックエンド インスタンスを含むことができます。It can contain up to 1000 backend instances. バックエンド インスタンスは IP 構成であり、NIC リソースのプロパティです。A backend instance is an IP configuration, which is a property of a NIC resource.

バックエンド プールは、スタンドアロン仮想マシン、可用性セット、または仮想マシン スケール セットを含むことができます。The backend pool can contain standalone virtual machines, availability sets, or virtual machine scale sets. バックエンド プールでリソースを混合することもできます。You can also blend resources in the backend pool. Load Balancer リソースごとに、バックエンド プールで最大 150 個のリソースを組み合わせることができます。You can combine up to 150 resources in the backend pool per Load Balancer resource.

バックエンド プールの設計方法を検討するときは、個々のバックエンド プール リソースを最小限の数に設計して、管理操作の期間をさらに最適化できます。When considering how to design your backend pool, you can design for the least number of individual backend pool resources to further optimize the duration of management operations. データ プレーンのパフォーマンスやスケールに違いはありません。There is no difference in data plane performance or scale.

正常性プローブHealth probes

Standard Load Balancer では、HTTPS アプリケーションを正確に監視するための HTTPS 正常性プローブ (トランスポート層セキュリティ (TLS) ラッパーを使用する HTTP プローブ) のサポートが追加されます。Standard Load Balancer adds support for HTTPS health probes (HTTP probe with Transport Layer Security (TLS) wrapper) to accurately monitor your HTTPS applications.

また、バックエンド プール全体でプローブがダウンしたときに、Standard Load Balancer は確立されたすべての TCP 接続の続行を許可しますIn addition, when the entire backend pool probes down, Standard Load Balancer allows all established TCP connections to continue. (Basic Load Balancer は、すべてのインスタンスへのすべての TCP 接続を終了します)。(Basic Load Balancer will terminate all TCP connections to all instances).

詳しくは、「Load Balancer の正常性プローブ」をご覧ください。Review Load Balancer health probes for details.

可用性ゾーンAvailability Zones

重要

リージョン固有の情報を含む関連トピックについては、Availability Zones に関するページを参照してください。Review Availability Zones for related topics, including any region specific information.

Standard Load Balancer は、可用性ゾーンを利用できるリージョンでの追加機能をサポートします。Standard Load Balancer supports additional abilities in regions where Availability Zones are available. これらの機能は、Standard Load Balancer のすべての機能に追加されます。These features are incremental to all Standard Load Balancer provides. 可用性ゾーンの構成は、パブリックと内部の Standard Load Balancer で利用できます。Availability Zones configurations are available for public and internal Standard Load Balancer.

可用性ゾーンを備えたリージョンにデプロイされると、非ゾーンのフロントエンドは既定でゾーン冗長になります。Non-zonal frontends become zone-redundant by default when deployed in a region with Availability Zones. ゾーン冗長フロントエンドは、ゾーンの障害の影響を受けず、すべてのゾーンで同時に専用のインフラストラクチャによって提供されます。A zone-redundant frontend survives zone failure and is served by dedicated infrastructure in all of the zones simultaneously.

さらに、特定のゾーンにフロントエンドを保証することができます。Additionally, you can guarantee a frontend to a specific zone. ゾーンのフロントエンドはそれぞれのゾーンと運命を供にし、1 つのゾーンの専用インフラストラクチャによってのみ提供されます。A zonal frontend shares fate with the respective zone and is served only by dedicated infrastructure in a single zone.

バックエンド プールではゾーン間負荷分散を使用でき、VNET 内のすべての仮想マシン リソースがバックエンド プールの一部になることができます。Cross-zone load balancing is available for the backend pool, and any virtual machine resource in a vnet can be part of a backend pool.

可用性ゾーン関連の機能の詳細な説明に関するページをご覧ください。Review detailed discussion of Availability Zones related abilities.

診断Diagnostics

Standard Load Balancer は Azure Monitor を通じて多次元メトリックを提供します。Standard Load Balancer provides multi-dimensional metrics through Azure Monitor. これらのメトリックは、フィルター処理し、グループ化し、特定のディメンションに分割することができます。These metrics can be filtered, grouped, and broken out for a given dimension. サービスのパフォーマンスと正常性に関する現在と過去の分析情報を提供します。They provide current and historic insights into performance and health of your service. リソースの正常性もサポートされます。Resource Health is also supported. サポートされている診断の概要を次に示します。Following is a brief overview of supported diagnostics:

メトリックMetric 説明Description
VIP 可用性VIP availability Standard Load Balancer は、リージョン内からロード バランサー フロントエンドを経て、VM をサポートする SDN スタックに至るまでのデータ パスを継続的に学習します。Standard Load Balancer continuously exercises the data path from within a region to the Load Balancer front-end all the way to the SDN stack that supports your VM. 正常なインスタンスが保持されていれば、測定ではアプリケーションの負荷分散されたトラフィックと同じパスに従います。As long as healthy instances remain, the measurement follows the same path as your application's load-balanced traffic. 顧客が使用しているデータ パスも検証されます。The data path that is used by your customers is also validated. 測定はアプリケーションには見えないので、他の操作と干渉することはありません。The measurement is invisible to your application and does not interfere with other operations.
DIP 可用性DIP availability Standard Load Balancer では、構成設定に従ってアプリケーション エンドポイントの正常性を監視する、分散型の正常性プローブ サービスが使われます。Standard Load Balancer uses a distributed health probing service that monitors your application endpoint's health according to your configuration settings. このメトリックは、Load Balancer プールの個々のインスタンス エンドポイントの集計ビューまたはエンドポイントごとのフィルター ビューを提供します。This metric provides an aggregate or per endpoint filtered-view of each individual instance endpoint in the Load Balancer pool. 正常性プローブ構成で示されているアプリケーションの正常性を、Load Balancer がどのように表示するのかを確認できます。You can see how Load Balancer views the health of your application as indicated by your health probe configuration.
SYN パケットSYN packets Standard Load Balancer は、TCP 接続を終了したり、TCP または UDP のパケット フローと対話したりすることはありません。Standard Load Balancer does not terminate TCP connections or interact with TCP or UDP packet flows. フローとハンドシェイクは、常にソースと VM インスタンスの間で発生します。Flows and their handshakes are always between the source and the VM instance. TCP プロトコルのシナリオのトラブルシューティングを適切に行うために、SYN パケット カウンターを使用して TCP 接続試行の数を把握できます。To better troubleshoot your TCP protocol scenarios, you can make use of SYN packets counters to understand how many TCP connection attempts are made. このメトリックは、受信済みの TCP SYN パケットの数を報告します。The metric reports the number of TCP SYN packets that were received.
SNAT 接続SNAT connections Standard Load Balancer は、パブリック IP アドレス フロントエンドにマスカレードされた送信フローの数を報告します。Standard Load Balancer reports the number of outbound flows that are masqueraded to the Public IP address front-end. SNAT ポートは有限のリソースです。SNAT ports are an exhaustible resource. このメトリックはアプリケーションが送信フローで SNAT にどれくらい依存しているかを示すことができます。This metric can give an indication of how heavily your application is relying on SNAT for outbound originated flows. 成功した送信 SNAT フローと失敗した送信 SNAT フローのカウンターがレポートされるので、送信フローの正常性について、トラブルシューティングしたり、理解したりするのに役立てることができます。Counters for successful and failed outbound SNAT flows are reported and can be used to troubleshoot and understand the health of your outbound flows.
バイト カウンターByte counters Standard Load Balancer は、フロントエンドごとに処理されたデータ量を報告します。Standard Load Balancer reports the data processed per front-end.
パケット カウンターPacket counters Standard Load Balancer は、フロントエンドごとに処理されたパケット数を報告します。Standard Load Balancer reports the packets processed per front-end.

Standard Load Balancer の診断の詳細な説明に関するページをご覧ください。Review detailed discussion of Standard Load Balancer Diagnostics.

HA ポートHA Ports

Standard Load Balancer は新しい種類のルールをサポートします。Standard Load Balancer supports a new type of rule.

アプリケーションがスケーラブルで高信頼性になるように、負荷分散ルールを構成できます。You can configure load-balancing rules to make your application scale and be highly reliable. HA ポートの負荷分散ルールを使うと、Standard Load Balancer は、内部 Standard Load Balancer のフロントエンド IP アドレスのすべてのエフェメラル ポートで、フローごとの負荷分散を提供します。When you use an HA Ports load-balancing rule, Standard Load Balancer will provide per flow load balancing on every ephemeral port of an internal Standard Load Balancer's frontend IP address. また、個々のポートを指定するのは実用的ではなかったり、望ましくなかったりするその他のシナリオにも対応できるようになります。The feature is useful for other scenarios where it is impractical or undesirable to specify individual ports.

HA ポートの負荷分散ルールでは、ネットワーク仮想アプライアンスおよび大きな範囲の受信ポートを必要とするすべてのアプリケーションに対し、アクティブ/パッシブまたはアクティブ/アクティブの n+1 シナリオを作成することができます。An HA Ports load-balancing rule allows you to create active-passive or active-active n+1 scenarios for Network Virtual Appliances and any application, which requires large ranges of inbound ports. 正常性プローブを使って、新しいフローを受信する必要があるバックエンドを決定できます。A health probe can be used to determine which backends should be receiving new flows. ネットワーク セキュリティ グループを使って、ポート範囲のシナリオをエミュレートできます。You can use a Network Security Group to emulate a port range scenario.

重要

ネットワーク仮想アプライアンスを使う予定の場合は、製品が HA ポートでテストされているかどうかをベンダーに確認し、実装に関する具体的なガイダンスに従います。If you are planning to use a Network Virtual Appliance, check with your vendor for guidance on whether their product has been tested with HA Ports and follow their specific guidance for implementation.

HA ポートの詳細な説明に関するページをご覧ください。Review detailed discussion of HA Ports.

既定でのセキュリティ保護Secure by default

Standard Load Balancer は仮想ネットワークに完全にオンボードされます。Standard Load Balancer is fully onboarded to the virtual network. 仮想ネットワークは、プライベートのクローズ ネットワークです。The virtual network is a private, closed network. Standard Load Balancer と Standard パブリック IP アドレスは、この仮想ネットワークに仮想ネットワークの外部からアクセスできるように設計されているので、これらのリソースは、ユーザーがオープンしない限り、既定ではクローズになります。Because Standard Load Balancers and Standard public IP addresses are designed to allow this virtual network to be accessed from outside of the virtual network, these resources now default to closed unless you open them. つまり、トラフィックを明示的に許可し、許可されたトラフィックをホワイトリストに登録するには、ネットワーク セキュリティ グループ (NSG) が使われるようになっています。This means Network Security Groups (NSGs) are now used to explicitly permit and whitelist allowed traffic. 仮想データ センター全体を作成し、それを何がいつ使用できるようにする必要があるかを、NSG によって決定できます。You can create your entire virtual data center and decide through NSG what and when it should be available. お使いの仮想マシン リソースのサブネットまたは NIC に NSG がない場合、トラフィックはこのリソースに到達することを許可されません。If you do not have an NSG on a subnet or NIC of your virtual machine resource, traffic is not allowed to reach this resource.

NSG と、ネットワーク セキュリティ グループをシナリオに適用する方法の詳細については、ネットワーク セキュリティ グループに関する記事をご覧ください。To learn more about NSGs and how to apply them for your scenario, see Network Security Groups.

送信接続Outbound connections

Load Balancer は、受信と送信のシナリオをサポートしています。Load Balancer supports inbound and outbound scenarios. Standard Load Balancer は、アウトバウンド接続に関して Basic Load Balancer と大きく異なります。Standard Load Balancer is significantly different than Basic Load Balancer with respect to outbound connections.

仮想ネットワーク上の内部プライベート IP アドレスを Load Balancer フロントエンドのパブリック IP アドレスにマッピングするには、送信元ネットワーク アドレス変換 (SNAT) が使われます。Source Network Address Translation (SNAT) is used to map internal, private IP addresses on your virtual network to public IP addresses on Load Balancer frontends.

Standard Load Balancer では、より堅牢かつスケーラブルで予測可能な SNAT アルゴリズム用に新しいアルゴリズムが導入されており、新しい機能を使用でき、あいまいさがなくなり、副作用ではなく明示的な構成を適用できます。Standard Load Balancer introduces a new algorithm for a more robust, scalable, and predictable SNAT algorithm and enables new abilities, removes ambiguity, and forces explicit configurations rather side effects. これらの変更は、新しい機能が出現するために必要なことです。These changes are necessary to allow for new features to emerge.

以下は、Standard Load Balancer を使うときの重要な原則です。These are the key tenets to remember when working with Standard Load Balancer:

  • ルールの完成によって、Load Balancer リソースが得られます。the completion of a rule drives the Load Balancer resource. Azure のすべてのプログラミングは、その構成から派生します。all programming of Azure derives from its configuration.
  • 複数のフロントエンドが使用可能な場合、すべてのフロントエンドが使われて、各フロントエンドは使用可能な SNAT ポートの数を乗算します。when multiple frontends are available, all frontends are used and each frontend multiplies the number of available SNAT ports
  • 送信接続に特定のフロントエンドが使われたくない場合は、フロントエンドを選んで制御できます。you can choose and control if you do not wish for a particular frontend to be used for outbound connections.
  • 送信シナリオは明示的であり、発信接続は指定されるまで存在しません。outbound scenarios are explicit and outbound connectivity does not exist until it has been specified.
  • 負荷分散ルールでは、SNAT のプログラミング方法が推測されます。load-balancing rules infer how SNAT is programmed. 負荷分散ルールはプロトコルに固有です。Load balancing rules are protocol specific. SNAT はプロトコルに固有であり、構成は副作用を作成するのではなくプロトコルを反映する必要があります。SNAT is protocol specific and configuration should reflect this rather than create a side effect.

複数のフロントエンドMultiple frontends

送信接続の需要が多くなると予想されるため、または既に多くなっているために、SNAT ポートを増やす必要がある場合は、同じ仮想マシン リソースに対してフロントエンド、ルール、およびバックエンド プールを追加構成することにより、増分 SNAT ポート インベントリを追加することもできます。If you want more SNAT ports because you are expecting or are already experiencing a high demand for outbound connections, you can also add incremental SNAT port inventory by configuring additional frontends, rules, and backend pools to the same virtual machine resources.

送信に使用されるフロントエンドを制御するControl which frontend is used for outbound

アウトバウンド接続を、特定のフロントエンド IP アドレスからの発信のみに制限したい場合は、必要に応じて、アウトバウンド マッピングを表すルールで送信 SNAT を無効にすることができます。If you want to constrain outbound connections to only originate from a specific frontend IP address, you can optionally disable outbound SNAT on the rule that expresses the outbound mapping.

送信接続を制御するControl outbound connectivity

Standard Load Balancer は、仮想ネットワークのコンテキスト内に存在します。Standard Load Balancer exists within the context of the virtual network. 仮想ネットワークは、分離されたプライベート ネットワークです。A virtual network is an isolated, private network. パブリック IP アドレスとの関連付けが存在しない場合、パブリック接続は許可されません。Unless an association with a public IP address exists, public connectivity is not allowed. VNET サービス エンドポイントは、仮想ネットワークの内側にあり、仮想ネットワークに対してローカルであるため、VNET サービス エンドポイントには到達できます。You can reach VNet Service Endpoints because they are inside of and local to your virtual network. 仮想ネットワークの外部にある宛先への送信接続を確立したい場合は、次の 2 つのオプションがあります。If you want to establish outbound connectivity to a destination outside of your virtual network, you have two options:

  • Standard SKU のパブリック IP アドレスを、インスタンスレベル パブリック IP アドレスとして、仮想マシン リソースに割り当てますassign a Standard SKU public IP address as an Instance-Level Public IP address to the virtual machine resource or
  • または、仮想マシン リソースを、パブリック Standard Load Balancer のバックエンド プールに配置します。place the virtual machine resource in the backend pool of a public Standard Load Balancer.

どちらの方法でも、仮想ネットワークから、仮想ネットワークの外部に、送信接続できます。Both will allow outbound connectivity from the virtual network to outside of the virtual network.

仮想マシン リソースが配置されているバックエンド プールに関連付けられている内部 Standard Load Balancer "のみ" がある場合、仮想マシンは仮想ネットワーク リソースと VNET サービス エンドポイントに対してだけ到達できます。If you only have an internal Standard Load Balancer associated with the backend pool in which your virtual machine resource is located, your virtual machine can only reach virtual network resources and VNet Service Endpoints. 前の段落で説明されている手順に従って、送信接続を作成できます。You can follow the steps described in the preceding paragraph to create outbound connectivity.

Standard SKU に関連付けられていない仮想マシン リソースの送信接続は前に説明したままです。Outbound connectivity of a virtual machine resource not associated with Standard SKUs remains as before.

送信接続の詳細な説明に関するページをご覧ください。Review detailed discussion of Outbound Connections.

複数のフロントエンドMultiple frontends

Load Balancer は、複数のフロントエンドで複数のルールをサポートします。Load Balancer supports multiple rules with multiple frontends. Standard Load Balancer は、これを送信シナリオまで広げます。Standard Load Balancer expands this to outbound scenarios. アウトバウンド シナリオは基本的に、インバウンド負荷分散ルールの逆です。Outbound scenarios are essentially the inverse of an inbound load-balancing rule. インバウンド負荷分散ルールも、アウトバウンド接続に対する関連付けを作成します。The inbound load-balancing rule also creates an associate for outbound connections. Standard Load Balancer は、負荷分散ルールを介して、仮想マシン リソースに関連付けられているすべてのフロントエンドを使います。Standard Load Balancer uses all frontends associated with a virtual machine resource through a load-balancing rule. さらに、負荷分散ルールのパラメーターにより、アウトバウンド接続のために負荷分散ルールを抑制することができ、特定のフロントエンドを選ぶことが (何も選ばないことも) できます。Additionally, a parameter on the load-balancing rule and allows you to suppress a load-balancing rule for the purposes of outbound connectivity, which allows the selection of specific frontends including none.

これに対し、Basic Load Balancer は単一のフロントエンドをランダムに選び、選ばれるものを制御する機能はありません。For comparison, Basic Load Balancer selects a single frontend at random and there is no ability to control which one was selected.

送信接続の詳細な説明に関するページをご覧ください。Review detailed discussion of Outbound Connections.

管理操作Management Operations

Standard Load Balancer リソースは、まったく新しいインフラストラクチャ プラットフォーム上に存在します。Standard Load Balancer resources exist on an entirely new infrastructure platform. これにより、Standard SKU の管理操作は高速化され、通常、操作が完了するまでの時間は Standard SKU リソースごとに 30 秒未満です。This enables faster management operations for Standard SKUs and completion times are typically less than 30 seconds per Standard SKU resource. バックエンド プールのサイズが大きくなると、バックエンド プールの変更に必要な時間も長くなります。As backend pools increase in size, the duration required for backend pool changes also increase.

Standard Load Balancer のリソースは変更することができ、ある仮想マシンから別の仮想マシンに Standard パブリック IP アドレスを非常に速く移動することができます。You can modify Standard Load Balancer resources and move a Standard public IP address from one virtual machine to another much faster.

SKU 間での移行Migration between SKUs

SKU は変更不可です。SKUs are not mutable. 一方の SKU からもう一方の SKU に移行する場合は、このセクションの手順に従います。Follow the steps in this section to move from one resource SKU to another.

重要

このドキュメント全体を確認して、SKU ごとの違いを理解し、シナリオを慎重に検証してください。Review this document in its entirety to understand the differences between SKUs and have carefully examined your scenario. シナリオに合わせて追加の変更が必要になる場合があります。You may need to make additional changes to align your scenario.

Basic SKU から Standard SKU への移行Migrate from Basic to Standard SKU

  1. 新しい Standard リソース (必要に応じて、Load Balancer とパブリック IP) を作成します。Create a new Standard resource (Load Balancer and Public IPs, as needed). 規則とプローブ定義を再作成します。Recreate your rules and probe definitions. 443/tcp に対する TCP プローブを以前に使用していた場合は、このプローブ プロトコルを HTTPS プローブに変更することを検討し、パスを追加してください。If you were using a TCP probe to 443/tcp previously, consider changing this probe protocol to an HTTPS probe and add a path.

  2. NIC またはサブネットで新規 NSGを作成するか、既存の NSG を更新して、負荷分散されたトラフィック、プローブ、その他の許可するすべてのトラフィックをホワイトリストに登録します。Create new or update existing NSG on NIC or subnet to whitelist load balanced traffic, probe, as well as any other traffic you wish to permit.

  3. すべての VM インスタンスから Basic SKU リソース (必要に応じて、Load Balancer とパブリック IP) を削除します。Remove the Basic SKU resources (Load Balancer and Public IPs, as applicable) from all VM instances. 可用性セットのすべての VM インスタンスも削除してください。Be sure to also remove all VM instances of an availability set.

  4. すべての VM インスタンスを新しい Standard SKU リソースに接続します。Attach all VM instances to the new Standard SKU resources.

Standard SKU から Basic SKU への移行Migrate from Standard to Basic SKU

  1. 新しい Basic リソース (必要に応じて、Load Balancer とパブリック IP) を作成します。Create a new Basic resource (Load Balancer and Public IPs, as needed). 規則とプローブ定義を再作成します。Recreate your rules and probe definitions. 443/tcp に対する HTTPS ブローブを TCP プローブに変更します。Change an HTTPS probe to a TCP probe to 443/tcp.

  2. すべての VM インスタンスから Standard SKU リソース (必要に応じて、Load Balancer とパブリック IP) を削除します。Remove the Standard SKU resources (Load Balancer and Public IPs, as applicable) from all VM instances. 可用性セットのすべての VM インスタンスも削除してください。Be sure to also remove all VM instances of an availability set.

  3. すべての VM インスタンスを新しい Basic SKU リソースに接続します。Attach all VM instances to the new Basic SKU resources.

重要

Basic SKU と Standard SKU の使用には制限事項があります。There are limitations regarding use of the Basic and Standard SKUs.

Standard SKU の HA ポート診断機能は、Standard SKU でのみ提供されます。HA Ports and Diagnostics of the Standard SKU are only available in the Standard SKU. Standard SKU から Basic SKU に移行し、この機能を保持することはできません。You can't migrate from the Standard SKU to the Basic SKU and also retain these features.

Basic SKU と Standard SKU には、この記事で説明したような相違点があります。Both Basic and Standard SKU have a number of differences as outlined in this article. よく理解し、それに合わせて準備してください。Make sure you understand and prepare for them.

Load Balancer リソースとパブリック IP リソースには一致する SKU を使用する必要があります。Matching SKUs must be used for Load Balancer and Public IP resources. Basic SKU リソースと Standard SKU リソースを組み合わせることはできません。You can't have a mixture of Basic SKU resources and Standard SKU resources. スタンドアロン仮想マシン、可用性セット リソース内の仮想マシン、または仮想マシン スケール セット リソースを、両方の SKU に同時にアタッチすることはできません。You can't attach standalone virtual machines, virtual machines in an availability set resource, or a virtual machine scale set resources to both SKUs simultaneously.

利用可能なリージョンRegion availability

現在、Standard Load Balancer はすべてのパブリック クラウド リージョンで利用できます。Standard Load Balancer is currently available in all public cloud regions.

SLASLA

Standard Load Balancer は、99.99% の SLA で利用できます。Standard Load Balancers are available with a 99.99% SLA. 詳しくは、Standard Load Balancer の SLA に関するページをご覧ください。Review the Standard Load Balancer SLA for details.

価格Pricing

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

  • 構成されている負荷分散規則とアウトバウンド規則の数 (インバウンド NAT 規則はルールの総数にカウントされません)Number of configured load-balancing and outbound rules (inbound NAT rules do not count against the total number of rules)
  • 規則に関係なくインバウンドとアウトバウンドで処理されたデータの量Amount of data processed inbound and outbound irrespective of rule.

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

制限事項Limitations

  • SKU は変更不可です。SKUs are not mutable. 既存のリソースの SKU を変更することはできません。You may not change the SKU of an existing resource.
  • スタンドアロン仮想マシン リソース、可用性セット リソース、または仮想マシン スケール セット リソースは、1 つの SKU でのみ参照でき、両方では参照できません。A standalone virtual machine resource, availability set resource, or virtual machine scale set resource can reference one SKU, never both.
  • Load Balancer の規則は、2 つの仮想ネットワークにまたがることはできません。A Load Balancer rule cannot span two virtual networks. フロントエンドとその関連するバックエンド インスタンスは、同じ仮想ネットワークに配置されている必要があります。Frontends and their related backend instances must be located in the same virtual network.
  • サブスクリプションの移動操作は、Standard SKU LB および PIP リソースではサポートされていません。Move subscription operations are not supported for Standard SKU LB and PIP resources.
  • VNet およびその他の Microsoft プラットフォーム サービスなしの Web Worker ロールにアクセスできるのは、事前 VNet サービスおよびその他のプラットフォーム サービスの動作の副作用により、内部の Standard Load Balancer が使用される場合のみです。Web Worker Roles without a VNet and other Microsoft platform services can be accessible when only an internal Standard Load Balancer is used due to a side effect from how pre-VNet services and other platform services function. 各サービス自体または基になるプラットフォームは予告なく変更される場合があるため、これに依存しないでください。You must not rely on this as the respective service itself or the underlying platform can change without notice. 内部の Standard Load Balancer のみを使用する場合は、必要に応じて、送信接続を明示的に作成する必要があることを常に想定する必要があります。You must always assume you need to create outbound connectivity explicitly if desired when using an internal Standard Load Balancer only.
  • 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 front-end 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 front-end. Load Balancer フロントエンドからの帯域内応答を受け取らない場合は、仮想マシンが応答できないことを示します。Not receiving an in-band response from the Load Balancer front-end indicates no virtual machines were able to respond. 応答できる仮想マシンがない状態で、Load Balancer フロントエンドと対話することはできません。It is not possible to interact with a Load Balancer front-end 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 front-end of an internal Load Balancer as both are in private IP address space. これにより、変換が必要ない固有内部 IP アドレス空間内の SNAT 枯渇が発生する可能性が回避されます。This avoids potential for SNAT 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 back-end pool attempts a flow to front-end 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 back-end pool which created the flow to the front-end, the flow will succeed. フローがそれ自体にマップバックする場合、送信フローは 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. ゲスト 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 back-end 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. このシナリオを確実に実現するためのいくつかの一般的な回避策があり (バックエンド プールから、バックエンド プールのそれぞれの内部ロード バランサー フロントエンドへの送信フロー)、それには内部ロード バランサーの背後にあるサード パーティ製プロキシの挿入、または DSR スタイル規則の使用が含まれます。There are several common workarounds for reliably achieving this scenario (originating flows from a back-end pool to the back-end pools respective internal Load Balancer front-end) which include either insertion of a third-party proxy behind the internal Load Balancer or using DSR style rules. パブリック ロード バランサーを使って軽減できますが、結果として得られるシナリオは、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