Application Gateway

L7 負荷分散 Azure Application Gateway について:3回目

こんにちは。ヤモトです。
今回はApplication GatewayのHTTP設定と正常性プローブ設定について掘り下げながらお話ししたいと思います。

Application Gatewayのヘルスチェック機能

Application Gatewayにはバックエンド側に設定したサーバーに対し、正常性確認を行い異常と判断したサーバーを振り分け対象から外すヘルスチェック機能が備わっています。

通常のロードバランサーと同じようにバックエンドターゲットに対してポーリングを行い、異常と判断したターゲットを切り離す(振り分け対象から除外する)機能です。
異常と判断する為の失敗回数の閾値など、既にApplication Gatewayでは決まった設定がございます。
下記はApplication Gatewayの正常性確認に関する既定の設定です。

項目設定値
URLhttp(s)://127.0.0.1:ポート/
※ポート番号はHTTP設定の設定値です。
間隔30秒
タイムアウト値30秒
失敗の閾値3回
状態コード Status Code 200~399

下図は正常性確認がなされる際のイメージ図です。

Application Gatewayのヘルスチェック機能はApplication Gatewayに設定されたプライベートIPアドレスからバックエンド側のサーバーに対し、特定のURLへGET通信を投げそのGETへの返答の際に返すステータスコードに応じて正常/異常を判断します。
ヘルスチェックを行う対象のURLはHTTP設定で指定されているプロトコル及びポート番号が継承される形で反映されます。
30秒間隔でヘルスチェックを行い、上記URLに対してヘルスチェックを投げてから30秒返答が無い場合、失敗とカウントされます。
失敗のカウントが3回以上となった場合、対象のサーバーは”異常”と判断され、振り分けの対象から除外されます。

除外されたサーバーはどうなるの?という質問を時折頂くことがありますが、
振り分けから除外された後も30秒間隔でヘルスチェックがされ続け、200~399のHTTP応答コードが帰り次第振り分け対象に復帰します。

それでは、正常性プローブ機能を使用するのに必要な各設定の内容を
お話ししたいと思います。

HTTP設定について

  • HTTP設定とは
    Application GatewayのHTTP設定はルールによってルーティングされたトラフィックをバックエンドターゲットに対して受け渡す際の条件を指定する設定です。
    プロトコルやポート番号、タイムアウト値 を設定する以外にバックエンドサーバーへ受け渡す際の追加機能としてCookieベースのアフィニティや接続のドレイン機能もこの設定で有効化することが出来ます。
    カスタムプローブ設定を使用しない場合、ヘルスチェックのURLのプロトコル、ポート番号がこの設定で指定したものになります。

  • 設定の詳細について



    • バックエンドポートとバックエンドプロトコル
      上記の画像はポータル上でのHTTP設定画面です。
      バックエンドプロトコルやバックエンドポートはバックエンドに設定した対象(サーバーやWeb AppsなどのWEBサービス)に対してトラフィックを受け渡す際のプロトコルとポートを指定します。

    • Cookieベースのアフィニティ
      クライアントからのアクセスを同一サーバーへ振り続けることが出来る機能です。
      この設定が有効化されている場合、クライアントからの通信がApplication Gatewayを通過する際に付与される”X-original-host”内に制御用のCookieを挿入し、同じクライアントからのセッションを同一のサーバーへと接続し続けることが出来ます。そのCookieが破棄されない限り同じサーバーに振り分けます。
      クライアントのブラウザが Cookie の使用をサポートしている場合のみ機能します。

    • 接続のドレイン
      コネクションドレイン機能です。
      Azure基盤側のメンテナンスや正常性プローブで異常と判断されロードバランシングの振り分け対象から切り離される際にすでに貼られている通信のセッションを接続が完了するまで維持する機能です。その間新規のセッションが切り離し対象のサーバへと振り分けられることはありません。

    • ドレインタイムアウト
      上記の接続のドレインを有効化する際に設定が必要となります。
      この設定は正常性プローブによって切り離し対象となったサーバーへの通信が完了するまでの猶予の時間を設定します。
      指定した時間に達した場合、この時点で残っているセッションは途中であったとしても閉じられます。

    • 通信のタイムアウト
      バックエンドプールに設定したサーバーからの応答を待つ待機時間を設定します。

    • バックエンドパスのオーバーライド
      アクセス時のパスをこの設定で指定したパスに上書きさせることが出来ます。IISなどのRewriteとは違いパスそのものを書き換えます。
      パスベースルールと組み合わせることにより複雑な書き換えも可能です。
      詳しくはこのドキュメントをご参照ください。

    • ホスト名
      バックエンドへのルーティングを行う際に通信リクエストのhostヘッダーがここで指定したホスト名に置き換えられます。
      書き換えの設定を有効化する場合は” 新しいホスト名でオーバーライドする “設定を有効化する必要があります。
      バックエンドにApp Serviceを配置して置き換えを行う場合は バックエンド ターゲットからホスト名を選択する”を選択し、それ以外は” 特定のドメイン名でオーバーライドする “を選択し置き換えを行うホスト名を指定します。
      詳しくはこのドキュメントをご参照ください。

    • カスタムプローブの使用
      既定のヘルスチェック設定を細かく設定したい場合はカスタムプローブ設定を使用します。
      既定のパス以外にヘルスチェック時のパスを設定したい場合はこの設定を有効化し、後述の正常性プローブ設定を使用する必要があります。


