エンタープライズ サーバーレス ワークロード向け Azure Functions Premium プランの発表

4月 3, 2019 に投稿済み

Program Manager, Azure Functions

最新の Functions ホスティング モデルである Azure Functions Premium プランがプレビューとして提供されたことをお知らせします。このプランにより、イベントベースのスケーリングを損なうことなく、長らく要望のあった一連のスケーリングと接続性に関するオプションが有効になります。Premium プランを使用すると、事前ウォーミングされたインスタンスを使用した、アイドル後の遅延がないアプリ実行、より強力なインスタンスでの実行、VNET への接続など、これらすべてを負荷に応じて自動スケーリングしながら行うことができます。

プライベート プレビューに参加してくださった皆様に感謝したします。Symantec CorporationVolpara Solutions は、Premium プランの新機能のメリットを得られる企業のうちのほんの 2 例です。

下の表は、Microsoft の既存の動的スケーリング プランである従量課金プランと比較して、Premium プランがどの程度向上しているかを示したものです。従量課金プランと Premium プラン (プレビュー) の SKU を比較した表。

高度なスケーリング制御によるデプロイのカスタマイズ

Premium プランでは、インスタンス サイズを指定できるようになりました。最大 4 つの D シリーズ コアと 14 GB のメモリーを選択できます。これらのインスタンスは、従量課金プランを使用した場合の関数で利用できる A シリーズ インスタンスよりもかなり強力であり、個々の呼び出しで CPU またはメモリー負荷の高いワークロードをはるかに多く実行することができます。

使用できるインスタンス サイズ

EP1、EP2、および EP3 の詳細を示すインスタンス サイズのグラフィック。

Premium プランでは、最大インスタンス数を指定できるようになりました。これは最も強い要望があった機能で、Premium プランの最大スケールアウト数を制限できます。最大スケールアウト数を制限することによって、ダウンストリームのリソースが関数によって圧迫されるのを防ぎ、毎月の最大課金額を予測できるようになります。

Premium プランでは最小インスタンス数を指定することによって、予測される需要に先んじてアプリケーションを事前スケーリングすることができます。電子メール キャンペーン、セール、または時間ゲート型イベントが推測される場合、事前ウォーミングされたインスタンスを補充するよりも迅速にアプリがスケーリングされます。最小インスタンス数を増やして、事前に容量を読み込むことができます。

Microsoft では、従量課金プランと、スケジュールに従って事前ウォーミングされるインスタンスを含む Premium プランの間で任意の関数を移動するサンプル永続関数を作成しました。これを使用してコストを最適化することができます。

従量課金プランと、スケジュールに従って事前ウォーミングされるインスタンスを含む Premium プランの間で任意の関数を移動できる永続関数

Functions を VNET に接続する

Premium プランでは、動的にスケーリングする関数から VNET に接続して、プライベート ネットワーク内にあるリソースに安全にアクセスできます。この機能は、以前は、App Service プランまたは App Service Environment で Functions を実行している場合にのみ利用できましたが、Premium プランを使用することによって動的にスケーリングするモデルでも利用できるようになりました。VNET 統合の詳細については、こちらをご覧ください。

事前ウォーミングされたインスタンスによってコールド スタートを回避する

Functions Premium プランには、初めてサーバーレス アプリケーションを呼び出す際の遅延に対して、"事前ウォーミングされたインスタンス" というソリューションが用意されています。これは一般にコールド スタートと呼ばれ、サーバーレスの開発者が最もよく経験する問題の 1 つです。コールド スタートの概要とその原因の詳細については、ブログ記事「Understanding serverless cold start (サーバーレスのコールド スタートについて)」を参照してください。

Premium プランでは、コードをすぐ実行できるようにウォームな状態に維持された事前ウォーミングされたインスタンスの数を指定できます。アプリケーションをスケーリングする必要がある場合、コールド スタートにならないように、事前ウォーミングされたインスタンスがまず使用されます。アプリによって、即座に別のインスタンスがバックグラウンドで事前ウォーミングされて、事前ウォーミングされたインスタンスのバッファーが補充されます。このモデルを使用することで、アイドル状態のアプリに対する最初の要求の実行時や、各スケーリング ポイントでも遅延を回避することができます。

現在、事前ウォーミングされたインスタンスはサイトあたり 1 つしか許可されていませんが、今後数週間のうちにもっと多く利用できるようにしていく予定です。

スケーリングに使用するために事前ウォーミングされたインスタンスのプールを維持することは、既存の回避策よりも有利な方法の 1 つです。現在、従量課金プランでは、多くの開発者が “pinger” を実装し、絶えずアプリケーションを ping してウォームな状態に維持するすることで、コールド スタートを回避しています。これは最初の要求には機能しない一方、pinger を使用するアプリでは、スケールアウト時にはやはりコールド スタートが発生します。これは、アプリケーションを実行するためにプルされた新しいインスタンスではコードを実行する準備が即座には整わないからです。ユーザーが要求した事前ウォーミングされたインスタンスの数がバッファーとして常に維持されるため、Microsoft でインスタンスをウォームアップするよりも速いペースでスケーリングしない限り、コールド スタートによる遅延が発生することはありません。

試用と詳細情報

Azure Functions Premium プランは本日プレビューとして提供が開始され、お試しいただけるようになりました。以下の方法で、このプランの詳細を確認するたことができます。

ハイブリッド エンタープライズ サーバーレスに関するビデオのサムネイル