LoadBalancerで、一時的にDataPath Availabilityが著しく下がったが、Backend側で何か異常があったか

Question

4/28の2:00AM - 4:00AMの間で、LoadBalancerのDataPathAvailabilityが一時的に著しく下がりました。

以前、5分plotで平均が95%を下回ると以上の可能性が高いとご教示いただきましたが、今回の事象の場合、3:05時点の平均が90%となっております。

こちらの原因、またSLAに抵触するかどうかについてご教示お願いします。

---

<モデレーター注>
この質問スレッドは、スパムフィルターの誤判定により削除されていましたがスレッドを復元させて頂きました。

Answer 1

こんにちは SHIRAISHI, KAZUMA 。

Azure Load Balancerにおいて「DataPathAvailability」の低下が観測された件につきまして、ご連絡いただきありがとうございます。

「Data Path Availability（データパスの可用性）」メトリックは、Load Balancerのフロントエンドから正常な状態にあるバックエンドインスタンスへの接続確認（TCP ping）の成功率を表す指標です。これらの確認は継続的に実行され、ワー​​クロードに影響を与えることなく、実際のアプリケーショントラフィックと同じ経路を通過して行われます。

このメトリックの一時的な低下（例：約90%への低下）は、サンプリング期間中に接続確認の一部が成功しなかったことを示しています。これは必ずしもバックエンド側の障害を意味するものではなく、むしろデータパスの接続性における一時的な劣化を示唆するものです。

プラットフォームの観点からは、以下の点が挙げられます：

• Data Path Availabilityが90%未満かつ25%超の状態が2分以上継続した場合、当該リソースは「Degraded（劣化）」状態とみなされる可能性があります。
• また、メトリックが90%を下回った際、Azureプラットフォーム側で「DataPathAvailabilityWarning」イベントが発行されることがあります。これは、プラットフォーム側のイベントや一時的な環境要因によって引き起こされるものです。

考えられる原因：

通常、この事象は以下のいずれか、または複数の要因に起因するものと考えられます。

• 一時的なプラットフォームイベント（インフラストラクチャやネットワークの一時的な変動など）
• 断続的なバックエンドプローブの失敗（アプリケーションの応答遅延や無応答、ポートの応答が不安定な状態など）
• ヘルスプローブの設定不備、またはバックエンドへの到達性に関する問題
• 短時間の一時的なネットワーク輻輳（混雑）やパケット損失

SLAに関する考慮事項：

Azure Load BalancerのSLA（サービス品質保証）は、単一の5分間データポイントのみに基づいて評価されるものではありません。

• Data Path Availabilityメトリックは、あくまで診断やリソースの健全性を示す指標であり、SLAの直接的な測定値ではありません。
• SLAの遵守状況は、短時間の一時的な低下ではなく、月単位で集計された期間全体に基づいて判断されます。

したがって：

短時間の一時的な低下（例：午前3時05分頃に約90%まで低下したケースなど）のみをもって、直ちにSLA違反となるわけではありません。SLAの定義に基づき「ダウンタイム」として計測可能なほどの、継続的な影響が発生した場合に限り、SLA違反とみなされます。

今回の事象がバックエンド側、あるいはプラットフォーム側のどちらに起因するものかをさらに検証するには、以下の手順をご確認ください。

1. 事象が発生したのと同時刻における「Health Probe Status（ヘルスプローブの状態）」メトリックを確認する。
2. バックエンドインスタンスの中に、「Unhealthy（異常）」と判定されたものがないかを確認する。
3. 「Resource Health（リソースの正常性）」ブレードを確認し、プラットフォーム側から報告されたイベントがないかを調べる。
4. 「Azure Service Health」を確認し、対象リージョン全体に影響を及ぼすようなインシデントが発生していないかをクロスチェックする。

https://learn.microsoft.com/ja-jp/troubleshoot/azure/load-balancer/load-balancer-troubleshoot-health-event-logs

上記の情報がお役に立ったかどうか、また本件に関して他にサポートが必要な点がございましたら、ぜひお知らせください。

もしこの回答がお役に立ちましたら、ぜひ「役に立った（Upvote）」ボタンを押して評価をお願いいたします。この回答について追加のご質問がございましたら、「コメント」をクリックしてください。

Answer 2

SLA については、以下からダウンロードできる SLA の条項を確認してください。

• Licensing Documents

最新版の SLA 条項によれば、

「最大利用時間 (分)」とは、当該期間に Microsoft Azure サブスクリプションにおいてお客様が所定の Azure Standard Load Balancer (2 台以上の正常仮想マシンにサービスを提供する) をデプロイしていた総時間 (分) です。 「ダウンタイム」とは、最大利用時間 (分) のうち、所定の Azure Standard Load Balancer を使用できなかった総時間 (分) です。すべての正常仮想マシンがロードバランスエンドポイント経由で、1 分間接続できない場合、1 分間使用できなかったと見なされます。ダウンタイムには、SNAT ポートの消耗が原因となった時間は含まれません。 Azure Standard Load Balancer の「稼働率」とは、最大利用時間 (分) からダウンタイムを差し引き、最大利用時間 (分) で割って 100 を乗じた値です。 稼働率: 稼働率は次の式を使用して計算されます。 (最大利用時間 (分) - ダウンタイム) /"最大利用時間 (分)" x 100

そして SLA が維持できなかった場合のクレジットの返金は

稼働率	サービス クレジット
99.99% 未満	10%
99.9% 未満	25%

となります。

LoadBalancerのDataPathAvailabilityが一時的に著しく下がったとしても仮想マシンへの接続ができない状況でなければ「ダウンタイム」とはならず、SLA に抵触する動作ではないということになるかと思います。