【Azure Application Gateway】運用・スケール編：オートスケール／ゾーン冗長・ログ・リライト・セッションアフィニティ

Azure
2026.07.16

「Application Gatewayって、作って終わりじゃないよね？本番で運用するときは何を設定すればいいの？」

——概要・作成・TLS・WAF・ネットワークとApplication Gateway（AGW）を学んできて、最後に立ちはだかるのが「運用・スケール」のテーマです。急なアクセス増にどう耐えるのか、ログはどこに貯めるのか、レスポンスヘッダーはどう書き換えるのか、セッションはどう維持するのか——このあたりは「なんとなく設定項目は見たことがあるけど、目的まで説明できない」と止まってしまいがちなポイントです。

オートスケールもログもセッションアフィニティも、設定画面は見たことある。でも「なぜ・どこで設定するのか」を聞かれると詰まる…

この記事では、Application Gatewayを本番で運用・スケールさせるときに押さえたい、次の4つに絞って整理します。読み終えたときに、この4つを自分の言葉で説明できるようになることをゴールにします。

  • 自動スケール／ゾーン冗長を構成できる（最小・最大インスタンス数と可用性ゾーンの設定）
  • アクセスログ／WAFログをLog Analyticsに送れる（診断設定でログを蓄積する）
  • リライト規則（ヘッダー／URL）を構成できる（レスポンスヘッダーの追加・書き換え）
  • セッションアフィニティ／接続ドレインを理解している（目的と設定箇所）

いずれもv2 SKU（Standard_v2 / WAF_v2）を前提に解説します。各セクションの最後に「これが説明できればOK」という自己チェックの目安を置いていますので、学習の到達度確認に使ってください。

自動スケール／ゾーン冗長を構成する

オートスケールとは、アクセス（トラフィック）量に応じてApplication Gatewayのインスタンス数を自動で増減させる仕組みです。ゾーン冗長とは、そのインスタンスを複数の可用性ゾーンに分散配置し、片方のゾーンで障害が起きてもサービスを継続させる構成です。

まず前提として、v2 SKUのApplication Gatewayは常に高可用な構成でデプロイされます。内部的には複数インスタンスで動いており、あるインスタンスが不調になれば、Azureが裏で新しいインスタンスを作り直してくれます。私たちが運用者として決めるのは、その「何インスタンスで走らせるか」という部分です。

最小・最大インスタンス数の考え方

オートスケールを有効にすると、次の2つを設定します。

  • 最小インスタンス数（Minimum instance count）：トラフィックが無くてもここを下回らないという下限。0〜100の範囲で指定します。1インスタンスはおよそ10 キャパシティユニットぶんの予約に相当し、0 にすると予約ゼロの「完全にオートスケール任せ」になります。
  • 最大インスタンス数（Maximum instance count）：これ以上は増やさないという上限。最大125まで指定でき、未指定なら既定値は10です。トラフィックに応じてこの範囲内で自動的に増減します。

ここで大事な感覚は、最小インスタンス数は「常時確保しておく余力」だという点です。新しいインスタンスの立ち上げにはおおよそ3〜5分かかるため、最小を 0 にしておくと、急な負荷スパイクに対して増設が間に合わない可能性があります。想定される平常時のトラフィックをさばける数を最小に置き、突発的な山を最大で受け止める——というのが基本の考え方です。

最小インスタンスは「レジの最低待機人数」。ゼロだとお客さんが殺到したとき、店員を呼ぶのに数分かかっちゃうイメージだね。

可用性ゾーン（ゾーン冗長）

可用性ゾーン（Availability Zone）とは、同じリージョン内にある物理的に分離されたデータセンター群のことです。Standard_v2 / WAF_v2 のApplication Gatewayは複数のゾーンにまたがって配置でき、これをゾーン冗長と呼びます。

ゾーンをまたいでおくと、あるゾーンのデータセンターがまるごと停電・障害を起こしても、別ゾーンのインスタンスが処理を続けられます。ゾーン冗長にすると、ゾーンごとに別々のApplication Gatewayを立てる必要がなくなる（1つのAGWでゾーンをまたげる）のもメリットです。

設定箇所は、Application Gatewayの作成時（構成タブ）です。オートスケールの有効化・最小／最大インスタンス数と並んで、可用性ゾーンを選びます。ポイントは以下です。

  • 可用性ゾーンの割り当ては作成時に決めるのが基本（後から自由に変えられる設定ではないため、最初に「ゾーン冗長にするか」を意思決定しておく）。
  • ゾーン障害の影響を最小化するため、Microsoftはオートスケールを常に有効にすることを推奨しています。

