Azure Front Door Service を使ってみる
「Webアプリケーションの前に置いて便利に使える何かが欲しい、CDNはちょっと扱いづらいのでその他で」みたいな話をしていてAzure Front Doorのことを思い出したので、ざっと調べてみました。
Azure Front Door Serviceとは
https://azure.microsoft.com/ja-jp/services/frontdoor/
- Webアプリケーションで必要となりそうな機能の詰め合わせといった感じ。
- CDN、 証明書ターミネーション、バックエンドヘルスチェックとルーティング、WAFなどなど。
- Azure Front Door(AFD)使うならTraffic Managerは入れなくていいかなという感じ(すくなくとも前段には)。
ポイント
- 見たままポチポチやればできる。落とし穴は少ない感じ。手順はクイックスタートの通り。
- デプロイもすぐ終わり、設定変更も概ねサクサク進められるので、少し試行錯誤すれば感覚は掴めるはず。
- バックエンドのヘルスチェックが200のみ(302等だとダメ)というのが引っかかるくらいか。アプリケーションによっては認証の作りで引っかかるかもしれない。
- サーバー証明書はKey Vaultに入れておくか、Front Door上で取得するかのいずれか。Front Door上で取得できる証明書は無料らしい。
Traffic Managerとの違い
- Traffic Manager(TM)はDNSベース、名前解決時に返すエンドポイントを変える。
- AFDはIP Anycastベース、グローバルで同じIPアドレスだが最寄りのAFDインスタンスにルーティングされる。
- AFDはトラフィックを終端するので、TLS終端もできるしバックエンドへの細かなルーティング制御(パスベース等)もWAFもキャッシュもできる。
- TMは1つのリソースでFQDN1つ、AFDは1つのリソースで複数FQDNをホストできる。
Application Gatewayとの違い
- Application Gateway (AppGw) はリージョンサービス。
- AFDはグローバルサービス、特定のリージョンに依存しない。
- Application GatewayはVNetに配置できるので、公開エンドポイントを持たないAzure VMをバックエンドにできる。
- AFDのバックエンドに配置できるのはパブリックなエンドポイントのみ。
- セッションアフィニティはどちらもCookieで。
WAFを有効にする
- ルーティングのルールセットに対してポリシーをポチポチ付けていく感じ。
- ポリシーは先に作る必要がある。ルールセットはプリセットがあるのでポリシーを作る時に選ぶ。
ログ(メトリック、診断ログ)
- Azureの一般的な仕様通り、メトリックと診断ログをストレージ、Stream Analytics、Log Analyticsに送信できる。
- WAFのログを見ようと思って有効化したら、「診断ログ (1 時間ごとにバッチ処理) を提供」ということで、見られるようになるまで少しお待ちください。
Log Analyticsでログを抽出する
アクセスログやWAFのブロックログ等は、Log AnalyticsのAzureDiagnosticsテーブルに格納されます。
FrontDoorのログを全件抽出する
AzureDiagnostics | where ResourceType == "FRONTDOORS"
WAFログのみ抽出する
AzureDiagnostics | where ResourceType == "FRONTDOORS" | where Category == "FrontdoorWebApplicationFirewallLog"
WAFログで扱いそうなカラム
主観ですが多分これくらい見ておけば。Application Gateway WAFの出力するログと比べていくつかカラムが不足しているようでした。1時間バッチでのログ出力になる件と併せて、運用上問題がないか確認しておいた方がよさそうです。
- TimeGenerated : 発生日時(UTC)。
- policy_s : ポリシー名。Azureリソースとして作った方のポリシー名。
- action_s : ブロックしたら「Block」と出る。
- requestUri_s : リクエストを受けたURL。
- clientIP_s : リクエスト元のIPアドレス。
- ruleName_s : ヒットしたWAFルール。例「DefaultRuleSet-1.0-RFI-931130」
IP Anycastの振る舞い
いくつかのリージョンからAFDのFQDNに対して名前解決をやってみました。都合によりWindows Serverが手近にあったのでnslookupとtracertで。nslookupでは同じIPアドレスが返っているのにtracerouteでそれぞれ最寄りのエッジに入っていくのが見えます。tyoは東京、osaは大阪、sgはシンガポール、sjcはサンノゼですかね。Azure VMからのRTTはほぼ1msとなっていて、バックボーン内で通信が完結している雰囲気が感じられます。
▼オンプレの物理サーバーから(東京)
>nslookup my-fd-test.azurefd.net
(略)
名前: standard.t-0001.t-msedge.net
Addresses: 2620:1ec:bdf::10
13.107.246.10
Aliases: my-fd-test.azurefd.net
t-0001.t-msedge.net
Edge-Prod-OSA02r3.ctrl.t-0001.t-msedge.net
>tracert my-fd-test.azurefd.net
standard.t-0001.t-msedge.net [13.107.246.10] へのルートをトレースしています
(略)
8 3 ms 3 ms 4 ms ae19-0.tya-96cbe-1b.ntwk.msn.net [104.44.12.93]
9 3 ms 3 ms 4 ms ae24-0.icr02.tyo31.ntwk.msn.net [104.44.236.189]
10 4 ms 9 ms 3 ms ae21-0.tyo01-96cbe-1b.ntwk.msn.net [104.44.236.182]
▼西日本のAzure VMから
>nslookup my-fd-test.azurefd.net
(略)
名前: standard.t-0001.t-msedge.net
Addresses: 2620:1ec:bdf::10
13.107.246.10
Aliases: my-fd-test.azurefd.net
t-0001.t-msedge.net
edge-prod-osa02r3.ctrl.t-0001.t-msedge.net
>tracert my-fd-test.azurefd.net
Tracing route to standard.t-0001.t-msedge.net [13.107.246.10]
(略)
7 1 ms 1 ms 1 ms ae20-0.osa02-96cbe-1a.ntwk.msn.net [104.44.236.120]
▼東南アジアのAzure VMから
>nslookup my-fd-test.azurefd.net
(略)
名前: standard.t-0001.t-msedge.net
Addresses: 2620:1ec:bdf::10
13.107.246.10
Aliases: my-fd-test.azurefd.net
t-0001.t-msedge.net
Edge-Prod-SG2r3.ctrl.t-0001.t-msedge.net
>tracert my-fd-test.azurefd.net
Tracing route to standard.t-0001.t-msedge.net [13.107.246.10]
(略)
7 5 ms 1 ms 4 ms ae27-0.sg2-96cbe-1b.ntwk.msn.net [104.44.236.148]
▼米国西部のAzure VMから
>nslookup my-fd-test.azurefd.net
(略)
Name: standard.t-0001.t-msedge.net
Addresses: 2620:1ec:bdf::10
13.107.246.10
Aliases: my-fd-test.azurefd.net
t-0001.t-msedge.net
Edge-Prod-SJCr3.ctrl.t-0001.t-msedge.net
>tracert my-fd-test.azurefd.net
Tracing route to standard.t-0001.t-msedge.net [13.107.246.10]
(略)
7 1 ms 1 ms 1 ms ae32-0.sjc-96cbe-1b.ntwk.msn.net [104.44.238.249]
