Azure Functions の Premium プラン

Azure Functions Elastic Premium プランは、関数アプリの動的スケール ホスティング オプションです。 その他のホスティング プラン オプションについては、ホスティング プランの記事を参照してください。

重要

Azure Functions は Azure App Service プラットフォームで実行できます。 App Service プラットフォームでは、Premium プラン関数アプリをホストするプランは Elastic Premium プランと呼ばれており、 のような SKU 名があります。 Premium プランで関数アプリを実行することを選択した場合、EP1 のように "E" で始まる SKU 名を持つプランを必ず作成してください。 P1V2 (Premium V2 Small プラン) のように "P" で始まる App Service プラン SKU 名は実際には P1V2です。 Dedicated であり、Elastic Premium ではないため、"P" で始まる SKU 名のプランは動的にスケールせず、コストが増えることがあります。

Premium プランのホスティングでは、関数に次の利点があります。

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) で実行する必要があります。

次の記事では、プログラムまたは Azure portal のいずれかを使用して、Premium プランで Function App を作成する方法について説明しています。

コールド スタートを排除する

従量課金プランでイベントも実行も発生しないときは、ゼロ インスタンスまでアプリをスケールインできます。 新しいイベントが発生したら、アプリの実行先となる新しいインスタンスを専用化する必要があります。 アプリによっては、新しいインスタンスの専用化に時間がかかる場合があります。 最初の呼び出しでこのように余分の待機時間が発生することを、アプリの "コールド スタート" と呼ぶことがよくあります。

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 つあります。

スケール アウトのグラフ

  1. アプリがアイドル状態であり、トリガーしているイベントがない場合、このアプリは 2 つのインスタンスでプロビジョニングされ、実行されます。 この時点では、2 つの常時使用可能なインスタンスに対して課金されますが、事前ウォーミングされたインスタンスは割り当てられていないため、事前ウォーミングされたインスタンスに対しては課金されません。
  2. アプリケーションが HTTP トラフィックを受信し始めると、それら 2 つの常時使用可能なインスタンス間で要求が負荷分散されます。 これら 2 つのインスタンスがイベントの処理を開始するとすぐに、インスタンスが追加されて、事前ウォーミングされたバッファーに格納されます。 この時点で、アプリは 3 つのプロビジョニングされたインスタンスを使用して実行されています。2 つの常時使用可能なインスタンスと、3 番目の事前ウォーミングされた非アクティブなバッファーです。 これら 3 つのインスタンスに対して課金されます。
  3. 負荷が増加し、HTTP トラフィックを処理するためにアプリで必要とされるインスタンスが増えると、その事前ウォーミングされたインスタンスがアクティブ インスタンスにスワップされます。 これで、HTTP 負荷は 3 つのインスタンスすべてにルーティングされることになり、4 番目のインスタンスがすぐにプロビジョニングされ、事前ウォーミングされたバッファーに格納されます。
  4. この一連のスケーリングと事前ウォーミングは、アプリの最大インスタンス数に達するか、負荷が減少して、一定期間後にプラットフォームがスケールインするまで続きます。 最大値を超えてインスタンスが事前ウォーミングまたはアクティブ化されることはありません。

事前ウォーミングされたインスタンス数の設定は、ポータルでは変更できません。代わりに、Azure CLI か Azure PowerShell を使用する必要があります。

Function App のインスタンスの最大数

プランの最大インスタンス数に加えて、アプリごとの最大数を構成できます。 アプリの最大数は、アプリのスケール制限を使用して構成できます。

プライベート ネットワーク接続

Premium プランにデプロイされた Function App では、Web アプリ向けの VNet 統合を利用できます。 構成すると、アプリを VNet 内のリソースと通信させる、またはサービス エンドポイントを介してセキュリティで保護することができます。 受信トラフィックを制限するための IP 制限もアプリで利用できます。

Premium プランで Function App にサブネットを割り当てるときは、個々の潜在的インスタンスのための十分な IP アドレスがあるサブネットが必要です。 使用可能なアドレスが 100 以上の IP ブロックが必要です。

詳細については、お使いの Function App と VNet の統合に関するページを参照してください。

高速エラスティック スケール

従量課金プランと同じ高速スケーリング ロジックを使用して、追加のコンピューティング インスタンスが自動的にアプリのために追加されます。 同じ Azure App Service のアプリは、個々のアプリのニーズに基づき、互いに依存せずにスケーリングします。 ただし、同じ Azure App Service の Function App では、可能であれば、コストを下げる目的で VM リソースが共有されます。 VM に関連付けられているアプリの数は、各アプリの占有領域と VM のサイズによって変わります。

スケーリングのしくみの詳細については、「Azure Functions でのイベント ドリブン スケーリング」を参照してください。