イメージとしては、次のような構成です。

          リージョン（例: Japan East）
 ┌──────────────────────────────────────────────┐
 │   Application Gateway v2（1つのリソース）        │
 │                                               │
 │   ゾーン1        ゾーン2        ゾーン3          │
 │  ┌───────┐    ┌───────┐    ┌───────┐          │
 │  │インスタンス│  │インスタンス│  │インスタンス│  ← 分散配置│
 │  └───────┘    └───────┘    └───────┘          │
 │                                               │
 │   ↑ オートスケールで 最小〜最大 の範囲で自動増減   │
 └──────────────────────────────────────────────┘
   ※ ゾーン1が障害でも、ゾーン2/3で処理を継続できる

【ここが説明できればOK①】
「オートスケールは最小・最大インスタンス数を設定してトラフィックに応じ自動増減する仕組み。ゾーン冗長は1つのAGWを複数の可用性ゾーンに分散配置してゾーン障害に耐える構成」——これを言えれば、1つ目のチェックはクリアです。

アクセスログ／WAFログをLog Analyticsに送る

診断設定（Diagnostic settings）とは、Azureリソースが出力するログを、Log Analyticsワークスペースなどの保存先へ転送するための設定です。

Application Gatewayは、放っておくとログをどこにも貯めてくれません。「誰が・いつ・どのURLにアクセスし、WAFが何をブロックしたか」を後から追えるようにするには、診断設定を有効にしてログを保存先に送る必要があります。おすすめの保存先がLog Analyticsワークスペースです（KQLで検索でき、アラートやダッシュボードも作れるため）。

v2で送れるログの種類

Application Gatewayのリソースログには、主に次の種類があります。

  • アクセスログ（Access log）：受け付けた各リクエストの記録。クライアントIP、リクエストURI、HTTPステータス、応答時間などが分かる。アクセスの実態把握・トラブルシュートの主役。
  • WAFログ（Firewall log）：WAF（WAF_v2 SKU）が検知・ブロックしたリクエストの記録。どのルールが何を弾いたかが分かる。誤検知（false positive）の調査に必須。
  • パフォーマンスログ（Performance log）：スループットや接続数などの性能情報。これはv1 SKU専用で、v2では出力されません（v2はAzure Monitorのメトリックで性能を見ます）。

つまりv2 SKUで診断設定から送れる代表格はアクセスログとWAFログです。「v2なのにパフォーマンスログが見当たらない」と混乱しがちですが、仕様通りなので安心してください。

設定の流れ

ポータルでの手順はシンプルです。

  1. Application Gatewayのリソース画面で ［監視］→［診断設定］ を開く。
  2. ［診断設定を追加する］ を選ぶ。
  3. 送りたいログのカテゴリ（アクセスログ／WAFログ）にチェックを入れる。
  4. 宛先として ［Log Analyticsワークスペースへの送信］ を選び、対象ワークスペースを指定して保存する。

このとき、Log Analytics側の保存方法として「リソース固有（Resource-specific）」と「Azure診断（Azure Diagnostics／レガシ）」のどちらかを選べます。リソース固有が既定かつ推奨で、ログはカテゴリごとの専用テーブルに書き込まれます。

  • アクセスログ → AGWAccessLogs テーブル
  • WAFログ → AGWFirewallLogs テーブル

蓄積を確認するには、しばらく待ってからLog Analyticsの［ログ］で次のようなKQLを実行します。行が返ってくれば、ログが正しく届いている証拠です。

// アクセスログ（リソース固有テーブル）を直近から確認
AGWAccessLogs
| take 50

// WAFログでブロックされたリクエストだけ絞り込む例
AGWFirewallLogs
| where action_s == "Blocked"
| take 50

なお、レガシのAzure診断を選んだ場合は、専用テーブルではなく共有の AzureDiagnostics テーブルに書き込まれます。既存の設定でそちらを使っているケースもあるので、「どちらのモードか」で参照するテーブル名が変わる点は覚えておきましょう。

【ここが説明できればOK②】
「診断設定でアクセスログとWAFログのカテゴリを選び、Log Analyticsワークスペースへ送る。v2ではパフォーマンスログは出ず、リソース固有モードなら AGWAccessLogs / AGWFirewallLogs テーブルに蓄積される」——これを説明できれば、2つ目のチェックはクリアです。

リライト規則（ヘッダー／URL）を構成する

