浅草橋青空市場

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

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

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

Azure Database for MySQLのFirewallルールをAzure CLIから設定する

メモ代わりに。 Azure CLIからAzure Database for MySQLのFirewallルールを設定する方法です。

az mysql server firewall-rule create --resource-group <リソースグループ名> --server <サーバー名> --name AllowAzureIP --start-ip-address <開始IPアドレス> --end-ip-address <終了アドレス>

Azureサービスからのアクセスを許可したい場合はこれ(0.0.0.0)で良いようです。

az mysql server firewall-rule create --resource-group <リソースグループ名> --server <サーバー名> --name AllowAzureIP --start-ip-address 0.0.0.0 --end-ip-address 0.0.0.0

WAF & SSLのApplication GatewayをARM Templateでデプロイする

ロードバランサーSSLを終端してついでにWAFも」というご要望で登場するのがAzureのApplication Gatewayです。よくある構成なのでARM Templateにしておきました。プロビジョニングで20分、設定変更のつど分単位で待たされるので、効率よくやりたいですね。

テンプレートからのデプロイ方法は、お手軽なところでポータルかを使う手順をご紹介しておきます。

  1. テンプレートデプロイ用のブレードを開く

    「Create a Resource」から「Template deployment」で検索するか、以下のURLから直接開けます。開いたら「Create」ボタンを押して進んでください。

    https://portal.azure.com/#create/Microsoft.Template

  2. 「Build your own template in the editor」をクリック

    f:id:yhara90:20180413210352p:plain

  3. テンプレートを貼り付けて「Save」をクリック

    f:id:yhara90:20180413210434p:plain

  4. パラメーターを適宜入力

    f:id:yhara90:20180413210524p:plain

    (参考)Base64への変換

    PowerShell

    $path="C:\Users\my\Documents\mycert.pfx"

    [Convert]::ToBase64String([System.IO.File]::ReadAllBytes($path))

    Linux / macOS

    openssl base64 -in mycert.pfx -out mycert.pfx.txt

  5. しばらくお待ちください

    ドキュメントによると「プロビジョニングに最大 20 分かかります」とのことでしばらく待ちましょう。

    Azure Application Gateway に関してよく寄せられる質問 | Microsoft Docs

▼Application Gateway のテンプレート(WAF & SSL)

gist.github.com

▼HTTPからHTTPSへのリダイレクトはテンプレートに入れてないので、設定したい場合はこちらのPowerShellをどうぞ

gist.github.com

Azure Database for PostgreSQLでCollation(照合順序)を指定してCREATE DATABASEしたい

というお困り状態を見かけたので。
これまで使っていたCREATE DATABASEをAzureのPostgreSQLに発行すると「ERROR: invalid locale name: "ja_JP.utf8"」となってしまう場合があるようです。

postgres=> CREATE DATABASE my_new_database ENCODING='UTF8' LC_COLLATE='ja_JP.utf8' LC_CTYPE='ja_JP.utf8';
ERROR:  invalid locale name: "ja_JP.utf8"

これはPostgreSQLWindows上で動いているのが原因のようで、エンコーディングを「UTF8」とする場合、COLLATIONの日本語ロケールは「Japanese_Japan.932」を指定すると良いようです。

ロケール(国際化と地域化) | Let's Postgres

Windows で UTF8 エンコーディングを使う場合のみ、ロケールエンコーディングにコードページ 932 (SJIS) を使うことができます。これは Windows の C ライブラリが UTF8 でのロケール処理をサポートしていないためで、PostgreSQL 側で専用の対応を行っています。

だそうです。SQLで書くとこんな感じです。

postgres=> CREATE DATABASE my_new_database ENCODING='UTF8' LC_COLLATE='Japanese_Japan.932' LC_CTYPE='Japanese_Japan.932' TEMPLATE='template0';

ちなみに、ロケールを指定しない場合のデフォルトは「English_United States.1252」となってました。

せっかくなので、Azure Database for PostgreSQL 上でいくつかの照合順序を指定して、実際にどのような並びになるのか簡単に試してみました。

Japanese_Japan.932 English_United States.1252 C
う゛
う゛ う゛

#これだけ見るとデフォルト(English_United States.1252)でいいんじゃ?って気にならなくもない。