実行継続時間の延長

Functions の従量課金プランでは、1 回の実行が 10 分までに制限されています。 Premium プランでは、実行中の暴走を防ぐために、実行継続時間の既定値が 30 分になっています。 ただし、host.json 構成を変更して、Premium プランのアプリの継続時間を無制限にすることができます。ただし、次の制限があります。

  • プラットフォームのアップグレードにより、マネージド シャットダウンがトリガーされ、関数の実行が停止する可能性があります。
  • プラットフォームの停止により、処理されないシャットダウンが発生し、関数の実行が停止する可能性があります。
  • 新しい実行がない状態で 60 分経つと worker を停止するアイドル タイマーがあります。
  • スケールイン動作により、60 分後に worker のシャットダウンが発生する可能性があります。
  • スロットのスワップにより、スワップ中にソース スロットとターゲット スロットの実行が終了される可能性があります。

移行

既存の関数アプリがある場合、Windows では、Azure CLI コマンドを使用して、従量課金プランと Premium プランの間でアプリを移行できます。 具体的なコマンドは、移行の方向によって異なります。 詳細については、「プランの移行」を参照してください。

この移行は Linux ではサポートされていません。

プランと SKU の設定

プランを作成するときは、2 つのプラン サイズ設定があります。インスタンスの最小数 (またはプラン サイズ) と最大バースト制限です。

常時使用可能なインスタンス数を超えるインスタンスがアプリに必要な場合、インスタンスの数が最大バースト制限に達するまでアプリのスケール アウトを続けることができます。 プラン サイズを超えたインスタンスに対する課金は、それらが実行されていて割り当てられている間のみ、秒単位で発生します。 定義された最大制限までのアプリのスケールアウトに関しては、プラットフォームのベスト エフォートでの提供となります。

プラン サイズまたは最大値は Azure portal で構成できます。そのプランにデプロイされている関数アプリの [設定] の下の [スケール アウト] オプションを選択します。

ポータルでのエラスティック プラン サイズ設定

各プランの最小値は、1 つ以上のインスタンスになります。 実際のインスタンスの最小数は、プラン内のアプリによって要求された常時使用可能なインスタンス数に基づいて自動構成されます。 たとえば、アプリ A が 5 つの常時使用可能なインスタンスを要求し、同じプラン内でアプリ B が 2 つの常時使用可能なインスタンスを要求した場合、最小プラン サイズは 5 として計算されます。 アプリ A は 5 つのすべてで実行され、アプリ B は 2 つでのみ実行されます。

重要

関数が実行されているかどうかにかかわらず、最小インスタンスで割り当てられているインスタンスごとに課金されます。

ほとんどの場合、この自動計算される最小値で十分です。 ただし、最小値を超えるスケーリングはベスト エフォートで実行されます。 追加のインスタンスを使用できない場合は、まれですが、特定の時間にスケールアウトが遅延する可能性があります。 自動計算された最小値よりも大きな最小値を設定することにより、スケールアウトの前にインスタンスを予約します。

Azure portal で最小数のインスタンスを構成するには、そのプランにデプロイされた関数アプリの[設定][Scale Out] (スケール アウト) オプションを選択します。

ポータルでの最小インスタンス設定

利用可能インスタンス 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 に設定されていることを 64 Bit で確認します。

リージョン最大スケール アウト

以下は、1 つのプランでサポートされている最大スケールアウト値をリージョンと OS の構成ごとにまとめたものです。

Functions のリージョン別の可用性の完全な情報については、Azure の Web サイトを参照してください。

リージョン Windows Linux
オーストラリア中部 100 利用不可
オーストラリア中部 2 100 利用不可
オーストラリア東部 100 40
オーストラリア南東部 100 20
ブラジル南部 100 20
カナダ中部 100 20
インド中部 100 20
米国中部 100 100
中国東部 2 100 20
中国北部 2 100 20
東アジア 100 20
米国東部 100 100
米国東部 2 100 100
フランス中部 100 60
ドイツ中西部 100 20
東日本 100 20
西日本 100 20
JIO インド西部 100 20
韓国中部 100 20
韓国南部 利用不可 20
米国中北部 100 20
北ヨーロッパ 100 100
ノルウェー東部 100 20
南アフリカ北部 100 20
米国中南部 100 100
インド南部 100 利用不可
東南アジア 100 20
スイス北部 100 20
スイス西部 100 20
アラブ首長国連邦北部 100 20
英国南部 100 100
英国西部 100 20
USGov アリゾナ 100 20
USGov テキサス 100 利用不可
USGov バージニア州 100 20
米国中西部 100 20
西ヨーロッパ 100 100
インド西部 100 20
米国西部 100 100
米国西部 2 100 20
米国西部 3 100 20

次のステップ