Azure Functions でのイベント ドリブン スケーリング
従量課金プランと Premium プランでは、Azure Functions は、Functions ホストのインスタンスを追加することによって CPU およびメモリ リソースをスケーリングします。 インスタンスの数は、関数をトリガーするイベントの数に基づいて決定されます。
従量課金プランの Functions ホストの各インスタンスは、通常、1.5 GB のメモリと 1 個の CPU に制限されています。 ホストのインスタンスは関数アプリ全体です。つまり、関数アプリ内のすべての関数がインスタンス内のリソースを共有し、同時にスケールされます。 同じ従量課金プランを共有する関数アプリは、独立にスケーリングされます。 Premium プランでは、プランのサイズによって、そのインスタンス上のそのプランのすべてのアプリで使用可能なメモリと CPU が決定されます。
関数コード ファイルは、関数のメイン ストレージ アカウントの Azure Files 共有に格納されます。 関数アプリのメイン ストレージ アカウントを削除すると、関数コード ファイルは削除され、復元できません。
実行時のスケーリング
Azure Functions は "スケール コントローラー" と呼ばれるコンポーネントを使用して、イベント レートを監視し、スケールアウトとスケールインのどちらを実行するかを決定します。 スケール コントローラーは、トリガーの種類ごとにヒューリスティックを使用します。 たとえば、Azure Queue ストレージ トリガーを使用している場合は、ターゲットベースのスケーリングが使用されます。
Azure Functions のスケールの単位は関数アプリです。 関数アプリがスケールアウトするときは、Azure Functions ホストの複数のインスタンスを実行するためのリソースが追加で割り当てられます。 反対に、コンピューティングの需要が減ると、スケール コントローラーにより、関数ホストのインスタンスが削除されます。 関数アプリ内でどの関数も実行されていない場合、インスタンスの数は 最終的に "スケールイン" されます。
コールド スタート
関数アプリが数分の間アイドル状態になると、プラットフォームによって、アプリが実行されるインスタンスの数が 0 にスケール ダウンされる可能性があります。 次の要求には、0 から 1 へのスケーリングの待機時間が追加されています。 この待機時間は、"コールド スタート"と呼ばれます。 関数アプリに必要な依存関係の数がコールド スタート時間に影響を与える場合があります。 コールド スタートは、応答を返す必要がある HTTP トリガーなどの同期操作においてよりいっそう問題です。 コールド スタートが関数に影響を与えている場合は、[常時接続] 設定を有効にして Premium プランまたは専用プランで実行することを検討してください。
スケーリングの動作について
スケーリングはさまざまな要因に基づいて異なる可能性があり、アプリは、選択したトリガーと言語に基づいて異なる方法でスケーリングします。 スケーリング動作には、注意が必要な複雑な作業がいくつかあります。
- 最大インスタンス数: 1 つの関数アプリがスケールアウトされるのは、プランごとに許可された最大数までのみとなります。 1 つのインスタンスで一度に複数のメッセージや要求を処理できるので、同時実行の数に上限は設定されていません。 必要な場合は最大値を下げてスケーリングを制限できます。
- 新しいインスタンスの頻度: HTTP トリガーの場合、新しいインスタンスは最大で 1 秒間に 1 回割り当てられます。 HTTP 以外のトリガーの場合、新しいインスタンスは最大で 30 秒ごとに 1 回割り当てられます。 Premium プランで実行しているときは、スケーリングが速くなります。
- ターゲットベースのスケーリング: ターゲットベースのスケーリングにより、高速で直感的なスケーリング モデルがお客様に提供されます。現在、Service Bus のキューとトピック、Storage キュー、Event Hubs、Cosmos DB 拡張機能でサポートされています。 ターゲットベースのスケーリングを確認して、スケーリングの動作を理解するようにしてください。
スケールアウトを制限する
スケールアウトするために使用されるアプリのインスタンスの最大数を制限したい場合があります。これは、データベースなどのダウンストリーム コンポーネントのスループットに制限があるケースで最も一般的です。 既定では、従量課金プランの関数は最大 200 インスタンスにスケールアウトし、Premium プランの関数は最大 100 インスタンスにスケールアウトします。 特定のアプリで最大値を下げるには、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 分、Premium プランのアプリでは最長 60 分まで延長できます。 イベントドリブン スケーリングとこの動作は、Dedicated プランのアプリには適用されません。
スケールイン動作には、次の考慮事項が適用されます。
- Windows 上で動作する従量課金プランの関数アプリの場合、2021 年 5 月よりも後に作成されたアプリのみについて、既定でドレイン モード動作が有効になります。
- Service Bus トリガーを使う関数の正常なシャットダウンを有効にするには、バージョン 4.2.0 以降の Service Bus 拡張機能を使います。
スケーラブルなアプリのベスト プラクティスとパターン
関数アプリには、ホスト構成、ランタイム フットプリント、リソース効率など、そのスケーリング方法に影響を与える多くの側面があります。 詳細については、パフォーマンスの考慮事項に関する記事のスケーラビリティのセクションをご覧ください。 関数アプリがスケールするにつれて、接続がどのように変化するかを認識する必要もあります。 詳細については、「How to manage connections in Azure Functions」(Azure Functions で接続を管理する方法) を参照してください。
Python と Node.js のスケールインの詳細については、「Azure Functions の Python 開発者向けガイド - スケーリングとコンカレンシー」および Azure Functions Node.js 開発者ガイド - スケーリングとコンカレンシーに関するページを参照してください。
課金モデル
各プランの課金の詳細については、Azure Functions の価格に関するページを参照してください。 使用量は Function App レベルで集計され、関数コードが実行されている期間のみカウントされます。 課金の単位は、次のとおりです。
- ギガバイト/秒 (GB/秒) 単位でのリソース使用量。 メモリ サイズと、関数アプリ内の全関数の実行時間の組み合わせとして計算されます。
- 実行回数。 イベント トリガーに応じて関数が実行されるたびにカウントされます。
従量課金の請求を理解する方法についての便利なクエリと情報については、請求に関する FAQ をご覧ください。
次のステップ
詳細については、以下の記事をお読みください。