Azure Load Balancer は、サービスの正常なインスタンス間で受信トラフィックを分散するレイヤー 4 (TCP/UDP) 負荷分散サービスです。 Load Balancer は、超低待機時間で高可用性とネットワーク パフォーマンスをアプリケーションに提供します。
Azure を使用する場合、 信頼性は共有責任です。 Microsoft では、回復性と回復性をサポートするさまざまな機能を提供しています。 使用するすべてのサービスでこれらの機能がどのように機能するかを理解し、ビジネス目標とアップタイムの目標を達成するために必要な機能を選択する必要があります。
この記事では、一時的な障害、可用性ゾーンの停止、リージョンの停止など、さまざまな障害や問題に対する Load Balancer の回復性を確保する方法について説明します。 また、Load Balancer サービス レベル アグリーメント (SLA) に関する重要な情報も示します。
Important
ソリューション全体の信頼性は、ロード バランサーがトラフィックをルーティングするバックエンド インスタンス (サーバー) (Azure 仮想マシン (VM) や Azure 仮想マシン スケール セットなど) の構成によって異なります。
バックエンド インスタンスはこの記事の対象ではありませんが、それらの可用性構成はアプリケーションの回復性に直接影響します。 ソリューション内のすべての Azure サービスの信頼性ガイドを確認して、各サービスが信頼性要件をどのようにサポートしているかを理解します。 バックエンド インスタンスも高可用性とゾーン冗長性のために構成されるようにすることで、アプリケーションのエンドツーエンドの信頼性を実現できます。
運用環境のデプロイに関する推奨事項
Azure Well-Architected Framework では、信頼性、パフォーマンス、セキュリティ、コスト、運用に関する推奨事項が提供されます。 これらの領域が互いに及ぼす影響を理解し、信頼性の高い Load Balancer ソリューションに貢献する方法については、 Azure Well-Architected Framework での Load Balancer のアーキテクチャのベスト プラクティスに関するページを参照してください。
信頼性アーキテクチャの概要
ロード バランサーには、パブリックまたは内部のいずれかを指定できます。 パブリック ロード バランサーは、パブリック IP アドレス リソースを介してインターネットからのトラフィックを受け入れます。 内部ロード バランサーには、仮想ネットワーク内と、仮想ネットワークに接続する他のネットワーク内でのみアクセスできます。
各ロード バランサーは、次のような複数のコンポーネントで構成されます。
- トラフィックを受信するフロントエンド IP 構成。 パブリック ロード バランサーは、パブリック IP アドレスでトラフィックを受信します。 内部ロード バランサーは、仮想ネットワーク内の IP アドレスでトラフィックを受信します。
- バックエンド プール。アプリケーションを実行する個々の VM など、トラフィックを受信できる バックエンド インスタンス のコレクションが含まれます。
- 負荷分散規則。フロントエンドからのトラフィックをバックエンド プールに分散する方法を定義します。
- 正常性プローブ。バックエンド インスタンスの可用性を監視します。
Load Balancer のしくみの詳細については、「 Load Balancer コンポーネント」を参照してください。
グローバルにデプロイされたソリューションの場合は、 グローバル ロード バランサーをデプロイできます。これは、ソリューションのさまざまなリージョンデプロイ間でトラフィックをルーティングするように設計された特殊な種類のパブリック ロード バランサーです。 グローバル ロード バランサーは、単一のエニーキャスト IP アドレスを提供します。 クライアントの近接性とリージョンの正常性状態に基づいて、最も近い正常なリージョン ロード バランサーにトラフィックをルーティングします。 詳細については、「 リージョン全体の障害に対する回復性」を参照してください。
一時的な障害に対する回復性
一時的な障害は、コンポーネントにおける短い断続的な障害です。 これらはクラウドのような分散環境で頻繁に発生し、運用の通常の範囲であり、 一時的な障害は、短時間の経過後に自分自身を修正します。 アプリケーションで一時的な障害を処理できることは重要です。通常は、影響を受ける要求を再試行します。
クラウドでホストされるすべてのアプリケーションは、クラウドでホストされている API、データベース、およびその他のコンポーネントと通信する際に、Azure の一時的な障害処理のガイダンスに従う必要があります。 詳細については、「一時的な障害を処理するための推奨事項」を参照してください。
Load Balancer を使用する場合は、アプリケーションに影響する一時的な障害のリスクを最小限に抑えるために、次のベスト プラクティスを検討してください。
再試行ロジックを実装します。 クライアントは、指数バックオフ戦略を含め、一時的な接続エラーに対して適切な再試行メカニズムを実装する必要があります。
許容値を設定した正常性プローブを構成します。 一時的な問題の誤検知を避けつつ迅速に障害を検出するために、ヘルスプローブを設定します。
SNAT ポートの割り当てを監視します。 送信接続の場合は、SNAT ポートの割り当てを監視し、ポート不足による一時的な接続エラーを防ぐために送信規則を構成します。
可用性ゾーンの障害に対する回復性
可用性ゾーン は、Azure リージョン内のデータセンターの物理的に分離されたグループです。 1 つのゾーンで障害が発生した際には、サービスを残りのゾーンのいずれかにフェールオーバーできます。
Load Balancer は、作成する各フロントエンド IP 構成を構成することで 、ゾーン冗長 としてデプロイできます。 ゾーン冗長フロントエンド IP 構成は、複数のゾーン内の独立したインフラストラクチャから同時に提供されます。 この構成により、ゾーンの障害が、ロード バランサーがトラフィックを受信および分散する機能に影響を与えないようにします。
次の図は、ゾーン冗長パブリック IP アドレスを作成することによって構成されるゾーン冗長パブリック ロード バランサーを示しています。
次の図は、同様のゾーン冗長構成を使用する内部ロード バランサーを示しています。
注
ゾーン ロード バランサーはデプロイできますが、単一のゾーンにデプロイされているワークロードの場合でも、ゾーン冗長ロード バランサーを常に使用することをお勧めします。 Microsoft は現在、すべてのパブリック IP アドレスとロード バランサーをゾーン冗長に移行しています。
可用性ゾーンのないリージョンでは、ゾーンが構成されていないフロントエンド構成を使用して 、非ゾーン 構成または リージョン 構成でロード バランサーが作成されます。 リージョンで障害が発生した場合、非ゾーン ロード バランサーでダウンタイムが発生する可能性があります。
バックエンド インスタンスと可用性ゾーン
バックエンド インスタンスの可用性ゾーン構成は、ロード バランサーのフロントエンド IP 構成とは無関係です。
バックエンド インスタンスが属するサービスの信頼性機能と設計するアーキテクチャに従って、関連するサービスを構成して、ゾーン間でバックエンド インスタンスを分散します。
注
回復性のためには、バックエンド インスタンスを複数の可用性ゾーンに分散することが不可欠です。 すべてのバックエンド インスタンスが 1 つのゾーンに配置されている場合、ゾーン冗長ロード バランサーを使用している場合でも、そのゾーンで障害が発生すると、アプリケーションは使用できなくなります。
たとえば、VM を使用する場合、運用ワークロードの一般的な設計アプローチは、ゾーン 1、2、3 に複数のゾーン VM を配置してゾーンの回復性を実現することです。 負荷分散のために、ゾーン冗長ロード バランサーを作成し、それらの VM をロード バランサー内のバックエンド インスタンスとして構成できます。 ロード バランサーの正常性プローブは、ゾーンの場所に関係なく、異常な VM をローテーションから自動的に削除します。
ただし、VM を同じ可用性ゾーンにデプロイする場合でも、ゾーン冗長フロントエンド IP 構成をロード バランサーにデプロイできます。次の図に示します。
Requirements
リージョンのサポート: ゾーン冗長ロード バランサーは、 可用性ゾーンをサポートする任意のリージョンにデプロイできます。
費用
可用性ゾーンの構成では、ロード バランサーの課金方法は変更されません。 課金は、ゾーン構成に関係なく、構成されたルールと処理されたデータの数に基づきます。 詳細については、 Azure Load Balancer の価格に関するページを参照してください。
可用性ゾーンのサポートを設定する
Load Balancer を使用する場合は、フロントエンド IP 構成で可用性ゾーンのサポートを設定します。
可用性ゾーンをサポートする新しいロード バランサーを作成します。
パブリック ロード バランサーの場合、フロントエンド IP 構成では、関連付けるパブリック IP アドレス リソースの可用性ゾーン構成が自動的に採用されます。 フロントエンド IP 構成をゾーン冗長にするには、ゾーン冗長パブリック IP アドレスを作成または選択します。 パブリック IP アドレスは、既定ではゾーン冗長です。 詳細な手順については、 Azure portal を使用して VM の負荷分散を行うパブリック ロード バランサーの作成に関するページを参照してください。
内部ロード バランサーの場合、ロード バランサーのフロントエンド IP を構成するときに、フロントエンド IP 構成で可用性ゾーンのサポートの種類を設定します。 詳細な手順については、「 Azure portal を使用して VM の負荷分散を行う内部ロード バランサーを作成する」を参照してください。
既存のロード バランサーの可用性ゾーン構成を変更します。 既存のロード バランサーの可用性ゾーン構成を変更するには、フロントエンド IP 構成を置き換える必要があります。 この方法を使用して、ゾーンベースからゾーン冗長フロントエンド IP 構成に移行できます。 大まかなアプローチは次のとおりです。
目的の可用性ゾーン構成を使用して、新しいフロントエンド IP 構成を作成します。
パブリック ロード バランサーの場合は、最初に目的の可用性ゾーン構成を使用する新しいパブリック IP アドレスを作成します。 次に、ロード バランサーを再構成して、そのパブリック IP アドレスを参照するフロントエンド IP 構成を追加します。
内部ロード バランサーの場合は、目的の可用性構成で新しいフロントエンド IP 構成を追加するようにロード バランサーを再構成します。 この手順では、サブネット内から新しいプライベート IP アドレスを割り当てます。
新しいフロントエンド IP 構成を使用するように負荷分散規則を再構成します。
Important
この操作では、新しいフロントエンド IP アドレスにトラフィックを送信するようにクライアントを再構成する必要があります。 クライアントによっては、プロセスにダウンタイムが必要になる場合があります。
古いフロントエンド IP 構成を削除します。
すべてのゾーンが正常な場合の動作
このセクションでは、ロード バランサーがゾーン冗長フロントエンド IP 構成を使用し、すべての可用性ゾーンが動作している場合に想定される内容について説明します。
ゾーン間のトラフィック ルーティング: 負荷分散は、任意の可用性ゾーンで実行できます。 バックエンド インスタンスがどの可用性ゾーンにあるかを考慮せずに、バックエンド プールで指定された正常なバックエンド インスタンスにトラフィックが送信されます。
ゾーン間のデータ レプリケーション。 Load Balancer は、アプリケーション データを格納またはレプリケートしないネットワーク パススルー サービスです。 ロード バランサーで セッション永続化 を有効にした場合でも、状態はロード バランサーに格納されません。 セッション永続化は、同じバックエンド インスタンスに要求をルーティングするようにハッシュ 処理を調整します。 ただし、セッションの永続化は保証されません。 バックエンド プールが変更されると、クライアント要求の分散が再計算されます。 このプロセスは、状態を保存または同期せずに実行されます。
このサービスは、ゾーン間の同期レプリケーションによって構成状態を維持し、負荷分散規則、正常性プローブ構成、およびすべてのゾーンのバックエンド プール メンバーシップの即時整合性を確保します。
ゾーン障害時の動作
このセクションでは、ロード バランサーがゾーン冗長フロントエンド IP 構成を使用し、可用性ゾーンが停止した場合に想定される内容について説明します。
- 検出と応答: Azure プラットフォームは、可用性ゾーンでの障害の検出と応答を担当します。 ゾーンのフェールオーバーを開始するために何もする必要はありません。
- 通知: ゾーンがダウンしても、Microsoft から自動的に通知されることはありません。 ただし、 Azure Resource Health を 使用して個々のリソースの正常性を監視したり、 Resource Health アラート を設定して問題を通知したりすることはできます。 また、Azure Service Health を使用して、ゾーンの障害を含むサービスの全体的な正常性を把握し、問題を通知する Service Health アラートを設定することもできます。
アクティブな要求: 失敗したゾーン内の既存の TCP/UDP フローはリセットされ、クライアントによって再試行される必要があります。 クライアントには、自動再試行を含め、十分な 一時的な障害処理 が実装されている必要があります。
予想されるデータ損失: ステートレス ネットワーク サービスとして、Load Balancer はアプリケーション データを格納しないため、ロード バランサー レイヤーでデータ損失は発生しません。
予期されるダウンタイム: ロード バランサーは正常なゾーンから引き続き動作するため、ゾーン冗長ロード バランサーのダウンタイムは発生しません。
ただし、障害がゾーン内のコンピューティング サービスに影響を与える場合は、影響を受けるゾーン内にある VM またはその他のリソースが使用できなくなる可能性があります。 ロード バランサーの正常性プローブは、これらのエラーを検出し、負荷分散アルゴリズムとバックエンド インスタンスの正常性状態に基づいて別のゾーンの代替インスタンスにトラフィックをルーティングするように設計されています。
トラフィックの再ルーティング: ロード バランサーは正常なゾーンから引き続き動作します。 Load Balancer サービスは、ゾーン障害時に同じフロントエンド IP アドレスを保持します。 この動作は、DNS 更新プログラムを適用したり、クライアントを再構成したりする必要がないようにすることを意味します。 新しい接続は、残りの正常なゾーンを通じて自動的に確立されます。
ゾーンの回復
可用性ゾーンが復旧すると、Load Balancer は通常の操作を自動的に再開します。 ゾーン冗長フロントエンドは、復旧されたゾーンからのトラフィックを他の運用ゾーンと共に自動的に処理し始めます。 復旧されたゾーンからの正常性プローブは、バックエンド インスタンスの評価を再開します。
ゾーンの障害がゾーン内のコンピューティング サービスにも影響を与えた場合、復旧されたゾーン内のバックエンド インスタンスが正常性チェックに合格すると、正常なバックエンド プールに自動的に追加されます。 トラフィック分散は、負荷分散アルゴリズムとバックエンド インスタンスの正常性状態に基づいて、使用可能なすべてのゾーン間で再調整されます。
ゾーンエラーのテスト
Azure プラットフォームは、トラフィック ルーティング、ゾーンダウン応答、および復旧を管理します。 これらの機能はフル マネージドであるため、可用性ゾーンの障害プロセスを開始または検証する必要はありません。
Azure Chaos Studio を使用して、1 つのゾーン内の VM の障害をシミュレートできます。 Chaos Studio には、VM のシャットダウンなど、 VM に組み込みの障害が用意されています。 これらの機能を使用して、ゾーンの障害をシミュレートし、フェールオーバー プロセスをテストできます。
リージョン全体の障害に対する回復性
パブリック ロード バランサーと内部ロード バランサーは、単一の Azure リージョンにデプロイされます。 リージョンが使用できなくなった場合、そのリージョン内のロード バランサーも使用できなくなります。 ただし、Azure Load Balancer は、グローバル ロード バランサーを通じてネイティブマルチリージョンのサポートを提供します。これにより、Azure リージョン間での負荷分散が可能になります。 他の負荷分散サービスをデプロイして、Azure リージョン間でルーティングとフェールオーバーを行うこともできます。
グローバル ロード バランサー
Global Load Balancer は、クライアントの近接性とリージョンの正常性に基づいて最適なリージョンデプロイにトラフィックを自動的にルーティングする単一の静的エニーキャスト IP アドレスを提供します。 グローバル ロード バランサーは、アプリケーションの信頼性とパフォーマンスの向上に役立ちます。
グローバル ロード バランサーでは、複数のパブリック ロード バランサーを異なるリージョンにデプロイします。グローバル ロード バランサーはグローバル フロントエンドとして機能します。 あるリージョンのバックエンド サーバーに問題がある場合、エニーキャスト IP アドレスは一定のままであり、トラフィックは別のリージョンにルーティングされるため、トラフィックは正常なリージョンに自動的に切り替わり、DNS は変更されません。
詳細については、「 グローバル ロード バランサー」を参照してください。
回復性のためのカスタム マルチリージョン ソリューション
Azure には、さまざまな要件に合ったさまざまな負荷分散サービスが用意されています。 回復性の要件を満たし、アプリケーションの種類に合ったロード バランサーを選択できます。 詳細については、「 負荷分散オプション」を参照してください。
サービス水準合意書
Azure サービスのサービス レベル アグリーメント (SLA) には、各サービスの期待される可用性と、その可用性の期待を達成するためにソリューションが満たす必要がある条件について記載されています。 詳細については、 オンライン サービスの SLA を参照してください。
Azure Load Balancer の SLA は、バックエンド インスタンスとして構成された正常な VM が少なくとも 2 つある場合に適用されます。 SLA では、トラフィックをブロックする SNAT ポートの枯渇またはネットワーク セキュリティ グループ (NSG) によるダウンタイムは除外されます。