テレメトリの欠落が無視できない頻度で発生する (詳細不明。少量のテレメトリで欠落したので、サンプリングは関係ないはず)。酷い時は数割程度欠落する時があった
リアルタイムでテレメトリを表示できるライブメトリックストリームは、更に表示の欠落が多い。ただ、この場合はライブメトリックストリーム画面の表示上の問題で、検索すれば出てくることが多い
Application Insights の送信が複数テレメトリをまとめてのバッチ送信になっている事も影響しているかもしれないが、必ずしも送信した時系列順で記録されるわけではなく、順番が前後することがあるため、テレメトリの正確な発生順の把握は出来ないと考えておいた方が良い
テレメトリ受信から数十分ほど経たないと、検索結果などに現れないことがある。最短でも、5 分程度は必要
クライアント IP は記録されなくなった (Client IP logged as 0.0.0.0 but geolocation is logged correctly)

2018-05-01

Azure Functions ホスティングプランの比較

Azure Functions App Service

基本については、大体以下のページに載ってる。

その上で、自分的に気になる点をまとめてみる。

まず、ホスティングプラン (= 料金プラン) の選択肢は、以下 2 つ

従量課金プラン (ドキュメント的に「サーバーレスプラン」はこっちらしい。でもそれ言うなら、どっちかと言うと「専用 VM なしプラン」の方が個人的にはしっくり来るけど・・・)
App Service プラン (Web Apps などで使用する App Service と同じ。月額固定料金)

料金に関して両者の大きな違いは、もう名前の通りで、従量課金プランは従量課金、App Service プランは App Service のプランに従い月額固定 (のようなもの)。なお、Function App を App Service プランで作成する場合は、App Service プランの Free, Shared は選べず、Basic 以上からとなる。従量課金と App Service プラン間の切り換えは Function App を作成した後は行えないため、よく考えて決める必要がある。ただ、Function App だったら、作成した環境を一度削除してプランを変えて新たに作成し直すのも、そこまで大変ではないかなと思う。

もう一つ大きな違いとしては、従量課金プランは実行インスタンスを他の開発者の Function App と共有、App Service プランは専有の違いがある。言い方を変えると、従量課金プランはインスタンスのリソース使用状況についてコントロール不可、App Service プランはコントロール可能となる。従量課金プランのコントロール不可については実際に使ってみないと分かりづらいが、恐らく予想している以上に安定していない。うまく行っている時は 3 分ぐらいで完了する処理が、インスタンスの混み具合によっては 10 分以上かかる事があったりするぐらい、安定していない (2018/6 現在)。処理が遅くなる事自体問題だが、従量課金プランの場合は実行時間が最大 10 分までと言う制限がある為、処理速度の低下が致命的になる可能性がある。リソースの使用状況をコントロール出来ない以上、従量課金プランを選択する場合は処理速度の低下について発生し得るものとして考慮しておく必要がある。

従量課金プラン
- 課金方法は名前の通り、従量課金
- ただ、単純に従量課金と言っても、課金対象となるエリアが複数あるので、注意。大きく分けると、以下
  - 関数の実行量 (実行回数と、使用メモリ量の 2 種類。どちらも一定量までは無料で、それを超えた分から課金となる)
  - ファイル配置に使用する Azure File Share の使用料 (保存量と、操作量の 2 種類。無料枠なし)
  - その他 (データ転送量とか)
