従量課金、Flex 従量課金、Premium の各プランでは、Azure Functions により、関数をトリガーするイベントの数に基づいてインスタンスが追加され、リソースがスケーリングされます。
関数アプリのスケーリング方法は、ホスティング プランによって異なります。
従量課金プラン: 従量課金プランの Functions ホストの各インスタンスは、通常、1.5 GB のメモリと 1 個の CPU に制限されています。 ホストの 1 つのインスタンスで、関数アプリ全体がサポートされます。 そのため、関数アプリ内のすべての関数が、インスタンス内のリソースを共有し、同時にスケーリングされます。 関数アプリが同じ従量課金プランを共有する場合でも、スケーリングは個別に行われます。
Flex 従量課金プラン: このプランは、決定論的な関数ごとのスケーリング戦略を使用します。HTTP、Blob、および Durable Functions でトリガーされる関数を除いて (これらは、関数独自のグループ内でスケーリングされます)、各関数は個別にスケーリングされます。 詳細については、「関数ごとのスケーリング」を参照してください。 これらのインスタンスは、要求のコンカレンシーに基づいてスケーリングされます。
Premium プラン: Premium プランの特定のサイズによって、そのインスタンス上のそのプラン内のすべてのアプリで使用できるメモリと CPU が決定されます。 このプランでは、プラン内のアプリのスケーリング ニーズに基づいてインスタンスがスケールアウトされ、アプリは必要に応じてプラン内でスケーリングされます。
関数コード ファイルは、関数のメイン ストレージ アカウントの Azure Files 共有に格納されます。 関数アプリのメイン ストレージ アカウントを削除すると、関数コード ファイルは削除され、復元できません。
実行時のスケーリング
Azure Functions は "スケール コントローラー" と呼ばれるコンポーネントを使用して、イベント レートを監視し、スケールアウトとスケールインのどちらを実行するかを決定します。 スケール コントローラーは、トリガーの種類ごとにヒューリスティックを使用します。 たとえば、Azure Queue ストレージ トリガーを使用している場合は、ターゲットベースのスケーリングが使用されます。
Azure Functions のスケールの単位は関数アプリです。 関数アプリがスケールアウトするときは、Azure Functions ホストの複数のインスタンスを実行するためのリソースが追加で割り当てられます。 反対に、コンピューティングの需要が減ると、スケール コントローラーにより、関数ホストのインスタンスが削除されます。 関数アプリ内でどの関数も実行されていない場合、インスタンスの数は 最終的に "スケールイン" されます。
コールド スタート
関数アプリが数分間アイドル状態になった場合、プラットフォームによって、アプリを実行するインスタンスの数をゼロにスケールダウンすることが決定される可能性があります。 次の要求には、0 から 1 へのスケーリングの待機時間が追加されています。 この待機時間は、"コールド スタート"と呼ばれます。 関数アプリに必要な依存関係の数がコールド スタート時間に影響を与える場合があります。 コールド スタートは、応答を返す必要がある HTTP トリガーなどの同期操作においてよりいっそう問題です。 コールド スタートが関数に影響を与えている場合は、従量課金以外のプランの使用を検討します。 他のプランは、コールド スタートを軽減または排除する戦略を提供します。
Premium プラン: 少なくとも 1 つのインスタンスで、事前ウォーミングされたインスタンスと常時使用可能なインスタンスの両方をサポートします。
Flex 従量課金プラン: オプションで設定された数の常時使用可能なインスタンスをサポートします。この数は、インスタンスごとのスケーリングに基づいて定義できます。
専用プラン: プラン自体で動的にスケーリングされることはありませんが、Always on 設定を有効にすると、継続的に実行できます。
スケーリングの動作について
スケーリングはさまざまな要因に基づいて異なる可能性があり、アプリは、選択したトリガーと言語に基づいて異なる方法でスケーリングします。 スケーリング動作には、注意が必要な複雑な作業がいくつかあります。
- 最大インスタンス数: 1 つの関数アプリがスケールアウトされるのは、プランごとに許可された最大数までのみとなります。 ただし、単一のインスタンスで一度に複数のメッセージまたは要求を処理できます。 必要な場合は最大値を下げてスケーリングを制限できます。
- 新しいインスタンスの頻度: HTTP トリガーの場合、新しいインスタンスは最大で 1 秒間に 1 回割り当てられます。 HTTP 以外のトリガーの場合、新しいインスタンスは最大で 30 秒ごとに 1 回割り当てられます。 Premium プランで実行しているときは、スケーリングが速くなります。
- ターゲットベースのスケーリング: ターゲットベースのスケーリングにより、高速で直感的なスケーリング モデルがお客様に提供されます。このスケーリングは、現在、Service Bus のキューとトピック、Storage キュー、Event Hubs、Apache Kafka、Azure Cosmos DB 拡張機能でサポートされています。 必ずターゲットベースのスケーリングを確認して、スケーリングの動作を理解するようにしてください。
- 関数ごとのスケーリング: 注意が必要ないくつかの例外を除き、Flex 従量課金プランで実行される関数は、独立したインスタンスでスケーリングされます。 この例外としては、HTTP トリガーと BLOB ストレージ (Event Grid) トリガーがあります。 これらの種類のトリガーはそれぞれ、同じインスタンスでグループとしてまとめてスケーリングされます。 同様に、すべての Durable Functions トリガーでもインスタンスが共有され、まとめてスケーリングされます。 詳細については、「関数ごとのスケーリング」を参照してください。
- 監視対象トリガーの最大数: 現在、スケール コントローラーがスケーリングの判断を行うために監視できるトリガーの最大数は 100 個です。 アプリに 100 を超えるイベントベース トリガーが存在する場合、スケールの判断は、実行される最初の 100 個のトリガーのみに基づいて行われます。 詳細については、「スケーラブル アプリのベスト プラクティスとパターン」を参照してください。
スケールアウトを制限する
アプリでスケールアウトに使用できるインスタンスの最大数を制限することを決定する場合があります。これは、データベースなどのダウンストリーム コンポーネントのスループットに制限があるケースで最も一般的です。 さまざまなホスティング プランを実行する場合の最大スケール制限については、スケールの制限に関するページを参照してください。
Flex 従量課金プラン
既定では、Flex 従量課金プランで実行されるアプリには、全体で 100 インスタンスの制限があります。 現在、最大インスタンス数の下限値は 40 であり、サポートされている最大インスタンス数の上限値は 1000 です。
az functionapp create コマンドを使用して、Flex 従量課金プランで関数アプリを作成する場合、--maximum-instance-count パラメーターを使用して、アプリのこの最大インスタンス数を設定します。
Flex Consumption アプリの最大インスタンス数は最大 1000 まで変更できますが、その数に達する前にアプリはクォータ制限に達することに注意してください。 詳細については、「リージョン サブスクリプション メモリ クォータ」を参照してください。
次の例では、最大インスタンス数を 200 に設定してアプリを作成します。
az functionapp create --resource-group <RESOURCE_GROUP> --name <APP_NAME> --storage <STORAGE_ACCOUNT_NAME> --runtime <LANGUAGE_RUNTIME> --runtime-version <RUNTIME_VERSION> --flexconsumption-location <REGION> --maximum-instance-count 200
次の例では、az functionapp scale config set コマンドを使用して、既存のアプリの最大インスタンス数を 150 に変更します。
az functionapp scale config set --resource-group <RESOURCE_GROUP> --name <APP_NAME> --maximum-instance-count 150
従量課金または Premium プラン
従量課金または Elastic Premium プランでは、functionAppScaleLimit サイトの構成設定の値を変更して、アプリの最大インスタンス数をより少ない値に指定できます。
functionAppScaleLimit は、0 または null (無制限の場合)、あるいは 1 とアプリの最大値の間の有効な値に設定できます。
az resource update --resource-type Microsoft.Web/sites -g <RESOURCE_GROUP> -n <FUNCTION_APP-NAME>/config/web --set properties.functionAppScaleLimit=<SCALE_LIMIT>
スケールインの動作
イベントドリブン スケーリングを使うと、関数に対する需要が減少したときに、自動的に容量を削減できます。 これを行うには、現在の関数実行のインスタンスをドレインし、それらのインスタンスを削除します。 この動作はドレイン モードとしてログに記録されます。 現在実行中の関数の猶予期間を、従量課金プラン アプリの場合は最大 10 分まで、Flex 従量課金アプリおよび Premium プラン アプリの場合は最大 60 分まで延長できます。 イベントドリブン スケーリングとこの動作は、Dedicated プランのアプリには適用されません。
スケールイン動作には、次の考慮事項が適用されます。
- Windows で実行される従量課金プランのアプリの場合、2021 年 5 月よりも後に作成されたアプリのみについて、既定でドレイン モード動作が有効になります。
- Service Bus トリガーを使う関数の正常なシャットダウンを有効にするには、バージョン 4.2.0 以降の Service Bus 拡張機能を使います。
関数ごとのスケーリング
Flex 従量課金プランにのみ適用されます。
Flex 従量課金プランは、"関数ごとのスケーリング" 動作を実装するという点で独特です。 関数ごとのスケーリングでは、HTTP トリガー、BLOB (Event Grid) トリガー、Durable Functions を除き、アプリ内の他のすべての種類の関数トリガーが、独立したインスタンスでスケーリングされます。 すべての BLOB (Event Grid) および独自の共有インスタンスを持つすべての Durable Functions トリガーと同様、アプリ内の HTTP トリガーはすべて、同じインスタンスでグループとしてまとめてスケーリングされます。
Flex 従量課金プランでホストされ、次の関数が含まれている関数アプリについて考えてみましょう。
| function1 | function2 | function3 | function4 | function5 | function6 | function7 |
|---|---|---|---|---|---|---|
| HTTP トリガー | HTTP トリガー | オーケストレーション トリガー (Durable) | アクティビティ トリガー (Durable) | Service Bus トリガー | Service Bus トリガー | Event Hubs トリガー |
次の点に注意してください。
- HTTP でトリガーされる 2 つの関数 (
function1とfunction2) は両方とも、独自のインスタンスでまとめて実行され、HTTP コンカレンシー設定 に従ってまとめてスケーリングされます。 - 2 つの Durable 関数 (
function3とfunction4) は両方とも独自のインスタンスでまとめて実行され、構成されたコンカレンシー スロットルに基づいてまとめてスケーリングされます。 - Service Bus でトリガーされる関数
function5は、独自に実行され、Service Bus キューとトピックのターゲットベースのスケーリング規則に従って、独立してスケーリングされます。 - Service Bus でトリガーされる関数
function6は、独自に実行され、Service Bus キューとトピックのターゲットベースのスケーリング規則に従って、独立してスケーリングされます。 - Event Hubs トリガー (
function7) は独自のインスタンスで実行され、Event Hubs のターゲットベースのスケーリング規則に従って、独立してスケーリングされます。
スケーラブルなアプリのベスト プラクティスとパターン
関数アプリには、ホスト構成、ランタイム フットプリント、リソース効率など、そのスケーリング方法に影響を与える多くの側面があります。 詳細については、パフォーマンスの考慮事項に関する記事のスケーラビリティのセクションをご覧ください。 関数アプリがスケールするにつれて、接続がどのように変化するかを認識する必要もあります。 詳細については、「How to manage connections in Azure Functions」(Azure Functions で接続を管理する方法) を参照してください。
アプリ内のイベントベース トリガーを使用する関数が 100 を超える場合は、アプリを 1 つ以上のアプリに分割し、各アプリのイベントベース関数の数を 100 未満にすることを検討してください。
Python と Node.js のスケールインの詳細については、「Azure Functions の Python 開発者向けガイド - スケーリングとコンカレンシー」および Azure Functions Node.js 開発者ガイド - スケーリングとコンカレンシーに関するページを参照してください。
次のステップ
詳細については、以下の記事をお読みください。