これまで App Service Environment は Availability Zones に対応していましたが、ついにマルチテナント型の App Service でも Availability Zones に対応しました。これで複数のゾーンに分散してアプリケーションをデプロイすることで、マルチリージョンより簡単に高可用性を実現出来るようになりました。
Availability Zones は東日本にも用意されているので、珍しく最初から日本でも利用可能です。
まだ公式ドキュメントの更新とリリースアナウンスは行われていないですが、近日中に諸々発表されると思われます。もしかしたら SLA が若干変わってくるかも知れないので期待したいところです。
元々 App Service のアーキテクチャは単一インスタンスでも高い可用性を実現できる仕組みになっていますが、基本は単一のリージョンやゾーンに属しているのでデータセンターの障害時には、複数インスタンス構成にしていても影響を受ける可能性はありました。
今回の Availability Zones 対応によって App Service のインスタンスを複数ゾーンに分散出来るようになったため、単一データセンター障害の影響を最小限に抑えることが出来ます。
その代わり以下のように利用には若干の制約も存在しています。主に料金面や Premium V3 (VMSS Worker) に影響する部分が大きいですが、それによって得られるメリットも十分大きいです。
- Premium V2 / Premium V3 のみ対応
- 既に Premium V3 を使っている場合は同一 RG に展開できる
- VMSS Worker で動いている Premium V2 / V3 が必要という話
- 最低でも 3 インスタンスが必要
- 自動的に 3 つの AZ に分散される
- インスタンス数は 3 の倍数にする必要はない
- App Service Plan の作成時のみ設定可能
- 後から設定変更することは出来ない
- ゾーン障害時には必要な数のインスタンスをベストエフォートで自動確保する
- キャパシティ不足の場合には確保できない場合もある
- 単一ゾーン障害を考慮しキャパシティを事前に設定するのが良い
- 現在は Azure Portal からデプロイは出来ない
- ARM Template を使う必要がある
一般的にマルチリージョン構成を組もうとすると、ピアリング含めた VNET とアクセス制御の設計、ストレージが非同期レプリケーションで切り替え時にデータ損失が発生すること、アプリケーションのデプロイ自体が複数に対して行う必要があるなど、設計面と運用面の両方で負荷が高まりやすいです。
しかし Availability Zones を利用した設計ではマルチリージョンに匹敵する高可用性を、単一リージョンと同等の設計で得ることが出来るので、今回の App Service の AZ 対応は今後の設計を大きく変えます。
実際にゾーン冗長に対応した App Service を試していきます。今は Azure Portal から作成出来ないので、以下のような ARM Template を作成して Azure Portal の Template Deployment に食わせるのが一番簡単です。
{ "$schema": "http://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#", "contentVersion": "1.0.0.0", "parameters": { "hostingPlanName": { "type": "string" }, "sku": { "type": "string" }, "skuCode": { "type": "string" }, "numberOfWorkers": { "type": "string" } }, "resources": [ { "apiVersion": "2020-12-01", "name": "[parameters('hostingPlanName')]", "type": "Microsoft.Web/serverfarms", "location": "[resourceGroup().location]", "kind": "app", "properties": { "zoneRedundant": true }, "sku": { "tier": "[parameters('sku')]", "name": "[parameters('skuCode')]", "capacity": "[parameters('numberOfWorkers')]" } } ] }
リソースグループは事前に AZ が利用可能なリージョンを指定して作成しておきます。今回は折角なので Japan East を使うことにしました。
Template Deployment を使うとフォーム形式で必要な情報を入力できるの簡単です。制約に従う形で Premium V2 の P1v2 を選択し、最低インスタンス数は 3 を指定しました。
これでデプロイを行うと、以下のように Zone redundant が Enabled になった App Service Plan が作成されます。この点以外はこれまでの App Service Plan と全く違いはありません。
後は Web App や Azure Functions の作成時にこのゾーン冗長に対応した App Service Plan を指定すると、自動的に東日本の場合は 3 つのゾーンに分散されてデプロイされます。App Service Plan の上で動く Web App や Azure Functions は AZ を意識する必要が無いのでシンプルです。
ARM Template 以外では、近日中にリリースされる予定の Terraform Provider for Azure の v2.74.0 から、ゾーン冗長に対応した App Service Plan を作成可能になるはずです。
ここからは複数ゾーンにデプロイされた App Service をもうちょっと深堀していきます。
いつも通り Kudu や ARM Explorer を使って 3 つのゾーンに分散してデプロイされたインスタンスの詳細を確認してみましたが、インスタンス ID と IP アドレス以外の違いはありませんでした。これまで通り VM や AZ を意識することなく利用できることを意味しています。
ぶっちゃけ App Service からはどのゾーンにデプロイされているのかを把握する方法は存在しないようで、Home Stamp は 3 インスタンス共に同じ値で違いはありませんでした。ただし CPU の世代が 3 インスタンスでバラバラだったので、どれが古いデータセンターなのか予想は付きそうです。
Intel(R) Xeon(R) CPU E5-2673 v3 @ 2.40GHz
Intel(R) Xeon(R) CPU E5-2673 v4 @ 2.30GHz
Intel(R) Xeon(R) Platinum 8272CL CPU @ 2.60GHz
今回は Premium V2 を選んだのでばらけましたが、Premium V3 を選ぶと結果は変わってくるはずです。ちなみにゾーン冗長を行っていてもスケールアップ・スケールアウトはこれまで通り高速に行えるので、ASE よりも確実に有利だと感じています。
割り当てられる Virtual IP address はこれまで通り 1 つですが、裏側の ARR はゾーン冗長されていることを期待しています。ファイル共有も全て同じ IP を指していたので、ゾーン冗長されていないと困ります。*1
App Service としての機能は全く同じで、何も気にせずに Regional VNET Integration を使って Service Endpoint や Private Endpoint 経由での通信が行えます。既に SQL Database や Cosmos DB など多くのサービスはゾーン冗長に対応しているので、組み合わせることでシンプルな構成を保ったまま高可用性と高いセキュリティを実現出来るでしょう。
残っていたコンピューティング部分の弱みが App Service の AZ 対応で埋まったと感じています。
最後に Azure Functions に関してですが、作成時に App Service Plan を選択すればゾーン冗長の App Service Plan 上で実行することは出来ますが、同時に作成される Azure Storage はデフォルトで Storage V1 の LRS となるので単一データセンターでホストされます。
この Azure Storage は Azure Functions の実行に必要で、データセンター障害が発生するともちろん影響を受けるものなので、価格は上がりますが Storage V2 (GPv2) の ZRS に変更するとゾーン冗長になります。
ZRS ではゾーン間で同期レプリケーションが行われるので、Azure Functions からも問題なく利用できます。ZRS の利用は公式にサポートされている使い方となるので安心してください。*2
ただし Azure Portal を使った Azure Functions の作成時には Azure Storage の冗長性を指定できないので、あらかじめ ZRS の Azure Storage を別に作成しておく必要があります。
これで Azure Functions 自体もゾーン冗長で動かすことが出来るようになります。
Azure Functions は Azure Storage と紐づくため、複数リージョンを使って可用性を高めたい場合には若干手間が多かったですが、Availability Zones を利用することでシンプルに実現出来ます。
App Service の歴史の中でかなりインパクトのあるアップデートだと思っているので、これまで以上に高い可用性が必要な場面では積極的に使っていきたいですね。
追記
リリースされた当初は App Service Plan の Premium V2 / V3 のみ対応でしたが、数日前に更新があり Azure Functions の Premium Plan (Elastic Premium や Functions Premium とも呼ばれる) でもゾーン冗長を有効化出来るようになったようです。
Additionally, AZ support for the Azure Functions Premium plan is now available. More information for that feature to be released within the coming weeks.
App Service Support for Availability Zones - Azure App Service
数週間以内に更なる情報が公開されるようなので、そのタイミングで Azure Functions をゾーン冗長にするドキュメントや Azure Portal での対応が公開されるのかもしれません。
特に Azure Portal では ZRS のストレージを予め作っておくのは面倒なので期待しています。
*1:確認する方法がないので公式のアナウンスを信じるしかない
*2:Azure Functions support ZRS storage account · Issue #69119 · MicrosoftDocs/azure-docs · GitHub
