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