Azure Functions の Premium プラン
Azure Functions Elastic Premium プランは、関数アプリの動的スケール ホスティング オプションです。 その他のホスティング プラン オプションについては、ホスティング プランの記事を参照してください。
重要
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 名のプランは動的にスケールせず、コストが増えることがあります。
Premium プランのホスティングでは、関数に次の利点があります。
- インスタンスをウォーム状態に維持することでコールド スタートを回避します。
- 仮想ネットワーク接続。
- より長いランタイム期間をサポートします。
- Premium インスタンス サイズの選択。
- 従量課金プランと比較して、予測可能な料金。
- 複数の Function App を含むプランでの高密度アプリ割り当て。
- Linux コンテナーのデプロイをサポートします。
Premium プランを使用すると、従量課金プランと同じように、Azure Functions ホストのインスタンスが、受信イベントの数に基づいて追加および削除されます。 複数の Function App を同じ Premium プランにデプロイできます。プランでは、コンピューティング インスタンス サイズ、基本プラン サイズ、および最大プラン サイズを構成できます。
課金
Premium プランの課金は、インスタンス全体にわたって割り当てられたコア秒数とメモリに基づいています。 この課金は、1 秒あたりのリソースの使用量と実行回数に基づいて課金される従量課金プランとは異なります。 Premium プランの場合、実行料金は発生しません。 この課金の結果として、関数がアクティブかアイドル状態かに関係なく、アクティブなプラン別の月間コストが最も少なくなります。 Premium プランのすべての Function App で割り当てられたインスタンスが共有されることにご注意ください。 詳しくは、「Azure Functions の価格」ページをご覧ください。
注意
すべての Premium プランには、常に 1 つ以上のアクティブな (課金された) インスタンスがあります。
Premium プランを作成する
Azure portal で関数アプリを作成する場合は、従量課金プランが既定になります。 Premium プランで実行される関数アプリを作成するには、いずれかの "エラスティック Premium" SKU を使用して Azure Functions Premium ホスティング プランを明示的に作成または選択する必要があります。 作成した Function App は、このプランでホストされます。 Azure portal を使用すると、Premium プランと Function App の両方を同時に簡単に作成できます。 同じ Premium プランで複数の関数アプリを実行できますが、どちらも同じオペレーティング システム (Windows または Linux) で実行する必要があります。
次の記事では、Premium プランを使用してプログラムで関数アプリを作成する方法について説明します:
コールド スタートを排除する
従量課金プランでイベントも実行も発生しないときは、ゼロ インスタンスまでアプリをスケールインできます。 新しいイベントが発生したら、アプリの実行先となる新しいインスタンスを専用化する必要があります。 アプリによっては、新しいインスタンスの専用化に時間がかかります。 最初の呼び出しでこのように余分の待機時間が発生することを、アプリの "コールド スタート" と呼ぶことがよくあります。
Premium プランには、関数のコールド スタートを効果的に排除するために連携する、"常時使用可能なインスタンス" と "事前ウォーミングされたインスタンス" という 2つの機能が用意されています。 常時使用可能なインスタンスとは、スケーリングの影響を受けない事前割り当て済みインスタンスのカテゴリのことです。事前ウォーミングされたインスタンスとは、HTTP イベントが原因でスケーリングする際のバッファーのことです。
イベントがアプリのトリガーを開始すると、そのイベントは最初に常時使用可能なインスタンスにルーティングされます。 HTTP イベントによって関数がアクティブになると、その他のインスタンスがバッファーとしてウォーミングされます。 これらのバッファーに格納されたインスタンスは、事前ウォーミングされたインスタンスと呼ばれます。 このバッファーによって、スケール中に要求された新しいインスタンスのコールド スタートが減少します。
常時使用可能なインスタンス
Premium プランでは、指定された数のインスタンスでアプリを常時使用可能にしておくことができます。 アプリは、負荷に関係なく、これらのインスタンスで継続的に実行されます。 常時使用可能なインスタンスで処理できる以上の負荷が発生すると、より多くのインスタンスが、指定した最大値まで必要に応じて追加されます。
このアプリ レベルの設定で、プランの最小インスタンスも制御されます。 たとえば、同じ Premium プランに 3 つの関数アプリがあるとします。 2 つのアプリで常時使用可能なインスタンス数が 1 に設定され、3 つ目のインスタンスでは常時使用可能が 5 に設定されている場合、プラン全体の最小数は 5 です。 この設定には、プランの課金対象となるインスタンスの最小数も反映されます。 アプリごとにサポートされる常時使用可能なインスタンスの最大数は 20 です。
Azure portal で常時使用可能なインスタンスの数を構成するには、選択した Function App から、 [プラットフォーム機能] タブへ移動して、 [スケールアウト] オプションを選択します。 Function App の編集ウィンドウでは、常時使用可能なインスタンスはそのアプリに固有のものです。
事前ウォーミングされたインスタンス
事前ウォーミングされたインスタンス数の設定により、HTTP スケールおよびアクティブ化イベント中に、ウォーミングされたインスタンスがバッファーとして提供されます。 事前ウォーミングされたインスタンスは、スケールアウトの上限に達するまでバッファーに格納され続けます。 事前ウォーミングされたインスタンスの既定の数は 1 であり、ほとんどのシナリオではこの値を 1 のままにしておく必要があります。
カスタム コンテナーで実行されているアプリなど、あまり一般的でないシナリオを考えてみましょう。 カスタム コンテナーはウォームアップが長くなるため、事前ウォーミングされたインスタンスのこのバッファーを増やすことを検討する場合があります。 事前ウォーミングされたインスタンスは、すべてのアクティブなインスタンスが使用中になった後にのみ、アクティブになります。
また、事前ウォームアップ プロセス中に実行されるウォームアップ トリガーを定義できます。 ウォームアップ トリガーを使用して、事前ウォームアップ プロセスの間にカスタムの依存関係を事前に読み込み、関数をすぐに要求の処理を開始できる状態にすることができます。 詳細については、「Azure Functions のウォームアップ トリガー」を参照してください。
常時使用可能なインスタンスと事前ウォーミングされたインスタンスが連携して動作する例について考えてみましょう。 Premium 関数アプリに、2 つの常時使用可能なインスタンスが構成されており、事前ウォーミングされたインスタンスが既定で 1 つあります。
- アプリがアイドル状態であり、トリガーしているイベントがない場合、このアプリは 2 つのインスタンスでプロビジョニングされ、実行されます。 この時点では、2 つの常時使用可能なインスタンスに対して課金されますが、事前ウォーミングされたインスタンスは割り当てられていないため、事前ウォーミングされたインスタンスに対しては課金されません。
- アプリケーションが HTTP トラフィックを受信し始めると、それら 2 つの常時使用可能なインスタンス間で要求が負荷分散されます。 これら 2 つのインスタンスがイベントの処理を開始するとすぐに、インスタンスが追加されて、事前ウォーミングされたバッファーに格納されます。 この時点で、アプリは 3 つのプロビジョニングされたインスタンスを使用して実行されています。2 つの常時使用可能なインスタンスと、3 番目の事前ウォーミングされた非アクティブなバッファーです。 これら 3 つのインスタンスに対して課金されます。
- 負荷が増加し、HTTP トラフィックを処理するためにアプリで必要とされるインスタンスが増えると、その事前ウォーミングされたインスタンスがアクティブ インスタンスにスワップされます。 これで、HTTP 負荷は 3 つのインスタンスすべてにルーティングされることになり、4 番目のインスタンスがすぐにプロビジョニングされ、事前ウォーミングされたバッファーに格納されます。
- この一連のスケーリングと事前ウォーミングは、アプリの最大インスタンス数に達するか、負荷が減少して、一定期間後にプラットフォームがスケールインするまで続きます。 最大値を超えてインスタンスが事前ウォーミングまたはアクティブ化されることはありません。
事前ウォーミングされたインスタンス数の設定は、ポータルでは変更できません。代わりに、Azure CLI か Azure PowerShell を使用する必要があります。
Function App のインスタンスの最大数
プランの最大バースト数に加えて、アプリごとの最大数を構成できます。 アプリの最大数は、アプリのスケール制限を使用して構成できます。 アプリのスケールアウト制限の上限は、プランの最大バースト インスタンス数を超えることはできません。
プライベート ネットワーク接続
Premium プランにデプロイされた関数アプリでは、Web アプリ向けの仮想ネットワーク統合を利用できます。 構成すると、アプリを仮想ネットワーク内のリソースと通信させる、またはサービス エンドポイントを介してセキュリティで保護することができます。 受信トラフィックを制限するための IP 制限もアプリで利用できます。
Premium プランで Function App にサブネットを割り当てるときは、個々の潜在的インスタンスのための十分な IP アドレスがあるサブネットが必要です。 使用可能なアドレスが 100 以上の IP ブロックが必要です。
詳細については、お使いの関数アプリと仮想ネットワークの統合に関するページを参照してください。
高速エラスティック スケール
従量課金プランと同じ高速スケーリング ロジックを使用して、より多くのコンピューティング インスタンスが自動的にアプリのために追加されます。 同じ Azure App Service のアプリは、個々のアプリのニーズに基づき、互いに依存せずにスケーリングします。 ただし、同じ Azure App Service の Function App では、可能であれば、コストを下げる目的で VM リソースが共有されます。 VM に関連付けられているアプリの数は、各アプリの占有領域と VM のサイズによって変わります。
スケーリングのしくみの詳細については、「Azure Functions でのイベント ドリブン スケーリング」を参照してください。
実行継続時間の延長
Functions の従量課金プランでは、1 回の実行が 10 分までに制限されています。 Premium プランでは、実行中の暴走を防ぐために、実行継続時間の既定値が 30 分になっています。 ただし、host.json 構成を変更して、Premium プランのアプリの継続時間を無制限にすることができます。ただし、次の制限があります。
- プラットフォームのアップグレードにより、マネージド シャットダウンがトリガーされ、関数の実行が 10 分の猶予期間で停止する可能性があります。
- 新しい実行がない状態で 60 分経つと worker を停止するアイドル タイマーがあります。
- スケールイン動作により、60 分後に worker のシャットダウンが発生する可能性があります。
- スロットのスワップにより、スワップ中にソース スロットとターゲット スロットの実行が終了される可能性があります。
移行
既存の関数アプリがある場合、Windows では、Azure CLI コマンドを使用して、従量課金プランと Premium プランの間でアプリを移行できます。 具体的なコマンドは、移行の方向によって異なります。 詳細については、「プランの移行」を参照してください。
この移行は Linux ではサポートされていません。
Premium プランの設定
プランを作成するときは、2 つのプラン サイズ設定があります。インスタンスの最小数 (またはプラン サイズ) と最大バースト制限です。
常時使用可能なインスタンス数を超えるインスタンスがアプリに必要な場合、インスタンスの数がプランの最大バースト制限に達するか、構成されているときはアプリの最大スケールアウト制限に達するまで、スケールアウトを続けることができます。 インスタンスに対する課金は、それらが実行されていて割り当てられている間のみ、秒単位で発生します。 定義された最大制限までのアプリのスケールアウトに関しては、プラットフォームのベスト エフォートでの提供となります。
プラン サイズまたは最大値は Azure portal で構成できます。そのプランにデプロイされている関数アプリの [設定] の下の [スケール アウト] オプションを選択します。
各 Premium プランの最小値は、少なくとも 1 インスタンスです。 実際のインスタンスの最小数は、プラン内のアプリによって要求された常時使用可能なインスタンス数に基づいて決定されます。 たとえば、アプリ A が 5 つの常時使用可能なインスタンスを要求し、同じプラン内でアプリ B が 2 つの常時使用可能なインスタンスを要求した場合、最小プラン サイズは 5 として決定されます。 アプリ A は 5 つすべてで実行されており、アプリ B は 2 つでのみ実行されています。
重要
関数が実行されているかどうかにかかわらず、最小インスタンスで割り当てられているインスタンスごとに課金されます。
ほとんどの場合、この自動計算される最小値で十分です。 ただし、最小値を超えるスケーリングはベスト エフォートで実行されます。 その他のインスタンスを使用できない場合は、まれですが、特定の時間にスケールアウトが遅延する可能性があります。 自動計算された最小値よりも大きな最小値を設定することにより、スケールアウトの前にインスタンスを予約します。
Azure portal で最小数のインスタンスを構成するには、そのプランにデプロイされた関数アプリの[設定]で [スケール アウト] オプションを選択します。
利用可能インスタンス SKU
プランを作成またはスケーリングするときは、3 つのインスタンス サイズから選択できます。 プロビジョニングされたコアとメモリの合計数に対して、各インスタンスが割り当てられている秒単位で課金されます。 アプリは必要に応じて自動的に複数のインスタンスにスケール アウトできます。
| SKU | コア | メモリ | ストレージ |
|---|---|---|---|
| EP1 | 1 | 3.5 GB | 250 GB |
| EP2 | 2 | 7 GB | 250 GB |
| EP3 | 4 | 14 GB | 250 GB |
メモリ使用量に関する考慮事項
メモリの多いコンピューターでお使いの Function App を実行しても、利用可能なすべてのメモリを使用できるとは限りません。
たとえば、JavaScript Function App には、Node.js の既定のメモリ上限の制限があります。 この固定のメモリ制限を増やすには、値に --max-old-space-size=<max memory in MB> を使用して languageWorkers:node:arguments のアプリ設定を追加します。
4 GB を超えるメモリの場合は、プラットフォームのビット設定が 64 Bit に設定されていることを [全般設定] で確認します。
リージョン最大スケール アウト
これらは、1 つのプランでサポートされている最大スケールアウト値をリージョンと OS の構成ごとにまとめたものです。
| リージョン | Windows | Linux |
|---|---|---|
| オーストラリア中部 | 100 | 20 |
| オーストラリア中部 2 | 100 | 利用不可 |
| オーストラリア東部 | 100 | 40 |
| オーストラリア南東部 | 100 | 20 |
| ブラジル南部 | 100 | 20 |
| カナダ中部 | 100 | 100 |
| インド中部 | 100 | 20 |
| 米国中部 | 100 | 100 |
| 中国東部 2 | 20 | 20 |
| 中国北部 2 | 20 | 20 |
| 中国北部 3 | 20 | 20 |
| 東アジア | 100 | 20 |
| 米国東部 | 100 | 100 |
| 米国東部 2 | 80 | 100 |
| フランス中部 | 100 | 60 |
| ドイツ中西部 | 100 | 20 |
| イスラエル中部 | 100 | 20 |
| イタリア北部 | 100 | 20 |
| 東日本 | 100 | 20 |
| 西日本 | 100 | 20 |
| JIO インド西部 | 100 | 20 |
| 韓国中部 | 100 | 20 |
| 韓国南部 | 40 | 20 |
| メキシコ中部 | 20 | 20 |
| 米国中北部 | 100 | 20 |
| 北ヨーロッパ | 100 | 100 |
| ノルウェー東部 | 100 | 20 |
| 南アフリカ北部 | 100 | 20 |
| 南アフリカ西部 | 20 | 20 |
| 米国中南部 | 100 | 100 |
| インド南部 | 100 | 利用不可 |
| 東南アジア | 100 | 20 |
| スペイン中部 | 20 | 20 |
| スイス北部 | 100 | 20 |
| スイス西部 | 100 | 20 |
| アラブ首長国連邦北部 | 100 | 20 |
| 英国南部 | 100 | 100 |
| 英国西部 | 100 | 20 |
| USGov アリゾナ | 20 | 20 |
| USGov テキサス | 20 | 利用不可 |
| USGov バージニア州 | 80 | 20 |
| 米国中西部 | 100 | 20 |
| 西ヨーロッパ | 100 | 100 |
| インド西部 | 100 | 20 |
| 米国西部 | 100 | 100 |
| 米国西部 2 | 100 | 20 |
| 米国西部 3 | 100 | 20 |
詳細については、Azure Functions のリージョン別の可用性の完全な情報に関するページをご覧ください。