- 上記のような課金体系となるため、いくら実行回数が少なかったとしても、完全な無料にはならない (そもそも Function App 自体が無料枠のない Azure File Share に配置される)
- ただ、詳細は価格に関するページを確認してもらいたいが、よっぽど重い処理だったり大量に実行されでもしない限り、無視できるぐらいの料金しかかからないはず
- 一例としては、以下
  - メモリ使用量が 256 MB の関数が月間に 200 万回実行され、各実行の実行時間が 1 秒、Function App 全体の合計ファイルサイズが 1 GB の Function App について、月額使用料を想定してみる
  - 実行回数への課金。100 万回までは無料で、以降 100 万回につき 22.4 円なので、100 万回分の 22.4 円かかる
  - 使用メモリ量への課金。400,000 GB 秒までは無料で、以降 1 GB 秒につき 0.001792 円かかる。(256 MB/ 1024 MB) x 200 万回 = 500,000 GB 秒。(500,000 - 400,000) x 0.001792 = 179.2 円かかる
  - ストレージへの保存量は、1 GB につき 6.72 円なので、1 GB のファイル保存だと 6.72 円かかる
  - ファイルの操作は、読み取りや列挙などの操作が 1 万回につき 1.68 円だが、正直なところこの回数については、実際にどれぐらい発生するものなのか目算に自信がなかったので、ここでは出さない
  - 以上のように、ファイル操作について除外すると、この試算だと大体合計で月 200 円ちょっととなる。パッと見、実行回数とストレージ保存量については度外視できると思われるし、やや気になる使用メモリ量についても、重く長い処理にならないようにすれば、ヤバいことにはならないように思える。
- ファイル配置に使用する Azure Storage 以外に、トリガーやログの内部管理にも別途 Azure Storage を使用するようなので、そちらでも料金かかるかも (詳細未確認)
- 実行インスタンスは他の開発者の Functions と共有。インスタンスの使用状況によって、速い時と遅い時で数倍ぐらい処理速度に差が出る可能性がある
- 最大実行時間は 10 分
- インスタンス共有と実行時間の制限から、実行時間は長くても 1, 2 分で完了する事を推奨。また、処理速度に数倍程度の差が発生しても問題ない必要がある
- コールドスタート問題あり
- スケーリングは自動で行われる
App Service プラン
- 課金方法は名前の通り、App Service プランでの課金となる (= 月額固定)
- App Service プランは Free から用意されているが、Functions では Basic 以降のプランが選択できる
- 例えば、選択可能なプランの中で一番安い Basic の B1 を使用すると、月 7,235 円かかる (App Service プランが存在している限り課金対象となるので、これ以上は節約しようがない)
- 従量課金と同様、トリガーやログのシステム管理に別途 Azure Storage を使用するようなので、そちらでも料金かかるかも (詳細未確認)。データ転送量とかも同様。
- インスタンスは専用なので、リソースの使用状況は自分である程度コントロール出来る
- 実行時間の制限はなし
- コールドスタート問題なし

Free より右は全て App Service プラン (サイズは S について掲載。サイズを大きくすると、搭載メモリや CPU コア数が増える。Premium は V2 について掲載)。 Free は Functions では利用できないが、参考までに掲載。

	従量課金プラン (Function のみ)	Free	Basic B1	Standard S1	Premium P1V2	Isolated I1
Function で選択可能	●	-	●	●	●	●
参考月額 (730h)	無料枠ありの従量課金 (実行回数＋メモリ使用量)	使用上限ありの無料	7,236 円	9,648 円	19,295 円	32,704 円 + (スタンプ料金 14.8 万)
永続ディスク	5TB (Azure Files 従量課金)	1GB	10GB	50GB	250GB	1TB
最大インスタンス数	200	-	3	10	20	100
スケール	自動	-	手動	手動/自動	手動/自動	手動/自動
コールドスタートの可能性	● (20 分アイドルで発生)	-	-	-	-	-
最大実行可能時間	10 分	-	無制限	無制限	無制限	無制限
スタンプ (=スケールユニット)	複数の可能性あり	?	基本固定	基本固定	基本固定	専有(?)
SLA	-	-	99.95%	99.95%	99.95%	99.95%
備考	共有 VM	共有 VM	専用 VM	専用 VM	専用 VM	App Service Environment 利用可能

スケールする場合は、下記インスタンス情報の単位となる。表には載っていないが、物理 CPU やストレージなどはプランによって使うグレードが変わり、パフォーマンスが変わるらしい (例：HDD -> SSD)。

	従量課金 (Function のみ)	Free	Basic B1	Standard S1	Premium P1V2	Isolated I1