リライト規則（Rewrite rule）とは、クライアントとバックエンドの間を通過するリクエスト／レスポンスの、HTTPヘッダーやURL（パス・クエリ文字列・ホスト名）を、Application Gateway上で書き換える機能です。

Application Gatewayはリバースプロキシとして「間」に立っているので、通過するパケットのヘッダーやURLに手を加えられます。これがリライトです。この機能はv2 SKU（Standard_v2 / WAF_v2）専用で、v1では使えません。

よくある使いどころは次のようなものです。

  • セキュリティ系のレスポンスヘッダーを追加する（例：Strict-Transport-Security（HSTS）、X-XSS-Protection など）。
  • サーバー名やバージョンなど内部情報を漏らすレスポンスヘッダーを削除する。
  • リダイレクト時の Location ヘッダーのホスト名を、AGWのドメインに書き換える。
  • URLのパスやクエリ文字列を書き換え、見た目のURLと実際のバックエンド用URLを分ける。

構成要素：リライトセット＝ルール＋条件＋アクション

リライトは「リライトセット（Rewrite set）」という単位で構成します。リライトセットは、次の3つの組み合わせです。

  • ルーティングルールとの関連付け：リライトセットはルーティングルール（リスナー）に紐づけて適用します。基本ルールに紐づければそのリスナー全体に、パスベースルールに紐づければ特定のパスだけに効きます。1つのルーティングルールに関連付けられるリライトは1つです。
  • 条件（Condition）：任意。HTTPヘッダーやサーバー変数の値をテキストまたは正規表現（RE2）で評価し、条件を満たしたときだけアクションを実行します。複数条件はAND（すべて満たす）で評価されます。
  • アクション（Action）：実際の書き換え内容。リクエスト／レスポンスヘッダーの追加・変更・削除、またはURLのパス・クエリ文字列の書き換えを指定します。

流れを図にすると、こうなります。

  リライトセット（ルーティングルールに関連付け）
        │
        ├─【条件】(任意) ヘッダー/サーバー変数を評価
        │        例: レスポンスに Server ヘッダーがある？
        │
        └─【アクション】条件を満たしたら実行
                 例: レスポンスヘッダー "Server" を削除
                 例: レスポンスヘッダー "X-Frame-Options: DENY" を追加

設定箇所と反映確認

ポータルでは Application Gateway →［リライト］ でリライトセットを作り、その中にリライトルール（条件＋アクション）を定義して、対象のルーティングルールに関連付けます。

レスポンスヘッダーを追加・書き換えした場合の反映確認は、ブラウザの開発者ツール（ネットワークタブ）や curl -I で、レスポンスヘッダーに意図した値が入っているかを見ればOKです。

# レスポンスヘッダーだけを取得して確認する
curl -I https://example.com/

# 期待する出力例（追加したヘッダーが返っていれば反映OK）
#   HTTP/1.1 200 OK
#   Strict-Transport-Security: max-age=31536000
#   X-Frame-Options: DENY

注意点として、Application Gateway自身が生成する4xx/5xxのエラーレスポンスや、リダイレクト・カスタムエラーページに対してはリライトが効きません。また Connection / Upgrade / Host ヘッダーなど一部は書き換え・削除の対象外です。「効かないな？」と思ったら、まずこの制限に当たっていないか確認しましょう。

【ここが説明できればOK③】
「リライトはv2 SKU専用で、リライトセット（ルール＋条件＋アクション）をルーティングルールに関連付けて、ヘッダーやURLを書き換える。レスポンスヘッダーを追加・書き換えして反映確認できる」——これを説明できれば、3つ目のチェックはクリアです。

セッションアフィニティ／接続ドレインを理解する

最後は、バックエンドとの「つなぎ方」に関わる2つの機能です。どちらもHTTP設定（バックエンド設定）で構成する、という共通点があります。

セッションアフィニティ（Cookieベース）

Cookieベースのセッションアフィニティとは、同じユーザーからの一連のリクエストを、毎回「同じバックエンドサーバー」へ振り分ける機能です。

通常、ロードバランサーはリクエストごとに空いているサーバーへ分散します。ですが、セッション状態をサーバーのローカル（メモリなど）に保持しているアプリでは、リクエストのたびに別のサーバーへ飛ぶと「ログイン状態が消える」「カートが空になる」といった問題が起きます。

そこでApplication Gatewayは、ゲートウェイが管理するCookie（ApplicationGatewayAffinity）をクライアントに付与し、以降そのCookieを持つリクエストを同じサーバーへ固定（アフィニティ）します。これがCookieベースのセッションアフィニティです。