正常性プローブについて

  • 正常性プローブとは
    既定のヘルスチェック設定とは違うヘルスチェック設定を指定したい場合にこの機能を使用します。
    本設定を使用する場合はHTTP設定のカスタムプローブ設定を有効化し、正常性プローブ設定を指定する必要があります。

  • 各設定について

    • プロトコル
      プローブの通信で使用するプロトコルです。
      HTTP設定のカスタムプローブ設定で正常性プローブ設定を使用する場合、同じプロトコルを指定しておく必要があります。

    • ホスト
      プローブの通信を送信する際にここで設定したホスト名に対して送信されます。マルチサイトリスナーが設定されている場合のみ機能します。

    • パス
      正常性確認を行う為のリソースを相対パスで指定します。
      必ずスラッシュ”/”から始まる必要があります。

    • 間隔(秒)
      プローブ通信の間隔を秒単位で指定できます。

    • タイムアウト
      プローブ通信のタイムアウトを秒数で指定します。
      設定したタイムアウトの時間内に正常性確認が確認出来なかった場合、”失敗”と判定されます。

    • 異常しきい値
      プローブの再試行の回数を指定します。
      プローブの連続失敗の回数がしきい値に達した場合、その対象のサーバーはダウンしたと判定され振り分け対象から除外されます。

    • プローブの一致条件を使用
      既定ではコード200~399の応答は正常であると見なされます。
      この設定を有効にすることで上記以外に設定を加えることが出来ます。

      • HTTP 応答の状態コードの一致
        一致条件を使用する設定を有効化した場合に設定できます。
        ここで指定した応答コードの通信は正常であると認識されます。HTTP応答コードはカンマ区切り、”200-300″といった範囲指定も可能です。

      • HTTP 応答本文の一致
        この設定で設定した文字列とHTTP応答本文を比較し、一致したものを正常であると認識されます。


Loganalyticsを利用してログを分析する前のページ

関連記事

  1. Azure

    WindowsVirtualDesktopがGAされているので(その2)

    その1で仮想マシンの展開まで行ったので次は接続、それとその他備考な…

  2. Azure

    Managed InstanceへのDB移行・アプリとの連携時の注意Point

    そがひろです。今回は、OnPremiseからAzure Manage…

  3. Azure

    Azure AD Connectの構築トラブルメモ

    今回はAzure AD Connect(AADC)を構築した際に色々…

  4. Azure

    Azureクラシックリソース(Azure Service Management)VMの廃止について

     こんにちは。三醍醐です。 先日、クラシックVMが2023年…

  5. Azure

    Azure Migrateを使ったIaaS移行

    はじめまして。新人クラウドエンジニアの三醍醐です。今回は、新機能が実…

  6. Application Gateway

    L7負荷分散 Azure Application Gateway について:1回目

    はじめまして。Azure推進チーム構成員のヤモトと申します。…

関連記事

  1. Azure

    Azure料金に関する豆知識①
  2. Office 365

    Office 365 F3(旧F1)
  3. Azure

    Azure Key Vaultでみんなしあわせ
  4. Application Gateway

    L7 負荷分散 Azure Application Gateway について:3…
  5. Azure

    Managed InstanceへのDB移行・アプリとの連携時の注意Point
PAGE TOP