Share via

Azure のロードバランサーは pre-warming も監視も不要です

  • Article

こんにちは。Azure サポートの宇田です。

今回は、最近お問い合わせの多い、ロードバランサーの pre-warming と監視について、改めてご案内します。

Azure におけるロードバランサーの挙動については、以下の投稿もあわせてご確認ください。

パフォーマンスや可用性を考慮する必要はありません

Azure で負荷分散を行う方法は、「ロードバランサー経由での通信ができない場合のチェックポイント」の投稿でもご紹介した通り、複数の種類があります。

  • クラウド サービス (クラシック環境での呼称): リソース マネージャー環境での外部ロードバランサーと同等
  • 外部ロードバランサー (ALB / Azure Load Balancer): フロントエンドに Public IP を持つ L4 のロードバランサー
  • 内部ロードバランサー (ILB / Internal Load Balancer): フロントエンドに Private IP を持つ L4 のロードバランサー
  • アプリケーション ゲートウェイ (Application Gateway): HTTP / HTTPS の負荷分散を行う L7 のロードバランサー
  • トラフィック マネージャー (Traffic Manager): 複数のリージョンをまたぎ、DNS レベルでの負荷分散を行うロードバランサー

今回は前者 3 つ (クラウドサービス、ALB、ILB) についてふれますが、結論から先に言うといわゆる pre-warming は不要です。

Azure のロードバランサーは、専用のハードウェアを利用しているわけではなく、ソフトウェア的に複数のインスタンスにて並列処理を行うといった実装となっております。

詳しくは、以下 sigcomm 2013 のAnanta の論文もしくは de:code 2016 のセッション動画などをご確認いただければと思いますが、設計段階より 1 つのパブリック IP アドレスあたり 100 Gbps を容易に達成できることを前提としたアーキテクチャとなっています。また、Load Balancer の一部のインスタンスが仮にダウンした場合についても、他の正常なインスタンスで負荷分散処理が継続されるため、高い可用性を有しております。

このため、ロードバランサー自体のキャパシティや可用性について、お客様側で意識していただく必要はございません。
(※ 恒常的に数百 Gbps などのトラフィックが発生するなど、データセンターの帯域を大きく消費することが見込まれる場合には、念のためサポートへ事前にご相談いただけますと幸いです。)

 

ロードバランサーではなくサービスを監視しましょう

前述の仕組みを踏まえると、ロードバランサー自体の監視を行うよりも、ロードバランサーを介した通信が正しく行えるかという観点での監視が重要だとわかります。このため、一般的には以下の 2 つの観点で監視を行うことをご案内しています。

  • アプリケーション レイヤーでの監視
  • バックエンドの各インスタンスの監視

前者については、例えば Web サービスを提供している場合であれば、外部から HTTP で 200 OK のレスポンスが返るかという観点で、後者については各インスタンスの OS やアプリケーションが正常に動作しているかという観点で、それぞれ監視方法をご検討ください。

なお、以前「ロードバランサー経由での通信ができない場合のチェックポイント」の投稿でも取り上げた通り、ロードバランサーはバックエンドのサーバーがプローブに応答するかをもとに死活監視を行っています。このため、例えばバックエンドの Web サーバーのうち一台がダウンすると、それ以外の仮想マシンにのみ通信を振り分けることとなります。

ロードバランサーからみて、バックエンドの何台が生きていて、何台が死んでいるかは、Azure Load Balancer のログ機能でご確認いただくことも可能です。本機能は現在プレビュー中のため、内部ロードバランサー (ILB) については対応していないなど、一部制限がございます。以下ドキュメントをあわせてご確認ください。

 

本情報の内容（添付文書、リンク先などを含む）は、作成日時点でのものであり、予告なく変更される場合があります。