Azure Load Balancer のトラブルシューティング
Azure Load Balancer は、ネットワーク スタックのトランスポート層で動作します。 Load Balancer によって、すべてのクライアントが接続する 1 つのパブリック IP アドレスがアドバタイズされます。 その後、Load Balancer では、独自のルーティングおよびアドレス変換ルールを使用して、受信した TCP 要求が送信アドレスのセットの 1 つに転送されます。 通常、各送信アドレスは、それぞれでアプリケーションのインスタンスが実行されている異なる仮想マシン (VM) に関連付けられています。
Load Balancer では、正常性プローブを使って、バックエンド プールの各 VM の可用性が判断されます。 Load Balancer では、正常であることを示した VM だけに要求が送信されます。
この例のシナリオでは、Load Balancer がバックエンド プール内の VM に要求を送信できないことを示すアラートを受け取りました。 ネットワーク構成の最近の変更によって問題が発生している可能性があります。 しかし、ネットワークの変更が Load Balancer の動作にどのような影響を与えるのかを理解する必要があります。
このユニットを完了すると、次のことができるようになります。
- Load Balancer の一般的な構成と、VM への要求のルーティングに関係するコンポーネントについて説明します。
- Load Balancer が VM への要求の分散に失敗する可能性がある一般的な問題について説明します。
Load Balancer のしくみ
Azure Load Balancer には、次のような多くのコンポーネントが含まれています。
- フロントエンド IP アドレス
- VM アドレスのバックエンド プール
- 1 つ以上のルーティング規則
- 正常性プローブ
- VM のコレクション (通常は仮想ネットワーク内)
次の図では、Load Balancer が使用するさまざまな要素の連携を示しています。
フロントエンド IP アドレスとバックエンド プール
Load Balancer では、クライアントから VM のコレクションで実行されるアプリケーションへの、透過的なエンドツーエンド接続が提供されます。 Load Balancer では、これらの VM の IP アドレスが、一般に "バックエンド プール" と呼ばれるリポジトリに格納されます。 Load Balancer からは、独自の "フロントエンド" IP アドレスがクライアントに対して公開されます。 クライアントからこのアドレスに要求が送信されると、Load Balancer によって、バックエンド プールから VM の IP アドレスが選択されます。 その後、Load Balancer では、このバックエンド IP アドレスを通して VM に要求がルーティングされます。
クライアントが Load Balancer を認識することはありません。 クライアントでは、IP アドレスまたは DNS 名が認識され、この宛先に要求が送信されます。 このプロセスは、クライアントが VM と直接通信している場合と同じです。 要求が VM に到着したとき、元のクライアントのアドレスは保持されています。
また、クライアントから VM に送信されるメッセージのペイロードは、Load Balancer からは見えません。 Load Balancer でメッセージの内容が調べられたり操作されたりすることはありません。 選択された VM に送信されるように、メッセージの宛先のアドレスが再設定されます。
Load Balancer では、要求を均等に分散するように設計されたアルゴリズムを使用して、バックエンド プールから VM の IP アドレスが選択されます。 Load Balancer により、次の情報を使用してハッシュが生成されます。
- クライアントのソース IP とポート アドレス
- 宛先 IP アドレスとポート
- ネットワーク プロトコル
ハッシュ値は、バックエンド プール内で IP アドレスが保持されているテーブルのキーとして使用されます。
スケーラビリティ
いつでもさらに VM インスタンスを起動し、その IP アドレスをバックエンド プールに追加できます。 Load Balancer により、ユーザーの要求を分散させるときに、これらの新しいインスタンスが組み込まれます。
Load Balancer では、複数のパブリック フロントエンド IP アドレスを公開し、複数のバックエンド プールを持つことができます。 このスキームにより、Load Balancer の同じインスタンスを再利用して、異なるシステムに対する要求を処理できます。
ルーティング規則
各フロントエンド IP アドレス宛の要求をバックエンド プールにマップする方法を指定するには、負荷分散規則を定義します。 また、負荷分散規則では、照合するプロトコルと、必要に応じてソース (クライアント) と宛先のポートも指定します。 フロントエンド IP アドレスに到着した受信要求のうち、プロトコルとポートの要件が一致しないものは、Load Balancer によって破棄されます。 負荷分散規則では、セッションの永続性を構成することもできるため、特定のクライアントの要求が同じ VM にルーティングされる可能性を高くして、VM 上で実行されているアプリケーションがキャッシュを利用してセッション固有の情報を保持できるようになります。
正常性プローブ
Load Balancer では、バックエンド プールによって参照されている各 VM が要求の処理に使用できるかどうかを判断する必要があります。 可用性は、正常性プローブを追加することによって決定されます。 正常性プローブでは、バックエンド プール内の VM に対して指定されているポートに、定期的に ping メッセージが送信されます。 HTTP 200 (OK) メッセージでこれらの ping メッセージに応答するサービスを VM に指定します。
指定した試行回数の後に VM が応答に失敗すると、Load Balancer はそれが正常ではないと想定し、それをユーザー要求の受け入れが可能な VM 一覧から削除します。 その後、ワークロードは残りの正常な VM 間に分散されます。 Load Balancer では、応答しない VM に対しても引き続き ping が送信されます。 応答を開始した VM は、正常な VM の一覧に再び追加され、ユーザー要求の受信を再開します。
正常性プローブを使用しないと、Load Balancer では VM が正常かどうかを判断できません。 代わりに、すべての VM が応答するものと想定します。
仮想ネットワーク
バックエンド プールによって参照される VM は、Azure Virtual Network サブネット内でホストされます。 このネットワーク内の VM を保護するには、ネットワーク セキュリティ グループ (NSG) を構成します。 NSG では、仮想ネットワークと明確に定義された一連のエンドポイントの間で出入りするトラフィックを制限できる、受信および送信のセキュリティ規則が実装されます。
たとえば、Load Balancer のバックエンド プール内の VM では、通常、仮想ネットワークの外部からポート 80 (HTTP) とポート 443 (HTTPS) に到着する受信トラフィックが許可されます。 しかし、VM では他のポートで受信したトラフィックはブロックされる可能性があります。
Load Balancer での障害の現象と原因
Load Balancer とバックエンド プール内の 1 つ以上の VM との接続が失われると、問題が発生します。 一般的な現象は次のとおりです。
- アプリケーションが到達不能になる。
- アプリケーションを実行している VM が到達不能になる。
- 応答時間が遅い。
- ユーザー要求がタイムアウトする。
これらのエラーには多くの原因が考えられます。 これらは、最も多くの場合、プローブの問題とデータ パスの問題に関連しています。
プローブに関する問題
バックエンド プール内の 1 つ以上の VM が正常性プローブ要求に応答できない場合、プローブの問題が発生します。 これらの問題に対しては、次のような原因が考えられます。
- 間違った URL やポートなど、プローブ構成が正しくありません。
- 必要なポートが開かれていないため、VM がプローブに応答できません。
データ パスの問題
データ パスの問題は、バックエンド プール内の VM で実行されるアプリケーションに Load Balancer がクライアント要求をルーティングできない場合に発生します。 考えられる原因は次のとおりです。
- アプリケーションが使用しているポートまたは IP アドレスが、NSG のルールまたはファイアウォールによってブロックされています。
- VM がダウンしているか、応答していません。 VM が起動されていないか、障害を起こしている可能性があります。または、サーバーの証明書の有効期限切れなどのセキュリティに関する問題が発生しています。
- アプリケーションが応答していません。 VM が過負荷になっているか、アプリケーションが間違ったポートでリッスンしているか、アプリケーションがクラッシュしている可能性があります。