タイトルの通り、Azure Functionsの機能をまとめてみた。
課金モデル
課金モデルが5パターンあるのではなく、運用方式が5パターンあり、それぞれ課金方式が違う。
呼称がMECEでなかったり公式ドキュメントで表記揺れが存在したり親切でない点はある。
Premium、DedicatedはApp Service Planで動かすことができ、かなり微妙に繋がっている。
実質的にPremium、DedicatedはApp Service Planで実現され課金がかかる。
コールドスタートに対する改善の歴史を感じる。
| 課金モデル | 概要 |
|---|---|
| 従量課金 | オーソドックスなFaaS。名前の通り資源の使用量に応じて課金。必要最低限のネットワーク分離が提供される。既存VNetとの統合は不可。コールドスタート。アプリのロード・アンロードが頻繁に発生し、しばしば遅い。 |
| Premium | 資源の使用量に応じて課金。従量課金よりも高機能な従量課金(言葉辛い..)。既存VNetとの統合がサポートされる。コールドスタートを回避するために用意された。インスタンス数をゼロまでスケールインさせないことでホットスタートを実現している。アクティブなインスタンスのコア数(vCPU/h)、メモリ使用量(GB/h)に課金。裏側はApp Service Planだが手持ちのカスタムイメージをACRに登録しApp Serviceにホストすることが可能。 |
| Dedicated | 通常のApp Service Planとして課金される。既にApp Serviceインスタンスを実行しており新たにFunctionを相乗りさせる時に使用する。従量課金的な要素が無いので(高価だけれども)コストを予測できる。 |
| App Service Environment(ASE) | 超強力なDedicated。1人の顧客に限定された専用環境。ASE v1,v2,v3と脈々と新しい奴が作られている。高スケール、分離およびセキュリティで保護されたネットワーク アクセス、高いメモリ使用率などが書かれている。マルチリージョンにまたがって構成できる。高RPS(Requests per Seconds)ワークロード向けに用意されるApp Serviceの強化版。 |
| Container Apps Hosting | Azure Container Appsでコンテナ化されたFunctionsの開発・デプロイ・管理。Kubernetes ベースの環境で関数を実行できる。現在プレビュー。 |
従量課金とPremiumの違い
リッチな従量課金プランであるPremiumについて詳細なドキュメントがある。
Azure Functions の Premium プラン
そのメリットとして、以下が列挙されている。
- インスタンスをウォーム状態に維持することでコールド スタートを回避します
- 仮想ネットワーク接続
- より長いランタイム期間をサポートします
- Premium インスタンス サイズの選択
- 従量課金プランと比較して、予測可能な料金
- 複数の Function App を含むプランでの高密度アプリ割り当て
従量課金プランは、インスタンス数をゼロまでスケールインできる。
その結果としてその料金の料金はかからない一方、リクエストが来たときにゼロから1個以上まで
スケールアウトする際に”コールドスタート”時間を要する。
Premiumプランには、”常時使用可能なインスタンス”という考え方がある。
要はインスタンス数をゼロまでスケールインさせず、常にアクティブにしておくということらしい。
当然、”常時使用可能なインスタンス”は常時課金される。
他に”事前ウォーミング可能なインスタンス”という考え方がある。
常時使用可能なインスタンスが負荷分散してリクエストを捌いている間、
事前ウォーミング可能なインスタンスが後で立ち上がる。常時使用可能なインスタンスの負荷が
規定値を超えると、事前ウォーミング可能なインスタンスがアクティブに昇格し捌き始める。
事前ウォーミング可能なインスタンスは昇格するまでの間立派に課金されてしまう。
Premiumプランは実際はApp Serviceの仕組みで動く。
プラン名に規約がありEで始めるとElastic Premium、つまり、App Serviceで動かすPremiumということになる。また、Pで始めると動的スケールしないDedicated Hostingプランということになる。
Azure Functions は Azure App Service プラットフォームで実行できます。 App Service プラットフォームでは、Premium プラン関数アプリをホストするプランは Elastic Premium プランと呼ばれており、EP1 のような SKU 名があります。 Premium プランで関数アプリを実行することを選択した場合、EP1 のように “E” で始まる SKU 名を持つプランを必ず作成してください。 P1V2 (Premium V2 Small プラン) のように “P” で始まる App Service プラン SKU 名は実際には Dedicated ホスティング プランです。 Dedicated であり、Elastic Premium ではないため、”P” で始まる SKU 名のプランは動的にスケールせず、コストが増えることがあります。
実行継続時間
従量課金プランは1回の実行の最大は10分。Premiumプランはデフォルトで最大30分。
ただし、Premiumプランの最大値は延長して無制限まで拡張できる。
- プラットフォームのアップグレードにより、マネージド シャットダウンがトリガーされ、関数の実行が停止する可能性があります
- プラットフォームの停止により、処理されないシャットダウンが発生し、関数の実行が停止する可能性があります
- 新しい実行がない状態で 60 分経つと worker を停止するアイドル タイマーがあります
- スケールイン動作により、60 分後に worker のシャットダウンが発生する可能性があります
- スロットのスワップにより、スワップ中にソース スロットとターゲット スロットの実行が終了される可能性があります
これはFunctionのタイムアウト期間であって、HTTPトリガーの応答にはAzure Load Balancerの
タイムアウト期間(=230秒)が適用される。HTTPトリガで長時間処理を実現する場合、
Durable Functionで作るか、即時応答・非同期処理のパターンにすべきとのこと。
Function App タイムアウト期間
HTTPトリガで長時間処理を実装するパターン
可能な限り、大きな関数は、連携して高速な応答を返す、より小さな関数セットにリファクタリングしてください。 たとえば、webhook または HTTP トリガー関数では、一定の時間内に確認応答が必要になる場合があります。webhook は通常、即座に応答を必要とします。 この HTTP トリガー ペイロードは、キュー トリガー関数によって処理されるキューに渡すことができます。 このアプローチを使用すると、実際の作業を遅らせて、即座に応答を返すことができます。
ネットワーク
既存のAzureリソースとAzure Functionsを連携する際に、どのように既存リソースと連携できるか、
各実現方式毎にやれることが決まっている。以下が参考になった。
| 特徴 | 従量課金 | Premium | Dedicated | ASE |
|---|---|---|---|---|
| 受信アクセス制限 | ✅ | ✅ | ✅ | ✅ |
| プライベートエンドポイント | ❌ | ✅ | ✅ | ✅ |
| 仮想ネットワークの統合 | ❌ | ✅ | ✅ | ✅ |
| VNet Trigger(非HTTP) | ❌ | ✅ | ✅ | ✅ |
| Hybrid接続 | ❌ | ✅ | ✅ | ✅ |
| 送信IPの制限 | ❌ | ✅ | ✅ | ✅ |
受信アクセス制限は、送信元のIPアドレスに対するAllow/Denyを設定する機能。
IPv4/v6のIPアドレスを直接指定するか、サービスエンドポイントを使用するVNetのサブネットを指定可。
より詳細な記述は、Azure App Service のアクセス制限を設定するを参照。
プライベートエンドポイントは、VNet内からプライベートエンドポイントを介したPrivateLink接続。
AWS VPCと異なり、Azure VNetはリソースの論理的なグルーピングに過ぎない、という側面があり、
通信を秘匿化したいという文脈でなくても、PrivateLinkを使って連携せざるを得ない事情がある。
プライベートエンドポイントのDNSはAzureが良しなに作ってくれる。
仮想ネットワークの統合(VNet統合)は、Azure Functionsを指定のVNetに論理的に配置するオプション。
これにより、FunctionからVNet内のリソースにアクセスできるようになる。
FunctionからVNet内リソースに対して送信呼び出しを行うために使われる。逆には使われない。
従量課金ではN.G.だがPremiumクラスの従量課金なら可能になる。これはメリット。
リージョン内であれば、VNet側にVirtual Network Gatewayは必要ないがリージョン間であれば必要。
Virtual Network Gatewayを必要とする場合、通信に大きな制約がかかる。
なお、Azure FunctionsをASEで運用する場合、FunctionはASE内に物理的に配置されるため、
論理的なVNet統合を行う必要はないとのこと。
トリガについては後述する。オーソドックスな従量課金モデルはHTTPトリガしかサポートしない。
Premium以降で他のトリガが解放される。
ハイブリッド通信は、Windowsで動作している従量課金以外の全てのFunctionについて、
他のネットワークのリソースにアクセスできる機能。Azure Relayという機能の1つ。
Windowsを使わないといけないため特殊な用途となる。省略。
トリガとバインド
トリガーによりFunctionが発火し実行される。つまりトリガーにより関数の呼び出し方法を定義する。
トリガーとバインドについてはAzure Functions でのトリガーとバインドの概念が参考になる。
トリガーにはデータが紐付けられていて、呼び出しの際のペイロードとなる。
バインドとは、別のリソースを宣言的に接続する方法。入力バインド/出力バインドがある。
バインドからのデータは、Functionから見てパラメータとして利用できる。
Azure Functionsのバージョンにより対応可否が異なる。現在のバージョンはv4。
比較的マイナーと思われるものについて、割と昔出来ていたことが出来なくなったパターンが多い。
Kafka、RabbitMQは従量課金プランではサポートされない。
| Type | v1.x | v2.x以降 | トリガー | 入力 | 出力 |
|---|---|---|---|---|---|
| Blob Storage | ✔ | ✔ | ✔ | ✔ | ✔ |
| Cosmos DB | ✔ | ✔ | ✔ | ✔ | ✔ |
| Azure Data Explorer | ✔ | ✔ | ✔ | ||
| Azure SQL | ✔ | ✔ | ✔ | ✔ | |
| Dapr | ✔ | ✔ | ✔ | ✔ | |
| Event Grid | ✔ | ✔ | ✔ | ✔ | |
| Event Hubs | ✔ | ✔ | ✔ | ✔ | |
| HTTP | ✔ | ✔ | ✔ | ✔ | |
| IoT Hub | ✔ | ✔ | ✔ | ||
| Kafka | ✔ | ✔ | ✔ | ||
| Mobile Apps | ✔ | ✔ | ✔ | ||
| Notification Hubs | ✔ | ✔ | |||
| Queue Storage | ✔ | ✔ | ✔ | ✔ | |
| Redis | ✔ | ✔ | |||
| Rabbit MQ | ✔ | ✔ | ✔ | ||
| SendGrid | ✔ | ✔ | ✔ | ||
| Service Bus | ✔ | ✔ | ✔ | ✔ | |
| SignalR | ✔ | ✔ | ✔ | ✔ | |
| Table Storage | ✔ | ✔ | ✔ | ✔ | |
| Timer | ✔ | ✔ | ✔ | ||
| Twillo | ✔ | ✔ | ✔ |
例えば、HTTPトリガーとバインドの例は以下。
RESTfulAPI的にURLにペイロードを含めることができる。
(ドキュメントを見ても何が正解が分からないし、もちろんどこかに実行例がある訳でもない)
ここで、リクエストパラメタが入力バインド、レスポンスが出力バインド、ということになる..(のかな)。
|
1 2 3 4 5 6 7 8 9 10 11 12 |
import logging import azure.functions as func @app.function_name(name="httpTrigger") @app.route(route="products/{category:alpha}/{id:int?}" auth_level=func.AuthLevel.ANONYMOUS) def main(req: func.HttpRequest) -> func.HttpResponse: category = req.route_params.get('category') id = req.route_params.get('id') message = f"Category: {category}, ID: {id}" return func.HttpResponse(message) |
こうしておくと、例えば以下のURLで定義したhttpTriggerを実行できる。
|
1 |
http://<APP_NAME>.azurewebsites.net/api/products/electronics/357 |
auth_levelは認可レベル。URLのリクエストに必要な認可キーを指定する。
ANNONYMOUSなら不要、FUNCTIONなら関数固有のAPIキー、ADMINならマスターキー(?)。
詳細はこちら。
まとめ
Azureドキュメントを見ながらAzure Functionの概要をまとめてみた。
実装例が少なくまとまったドキュメントが少ない、という問題があり、
座学版の他に「やってみた」を繰り返す必要がありそう。