Standard Load Balancer と可用性ゾーンStandard Load Balancer and Availability Zones

Azure Standard Load Balancer は、可用性ゾーンのシナリオをサポートしています。Azure Standard Load Balancer supports availability zones scenarios. Standard Load Balancer を使用することで、リソースをゾーンに一致させて、複数のゾーンに分散させることにより、エンド ツー エンドのシナリオで可用性を最適化させることができます。You can use Standard Load Balancer to optimize availability in your end-to-end scenario by aligning resources with zones and distributing them across zones. 可用性ゾーンとは何か、現在可用性ゾーンをサポートしているリージョン、その他の関連する概念と製品については、可用性ゾーンに関する記事をご覧ください。Review availability zones for guidance on what availability zones are, which regions currently support availability zones, and other related concepts and products. 可用性ゾーンと Standard Load Balancer の組み合わせは、さまざまなシナリオを作成できる拡張性と柔軟性の高い機能セットです。Availability zones in combination with Standard Load Balancer is an expansive and flexible feature set that can create many different scenarios. このドキュメントを読んで、これらの概念と基本的なシナリオの設計ガイダンスを理解してください。Review this document to understand these concepts and fundamental scenario design guidance.

重要

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

Load Balancer に適用される可用性ゾーンの概念Availability Zones concepts applied to Load Balancer

Load Balancer のリソースと実際のインフラストラクチャの間に直接的な関係はありません。Load Balancer を作成しても、インスタンスは作成されません。There's no direct relationship between Load Balancer resources and actual infrastructure; creating a Load Balancer doesn't create an instance. Load Balancer のリソースはオブジェクトであり、その中では、ユーザーが作成したいシナリオを実現するために Azure がその構築済みマルチ テナント インフラストラクチャをプログラミングする方法を表すことができます。Load Balancer resources are objects within which you can express how Azure should program its prebuilt multi-tenant infrastructure to achieve the scenario you wish to create. これは、1 つの Load Balancer リソースで複数の可用性ゾーンのインフラストラクチャのプログラミングを制御でき、一方でゾーン冗長サービスは顧客の観点からは 1 つのリソースに見えるので、ゾーンの可用性のコンテキストでは重要なことです。This is significant in the context of availability zones because a single Load Balancer resource can control programming of infrastructure in multiple availability zones while a zone-redundant service appears as one resource from a customer point of view.

Load Balancer リソース自体はリージョン ベースであり、ゾーン ベースではありません。A Load Balancer resource itself is regional and never zonal. また、VNet とサブネットも常にリージョン ベースであり、ゾーン ベースではありません。And a VNet and subnet are always regional and never zonal. 構成できる対象の粒度は、フロントエンド、規則、およびバックエンド プール定義の各構成によって制限されます。The granularity of what you can configure is constrained by each configuration of frontend, rule, and backend pool definition.

可用性ゾーンのコンテキストでは、Load Balancer 規則の動作とプロパティは、ゾーン冗長またはゾーン ベースとして記述されます。In the context of availability zones, the behavior and properties of a Load Balancer rule are described as zone-redundant or zonal. ゾーン冗長とゾーン ベースは、プロパティのゾーン性を記述します。Zone-redundant and zonal describe the zonality of a property. Load Balancer のコンテキストでは、ゾーン冗長は常に "ゾーン" を意味し、ゾーン ベースはサービスを "単一のゾーン" に分離することを意味します。In the context of Load Balancer, zone-redundant always means multiple zones and zonal means isolating the service to a single zone.

パブリックと内部のどちらの Load Balancer も、ゾーン冗長とゾーン ベースのシナリオをサポートし、必要に応じて、ゾーン間でトラフィックを受け渡しできます ("ゾーン間負荷分散")。Both public and internal Load Balancer support zone-redundant and zonal scenarios and both can direct traffic across zones as needed (cross-zone load-balancing).

フロントエンドFrontend

Load Balancer のフロントエンドは、仮想ネットワーク リソースのサブネット内のパブリック IP アドレス リソースまたはプライベート IP アドレスのいずれかを参照するフロントエンド IP 構成です。A Load Balancer frontend is a frontend IP configuration referencing either a public IP address resource or a private IP address within the subnet of a virtual network resource. サービスが公開される負荷分散されたエンドポイントを形成します。It forms the load balanced endpoint where your service is exposed.

