Azure Functions の Flex 従量課金プラン ホスティング
Flex 従量課金は Linux ベースの Azure Functions ホスティング プランで、従量課金の "使用した分だけ支払う" サーバーレス課金モデルに基づいています。 プライベート ネットワーク、インスタンス メモリ サイズの選択、"サーバーレス" モデルに基づく高速または大規模スケールアウト機能を導入することで、柔軟性とカスタマイズ性が向上します。
重要
Flex 従量課金プランは現在、プレビュー段階です。 このホスティング プランを使用する場合の現在の制限事項のリストについては、「考慮事項」を参照してください。 プレビュー期間中の課金に関する最新情報については、「課金」を参照してください。
Flex 従量課金プランを備えるエンド ツー エンドのサンプルは、Flex 従量課金プランのサンプル リポジトリで確認できます。
メリット
Flex 従量課金プランは、動的スケーリングと実行ベースの課金を含む従量課金プランの長所に基づいています。 Flex 従量課金では、次の追加機能も利用できます。
- 常時使用可能なインスタンス
- 仮想ネットワークの統合
- HTTP アプリと非 HTTP アプリの両方のコンカレンシーに基づく高速スケーリング
- インスタンス、メモリ サイズなどの複数の選択肢
次の表は、Flex 従量課金の機能と従量課金ホスティング プランを直接比較するのに役立ちます。
機能 | 従量課金 | Flex 従量課金 |
---|---|---|
ゼロにスケール | ✅ はい | ✅ はい |
スケーリングの動作 | イベント ドリブン | イベント ドリブン (高速) |
仮想ネットワーク | ❌ サポート対象外 | ✅ サポートされています |
専用コンピューティング (コールド スタートの軽減) | ❌ なし | ✅ 常時使用可能なインスタンス (省略可能) |
請求 | 実行時間のみ | 実行時間と常時使用可能なインスタンス |
スケールアウト (最大) | 200 | 1000 |
従量課金プランと Flex 従量課金プラン、その他すべてのプランやホスティングの種類との完全な比較については、関数スケールとホスティング オプションに関するページを参照してください。
仮想ネットワークの統合
Flex 従量課金は、仮想ネットワーク統合のサポートを追加することで、従量課金プランの従来の利点を拡張します。 Flex 従量課金プランでアプリを実行すると、仮想ネットワーク内でセキュリティ保護された他の Azure サービスに接続できます。 その一方、Flex 従量課金プランのスケールとスループットの利点と共に、サーバーレスの課金とスケールを利用できます。 詳細については、仮想ネットワーク統合の有効化に関する記事を参照してください。
インスタンス メモリ
Flex 従量課金プランで関数アプリを作成する場合は、アプリを実行するインスタンスのメモリ サイズを選択できます。 インスタンス メモリ サイズが関数アプリのコストに与える影響については、「課金」を参照してください。
現在、Flex 従量課金では、2,048 MB と 4,096 MB の両方のインスタンス メモリ サイズのオプションが提供されています。
アプリで使用するインスタンス メモリ サイズを決定する場合は、次の点を考慮する必要があります。
- 2,048 MB のインスタンス メモリ サイズが既定であり、ほとんどのシナリオで使用されます。 4,096 MB のインスタンス メモリ サイズは、アプリがより高度なコンカレンシーや処理能力を必要とするシナリオで使用します。 詳細については、インスタンス メモリの構成に関するページを参照してください。
- インスタンス メモリ サイズはいつでも変更できます。 詳細については、インスタンス メモリの構成に関するページを参照してください。
- インスタンス リソースは、関数コードと Functions ホストの間で共有されます。
- インスタンス メモリ サイズが大きいほど、同時実行やより集中的な CPU またはメモリのワークロードに関する限り、各インスタンスで処理できる量が多くなります。 特定のスケールの決定は、ワークロード固有で行われます。
- HTTP トリガーの既定のコンカレンシーは、インスタンス メモリ サイズによって異なります。 詳細については、HTTP トリガーのコンカレンシーに関するページを参照してください。
- 使用可能な CPU とネットワーク帯域幅は、特定のインスタンス サイズに比例して提供されます。
関数ごとのスケーリング
コンカレンシーは、Flex 従量課金関数アプリのスケーリング方法を決定する重要な要素です。 さまざまなトリガーの種類でアプリのスケール パフォーマンスを向上させるために、Flex 従量課金プランでは、関数ごとにアプリのスケーリングに関するより明確な方法が提供されます。
この "関数ごとのスケーリング" 動作は、ホスティング プラットフォームの一部であるため、アプリを構成したり、コードを変更したりする必要はありません。 詳細については、イベント ドリブン スケーリングにある関数ごとのスケーリングに関する記事を参照してください。
関数ごとのスケーリングでは、グループ集計に基づいて特定の関数トリガーについて決定が行われます。 この表は、関数スケール グループの定義済みセットを示しています。
スケール グループ | グループ内のトリガー | 設定値 |
---|---|---|
HTTP トリガー | HTTP トリガー SignalR トリガー |
http |
Blob Storage のトリガー (Event Grid ベース) |
Blob Storage のトリガー | blob |
Durable Functions | オーケストレーション トリガー アクティビティ トリガー エンティティ トリガー |
durable |
アプリ内の他のすべての関数は、独自のインスタンスのセットで個別にスケーリングされ、規約 function:<NAMED_FUNCTION>
を使用して参照されます。
常時使用可能なインスタンス
Flex 従量課金には、常に実行され、関数ごとのスケール グループまたは関数にそれぞれ割り当てられるインスタンスを選択できる、"常時使用可能" の機能が含まれています。 これは、たとえば、アプリケーションのコールド スタートの待ち時間を短縮するために、要求を処理するために常時使用可能な最小数のインスタンスを必要とするシナリオに最適なオプションです。 既定値は 0 (ゼロ) です。
たとえば、関数の HTTP グループに対して常時使用可能を 2 に設定した場合、プラットフォームは 2 つのインスタンスを常に実行し、アプリ内の HTTP 関数に対してアプリに割り当てます。 これらのインスタンスは関数の実行を処理していますが、コンカレンシー設定に応じて、プラットフォームではオンデマンド インスタンスを使って 2 つのインスタンスを超えてスケーリングされます。
常時使用可能なインスタンスを構成する方法については、常時使用可能なインスタンス数の設定に関するページを参照してください。
コンカレンシー
コンカレンシーとは、アプリのインスタンスに対する関数の並列実行の数を指します。 各インスタンスがいつでも処理する必要がある同時実行の最大数を設定できます。 詳細については、HTTP トリガーのコンカレンシーに関するページを参照してください。
コンカレンシーは、コンカレンシー レベルが低いほど、関数に対するイベント ドリブンの要求を処理するためにより多くのインスタンスが必要になるため、アプリのスケーリング方法に直接影響します。 コンカレンシーは制御および微調整できますが、ほとんどの場合に機能する既定値を提供しています。 HTTP トリガー関数のコンカレンシー制限を設定する方法については、HTTP コンカレンシー制限の設定に関するページを参照してください。
展開
Flex 従量課金プランのデプロイは、1 つのパスに沿って進行します。 プロジェクト コードがビルドされ、圧縮されてアプリケーション パッケージが作成された後、BLOB ストレージ コンテナーにデプロイされます。 起動時に、アプリはパッケージを取得し、このパッケージから関数コードを実行します。 既定では、内部ホスト メタデータ (AzureWebJobsStorage) の格納に使用されるのと同じストレージ アカウントも、デプロイ コンテナーとして使用されます。 ただし、代替のストレージ アカウントを使用するか、アプリのデプロイ設定を構成して優先認証方法を選択することもできます。 デプロイ パスの合理化により、アプリの設定でデプロイの動作を変更する必要はなくなりました。
請求
Flex 従量課金プランでアプリを実行するときにコストを決定する 2 つのモードがあります。 各モードは、インスタンスごとに決定されます。
課金モード | 説明 |
---|---|
オンデマンド | "オンデマンド" モードで実行する場合、関数コードが使用可能なインスタンスで実行されている時間に対してのみ課金されます。 オンデマンド モードでは、最小インスタンス数は必要ありません。 課金の対象: • 各オンデマンド インスタンスが "アクティブに" 関数を実行している間に、プロビジョニングされたメモリの合計量 (GB 秒) から、1 か月あたりの無料付与の GB 秒を引いた値。 • 実行の合計数から、1 か月あたりの無料付与の実行数を引いた値。 |
常時使用可能 | 特定のトリガーの種類 (HTTP、Durable、BLOB) と個々の関数に割り当てられた 1 つ以上のインスタンスを構成できます。これは、要求を処理するために常に使用できます。 常時使用可能なインスタンスが有効になっている場合は、課金の対象は次のとおりです。 • "ベースライン" (GB 秒) と呼ばれる、常時使用可能なすべてのインスタンスにわたってプロビジョニングされたメモリの合計量。 • 常時使用可能なインスタンスがそれぞれ "アクティブに" 関数を実行しているときにプロビジョニングされたメモリの合計量 (GB 秒)。 • 実行回数の合計。 常時使用可能の課金では、無料の付与はありません。 |
どちらの実行モードも課金対象の最小実行期間は 1,000 ミリ秒です。 その後、課金対象のアクティビティ期間は、最も近い 100 ミリ秒に切り上げられます。 Flex 従量課金プランの課金メーターの詳細については、監視リファレンスに関するページを参照してください。
例を含め、Flex 従量課金プランで実行した場合のコストの計算方法の詳細については、従量課金ベースのコストに関するページを参照してください。
実行価格、常時使用可能のベースライン コスト、オンデマンド実行の無料付与に関する最新情報については、Azure Functions の価格に関するページを参照してください。
サポートされる言語スタック バージョン
次の表は、Flex 従量課金アプリで現在サポートされている言語スタックのバージョンを示しています。
言語スタック | 必要なバージョン |
---|---|
C# (分離プロセス モード)1 | .NET 82 |
Java | Java 11、Java 17 |
Node.js | ノード 20 |
PowerShell | PowerShell 7.4 |
Python | Python 3.10、Python 3.11 |
1C# インプロセス モードはサポートされません。 代わりに、分離ワーカー モデルで実行する .NET コード プロジェクトを移行する必要があります。
2Microsoft.Azure.Functions.Worker のバージョン 1.20.0
以降と Microsoft.Azure.Functions.Worker.Sdk のバージョン 1.16.2
以降が必要です。
リージョン サブスクリプションのメモリ クォータ
現在プレビュー段階にあり、特定のサブスクリプション内の各リージョンには、Flex 従量課金プランで実行されているアプリのすべてのインスタンスに対して 512,000 MB
のメモリ制限があります。 つまり、特定のサブスクリプションとリージョンでは、クォータ制限内であれば、インスタンス メモリのサイズと数を自由に組み合わせることができます。 たとえば、次の各例は、クォータに達したため、アプリのスケーリングが停止することを意味します。
- 1 つの 2,048 MB のアプリを 100 インスタンスにスケーリングし、2 番目の 2,048 MB のアプリを 150 インスタンスにスケーリングした
- 1 つの 2,048 MB のアプリを 250 インスタンスにスケールアウトした
- 1 つの 4,096 MB のアプリを 125 インスタンスにスケールアウトした
- 1 つの 4,096 MB のアプリを 100 インスタンスにスケーリングし、2 番目の 2,048 MB のアプリを 50 インスタンスにスケーリングした
このクォータを増やすと、要件に応じて Flex 従量課金アプリをさらにスケーリングすることができます。 アプリでより大きなクォータが必要な場合は、サポート チケットを作成してください。
非推奨のプロパティと設定
Flex 従量課金では、Bicep、ARM テンプレート、コントロール プレーン全体で使用される標準のアプリケーション設定とサイト構成プロパティの多くは、非推奨または移動されているため、関数アプリのリソース作成を自動化するときに使用しないでください。 詳細については、Flex 従量課金プランの非推奨に関するページを参照してください。
考慮事項
現在のプレビュー中に Flex 従量課金プランを使用する場合は、次の考慮事項に注意してください。
- ホスト: アプリの初期化は 30 秒でタイムアウトします。 関数アプリの起動に 30 秒より長くかかる場合、gRPC 関連の System.TimeoutException エントリが表示されます。 このタイムアウトは構成可能であり、このホスト作業項目の一部として、より明確な例外が実装されます。
- Durable Functions: Flex 従量課金の関数ごとのスケーリングの性質により、Durable Functions を最適なパフォーマンスにするには、
durable
グループの常時使用可能なインスタンス数を1
に設定することをお勧めします。 また、Azure Storage プロバイダーを使うときは、キューのポーリング間隔を 10 秒以下に減らすことを検討してください。 Flex 従量課金でホストされる Durable Functions 用のバックエンド ストレージ プロバイダーとしてサポートされるのは、Azure Storage のみです。 - VNet 統合: こちらの手順に従って、
Microsoft.App
Azure リソース プロバイダーがサブスクリプションで有効になっていることを確認します。 Flex 従量課金アプリで必要なサブネットの委任はMicrosoft.App/environments
です。 - トリガー: Kafka、Azure SQL トリガーを除くすべてのトリガーが完全にサポートされています。 BLOB ストレージ トリガーは、Event Grid ソースのみをサポートします。 C# 以外の関数アプリでは、拡張機能バンドルのバージョン
[4.0.0, 5.0.0)
またはそれ以降のバージョンを使用する必要があります。 - リージョン: 現在、すべてのリージョンがサポートされているわけではありません。 詳細については、現在サポートされているリージョンの表示に関するページを参照してください。
- デプロイ: 現在、デプロイ スロットはサポートされていません。
- スケール: プレビューで最小の最大スケールは
40
です。 現在サポートされている最大値は、1000
です。 - マネージド依存関係: PowerShell のマネージド依存関係は、Flex 従量課金ではサポートされていません。 代わりに、独自のカスタム モジュールを定義する必要があります。
- 診断設定: 診断設定は現在サポートされていません。
- 証明書: WEBSITE_LOAD_CERTIFICATES のアプリ設定を使用した証明書の読み込みは、現在サポートされていません。
- Key Vault 参照: 関数アプリに Virtual Network 統合がある場合でも、Key Vault のネットワーク アクセスが制限されていると、アプリ設定の Key Vault 参照は機能しません。 現時点でこれを回避するには、コードで Key Vault を直接参照して、必要なシークレットを読み取ります。
- Azure Files ファイル共有のマウント: 関数アプリに Virtual Network 統合がある場合、Azure Files ファイル共有のマウントは機能しません。