浅草橋青空市場

Microsoft Azure のニュースや情報を中心にあれこれと

Application Gateway V2 を試す

Igniteあたりの発表で Application Gateway が強化されたようだと聞いて少し試してみました。

手頃なリリースが見あたらなかったのでドキュメントにリンクしておきます。オートスケール対応、可用性ゾーン対応、パフォーマンス向上、デプロイや更新の高速化、静的IPアドレス、あたりが目玉ですね。

docs.microsoft.com

作り方(ポータル)

おもむろに Application Gateway を作ると、Tier の選択で「Standard V2」や「WAF V2」が選べます。試したところ、日本のリージョンはダメで、Southeast Asia でデプロイできました。

f:id:yhara90:20181003025317p:plain

作り方(PowerShell)

ドキュメントがありましたのでこちらからどうぞ。

docs.microsoft.com

デプロイや設定変更は早くなったのか?

6分35秒で完了しました。V1(16分23秒)に比べるとずいぶん高速化されましたね。設定変更も、バックエンドの追加が58秒で終わりました。

固定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 sizes

  • Ultra SSD – Public Preview
    → from 4GiB up to 64 TiB、160,000 IOPS、2 GB/s

  • Azure 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 MariaDBPreview → プレビューが始まりました

  • Azure Database for MySQL and PostgreSQL | Performance recommendations for PostgreSQLPreview → 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

その他

  • Announcing Windows Virtual Desktop, the best virtual desktop experience, delivered on Azure → 今後が気になる(Citrixとの兼ね合いなど)

  • Azure Functions | Python support in preview → ようやく登場

Azure FunctionsのBLOBトリガーとEvent Gridのレスポンス比較

Azure FunctionsでBLOBの更新を契機に処理を開始する場合、BLOBトリガーを利用する場合と、Event GridのBLOBイベントで発火させる場合とがあるかと思います。諸方面で前者は非推奨な扱いになっていますが、実際にどんなものか実測してみました。

測定方法

VM上でスクリプトを回してコンテナーにファイルをput、Functions側ではトリガーを受けてTable Storageに結果を記録して所要時間を計測するというごくシンプルな方法。Functionsのプランによる差異も計測しました。

測定結果1 BLOBトリガー

f:id:yhara90:20180829021717p:plain

だいたい5,000オブジェクト毎に階段状に処理時間が増えました。 ドキュメントに「ポーリング」とあるのでリニアに増えるのかと思ったのですが、綺麗な階段状のグラフになりました。また「トリガーされるまで数分かかる場合もある」「トリガーはベストエフォート」などの記載があり、ドキュメントのレベルでもお勧めしない感がにじみ出ていますね。

docs.microsoft.com

測定結果2 Event Grid + App Service Plan

f:id:yhara90:20180829021725p:plain

こちらは Event Grid で発火、Functions は App Service Plan で受けるパターンです。綺麗にフラットなグラフになりました。

測定結果3 Event Grid + Consumption Plan

f:id:yhara90:20180829021738p:plain

こちらは Event Grid で発火、Functions は Consumption Plan で受けるパターンですが、イベントが毎秒発生するので App Service Plan とほぼ同じような結果になりました。

まとめ

ということで、BLOBの作成をトリガーにするような処理は Event Grid が安心そうだという結果になりました。イベント発火の確実性という点でも、リトライまできっちりやってくれる Event Grid が。安心そうです

f:id:yhara90:20180829023054p:plain

Azure Functions のレスポンスタイム

サーバーレスというとレスポンスが云々とかコールドスタートが云々とか気になるということで、Azure Functions の各ホスティングプランについてざっくりと傾向を見てみました。

  • 2018年6月1日~6月22日で測定。
  • パターンは以下の3つ
    1. App Service プラン + リクエストは1秒毎
    2. Consumption プラン + リクエストは1秒毎
    3. Consumption プラン + リクエストは15分毎
  • Functions の中身はHTTPリクエストをGETで受けて200を返すだけのcsx
  • リクエストを投げる側はVirtual Machine上のスクリプト

実質的に、3つめの「Consumptionプランが寝る条件でどれくらいレスポンスがバラつくのかが焦点になりそうですね。「Web App プランで15分置き」というのも見てみたい気はしますが、プランを分けるとコストも嵩みますし、AlwaysOn有効でちょっとやってみた感じでは安定してそうだったので今回は見送りで。

結果発表

早速ですがスクショでペタペタと。

App Service プラン + リクエストは1秒毎

やはり安定していますね。平均24,8ms、99パーセンタイル値は94msでした。

f:id:yhara90:20180801001507p:plain

f:id:yhara90:20180801001514p:plain

Consumption プラン + リクエストは1秒毎

Consumption プランといいつつ毎秒リクエストを受けていれば起きっぱなしだったようで、App Service プランと変わりませんね。平均35.6ms、99パーセンタイル値は100msでした。

f:id:yhara90:20180801002522p:plain

f:id:yhara90:20180801002534p:plain

Consumption プラン + リクエストは15分毎