Load Balancer リソースは、ゾーン ベースのフロントエンドとゾーン冗長のフロントエンドの規則を同時に含むことができます。A Load Balancer resource can contain rules with zonal and zone-redundant frontends simultaneously.

パブリック IP リソースまたはプライベート IP アドレスがゾーンに対して保証されている場合、ゾーン性 (またはその欠如) は変更できません。When a public IP resource or a private IP address has been guaranteed to a zone, the zonality (or lack thereof) isn't mutable. パブリック IP またはプライベート IP アドレスのフロントエンドのゾーン性を変更または省略する必要がある場合は、適切なゾーンでパブリック IP を再作成する必要があります。If you wish to change or omit the zonality of a public IP or private IP address frontend, you need to recreate the public IP in the appropriate zone. 可用性ゾーンでは、複数のフロントエンドについての制約が変更されません。この機能の詳細については、「Load Balancer の複数フロントエンド」を確認してください。Availability zones do not change the constraints for multiple frontend, review multiple frontends for Load Balancer for details for this ability.

既定で冗長なゾーンZone redundant by default

可用性ゾーンのあるリージョンでは、Standard Load Balancer のフロントエンドは既定でゾーン冗長になります。In a region with availability zones, a Standard Load Balancer frontend is zone-redundant by default. ゾーン冗長とは、すべての受信フローまたは送信フローが、1 つの IP アドレスを使って、リージョン内の複数の可用性ゾーンにより同時に処理されることを意味します。Zone-redundant means that all inbound or outbound flows are served by multiple availability zones in a region simultaneously using a single IP address. DNS の冗長性スキームは必要ありません。DNS redundancy schemes aren't required. 1 つのフロントエンド IP アドレスがゾーンの障害に対応でき、ゾーンに関係なくすべての (影響を受けない) バックエンド プール メンバーへのアクセスに使用できます。A single frontend IP address can survive zone failure and can be used to reach all (non-impacted) backend pool members irrespective of the zone. 1 つまたは複数の可用性ゾーンで障害が発生しても対応可能であり、リージョン内に正常なゾーンが 1 つでも残っていれば、データ パスは存続します。One or more availability zones can fail and the data path survives as long as one zone in the region remains healthy. フロントエンドの単一の IP アドレスは、複数の可用性ゾーンで複数の独立したインフラストラクチャ展開によって同時に処理されます。The frontend's single IP address is served simultaneously by multiple independent infrastructure deployments in multiple availability zones. これはヒットレス データ パスを意味するものではなく、ゾーンの障害による影響を受けていない他のゾーンですべての再試行または再確立が成功します。This doesn't mean hitless data path, but any retries or reestablishment will succeed in other zones not impacted by the zone failure.

次の抜粋は、パブリック Standard Load Balancer で使用するゾーン冗長のパブリック IP アドレスを定義する方法を示しています。The following excerpt is an illustration for how to define a public IP a zone-redundant Public IP address to use with your public Standard Load Balancer. 構成で既存の Resource Manager テンプレートを使用している場合は、これらのテンプレートに sku セクションを追加してください。If you're using existing Resource Manager templates in your configuration, add the sku section to these templates.

            "apiVersion": "2017-08-01",
            "type": "Microsoft.Network/publicIPAddresses",
            "name": "public_ip_standard",
            "location": "region",
            "sku":
            {
                "name": "Standard"
            },