1 時間の料金 (スケール時参考)	-	-	10 円	13 円	26 円	45 円
CPU コア数	1 (共用)	共用	1 (*1)	1 (*1)	1 (*1)	1 (*1)
メモリ	1.5GB	1GB	1.75GB (*2)	1.75GB (*2)	3.5GB (*2)	3.5GB (*2)
一時ディスク	500MB	500MB	11GB (*3)	11GB (*3)	21GB (*3)	21GB (*3)
最大コネクション数	300	300	1,920 (*4)	1,920 (*4)	1,920 (*4)	?
最大スレッド数	512	512	無制限	無制限	無制限	無制限

*1 VM のサイズによって異なる。S が 1、M が 2、L が 4。言語が JavaScript の場合は、言語の仕様上複数コア時のパフォーマンスアップが見込めないらしいので、1 コアのプランでスケールアウトさせる必要があるらしい

*2 VM のサイズによって異なる。Basic と Standard は S が 1.75GB、M が 3.5GB、L が 7GB。PremiumV2 と Isolated は S が 3.5GB、M が 7GB、L が 14GB

*3 VM のサイズによって異なる。Basic と Standard は S が 11GB、M が 15GB、L が 58GB。PremiumV2 と Isolated は S が 21GB、M が 61GB、L が 140GB。領域自体は各インスタンス毎に作成されるが、使用可能量は全インスタンスでの使用量合計となる点に注意。

*4 App 単位ではなく、VM 全体のリミット。App 単位は無制限。また、VM のサイズによって異なる。S が 1,920、M が 3,968、L が 8,064

上述の表を見ると分かるように、各プランによって一度に使用可能なリソースの上限が異なる。使用リソースが少ない Function App はスケールのメリットを享受できるが、使用リソースが多い場合、高性能なインスタンスでないと実行できない可能性がある。例えば、メモリを 1.8GB 使用する Function App の場合、従量課金及び B1, S1 プランではスケール関係なしにメモリが足りず実行できない。

また、状況見る限り、従量課金プランは低スペックマシンで実行して、実行数の増大に対しては大量のスケールアウトで対処するような想定に見えるので、リソースの最小化には特に気を使う必要があるように思える。

従量課金プランと App Service プランの処理速度についてざっくりと比較すると、App Service の B1 プランで他に全くサービスを動かしていない状態で 2 分かかる関数があったとすると、同じ関数を従量課金プランで動かすと、大体 3 分から 10 分ぐらいかかる可能性がある。

結局どっちのプランを選ぶべきか

一番の懸念事項は、公表されているスペックや料金以外の特記事項として、従量課金プランの動作が安定していない事に尽きる。これは実際にある程度使ってみないと分からないし、今後改善・改悪の可能性もある事項なので、その点も注意。

もっと効率的な使い方があったりするかもしれないのであくまで自分が使った印象になるが、プランの選択については以下の考慮を行う。

従量課金プラン
- 動作が安定しない前提で使うのであれば、開発環境や動作確認環境としてなら使える（コスト重視）
- コールドスタート問題が使う上で問題とならないこと
- 10 分以内に処理完了する必要があるため、App Service プランで実行した時に 1 分以内で処理完了するようなタスクが何となくの目安（計測は処理が安定する App Service プランでないと正確に行えない）
App Service プラン
- 安定動作が必要な処理で選択
- 少なくとも本番はよっぽどの事がない限り、こちらの使用を推奨

※ ネットの情報を見る限り、短時間の処理を行う大量の HTTP リクエストを受け、その際ある程度の処理取りこぼしが発生しても問題ないとかいう状況であれば、従量課金プランの方が適しているのかもしれない（自分は試していないので実際のところは分からないが）

参考 URL

2018-04-30

Azure Functions の各種トリガーの使い方とか

Azure Azure Functions

各種トリガーの使い方を簡単に説明。とは言っても、自分が使ったことがあるのが 2 種類しかないので、今の所それだけ。

