Azure App ServiceのプランをPremium V2に上げる

azure
目次

はじめに

このKTKR雑記は2019年7月にオープンしたのですが、その当時はそれほど(というか全く)アクセス数がなかったので、App Service PlanはB1で運営していました。

最近はAzureの記事もそうですが、ニンテンドースイッチの記事も比較的Page Viewが伸びてきて、このままではB1(ACU 100、1.7GB Memory)では足りなくなりそうだと思っていました。

いつかはPremium V2に上げないと？と思っていたのですが、なんとAzureポータルでスケールアップを見ると、Premium V2がグレーアウトしているではありませんか！

img

本記事では、実際に本サイトをPremium V2にスケールアップするためにApp Service Planの変更(コンテンツ移動)を行った時の操作手順を記載しています。

どうしてこういう事が起こるのか

Azure App Serviceは初回デプロイ時に指定した価格レベルのインスタンスが利用できるグループに配置されます。

最初から素直に「あまり使われないと思うし、でもカスタムドメインは使いたいからB1でいいや」というお気持ちでデプロイすると、稀に運悪く古めのインスタンスがあるグループにApp Service Planが配置されてしまいます。

この場合には、新しいリソースグループ上に新しくApp Service PlanをPremium V2で作成して、コンテンツデータを移行してあげる必要があります。

サポートされてないリソース グループとリージョンの組み合わせからスケール アップする

移行の方式

移行の方式には以下の3点があるかなと思います。

  • 新たなApp Service(V2)にコンテンツやアプリケーション設定、カスタムドメイン、SSL証明書など手動で移行する
  • App Serviceのバックアップを取って、新たなApp Service(V2)上でリストアする
  • App Serviceの「複製」機能を使ってコンテンツとアプリケーション設定を複製する

App Service上のストレージに何もデータが入っていなければ、アプリケーションを再デプロイすればいいのだと思いますが、このサイトはWordPressで動作しており、おもいっきり画像データなどがApp Service上のストレージに保存されています。

今回は3番目の複製機能を使って移行を行ってみます。

手順

App Serviceの複製機能は複製元のApp Serviceから、複製先のApp Service Planを選択して、新しいApp Serviceを作成してアプリケーション(及びデータ)と、アプリケーション設定を複製してくれます。

App Service Planの作成

従来と同じリソースグループには仕様上作成できないので、新しくリソースグループを作り、その中にPremium V2のApp Service Planを作成します(Web Appsの作成ではなく、App Service Planだけを作成します)

img

さくっと出来ました。

img

既存のApp Service Planの確認

App Serviceの複製機能はStandard以上の価格レベルで対応です。私も最初はB1で動かしていたので、これはまずはS1に変更しました。

img

複製の実行

既存のApp Serviceのメニューから「アプリの複製」を選び、入力項目としていは先に作成したApp Service Plan(V2)を選択しつつも、新しいアプリ名(xxxx.azurewebsites.netのxxxx部分)を入力し、最後に実行します。

img

コンテンツのサイズにもよりますが、5分ほどで新しくApp ServiceがPremium V2のApp Service Plan上で立ち上がりました。

複製後の確認

アプリケーション設定と、接続文字列は今までWordPressの動作に必要なものが、ちゃんと複製されていました。

img

wwwroot配下についても、一応なんとなく全部コピーされているっぽい。

img

カスタムDNS,SSL証明書

SSL(TLS)証明書は複製してくれないので、再度自分のpfxファイルをアップロードします。

img

カスタムドメインも複製してくれないので、私の場合はwww.nya-n.netとzakki.nya-n.netを追加します。
ドメインの所有者確認については、既に確認済みとなっていたため事前にDNSレコードの追加変更を行わなくても追加ができました。

img

最後にSSLバインディングの追加をしたら完了です。

img

ばっちりです。最後に新しいApp ServiceのIPアドレスを控えておきます。

img

DNSレコードの更新

うっかりTTLが3600秒(1時間)のまま移行作業を開始してしまいましたが、とりあえずwww, zakkiのAレコードを新しいApp ServiceのIPアドレスに変更します。

img

つまり、1時間くらいは利用者からは新・旧両方のサイトにアクセスが来るということなので、その間はWordPressの記事投稿とか余計なことはせずに、しばらく待機します。

本来は、こういった移行作業の前にはDNSレコードのTTLをもっと短い値にした上で作業を行います。

移行後確認

古いApp Serviceを停止します。

img

通常のブラウザでカスタムドメイン名でアクセスして、表示されることを確認します。
つまり、App Service Plan(Premium)上のApp Service(WordPress)にアクセスできているということですね。

img

App Serviceの概要にあるメトリックのグラフでも、ちゃんとリクエストが処理されているっぽい事がわかりました。

img

古いApp Service, App Service Planの削除

しばらく(数日？)新環境で運用して、特に不具合が無さそうでしたら、古いApp ServiceとApp Service Planは削除します。

App Serviceを停止しても課金は続くのでご注意を。

おわりに

今回はWordPressの移行ではなく、App Service PlanのPremium V2移行に関するお話であったため、WordPressが利用しているAzure Database for MySQLのネットワーク設定の変更等には触れていません。
もし、MySQLのFirewall設定で送信元IPアドレスを制限している場合は、App Serviceが変更になっているので、新しいIPアドレスを接続許可に追加するなども実施してくださいね。