Azure Functions の Premium プラン

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

プレミアム プランのホスティングには、次の利点があります。

• コールド スタートを回避する "常時使用可能" および "事前ウォーミングされた" インスタンス
• 仮想ネットワーク接続
• より長いランタイム期間のサポート
• Premium インスタンス サイズの選択
• 従量課金プランと比較して、より予測可能な価格
• 複数の関数アプリを含むプランにおける高密度アプリ配置
• Linux コンテナーのデプロイのサポート

Premium プランを使用する場合は、 Flex 従量課金プラン や 従量課金プランと同様に、受信イベントの数に基づいて Azure Functions ホストのインスタンスを追加および削除します。 複数の関数アプリを同じ Premium プランにデプロイできます。 コンピューティング インスタンスのサイズ、基本プラン サイズ、および最大プラン サイズを構成できます。

課金

Premium プランの料金は、インスタンス間で割り当てられたコア秒数とメモリに基づいて行われます。 この課金モデルは、1 秒あたりのリソース使用量と実行に基づいて課金される従量課金プランとは異なります。 Premium プランには実行料金はありません。 この課金モデルでは、関数がアクティブであるかアイドル状態であるかに関係なく、アクティブなプランあたりの最小月額コストが発生します。 Premium プラン内のすべての関数アプリは、割り当てられたインスタンスを共有します。 詳細については、Azure Functions の価格に関するページを参照してください。

Premium プランを作成する

Azure portal で関数アプリを作成する場合は、従量課金プランが既定になります。 Premium プランで実行される関数アプリを作成するには、 Elastic Premium バージョンのいずれかを使用して、Azure Functions Premium ホスティング プランを明示的に作成または選択する必要があります。 このプランで作成した関数アプリをホストします。 Azure portal を使用すると、Premium プランと Function App の両方を同時に簡単に作成できます。 同じ Premium プランで複数の関数アプリを実行できますが、どちらも同じオペレーティング システム (Windows または Linux) で実行する必要があります。

次の記事では、Premium プランを使用してプログラムで関数アプリを作成する方法について説明します:

• Azure CLI
• Azure Resource Manager テンプレート

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

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

Premium プランには、機能のコールド スタートを効果的に排除するために連携する 2 つの機能が用意されています。 常に準備が整っているインスタンス と 、事前に予約されたインスタンスです。 Always Ready インスタンスは、スケーリングの影響を受けない事前割り当て済みインスタンスのカテゴリであり、事前に予約されたインスタンスは、HTTP イベントのためにスケーリングする際のバッファーです。

イベントがアプリをトリガーし始めると、システムはまず、常に準備が整ったインスタンスにイベントをルーティングします。 HTTP イベントが原因で関数がアクティブになると、他のインスタンスはバッファーとしてウォームされます。 これらのバッファーに格納されたインスタンスは、事前ウォーミングされたインスタンスと呼ばれます。 このバッファーによって、スケール中に要求された新しいインスタンスのコールド スタートが減少します。

常時使用可能なインスタンス

Premium プランでは、指定された数のインスタンスでアプリを常時使用可能にしておくことができます。 アプリは、負荷に関係なく、これらのインスタンスで継続的に実行されます。 読み込みが常時稼働しているインスタンスが処理できる量を超えた場合、アプリは指定した最大値までインスタンスを自動的に追加します。

このアプリ レベルの設定で、プランの最小インスタンスも制御されます。 たとえば、同じ Premium プランの 3 つの関数アプリについて考えてみましょう。 2 つのアプリのインスタンス数が常に 1 に設定されていて、3 つ目のアプリが 5 に設定されている場合、プラン全体の最小数は 5 です。 この数には、プランが課金されるインスタンスの最小数も反映されます。 アプリごとにサポートされている常時対応インスタンスの最大数は 20 です。

az functionapp update -g <RESOURCE_GROUP> -n <FUNCTION_APP_NAME> --set siteConfig.minimumElasticInstanceCount=<YOUR_ALWAYS_READY_COUNT>

