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]
Windows VMにAzure AD認証でサインインする
Azure AD authentication to Windows VMs in Azure now in public preview - Microsoft Tech Community - 827840 techcommunity.microsoft.com
Azure上のWindows VMにAzure ADでユーザー認証してサインインできるという機能がパブリックプレビューで提供され始めました(2019/12/13頃)。 ちなみにLinux版はだいぶ前から提供されていたのですが、いま見に行ったらこちらもまだプレビュー状態のようでした。
Log in to a Linux VM with Azure Active Directory credentials - Azure Linux Virtual Machines | Microsoft Docs
ドキュメントは日本語化されていて、内容も丁寧なので、読みながら進めれば大丈夫でしょう。
条件
ドキュメント類に書いてあるとおりですが、使える条件はざっくりこんな感じです。
- 対象(サインインされる側)のOSはWindows Server 2019 Datacenter edition もしくは Windows 10 1809以降。
- VMを作成する際に「Login with AAD credentials (Preview)」を「On」にすること(もしくは事後にExtension導入)。
- サインインする側は、対象VMと同じテナントにAzure AD JoinedもしくはHybrid Azure AD Joinedであること(＝Windows 10のみ)。対象VMはJoinedじゃなくて大丈夫です。
- 対象のVMに対して、ログインしたいAzure ADユーザーが「Machine Administrator Login」もしくは「Virtual Machine User Login」ロールを付与されていること。
- Azure ADアカウントにMFAが設定されている場合はドキュメントの「トラブルシューティング」の項を参照。
という感じの制約がありますので、今のところAzure Bastion経由ではアクセスできません。
「認証しようとしているAzure ADのアカウントがあるテナントに、アクセス元PCのデバイスIDが登録されている」チェックがあるため、(Hybrid) Azure AD Joined 状態のPCが必要ということになるようです。
このあたりは少し面倒な制約ではありますが、今後が楽しみです。
Azure Proximity Placement Group (近接配置グループ) に既存VMを入れてみた
2019年12月9日にProximity Placement Group (近接配置グループ)がGAしたとのアナウンスがありましたので、軽く既存のVMを入れてみました。
Announcing the General Availability of Proximity Placement Groups | Blog | Microsoft Azure
基本的な考え方
- Start(起動)時に物理的に近接する場所に配置されるという振る舞いをするようです。
- 単独VMと可用性セットを同じPPGに混在させられます。
- ゾーンは跨げません。単一ゾーン用です。
既存のVM/可用性セットをPPGに追加する
既存リソースをPPGに追加するには、今のところARMテンプレートの差分展開で行う必要があるようです。PowerShellやCLIは新規リソース作成時のオプションとしてのみ指定出来るようでした。
ARMテンプレート例
resourcesセクションの前半がVM、後半が可用性セットです。
{ "$schema": "https://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#", "contentVersion": "1.0.0.0", "parameters": {}, "variables": {}, "resources": [ { "type": "Microsoft.Compute/virtualMachines", "apiVersion": "2019-03-01", "name": "仮想マシン名", "location": "リージョン", "properties": { "proximityPlacementGroup": { "id": "近接配置グループのID" } } }, { "type": "Microsoft.Compute/availabilitySets", "apiVersion": "2019-03-01", "name": "可用性セット名", "location": "リージョン", "properties": { "proximityPlacementGroup": { "id": "近接配置グループのID" } } } ] }
Azure PortalからARMテンプレートを差分デプロイする
短いのでGUIでさっと済ませたいと思います。
- Create a resource
- Template deployment
- Build your own template in the editor
- 編集枠にテンプレートを貼る
- Save
- 入力項目を適宜指定してPurchase
ベンチマーク(VM間のレイテンシ)
ざっくりした取得方法なので参考まで。 東南アジアリージョン、Windows Server 2016、Standard DS3 v2 (4 vcpus, 14 GiB memory)、Accelerated networking有効、というスペック。 計測方法は参考ドキュメントにあるlatteを使った方法。
| 測定箇所 | 回数 | 高速ネット枠有効 近接配置あり (usec) |
高速ネット枠有効 近接配置無し (usec) |
高速ネット枠無効 近接配置あり (usec) |
高速ネット枠無効 近接配置無し (usec) |
|---|---|---|---|---|---|
| 受信側 | 1-1 | 93.93 | 111.50 | 634.00 | 1,716.87 |
| 1-2 | 91.62 | 110.94 | 568.43 | 1,689.66 | |
| 1-3 | 97.65 | 102.98 | 582.78 | 1,692.82 | |
| 2-1 | 102.18 | 110.98 | 682.04 | 1,189.40 | |
| 2-2 | 101.45 | 108.09 | 667.29 | 1,202.97 | |
| 2-3 | 103.23 | 107.09 | 689.30 | 1,175.36 | |
| 送信側 | 1-1 | 93.92 | 111.50 | 634.00 | 1,716.81 |
| 1-2 | 91.62 | 110.94 | 568.42 | 1,689.61 | |
| 1-3 | 97.65 | 102.98 | 582.77 | 1,692.76 | |
| 2-1 | 102.17 | 110.98 | 682.03 | 1,189.40 | |
| 2-2 | 101.44 | 108.09 | 667.29 | 1,202.97 | |
| 2-3 | 103.23 | 107.09 | 689.30 | 1,175.37 |
Accelerated networking有効にしたVMでのベンチマーク結果
1-3から2-1の間でdeallocate/startした。
Accelerated networking無効にしたVMでのベンチマーク結果
1-3から2-1の間でdeallocate/startした。
参考ドキュメント
近接通信配置グループの概要 | ブログ | Microsoft Azure
Windows VM に近接通信配置グループを使用する | Microsoft Docs
Linux VM に近接通信配置グループを使用する | Microsoft Docs
Azure Virtual Network で Azure Virtual Machines のネットワーク待機時間をテストする | Microsoft Docs
Application Gateway V2 を試す
Igniteあたりの発表で Application Gateway が強化されたようだと聞いて少し試してみました。
手頃なリリースが見あたらなかったのでドキュメントにリンクしておきます。オートスケール対応、可用性ゾーン対応、パフォーマンス向上、デプロイや更新の高速化、静的IPアドレス、あたりが目玉ですね。
作り方(ポータル)
おもむろに Application Gateway を作ると、Tier の選択で「Standard V2」や「WAF V2」が選べます。試したところ、日本のリージョンはダメで、Southeast Asia でデプロイできました。
作り方(PowerShell)
ドキュメントがありましたのでこちらからどうぞ。
デプロイや設定変更は早くなったのか？
6分35秒で完了しました。V1(16分23秒)に比べるとずいぶん高速化されましたね。設定変更も、バックエンドの追加が58秒で終わりました。
おお、Application Gateway v2 のデプロイが6分35秒で完了。確かに早くなりましたね(というか普通に)。 pic.twitter.com/QI9a9ksPhi
— haray (@haray_isa) September 28, 2018
Application Gateway v2、バックエンドの追加が58秒で終わった pic.twitter.com/38BlJLS4Ye
— haray (@haray_isa) September 28, 2018
固定IPアドレスは？
新規作成の画面では Dynamic /Static の選択がグレーアウトして選べませんでしたが、デプロイ後に確認したら Static になっていました。FQDNは指定できます。また、既存のIPアドレスも指定できそうでした。
実際の FQDN はこんな感じ。ようやくv2仮想マシンベースになったようですね。
- V1 の場合： f59c2f2a-c8fc-4f8d-92fa-6659b1a0105d.cloudapp.net
- V2 の場合:： appgwv2testsea.southeastasia.cloudapp.azure.com
その他
デプロイ直後にアクセスしてみたら nginx から応答がありました。VMだけでなく中身も変わりましたか。
$ curl -I http://appgwv2testsea.southeastasia.cloudapp.azure.com/ HTTP/1.1 502 Bad Gateway Server: nginx/1.13.8 Date: Tue, 02 Oct 2018 16:11:58 GMT Content-Type: text/html Content-Length: 173 Connection: keep-alive
とりあえずリダイレクト設定してみたところ。
$ curl -I http://appgwv2testsea.southeastasia.cloudapp.azure.com/ HTTP/1.1 301 Moved Permanently Server: nginx/1.13.8 Date: Tue, 02 Oct 2018 16:23:25 GMT Content-Type: text/html Content-Length: 185 Connection: keep-alive Location: http://example.com/
V1 だとIISからの応答ですね。
$ curl -I http://104.215.176.233/ HTTP/1.1 502 Bad Gateway Content-Length: 1477 Content-Type: text/html Server: Microsoft-IIS/10.0 Date: Tue, 02 Oct 2018 16:25:27 GMT $ curl -I http://104.215.176.233/ HTTP/1.1 301 Moved Permanently Content-Length: 141 Content-Type: text/html; charset=UTF-8 Location: http://example.com/ Server: Microsoft-IIS/10.0 Date: Tue, 02 Oct 2018 16:46:14 GMT
ログも微妙に変わってました
もしかしてと思ってストレージに出力されるログを見てみたら微妙に変わっていました。InstanceId が、Cloud Services 的な名前から VMSS っぽい名前になりましたね。
V1 のログ
{ "resourceId": "(省略)", "operationName": "ApplicationGatewayAccess", "time": "2018-10-02T17:32:59Z", "category": "ApplicationGatewayAccessLog", "properties": {"instanceId":"ApplicationGatewayRole_IN_0","clientIP":"51.141.54.177","clientPort":27665,"httpMethod":"GET","requestUri":"/","requestQuery":"-","userAgent":"Mozilla/5.0+(compatible;+MSIE+9.0;+Windows+NT+6.1;+Trident/5.0;+AppInsights)","httpStatus":301,"httpVersion":"HTTP/1.1","receivedBytes":553,"sentBytes":331,"timeTaken":235,"sslEnabled":"off","host":"104.215.176.233"} }
V2 のログ
{ "timeStamp": "2018-10-02T17:34:44+00:00", "resourceId": "(省略)", "operationName": "ApplicationGatewayAccess", "category": "ApplicationGatewayAccessLog", "properties": {"instanceId"=>"vm000003", "clientIP"=>"52.174.166.113", "clientPort"=>"19569", "httpMethod"=>"GET", "requestUri"=>"/", "requestQuery"=>"", "userAgent"=>"Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0; AppInsights)", "httpStatus"=>"301", "httpVersion"=>"HTTP/1.1", "receivedBytes"=>"549", "sentBytes"=>"377", "timeTaken"=>"0.000", "host"=>"vm000003"}, "time": "2018-10-02T17:34:44.0000000Z" }
簡単ですがこんなところで。いろいろと楽しみですね。
Ignite 2018 の発表で気になったことのメモ
Igniteでいろいろ発表されていますね。
Cloud Platform Release Announcements for September 24, 2018 | Cloud Platform News Bytes Blog
リリースから、個人的に気になったポイントをいくつかメモしておきます。
ネットワーク関連
Azure App Gateway autoscaling Public Preview
→ スケールの速さが気になるところAzure DNS Alias Records – GA
→ ようやく。GAでの登場は嬉しいところ。Azure Frontdoor Service | Public Preview
→ IP Anycast などなど
ストレージ関連
Large Disks – Public Preview
→ 8, 16 and 32 TiB disk sizesUltra SSD – Public Preview
→ from 4GiB up to 64 TiB、160,000 IOPS、2 GB/sAzure Premium Blob Storage | Public Preview
→ Filesも。SSD化でレイテンシ短縮とTPC、スループットの向上Azure Files AAD Integration Public Preview
→ AAD統合とNTFS ACLのサポート、Premium Files での高速化も期待
データベース関連
Azure Databricks | Japan, India, Canada and Australia GA → Databricksが日本でもGA、東西とも使えます
Azure Cosmos DB | Multi-Master – GA → GAして99.999%のRead/Write SLA(Spannerに揃いましたね)
SQL DB Managed Instance general purpose – GA → GAしました
Azure Database for MySQL and PostgreSQL | Performance recommendations for PostgreSQL – Preview → Query Performance Insights や Query Store も合わせてプレビュー。
Azure SQL Database | Hyperscale – Public Preview → 新アーキテクチャ、100TBまでオートスケールとのこと
Azure Database Migration Service: Support for SQL to Azure SQL DB Managed Instance online migrations → 使う機会が増えそうなので
Azure Data Studio | GA → SQL Operations Studio が名前を変えてGA
その他
Azure FunctionsのBLOBトリガーとEvent Gridのレスポンス比較
Azure FunctionsでBLOBの更新を契機に処理を開始する場合、BLOBトリガーを利用する場合と、Event GridのBLOBイベントで発火させる場合とがあるかと思います。諸方面で前者は非推奨な扱いになっていますが、実際にどんなものか実測してみました。
測定方法
VM上でスクリプトを回してコンテナーにファイルをput、Functions側ではトリガーを受けてTable Storageに結果を記録して所要時間を計測するというごくシンプルな方法。Functionsのプランによる差異も計測しました。
測定結果1 BLOBトリガー
だいたい5,000オブジェクト毎に階段状に処理時間が増えました。 ドキュメントに「ポーリング」とあるのでリニアに増えるのかと思ったのですが、綺麗な階段状のグラフになりました。また「トリガーされるまで数分かかる場合もある」「トリガーはベストエフォート」などの記載があり、ドキュメントのレベルでもお勧めしない感がにじみ出ていますね。
測定結果2 Event Grid + App Service Plan
こちらは Event Grid で発火、Functions は App Service Plan で受けるパターンです。綺麗にフラットなグラフになりました。
測定結果3 Event Grid + Consumption Plan
こちらは Event Grid で発火、Functions は Consumption Plan で受けるパターンですが、イベントが毎秒発生するので App Service Plan とほぼ同じような結果になりました。
まとめ
ということで、BLOBの作成をトリガーにするような処理は Event Grid が安心そうだという結果になりました。イベント発火の確実性という点でも、リトライまできっちりやってくれる Event Grid が。安心そうです
Azure Functions のレスポンスタイム
サーバーレスというとレスポンスが云々とかコールドスタートが云々とか気になるということで、Azure Functions の各ホスティングプランについてざっくりと傾向を見てみました。
- 2018年6月1日～6月22日で測定。
- パターンは以下の3つ
- Functions の中身はHTTPリクエストをGETで受けて200を返すだけのcsx
- リクエストを投げる側はVirtual Machine上のスクリプト
実質的に、3つめの「Consumptionプランが寝る条件でどれくらいレスポンスがバラつくのかが焦点になりそうですね。「Web App プランで15分置き」というのも見てみたい気はしますが、プランを分けるとコストも嵩みますし、AlwaysOn有効でちょっとやってみた感じでは安定してそうだったので今回は見送りで。
結果発表
早速ですがスクショでペタペタと。
App Service プラン ＋ リクエストは1秒毎
やはり安定していますね。平均24,8ms、99パーセンタイル値は94msでした。
Consumption プラン ＋ リクエストは1秒毎
Consumption プランといいつつ毎秒リクエストを受けていれば起きっぱなしだったようで、App Service プランと変わりませんね。平均35.6ms、99パーセンタイル値は100msでした。
Consumption プラン ＋ リクエストは15分毎
予想通り寝たり起きたりしている感じではありますが、思ったよりは安定していました。平均は135ms、50パーセンタイル値が100ms、99パーセンタイル値が640msでした。
参考ドキュメント
実際には処理の内容にも依存することですので、公式ドキュメントを参考にしつつ最後は実測してみましょう。
