f:id:tarutaru_pyorne:20210609131846p:plain

はじめに

Azureコンテナソリューショングループ）土居です。
我々の部署ではAzureにフォーカスをあてクラウドネイティブ関連の技術を追求しお客様をサポートしていきます。その一環としてAzureに関して日々ブログで技術紹介していきますので宜しくお願いします。

今回はApp Serviceで利用可能になったゾーン冗長について紹介します。

App Serviceがより使いやすく

2021/8/25にApp Service Team BlogにApp ServiceプランのPremium V2/V3でゾーン冗長化がサポートされた旨の発表がありました。
MS DocsやApp Serviceの価格表においてこちらの記載がまだありませんが、いわゆるプレビュー扱いではなく正式なサポートのようです。

azure.github.io

App Serviceでゾーン冗長がサポートされる以前でApp Serviceで可用性を確保するには

App Service Environmentのゾーン冗長を利用する
マルチリージョン構成にする

の2通りしかありませんでした。
ASEは固定スタンプ費用（V3では課金されなくなる）やスケールの時間、マルチリージョンではデータ同期など構成面での複雑化がネックとなり本番導入においてイマイチな部分もあったので、ここに大きな選択肢が加わる事となります。
最近のApp ServiceではVNet統合やプライベートエンドポイントを始め、継続的デプロイ連携、Easy Auth、スロットリング、スケールアウトなど本番環境でも十分に利用できる機能が揃っているので今後App Serviceの利用がさらに拡大していく事と思われます。

Terraformでデプロイしてみた

現在、Azure Portal上の操作でApp Serviceのゾーン冗長化を行うことはできません。

Must be created using ARM templates

ARM Templatesか・・・と思った矢先、Terraformの最新のProviderでこちらがサポートされたようなので早速試してみました。

azurerm_app_service_plan - support for the zone_redundant property (#13145)

github.com

terraform {
  required_providers {
    azurerm = {
      source  = "hashicorp/azurerm"
      version = "2.74.0"
    }
  }
}

provider "azurerm" {
  features {}
}

resource "azurerm_resource_group" "rg-app" {
  name     = "rg-appservice"
  location = "Japan East"
}

resource "azurerm_app_service_plan" "app_plan" {
  name                = "appserviceplan-premium"
  location            = azurerm_resource_group.rg-app.location
  resource_group_name = azurerm_resource_group.rg-app.name
  zone_redundant      = true

  sku {
    tier = "PremiumV3"
    size = "P1v3"
  }
}

resource "azurerm_app_service" "example" {
  name                = "example-app-doi"
  location            = azurerm_resource_group.rg-app.location
  resource_group_name = azurerm_resource_group.rg-app.name
  app_service_plan_id = azurerm_app_service_plan.app_plan.id
}

リソースグループ内に、App ServiceプランとApp Serviceが作成されています。中身を見ていきましょう。

f:id:tarutaru_pyorne:20210831000317p:plain

App Serviceプランの概要にゾーン冗長が有効と表示されています。また、App Serviceプランが既に3つスケールアウト（Zone:1:2:3それぞれに配置）していることも確認できます。

f:id:tarutaru_pyorne:20210831000332p:plain

最後にApp Serviceを確認します。こちらも、App Serviceのスケールアウト画面より、現在のインスタンス数を確認すると自動で3になっている事がわかります。

f:id:tarutaru_pyorne:20210831000345p:plain

試しにインスタンス数を2にするとエラーが出て構成変更が完了しません。

The platform will enforce this minimum count behind the scenes if you specify an instance count fewer than 3. This is due to the platform automatically spreading these VMs across 3 zones when zone redundancy is enabled.

f:id:tarutaru_pyorne:20210831000357p:plain