$Resource = Get-AzResource -ResourceGroupName <RESOURCE_GROUP> -ResourceName <FUNCTION_APP_NAME>/config/web -ResourceType Microsoft.Web/sites
$Resource.Properties.minimumElasticInstanceCount = <YOUR_ALWAYS_READY_COUNT>
$Resource | Set-AzResource -Force

事前ウォーミングされたインスタンス

事前ウォーミングされたインスタンス数の設定により、HTTP スケールおよびアクティブ化イベント中に、ウォーミングされたインスタンスがバッファーとして提供されます。 事前ウォーミングされたインスタンスは、スケールアウトの上限に達するまでバッファーに格納され続けます。 既定の事前予約インスタンス数は 1 であり、ほとんどのシナリオでは、この値を 1 のままにします。

カスタム コンテナーで実行されているアプリなど、あまり一般的でないシナリオを考えてみましょう。 カスタム コンテナーには長いウォームアップ時間があるため、この予約済みインスタンスのバッファーを増やすことを検討してください。 事前ウォーミングされたインスタンスは、すべてのアクティブなインスタンスが使用中になった後にのみ、アクティブになります。

また、事前ウォーミング プロセス中に実行されるウォームアップ トリガーを定義することもできます。 ウォームアップ トリガーを使用して、事前ウォームアップ プロセスの間にカスタムの依存関係を事前に読み込み、関数をすぐに要求の処理を開始できる状態にすることができます。 詳細については、 Azure Functions ウォームアップ トリガーに関するページを参照してください。

この例では、常に準備が整っているインスタンスと事前に準備されたインスタンスがどのように連携するかを示します。 Premium 関数アプリに、2 つの常時使用可能なインスタンスが構成されており、事前ウォーミングされたインスタンスが既定で 1 つあります。

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

az functionapp update -g <RESOURCE_GROUP> -n <FUNCTION_APP_NAME> --set siteConfig.preWarmedInstanceCount=<YOUR_PREWARMED_COUNT>

$Resource = Get-AzResource -ResourceGroupName <RESOURCE_GROUP> -ResourceName <FUNCTION_APP_NAME>/config/web -ResourceType Microsoft.Web/sites
$Resource.Properties.preWarmedInstanceCount = <YOUR_PREWARMED_COUNT>
$Resource | Set-AzResource -Force

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

プランの最大バースト数に加えて、アプリごとの最大値を構成できます。 アプリの上限を構成するには、 アプリのスケール制限を使用します。 アプリのスケールアウトの上限は、プランの最大バースト インスタンスを超えることはできません。

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

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

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

詳細については、「 Azure Functions と仮想ネットワークの統合」を参照してください。

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

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

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

実行継続時間の延長

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

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

移行

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

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

Premium プランの設定

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

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

az functionapp plan update -g <RESOURCE_GROUP> -n <PREMIUM_PLAN_NAME> --max-burst <YOUR_MAX_BURST>

Update-AzFunctionAppPlan -ResourceGroupName <RESOURCE_GROUP> -Name <PREMIUM_PLAN_NAME> -MaximumWorkerCount <YOUR_MAX_BURST> -Force

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

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

az functionapp plan update -g <RESOURCE_GROUP> -n <PREMIUM_PLAN_NAME> --min-instances <YOUR_MIN_INSTANCES>

Update-AzFunctionAppPlan -ResourceGroupName <RESOURCE_GROUP> -Name <PREMIUM_PLAN_NAME> -MinimumWorkerCount <YOUR_MIN_INSTANCES> -Force

利用可能インスタンス SKU

プランを作成またはスケーリングするときは、3 つのインスタンス サイズから選択します。 プロビジョニングしたコアとメモリの合計数に対して、割り当てられたインスタンスごとに 1 秒あたりに課金されます。 アプリは必要に応じて自動的に複数のインスタンスにスケール アウトできます。

メモリ使用量に関する考慮事項

メモリの多いコンピューターでお使いの 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 つのプランの最大スケールアウト値を示します。

詳細については、「 リージョン別に利用可能な製品」を参照してください。

関連コンテンツ

• Azure Functions のホスティング オプションについて
• Azure Functions でのイベント ドリブンスケーリング