次の抜粋は、内部 Standard Load Balancer に対してゾーン冗長のフロントエンド IP アドレスを定義する方法を示しています。The following excerpt is an illustration for how to define a zone-redundant frontend IP address for your internal Standard Load Balancer. 構成で既存の Resource Manager テンプレートを使用している場合は、これらのテンプレートに sku セクションを追加してください。If you're using existing Resource Manager templates in your configuration, add the sku section to these templates.

            "apiVersion": "2017-08-01",
            "type": "Microsoft.Network/loadBalancers",
            "name": "load_balancer_standard",
            "location": "region",
            "sku":
            {
                "name": "Standard"
            },
            "properties": {
                "frontendIPConfigurations": [
                    {
                        "name": "zone_redundant_frontend",
                        "properties": {
                            "subnet": {
                                "Id": "[variables('subnetRef')]"
                            },
                            "privateIPAddress": "10.0.0.6",
                            "privateIPAllocationMethod": "Static"
                        }
                    },
                ],

前の抜粋は完全なテンプレートではありませんが、可用性ゾーンのプロパティを表す方法を示すことを目的としています。The preceding excerpts are not complete templates but intended to show how to express availability zones properties. これらのステートメントをお使いのテンプレートに組み込む必要があります。You need to incorporate these statements into your templates.

省略可能なゾーンの分離Optional zone isolation

単一ゾーンを保証されたフロントエンドにすることができます。これは、"ゾーン ベースのフロントエンド" と呼ばれます。You can choose to have a frontend guaranteed to a single zone, which is known as a zonal frontend. これは、すべての受信または送信フローが、リージョン内の 1 つのゾーンによって処理されることを意味します。This means any inbound or outbound flow is served by a single zone in a region. フロントエンドは、ゾーンの正常性に左右されます。Your frontend shares fate with the health of the zone. データ パスは、それが保証されたゾーン以外のゾーンのエラーによっては影響を受けません。The data path is unaffected by failures in zones other than where it was guaranteed. ゾーン ベースのフロントエンドを使って、可用性ゾーンごとに IP アドレスを公開することができます。You can use zonal frontends to expose an IP address per Availability Zone.

また、各ゾーン内の負荷分散されたエンドポイントに対して、ゾーン ベースのフロントエンドを直接使用することもできます。Additionally, you can consume zonal frontends directly for load balanced endpoints within each zone. これを使ってゾーンごとに負荷分散されたエンドポイントを公開し、各ゾーンを個別に監視することもできます。You can also use this to expose per zone load-balanced endpoints to individually monitor each zone. また、パブリック エンドポイントの場合は、これらを Traffic Manager などの DNS 負荷分散製品と統合して、1 つの DNS 名を使用できます。Or for public endpoints you can integrate them with a DNS load-balancing product like Traffic Manager and use a single DNS name. その後、クライアントは、複数のゾーン ベースの IP アドレスにこの DNS 名を解決します。The client then will then resolve to this DNS name to multiple zonal IP addresses.

これらの概念を組み合わせる (同じバックエンドでゾーン冗長とゾーン ベースを使う) 場合は、Azure Load Balancer での複数のフロントエンドに関するページをご覧ください。If you wish to blend these concepts (zone-redundant and zonal for same backend), review multiple frontends for Azure Load Balancer.

パブリック Load Balancer フロントエンドの場合は、それぞれの規則によって使用されるフロントエンド IP 構成が参照するパブリック IP リソースに zones パラメーターを追加します。For a public Load Balancer frontend, you add a zones parameter to the public IP resource referenced by the frontend IP configuration used by the respective rule.

内部 Load Balancer フロントエンドの場合は、内部 Load Balancer のフロントエンド IP 構成に zones パラメーターを追加します。For an internal Load Balancer frontend, add a zones parameter to the internal Load Balancer frontend IP configuration. ゾーン ベースのフロントエンドでは、Load Balancer は特定のゾーンに対してサブネット内の IP アドレスを保証します。The zonal frontend causes the Load Balancer to guarantee an IP address in a subnet to a specific zone.

次の抜粋は、可用性ゾーン 1 でゾーン ベースの Standard パブリック IP アドレスを定義する方法を示しています。The following excerpt is an illustration for how to define a zonal Standard Public IP address in Availability Zone 1. 構成で既存の Resource Manager テンプレートを使用している場合は、これらのテンプレートに sku セクションを追加してください。If you're using existing Resource Manager templates in your configuration, add the sku section to these templates.

            "apiVersion": "2017-08-01",
            "type": "Microsoft.Network/publicIPAddresses",
            "name": "public_ip_standard",
            "location": "region",
            "zones": [ "1" ],
            "sku":
            {
                "name": "Standard"
            },

次の抜粋は、可用性ゾーン 1 で内部 Standard Load Balancer フロントエンドを定義する方法を示しています。The following excerpt is an illustration for how to define an internal Standard Load Balancer front end in Availability Zone 1. 構成で既存の Resource Manager テンプレートを使用している場合は、これらのテンプレートに sku セクションを追加してください。If you're using existing Resource Manager templates in your configuration, add the sku section to these templates. また、子リソースのフロントエンド IP 構成で zones プロパティを定義します。Also, define the zones property in the frontend IP configuration for the child resource.

            "apiVersion": "2017-08-01",
            "type": "Microsoft.Network/loadBalancers",
            "name": "load_balancer_standard",
            "location": "region",
            "sku":
            {
                "name": "Standard"
            },
            "properties": {
                "frontendIPConfigurations": [
                    {
                        "name": "zonal_frontend_in_az1",
                        "zones": [ "1" ],
                        "properties": {
                            "subnet": {
                                "Id": "[variables('subnetRef')]"
                            },
                            "privateIPAddress": "10.0.0.6",
                            "privateIPAllocationMethod": "Static"
                        }
                    },
                ],

前の抜粋は完全なテンプレートではありませんが、可用性ゾーンのプロパティを表す方法を示すことを目的としています。The preceeding excerpts are not complete templates but intended to show how to express availability zones properties. これらのステートメントをお使いのテンプレートに組み込む必要があります。You need to incorporate these statements into your templates.

クロスゾーン負荷分散Cross-zone Load-Balancing

クロスゾーンの負荷分散は、任意のゾーン内のバックエンド エンドポイントに到達する Load Balancer の機能であり、フロントエンドおよびそのゾーン性からは独立しています。Cross-zone load-balancing is the ability of Load Balancer to reach a backend endpoint in any zone and is independent of frontend and its zonality. すべての負荷分散規則は、任意の可用性ゾーンまたはリージョン インスタンスのバックエンド インスタンスを対象にすることができます。Any load balancing rule can target backend instance in any availability zone or regional instances.

可用性ゾーンの概念を表す方法でシナリオを構築する必要があります。You need to take care to construct your scenario in a manner which expressed an availability zones notion. たとえば、単一または複数のゾーン内で仮想マシン展開を保証し、ゾーン ベースのフロントエンド リソースとゾーン ベースのバックエンド リソースを同じゾーンに揃える必要があります。For example, you need guarantee your virtual machine deployment within a single zone or multiple zones, and align zonal frontend and zonal backend resources to the same zone. ゾーン ベースのリソースのみで可用性ゾーンをクロスさせる場合、そのシナリオは機能しますが、可用性ゾーンに関して明確な障害モードがない場合があります。If you cross availability zones with only zonal resources, the scenario will work but may not have a clear failure mode with respect to availability zones.

バックエンドBackend

Load Balancer は仮想マシン インスタンスで動作します。Load Balancer works with virtual machines instances. これらは、スタンドアロン、可用性セット、または仮想マシン スケール セットです。These can be standalone, availability sets, or virtual machine scale sets. ゾーンに対して保証されていたかどうか、またはどのゾーンが保証対象であったかに関係なく、単一の仮想ネットワーク内の任意の仮想マシンが、バックエンド プールの一部になることができます。Any virtual machine instance in a single virtual network can be part of the backend pool irrespective of whether or not it was guaranteed to a zone or which zone was guaranteed to.

フロントエンドとバックエンドを 1 つのゾーンに揃えて保証する場合は、同じゾーン内の仮想マシンのみをそれぞれのバックエンド プールに配置します。If you wish to align and guarantee your frontend and backend with a single zone, only place virtual machines within the same zone into the respective backend pool.

複数のゾーンの仮想マシンに対応したい場合は、単に複数のゾーンからの仮想マシンを同じバックエンド プールに配置します。If you wish to address virtual machines across multiple zones, simply place virtual machines from multiple zones into the same backend pool. 仮想マシン スケール セットを使っているときは、1 つまたは複数の仮想マシン スケール セットを同じバックエンド プールに配置できます。When using virtual machine scale sets, you can place one or more virtual machine scale sets into the same backend pool. また、これらの各仮想マシン スケール セットを 1 つまたは複数のゾーンに配置できます。And each of these virtual machine scale sets can be in a single or multiple zones.

送信接続Outbound connections

送信接続には同じゾーン冗長プロパティとゾーン ベースのプロパティが適用されます。The same zone-redundant and zonal properties apply to outbound connections. 送信接続に使用されるゾーン冗長パブリック IP アドレスは、すべてのゾーンによって処理されます。A zone-redundant public IP address used for outbound connections is served by all zones. ゾーン ベースのパブリック IP アドレスは、それが保証されているゾーンによってのみ処理されます。A zonal public IP address is served only by the zone it is guaranteed in. 送信接続 SNAT ポートの割り当ては、ゾーンの障害でも維持され、ゾーンの障害による影響を受けていない場合、このシナリオでは引き続き送信 SNAT 接続が提供されます。Outbound connection SNAT port allocations survive zone failures and your scenario will continue to provide outbound SNAT connectivity if not impacted by zone failure. これは、影響を受けたゾーンによってフローが処理された場合、ゾーン冗長のシナリオで転送または接続の再確立が必要になることがあります。This may require transmissions or for connections to be re-established for zone-redundant scenarios if a flow was served by an impacted zone. 影響を受けるゾーン以外のゾーン内のフローは、影響を受けません。Flows in zones other than the impacted zones are not affected.

SNAT ポートの事前割り当てアルゴリズムは、可用性ゾーンがあってもなくても同じです。The SNAT port preallocation algorithm is the same with or without availability zones.

正常性プローブHealth probes

既存の正常性プローブの定義は、可用性ゾーンがない場合でも同じです。Your existing health probe definitions remain as they are without availability zones. ただし、正常性モデルはインフラストラクチャ レベルで拡張されています。However, we've expanded the health model at an infrastructure level.

ゾーン冗長のフロントエンドを使うと、Load Balancer の内部正常性モデルは、各可用性ゾーンからの仮想マシンの到達可能性を独立してプローブし、障害が発生した可能性のあるゾーンとのパスをユーザーの介入なしにシャットダウンするように、拡張されます。When using zone-redundant frontends, Load Balancer expands its internal health model to independently probe the reachability of a virtual machine from each availability zone and shut down paths across zones that may have failed without customer intervention. あるゾーンの Load Balancer インフラストラクチャから別のゾーン内の仮想マシンへの特定のパスを使用できない場合、Load Balancer はこの障害を検出して回避することができます。If a given path is not available from the Load Balancer infrastructure of one zone to a virtual machine in another zone, Load Balancer can detect and avoid this failure. この VM に到達できる他のゾーンは、それぞれのフロントエンドから VM の処理を続けることができます。Other zones who can reach this VM can continue to serve the VM from their respective frontends. その結果、障害が発生している間は、エンド ツー エンドのサービスの全体的な正常性を保護するために、各ゾーンで新しいフローのディストリビューションが若干異なる可能性があります。As a result, it is possible that during failure events, each zone may have slightly different distributions of new flows while protecting the overall health of your end-to-end service.

設計上の考慮事項Design considerations

Load Balancer は、可用性ゾーンのコンテキストにおいて柔軟性を持つように意図されています。Load Balancer is purposely flexible in the context of availability zones. ゾーンに一致させることも、規則ごとにゾーン冗長にすることもできます。You can choose to align to zones or you can choose to be zone-redundant for each rule. 可用性を高めると複雑さが増す可能性があり、パフォーマンスが最適になるように可用性を設計する必要があります。Increased availability can come at the price of increased complexity and you must design for availability for optimal performance. 以下では、設計に関する重要な考慮事項を示します。Let's take a look at some important design considerations.

自動ゾーン冗長性Automatic zone-redundancy

Load Balancer を使うと、ゾーン冗長フロントエンドとして 1 つの IP アドレスを簡単に持つことができます。Load Balancer makes it simple to have a single IP as a zone-redundant frontend. ゾーン冗長 IP アドレスは、任意のゾーンでゾーン ベースのリソースを安全に提供でき、リージョン内に正常なゾーンが 1 つでも残っている限り、1 つまたは複数のゾーンで障害があっても存続できます。A zone-redundant IP address can safely serve a zonal resource in any zone and can survive one or more zone failures as long as one zone remains healthy within the region. 逆に、ゾーン ベースのフロントエンドは、単一のゾーンへのサービスの縮小であり、対応するゾーンの正常性に依存します。Conversely, a zonal frontend is a reduction of the service to a single zone and shares fate with the respective zone.

ゾーンの冗長性は、ヒットレス データパスまたは制御プレーンを意味するものではなく、データ プレーンを明示します。Zone-redundancy does not imply hitless datapath or control plane; it is expressly data plane. ゾーン冗長なフローは任意のゾーンを使うことができ、ユーザーのフローはリージョン内で正常なすべてのゾーンを使います。Zone-redundant flows can use any zones and a customer's flows will use all healthy zones in a region. ゾーンで障害が発生すると、その時点で正常なゾーンを使っているトラフィック フローは影響を受けません。In the event of zone failure, traffic flows using healthy zones at that point in time are not impacted. ゾーンで障害が発生したときにゾーンを使用しているトラフィック フローは影響を受ける可能性がありますが、アプリケーションは復旧できます。Traffic flows using a zone at the time of zone failure may be impacted but applications can recover. Azure がゾーンの障害を収束したら、再送信または再確立時にリージョン内に残っている正常なゾーンでこれらのフローを続行できます。These flows can continue in the remaining healthy zones within the region upon retransmission or reestablishment, once Azure has converged around the zone failure.

ゾーンの境界を越えるCross zone boundaries

エンド ツー エンドのサービスがゾーンを越えるときは常に、1 つのゾーンではなく複数のゾーンの正常性に依存する可能性があることを理解しておくことが重要です。It is important to understand that any time an end-to-end service crosses zones, you share fate with not one zone but potentially multiple zones. その結果、エンド ツー エンドのサービスは、ゾーン ベースではない展開より可用性が高くならない可能性があります。As a result, your end-to-end service may not have gained any availability over non-zonal deployments.

可用性ゾーンを使ったときの可用性のメリットがなくなる、意図しないクロスゾーンの依存関係が発生しないようにします。Avoid introducing unintended cross-zone dependencies, which will nullify availability gains when using availability zones. アプリケーションが複数のコンポーネントで構成されていて、ゾーンの障害に対する回復力が必要な場合は、ゾーンで障害が発生したときに十分な数の重要なコンポーネントが存続するように注意する必要があります。When your application consists of multiple components and you wish to be resilient to zone failure, you must take care to ensure the survival of sufficient critical components in the event of a zone failing. たとえば、アプリケーションの 1 つの重要なコンポーネントが、障害を存続できなかったゾーンに存在していた場合、アプリケーション全体に影響する可能性があります。For example, a single critical component for your application can impact your entire application if it only exists in a zone other than the surviving zone(s). さらに、ゾーンの復元とアプリケーションの収束方法についても検討します。In addition, also consider the zone restoration and how your application will converge. アプリケーションがその一部の障害に関してどのように判別するかを理解する必要があります。You need to understand how your application reasons with respect to failures of portions of it. 以下で確認する重要な点を、特定のシナリオについて考えるときの質問の参考にしてください。Let's review some key points and use them as inspiration for questions as you think through your specific scenario.

  • アプリケーションに 2 つのコンポーネント (たとえば、IP アドレスと、マネージド ディスクを含む仮想マシン) があり、ゾーン 1 とゾーン 2 で保証されている場合、ゾーン 1 で障害が発生すると、エンド ツー エンド サービスは存続できません。If your application has two components like an IP address and a virtual machine with managed disk, and they're guaranteed in zone 1 and zone 2, when zone 1 fails your end-to-end service will not survive when zone 1 fails. 潜在的に危険性のある障害モードを作成していることをよく理解していない限り、ゾーン ベースのシナリオでゾーンをクロスさせないようにしてください。Don't cross zones with zonal scenarios unless you fully understand that you are creating a potentially hazardous failure mode. このシナリオでは柔軟性を提供できます。This scenario is allowed to provide flexibility.

  • アプリケーションに 2 つのコンポーネント (たとえば、IP アドレスと、マネージド ディスクを含む仮想マシン) があり、それぞれでゾーン冗長とゾーン 1 が保証されている場合、ゾーン 1 さえ正常であれば、ゾーン 2 とゾーン 3 のどちらか一方または両方で障害が発生しても、エンド ツー エンドのサービスは存続できます。If your application has two components like an IP address and a virtual machine with managed disk, and they are guaranteed to be zone-redundant and zone 1 respectively, your end-to-end service will survive zone failure of zone 2, zone 3, or both unless zone 1 has failed. ただし、フロントエンドの到達可能性だけを観察している場合は、サービスの正常性を判断する機能が若干失われます。However, you lose some ability to reason about the health of your service if all you are observing is the reachability of the frontend. さらに広範な正常性と容量のモデルの開発を検討します。Consider developing a more extensive health and capacity model. ゾーン冗長とゾーン ベースの概念を組み合わせて、洞察と管理容易性を拡張する場合があります。You might use zone-redundant and zonal concepts together to expand insight and manageability.

  • アプリケーションの 2 つのコンポーネント (たとえば、ゾーン冗長な Load Balancer フロントエンドと、クロスゾーンの仮想マシン スケール セット) が 3 つのゾーンに存在している場合、障害の影響を受けないゾーンのリソースは使用できますが、エンド ツー エンド サービスの容量はゾーン障害の間に低下する可能性があります。If your application has two components like a zone-redundant Load Balancer frontend and a cross-zone virtual machine scale set in three zones, your resources in zones not impacted by failure will be available but your end-to-end service capacity may be degraded during zone failure. インフラストラクチャの観点からは、1 つ以上のゾーンで障害が発生しても展開は存続することができ、これにより次のような質問が発生します。From an infrastructure perspective, your deployment can survive one or more zone failures, and this raises the following questions:

    • このような障害および容量低下をアプリケーションが判断する方法を理解していますか。Do you understand how your application reasons about such failures and degraded capacity?
    • サービスには、必要に応じてリージョン ペアに強制的にフェールオーバーする安全策が必要ですか。Do you need to have safeguards in your service to force a failover to a region pair if necessary?
    • どのような方法で、このようなシナリオを監視、検出、軽減しますか。How will you monitor, detect, and mitigate such a scenario? Standard Load Balancer の診断機能を使って、エンド ツー エンド サービスのパフォーマンスの監視を強化できる場合があります。You may be able to use Standard Load Balancer diagnostics to augment monitoring of your end-to-end service performance. 使用可能なもの、および全体像のために拡張が必要なものを検討します。Consider what is available and what may need augmentation for a complete picture.
  • ゾーンを使うと、障害の把握と阻止が容易になる可能性があります。Zones can make failures more easily understood and contained. ただし、タイムアウト、再試行、バックオフ アルゴリズムなどの概念に関しては、ゾーンの障害も他の障害と違いはありません。However, zone failure is no different than other failures when it comes to concepts like timeouts, retries, and backoff algorithms. Azure Load Balancer がゾーン冗長なパスを提供し、迅速な復旧を試みる場合であっても、リアルタイムのパケット レベルでは、障害が発生すると再送信または再確立が行われる可能性があり、アプリケーションが障害に対処する方法を理解しておくことが重要です。Even though Azure Load Balancer provides zone-redundant paths and tries to recover quickly, at a packet level in real time, retransmissions or reestablishments may occur during the onset of a failure and it's important to understand how your application copes with failures. 負荷分散スキームは存続しますが、次のことを計画する必要があります。Your load-balancing scheme will survive, but you need to plan for the following:

    • ゾーンで障害が発生した場合、エンド ツー エンド サービスはそれを認識しますか。また、状態が失われた場合、どのようにして復旧しますか。When a zone fails, does your end-to-end service understand this and if the state is lost, how will you recover?
    • ゾーンが復帰したとき、アプリケーションは安全に収束する方法を認識しますか。When a zone returns, does your application understand how to converge safely?

障害シナリオに対するアプリケーションの回復性を向上させるには、Azure クラウド設計パターンに関する記事を参照してください。Review Azure cloud design patterns to improve the resiliency of your application to failure scenarios.

ゾーン冗長とゾーン ベースの比較Zone-redundant versus zonal

ゾーン冗長は、ゾーンに依存しないオプションと、サービスに対する単一の IP アドレスでの回復性オプションの併用により、シンプルさを実現します。Zone-redundant can provide a simplicity with a zone-agnostic option and at the same time resilient option with a single IP address for the service. さらに、複雑さを低下させることができます。It can reduce complexity in turn. ゾーン冗長は、ゾーンを越えて移動することもでき、任意のゾーンのリソースで安全に使用できます。Zone-redundant also has mobility across zones, and can be safely used on resources in any zone. また、可用性ゾーンのないリージョンでも将来的に保証されており、リージョンで可用性ゾーンを利用できるようになったときに必要な変更を制限できます。Also, it's future proof in regions without availability zones, which can limit changes required once a region does gain availability zones. ゾーン冗長の IP アドレスまたはフロントエンドの構成構文は、可用性ゾーンがないリージョンも含めて、すべてのリージョンで成功します。ゾーンはリソースの zones プロパティ内で指定されません。The configuration syntax for a zone-redundant IP address or frontend succeeds in any region including those without availability zones: a zone is not specified within the zones: property of the resource.

ゾーン ベースは、1 つのゾーンに対する明示的な保証を提供し、そのゾーンの正常性に明示的に依存します。Zonal can provide an explicit guarantee to a zone, explicitly sharing fate with the health of the zone. ゾーン ベースの IP アドレス フロントエンドまたはゾーン ベースの内部 Load Balancer フロントエンドを使用した Load Balancer 規則の作成は、アタッチされているリソースが同じゾーン内のゾーン ベースの仮想マシンであるときは特に望ましい場合があります。Creating a Load Balancer rule with a zonal IP address frontend or zonal internal Load Balancer frontend can be a desirable especially if your attached resource is a zonal virtual machine in the same zone. そうでなければおそらく、アプリケーションはリソースが存在するゾーンを前もって明確に知る必要があり、ユーザーは別のゾーンの可用性を明示的に判別する必要があります。Or perhaps your application requires explicit knowledge about which zone a resource is located in ahead of time and you wish to reason about availability in separate zones explicitly. 複数のゾーンに分散されているエンド ツー エンド サービスに対し、複数のゾーン ベースのフロントエンドを公開することもできます (つまり、複数のゾーン ベースの仮想マシン スケール セットに対して、ゾーンごとのゾーン ベースのフロントエンド)。You can choose to expose multiple zonal frontends for an end-to-end service distributed across zones (that is, per zone zonal frontends for multiple zonal virtual machine scale sets). また、ゾーン ベースのフロントエンドがパブリック IP アドレスである場合は、これらの複数のゾーン ベースのフロントエンドを使って、Traffic Manager でサービスを公開することができます。And if your zonal frontends are public IP addresses, you can use these multiple zonal frontends for exposing your service with Traffic Manager. または、複数のゾーン ベースのフロントエンドを使うと、サード パーティ製の監視ソリューションによりゾーンごとの正常性とパフォーマンスの洞察を取得でき、ゾーン冗長なフロントエンドでサービス全体を公開することができます。Or you can use multiple zonal frontends to gain per zone health and performance insights through third party monitoring solutions and expose the overall service with a zone-redundant frontend. ゾーン ベースのリソースの提供は、同じゾーンに揃えられたゾーン ベースのフロントエンドでのみ行う必要があり、ゾーン ベースのリソースに対して潜在的に危険なクロスゾーン シナリオは回避する必要があります。You should only serve zonal resources with zonal frontends aligned to the same zone and avoid potentially harmful cross-zone scenarios for zonal resources. ゾーン ベースのリソースは、可用性ゾーンが存在するリージョンにのみ存在します。Zonal resources only exist in regions where availability zones exist.

サービス アーキテクチャを理解することなく、選択肢の優劣を判断するための一般的なガイダンスはありません。There's no general guidance that one is a better choice than the other without knowing the service architecture. 障害シナリオに対するアプリケーションの回復性を向上させるには、Azure クラウド設計パターンに関する記事を参照してください。Review Azure cloud design patterns to improve the resiliency of your application to failure scenarios.

次のステップNext steps