しばやん雑記

ASP.NET Core とメイドさんが大好きなフリーランスのプログラマーのブログ

Azure Functions の Premium Plan が Public Preview に

去年から Private Preview になっていた Azure Functions の Premium Plan が Public Preview に移行しました。

ベースとなっている Premium V2 とはスケーリングの仕組みと課金体系が異なっているので、Consumption だとパフォーマンス不足なので App Service Plan を使っていたケースには適しています。

大体新しいサービス追加時にはおま国になることが多いですが、Premium Plan は Japan West で使えるようになっているので安心です。

ちょっと分かりにくいですが、Azure Functions の作成時に App Service Plan を選んで、Pricing Tier として EP1-3 を選ぶと Premium Plan となります。

f:id:shiba-yan:20190404133828p:plain

ちなみに EP とは Elastic Premium のことです。考え方としては App Service Plan と Consumption を足した感じで、固定のインスタンス + 従量課金のインスタンスという形です。

課金体系ですが、相変わらず Consumption 部分が計算しにくい感じですが、基本的には Minimum Instances で指定した数は通常の App Service Plan のように、時間単位で使っていなくても課金が発生するようです。

Azure Portal の表示を見る感じでは、Minimum Instances で設定したインスタンスに対しては 50% の割引は効いていない気がします。既に Premium V2 とオートスケールを使っている場合は、移行した方が良いケースが多そうです。全体的なコスト最適化になります。

実際に Premium Plan を作成してスケーリング周りの挙動を確認しておきました。

Elastic Scaling / Pre-Warmed

Premium Plan を作成すると Scale out の設定がこれまでと大きく異なります。Plan Scale out は最低・最大インスタンス数を設定するだけなので分かりやすいです。

App Scale out はウォームアップしておく Function App の数を表していますが、今は少し挙動がおかしいです。本来なら最低インスタンス数を上限に指定できるはずですが、今は 0 か 1 しか指定できません。

f:id:shiba-yan:20190404134256p:plain

ウォームアップの仕組み自体は Always On と同じように 10 秒間隔で ping が打たれているようです。

f:id:shiba-yan:20190404140420p:plain

気になっていたポイントとしては 1 つの Premium Plan 上に複数の Function App をデプロイした状態で、特定の 1 つの Function App に負荷が集中した場合にどのようにスケーリングが行われるかでした。

通常の App Service Plan で使えるオートスケールでは Service Plan 単位のスケーリングとなるので、デプロイされている全てのアプリケーションがスケールアウトされますが、Premium Plan では Function App 単位でスケーリングが実行されました。

f:id:shiba-yan:20190404143828p:plain

上のように Application Insights 上で 5 インスタンスに増やされてリクエストを受けていることが確認できますが、同居してる他の Function App は 1 インスタンスのままでした。

実際の運用としては 1 つだけ Premium Plan を作成して、その上に Function App を複数デプロイして行けば、高負荷時には Function App 単位で柔軟なスケーリングを行いつつ、ウォームアップ済みの状態を保てるというメリットがあります。他の Function App にリソースを食われるという心配も不要です。

VNET Integration

Premium Plan は新しい VNET Integration を使うことが出来るようになっています。Consumption では無理でしたが、Premium Plan では動的に追加されるインスタンスでも VNET に参加できるので、これまでよりも適用可能な環境が広がっています。

f:id:shiba-yan:20190404134306p:plain

ただし以前にも書いたように、新しい VNET Integration はプレビュー中で mid-year of 2019 に GA 予定です。

スケジュールはふわっとしてますが、恐らく Premium Plan より先か同時期の GA になるかと思います。

ちなみに Premium Plan ではない App Service Plan の Premium V2 系でも、新しい VNET Integration は使えるので誤解のないように注意してください。

Service Plan 間の移動

これは知らなかったのですが、1 つのリソースグループ内に Consumption / App Service Plan / Premium Plan を作成しておけば、ARM を使って簡単に Function App がホストされる Service Plan の移動が行えます。

実際に Service Plan が混在したリソースグループを作成して、移動が出来ることを確認しました。

f:id:shiba-yan:20190404151437p:plain

Azure Portal からは出来ないので、ARM Explorer などで serverFarmId を書き換えて対応します。

ただし同一 Webspace という制約はあるので、古い Scale unit の場合はそもそもデプロイ出来ません。先に Premium Plan か Premium V2 を作っておくと安心という状況は特に変わらないです。