HTTP トリガー
- 所謂、Web API, REST API とか呼ばれるやつ。HTTP でリクエストを受けて、レスポンスを返す
- GET, POST, PUT など任意のメソッドで受信することが可能。Run メソッドの引数で指定できる
- 受け取る URL パスについても、引数の Route で指定できる
- 認証方法として、匿名や API キー必須などの選択が可能。API キーは Azure ポータル画面で設定したキーを HTTP ヘッダーやクエリストリングで渡すことで、認証処理が行われる
- HTTP トリガーについては、リクエストから約 2.5 分以内にレスポンスが返らない場合、ゲートウェイ側でタイムアウトが発生し、HTTP 502 エラーが呼び出し元に返る。その場合も Function の実行自体は継続されるが、最終的なレスポンスを返すことは出来ないので、注意。この仕様のため、基本的にはすぐレスポンスを返せるような処理を推奨
- 従量課金プランの場合、20 分ほど呼び出しがないとインスタンスが落ちて次回の呼び出しがコールドスタートになる (インスタンスの準備に 10 秒前後かかる) が、HTTP トリガーはコールドスタートの影響を受けやすいので、予め考慮が必要
タイマートリガー

タイマートリガーは詳細な説明を下記ページに記載

poke-dev.hatenablog.com

参考 URL

2018-04-30

Visual Studio を使用した Azure Functions の始め方

Azure Azure Functions Visual Studio

Functions を作成する方法は、Azure ポータルを使ったり Visual Studio を使ったり、いくつかあるが、ここでは一番使われると思われる、Visual Studio を使用した始め方を簡単に記載する。

注：Visual Studio は、基本的に最新の状態で使うこと。Azure Functions 自体が出て間もないサービスと言うこともあり、Visual Studio との統合機能もかなり頻繁に更新されている。使用できる機能や UI なども結構変わるので、ここでの手順も、細かいところは違っている可能性がある。

ここでは、Visual Studio 2017+C# で新規の Functions プロジェクトを従量課金プランで作成してみる。

Visual Studio で新規プロジェクトを作成し、テンプレートは「Azure Functions」を選択する
Functions は関数単位でエントリポイントを作成していく。例えば、GET の REST API を追加するのであれば、ソリューションエクスプローラーで当該プロジェクトを右クリックし、コンテキストメニューから [追加] - [新しい項目] を選んで [Azure 関数] を追加し、関数の種類では Http trigger を選択する。Access rights は関数の呼び出し時にどのような認証を行うかだが、単純なテスト用であれば、誰でも呼ぶことが出来る「Anonymous」で良いと思う
この状態で、ローカルでのデバッグ実行可能。念の為デバッグ実行してみる (デバッグ実行すると、関数実行用の URL が表示されて待ち状態になるので、その URL をブラウザから叩く)
ソリューションエクスプローラーで当該プロジェクトを右クリックし、コンテキストメニューから[発行] をクリックする
[発行] 画面で [Azure 関数アプリ] の新規作成を選択し、[Create Profile] をクリックする (Publish の方でも構わない)
App Service の作成ダイアログが表示されるので、適宜項目を入力する。いくつか入力するところがあるが、重要なのは、「アプリ名」と「App Service プラン」
- [アプリ名] - この名称が発行先の実際の Function App 名になる。ローカルで作成したプロジェクトの名称は関係ないので、注意。URL にも使用されるので、グローバルで一意である必要がある
- [App Service プラン] - App Service プランか従量課金プランかを選択する。App Service プランを選ぶ場合は、Basic 以上のプランである必要がある。基本無料で使用できる従量課金プランを選ぶ時は、[新規作成] ボタンをクリックして App Service プランの構成ダイアログを表示し、[サイズ] のドロップダウンで「消費」を選択する必要がある
項目の入力が終わったら、[作成] ボタンをクリックする。最初に [Create Profile] を選んでいた場合は、この時点で Azure ポータルに入力した Function App 名で枠だけ作成される (中身の関数はまだ)
[発行] ボタンをクリックすると、選択しているプロファイル情報を基に関数が発行される。この時点で、Azure 上での実行が可能な状態となる
Azure ポータルで当該 Function App を選択し、実行したい関数を選択して [実行] ボタンを押すと、関数が実行される。[実行] ボタンの右にある [関数の URL の取得] をクリックすると、URL がコピーできる (Http trigger 関数の場合)
Visual Studio から発行した場合、Azure ポータル上で関数の修正とかは出来ないので、関数の修正や追加など行う場合は Visual Studio で行った後に、再度発行する

参考 URL

Visual Studio を使用して初めての関数を作成する