「担当を毎回同じ店員に固定する」機能。前回の会話（セッション）を覚えている店員に戻れるから、話がやり直しにならないんだ。

設定箇所はHTTP設定（バックエンド設定）です。ここでCookieベースのアフィニティを「有効／無効」で切り替えます。理想はアプリ側でセッションを外部（Redisなど）に持ってサーバーを問わない設計（ステートレス）ですが、既存アプリがサーバーローカルにセッションを持つ場合の現実的な対処として使います。

接続ドレイン（Connection draining）

接続ドレインとは、バックエンドサーバーをプールから外すとき、処理中のリクエストを最後まで完了させてから切り離す（＝新規リクエストは送らず、既存の接続だけ猶予時間内で終わらせる）機能です。

デプロイやスケールインでサーバーをプールから抜くとき、いきなり切断すると処理中のリクエストが失敗し、502エラーや接続断が起きます。接続ドレインを有効にすると、抜こうとしているサーバーには新しいリクエストを回さず、すでに処理中のリクエストだけを一定時間の猶予内で完了させてから切り離します。

  • 目的：ローリングデプロイ・スケールイン・バックエンド不調時などに、散発的な502エラーや接続ロスを減らす。
  • 設定箇所：セッションアフィニティと同じくHTTP設定（バックエンド設定）で有効化する。有効／無効に加え、猶予時間（ドレインのタイムアウト）を1〜3600秒で指定できる。

身近な例なら、閉店する窓口が「新規のお客様の受付は止めますが、いま対応中のお客様のご用件は最後まで承ります」と案内するイメージです。これにより、利用者は途中で追い出されずに済みます。

2つを整理すると、次のようになります。どちらも「HTTP設定（バックエンド設定）で構成する」のが共通点です。

HTTP設定（バックエンド設定）
 ├─ Cookieベースのセッションアフィニティ
 │     目的: 同じユーザーを同じサーバーへ固定（セッション維持）
 │     手段: ApplicationGatewayAffinity Cookie
 │
 └─ 接続ドレイン
       目的: サーバー切り離し時に処理中の接続を守る（502削減）
       設定: 有効/無効 ＋ 猶予時間 1〜3600秒

【ここが説明できればOK④】
「セッションアフィニティはCookie（ApplicationGatewayAffinity）で同じユーザーを同じサーバーに固定する機能。接続ドレインはサーバー切り離し時に処理中の接続を完了させて502を減らす機能。どちらもHTTP設定（バックエンド設定）で構成する」——これを説明できれば、4つ目のチェックはクリアです。

まとめ

今回の運用・スケール編のポイントを振り返りましょう。この4つを自分の言葉で説明できれば、Application Gatewayを「本番で運用する」目線が身についています。

  • 自動スケール／ゾーン冗長：最小（0〜100）・最大（〜125、既定10）インスタンス数で自動増減。複数の可用性ゾーンに分散してゾーン障害に耐える
  • アクセスログ／WAFログ：診断設定でカテゴリを選びLog Analyticsへ。v2はパフォーマンスログ非対応、リソース固有なら AGWAccessLogs / AGWFirewallLogs
  • リライト規則：v2専用。リライトセット（ルール＋条件＋アクション）をルーティングルールに関連付け、ヘッダー／URLを書き換える
  • セッションアフィニティ／接続ドレイン：どちらもHTTP設定。前者はCookieでユーザーをサーバーに固定、後者は切り離し時の502削減（猶予1〜3600秒）

そしてこれで、Application Gatewayシリーズ（概要／作成・ルーティング／TLS／WAF／ネットワーク／運用・スケール）の全体を学び終えました。L7ロードバランサーとしての土台から、本番運用に必要なスケール・可観測性・トラフィック制御まで、ひととおり地図が描けたはずです。学習アプリ「cloud-engineer-roadmap」のApp Gateway／WAFのチェックリストを、ぜひここで最後まで完走してみてください。「見たことはあるけど説明できない」項目が、「自分の言葉で説明できる」項目に変わっていれば大成功です。

あわせて読みたい

  • Application Gatewayの概要（L7ロードバランサー／SKU／主要コンポーネント）※シリーズ1記事目
  • Application Gatewayの作成手順（リスナー・ルール・ルーティングの設定）※別記事
  • WAF（Webアプリケーションファイアウォール）の仕組みとルール設定 ※別記事
タイトルとURLをコピーしました