- AzureFunctionsとは
- Functionsはどの料金プランを使うべきか
- 別リソースとの連携(入力出力バインド)
- 送信 IP の固定化
- 関数アプリケーションの実行のされ方
- Functions のログ
AzureFunctionsとは
Functionsの概要は、以下ページを参照願います。
Functionsはどの料金プランを使うべきか
Functions を新規作成する際は、以下３つの選択肢があります。
・従量課金プラン
・Premiumプラン
・AppServiceプラン
しかし、何を基準に料金プランを選択すれば良いかよくわからない方もいると思うので、この記事を参考にしていただけたらと思います。
従量課金プラン
以下をすべて許容できる場合に限り、従量課金プランを使っても問題ないと思います。
● 課金・コストを抑えたい
● コールドスタートが発生して関数アプリの処理開始・処理中の自動スケールアウトの際待機時間が発生しても良い
● いつか関数アプリの実行が完了されれば良い
Premiumプラン
FunctionsはPremiumプランが推奨プランとなります。
以下ポイントのうち一つでも当てはまるのであれば、Premiumプランを使う必要があると思います。
● 処理時間にシビアなシステム要件的がある
● 処理開始時にコールドスタートを発生させたくない(デフォルト動作として、常にアクティブなインスタンスが用意される)
● 処理中に自動でスケールアウトされるときもコールドスタートを発生させたくない
AppServiceプラン
以下の場合はAppServiceプランを利用することになると思います。
● AppService/Functions 等の他リソースと同じAppServiceプラン上で実行させたい
※ Premiumプランのように、処理開始時にコールドスタートを発生させたくない場合、AppServiceプランに常時接続機能を有効にしましょう。
※ Premiumプランのように、必要に応じて自動でスケールアウトさせたい場合、AppServiceプランに自動スケールを設定しましょう。
注意点
既にAppServiceプランをもっているからといって、何でも一つのAppServiceプランに詰め込めばいいと思ったらそれは違います。一つのAppServiceプラン(Azureサーバ)で使えるリソースは有限ですので。
例えば、従量課金プラン・Premiumプランはリクエストが急に増えたりリソースが足りないとAzureサーバが判断したらデフォルトで自動スケールアウトしてくれますが、AppServiceプランは自動スケールアウトは事前に設定しないと自動スケールアウトしてくれません。
あと、従量課金プランはサーバーレスと書かれているようにAzure側が必要なサーバを用意して実行してくれるのですが、AppServiceプランは自分で適切な価格レベルを自分で選択する必要があります。
別リソースとの連携(入力出力バインド)
送信 IP の固定化
従量課金プランとPremiumプラン
従量課金プランとPremiumプランの場合は、送信 IP が勝手に変更されるので、例えば「特定 IP からのみの通信を許可する」というルールをストレージアカウントやデータベース側に設定することはできません。
※ 厳密にいうと設定することはできるのですが、送信 IP が勝手に変更されることがあるので、意味のないアクセス制御の設定になってしまう。ということです。
NAT ゲートウェイを使えば送信 IP を固定化できる
公式ドキュメントに書いてあるように構成すると、送信 IP を固定化できます。
AppServiceプラン
送信 IP が変更されるのが当たり前な従量課金プランとPremiumプランと比べて、AppServiceプランの場合は、特定の条件で 送信 IP が変更されることがあります。
「特定の条件」は公式ドキュメントに書かれています。
===== 抜粋 ここから =====
次のいずれかの操作を実行すると、アプリの一連の送信 IP アドレスが変更されます。
アプリを削除した後、別のリソース グループ内に再作成する (デプロイ単位が変更される場合があります)。
リソース グループと リージョンの組み合わせに含まれる最後のアプリケーションを削除した後、再作成する (デプロイ単位が変更される場合があります)。
アプリを下位レベル (Basic、Standard、および Premium)、Premium V2、PremiumV3 レベルの間でスケーリングする (IP アドレスはセットに追加するか、削除することができます)。
===== 抜粋 ここまで =====
関数アプリケーションの実行のされ方
Functionsはユーザがデプロイしたプログラムファイルがストレージアカウントに配置されます。関数アプリケーションが実行する際は、そのストレージアカウントから取得してきてインスタンス上で関数アプリケーションが実行されます。
通常のデプロイは、プログラムファイルや設定ファイルが開発した通り（構成フォルダ通り）にAzureサーバ上に配置されるのですが、kuduサイトなどから簡単にいじれてしまって意図しない変更をされてしまうとアプリケーションの動作に支障が出ます。
あと、Zipファイルをデプロイにした方がアプリケーション起動も早くなると公式ドキュメントに書かれています。
Zipデプロイ
Zipデプロイのメリット
・Zipファイルだけになるので、プログラムファイルのリソース管理が簡単になる
・kuduサイトなどからファイルの部分変更などができなくなる（ルール通りのデプロイを強制できる）
・AppService/Functionsのアプリケーションをインスタンス上に起動する時間が早くなる
Functions のログ
Azure Functions でご利用いただけるログ機能について記載します。
関数アプリケーションのログをAzure側に出力～確認
下記３箇所にログファイルが出力されますが、出力される条件としては Functions に関数を作成およびその関数アプリケーションを実行すると、Azure 側でログを出力されます。
関数アプリケーションでのログへの書き込み方法は、プログラム言語ごとに説明が書いてあるので、以下ページを確認ください。
公式ドキュメント
ログへの書き込み
そして、出力されたログ確認は下記３箇所できます。
(３箇所とも同じ内容が出力されます。)
Azureポータル(関数のモニター)画面で確認
● 該当 Functions > [関数]関数 > <<関数名>> [Developer]モニター > ログタブ
Kuduサイト(LogFilesフォルダ)で確認
● 該当 Functions > [開発ツール]高度なツール > 移動 > Debug console タブ > CMD > LogFiles > Application > Functions > Function > <<関数名>> フォルダ
ストレージアカウント(ファイル共有)で確認
● 該当 ストレージアカウントの ファイル共有 > LogFiles > Application > Functions > function > <<関数名>> フォルダ
ストレージアカウントのリソース名がわからなければ、ここで確認できます。
診断設定の活用
上記で説明した３箇所で、関数アプリケーションのログやメトリック画面にメトリック情報は出力されます。
これらの情報をAnalyticsワークスペース等に転送し、クエリ検索をしたり複数のAppService/Functions等のリソースのログを統合的に調査・監視したい場合は、以下をご利用ください。
公式ドキュメント
AzureMonitorログを使用したAzureFunctionsの監視
===== 抜粋 ここから =====
Azure Monitor Logs を使うと、同じワークスペース内の異なるリソースのログを統合できます。また、それをクエリを使って分析し、収集したデータをすばやく取得、統合、分析できます。
===== 抜粋 ここまで =====
AzureMonitorのApplicationInsightsの活用
こちらを有効設定すると、上記で紹介してきたログ情報とはまた別に、アプリケーションに関するAzureサーバ側の稼働状況に関する情報が取得できます。
例えば、ASP.NET の場合はCPU・メモリ・I/Oの使用状況などが Azure 側で自動で収集されます。
公式ドキュメント
AzureAppServiceのアプリケーションの監視の概要
以上です。
