Azure Functions Elastic Premium プランは、関数アプリの動的スケール ホスティング オプションです。 その他のホスティング プラン オプションについては、 Azure Functions のホスティング オプションに関するページを参照してください。
重要
Azure Functions は Azure App Service プラットフォームで実行できます。 App Service プラットフォームでは、Premium プラン関数アプリをホストするプランは Elastic Premium プランと呼ばれ、sku 名は EP1 と呼ばれます。 Premium プランで関数アプリを実行することを選択した場合、EP1 のように "E" で始まる SKU 名を持つプランを必ず作成してください。
P1V2 (Premium V2 Small プラン) など、"P" で始まる App Service プラン SKU 名は、実際には専用ホスティング プランです。 Dedicated であり、Elastic Premium ではないため、"P" で始まる SKU 名のプランは動的にスケールせず、コストが増えることがあります。
プレミアム プランのホスティングには、次の利点があります。
- コールド スタートを回避する "常時使用可能" および "事前ウォーミングされた" インスタンス
- 仮想ネットワーク接続
- より長いランタイム期間のサポート
- Premium インスタンス サイズの選択
- 従量課金プランと比較して、より予測可能な価格
- 複数の関数アプリを含むプランにおける高密度アプリ配置
- Linux コンテナーのデプロイのサポート
Premium プランを使用すると、 Flex 従量課金 プランや 従量課金プランと同様に、受信イベントの数に基づいて Azure Functions ホストのインスタンスが追加および削除されます。 複数の Function App を同じ Premium プランにデプロイできます。プランでは、コンピューティング インスタンス サイズ、基本プラン サイズ、および最大プラン サイズを構成できます。
課金
Premium プランの課金は、インスタンス全体にわたって割り当てられたコア秒数とメモリに基づいています。 この課金は、1 秒あたりのリソースの使用量と実行回数に基づいて課金される従量課金プランとは異なります。 Premium プランの場合、実行料金は発生しません。 この課金では、関数がアクティブまたは待機状態であるかに関係なく、利用中のプランあたりの最小月額コストが発生します。 Premium プランのすべての Function App で割り当てられたインスタンスが共有されることにご注意ください。 詳細については、 Azure Functions の価格に関するページを参照してください。
注意
すべての Premium プランには、常に 1 つ以上のアクティブな (課金された) インスタンスがあります。
Premium プランを作成する
Azure portal で関数アプリを作成する場合は、従量課金プランが既定になります。 Premium プランで実行される関数アプリを作成するには、 Elastic 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 つの Always Ready インスタンスに対して課金されますが、予約済みインスタンスは割り当てられていないため、予約済みインスタンスに対しては課金されません。
- アプリケーションが 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 Functions と仮想ネットワークの統合」を参照してください。
高速エラスティック スケール
従量課金プランと同じ高速スケーリング ロジックを使用して、より多くのコンピューティング インスタンスが自動的にアプリのために追加されます。 同じ 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 分後にワーカーのシャットダウンが発生する可能性があります。
- スロット スワップは、スワップ 中にソース スロットとターゲット スロットでの実行を終了できます。
移行
既存の関数アプリがある場合、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ギガバイト | 250 GB |
| EP2の | 2 | 7ギガバイト | 250 GB |
| EP3の | 4 | 14ギガバイト | 250 GB |
メモリ使用量に関する考慮事項
メモリの多いコンピューターでお使いの Function App を実行しても、利用可能なすべてのメモリを使用できるとは限りません。
たとえば、JavaScript Function App には、Node.js の既定のメモリ上限の制限があります。 この固定のメモリ制限を増やすには、値に languageWorkers:node:arguments を使用して --max-old-space-size=<max memory in MB> のアプリ設定を追加します。
また、メモリが 4 GB を超えるプランの場合は、[全般設定] で [Bitness Platform Setting]\(ビットネス プラットフォーム設定\) が 64 Bit に設定されていることを確認 します。
リージョン最大スケール アウト
次の表に、各リージョンと OS 構成で現在サポートされている 1 つのプランの最大スケールアウト値を示します。
| リージョン | ウィンドウズ | 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 | 六十 |
| ドイツ中西部 | 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 | 100 |
| 英国南部 | 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 |
詳細については、「 リージョン別に利用可能な製品」を参照してください。