予想通り寝たり起きたりしている感じではありますが、思ったよりは安定していました。平均は135ms、50パーセンタイル値が100ms、99パーセンタイル値が640msでした。

f:id:yhara90:20180801003005p:plain

f:id:yhara90:20180801003014p:plain

参考ドキュメント

実際には処理の内容にも依存することですので、公式ドキュメントを参考にしつつ最後は実測してみましょう。

docs.microsoft.com

docs.microsoft.com

Azure File Storage の空き容量を監視する

タイトルに「空き容量」と書きましたが、正確には『使用量」ですね。メトリックが見えているのですぐできると思って調べてみたら意外と見あたらなかったので記録しておきます。先に結論を書いておくと、こんな感じになりそうです。

  1. 共有(Share)単位では出来ない。いま取得出来るメトリックはストレージアカウント単位のみ。
  2. Azure Monitor の Alerts から設定する。
  3. 容量のメトリックがAzure Monitorに送信されるのは1時間に1回。

共有をマウントするOSがある場合はそちらでcronなりタスクスケジューラーなりを回せば済むんでしょうね。

では、設定の手順です。ストレージアカウントと共有は作成済みの前提です。

Azure Monitor にアラートルールを追加する

「Azure Monitor --> Alerts --> New Alert Rule」と進んでアラートルールを追加します。

「+ Select target」から監視対象を追加するのですが、リソースタイプのプルダウンから「Storage Service」を選択すると、ストレージのサービス(blobやtable, file, queue)別に選択できます。

f:id:yhara90:20180731235306p:plain

閾値の定義

続いて「+ Add criteria」から閾値を定義します。「File Capacity」が使用量です。他にも「File Share Count」というメトリックがあって同じストレージアカウント内にある共有数が取れるようなのですが、そこまで取れるならもうひと頑張りして共有単位のメトリックも欲しかったところです。

アラート発生条件の指定

選択すると条件の定義に移ります。一般的には「閾値を超えたら(例:使用量が500GBを超えたらアラート発報)」となるかと思いますので、プルダウンから「Greater than」「Maximum」「500000000000」のように指定します(最後の「500000000000」は単位が「bytes」なので)。

次に評価のタイミングですが、ドキュメントによると「容量メトリックの値は 1 時間ごとに Azure Monitor に送信され」ということなので、Periodに1時間以上(Over the last hour)を指定しましょう。それより短いとこのグラフみたいになるので、アラートが出たり引っ込んだりしてしまいます。

f:id:yhara90:20180731235323p:plain

docs.microsoft.com

ということで、ひととおり設定し終えてこんな感じになりました。

f:id:yhara90:20180731235404p:plain

残りはAzure Monitoのアラート設定なので割愛。アラートに名前を付けたりアクショングループを作ってメールの送信先を設定したりします。

実際のアラートが発生すると、通知方法をメールとした場合はこんな感じのメールが届きます。

f:id:yhara90:20180731235423p:plain

これで無事に空き容量が監視できるようになりました。

GAしたQnA Makerをちょっと試してみた

build のタイミングでQnA MakerがGAしましたね。

blog.botframework.com

簡単に試したのでTwitterのログをまとめておきます。

Azure上のLinux VMにAzure AD認証でログインする

Linux VM用に「Azure AD login VM extension」というVM機能拡張が用意されたおかげで、Azure AD認証でログインできるようになりました。詳しくはこちらのドキュメントを。

docs.microsoft.com

対象のディストリビューションとバージョンはこんな感じ。

Distribution Version
CentOS CentOS 6.9 and CentOS 7.4
RedHat Enterprise Linux RHEL 7
Ubuntu Server Ubuntu 14.04 LTS, Ubuntu Server 16.04 and Ubuntu Server 17.10

準備

既にLinux VMがある場合はextensionを導入するだけです。実質1行。

az vm extension set \
    --publisher Microsoft.Azure.ActiveDirectory.LinuxSSH \
    --name AADLoginForLinux \
    --resource-group [VMのリソースグループ名] \
    --vm-name [VM名]

インストールが終わったら、VMに対してRBACの権限を割り当てます。

OSに対して管理者権限でログインしたい場合は「Virtual Machine Administrator Login」を、一般ユーザーの場合は「Virtual Machine User Login」を選びます。

f:id:yhara90:20180511190837p:plain

VMsshする

「-l」オプションを付けてsshでログインします。

ssh -l azureuser@contoso.onmicrosoft.com [VMのIPアドレス/FQDN] -p 22

URLとコードが表示されるので、URLをブラウザで開いてコードを入力しましょう。デバイスログインの仕組みですね。最近はCloud Shellばかり使っていたので久々に見ました。

To sign in, use a web browser to open the page https://microsoft.com/devicelogin and enter the code [コード] to authenticate. Press ENTER when ready.

ここでコードを入力して、

f:id:yhara90:20180511191716p:plain f:id:yhara90:20180511192023p:plain

ここまで来たらターミナルの方でEnterを押せばログイン完了です。無事にログインできました。

f:id:yhara90:20180511192516p:plain

元のユーザー情報が消えたり制限されたりするわけではないので安心です。逆に制限したい場合は各自でケアするということですね。