ここ数日の間に App Service の Disaster Recovery Mode が 2025/3/31 で廃止されるというメールが大量に届いていると思います。こういうメールが届くと少し身構えてしまうものですが、そもそも App Service の Disaster Recovery Mode ってなんやねんという気持ちです。
個人的には App Service の Disaster Recovery Mode について知りませんでしたが、App Service をデプロイしているリージョンに障害が発生した場合には、通常は Standard 以上の Tier が必要なところ全ての Tier で有効になるという機能らしいです。
結局のところはバックアップ・リストアの機能でしかないですし、最近は App Service のリージョン障害もかなり減っているので使ったことばかりか存在すら知らない機能でした。
DR が必要なシナリオではリージョン障害が発生してから、別リージョンに Azure Portal から再デプロイするという手順はそもそも筋が悪いので、最新のドキュメントに従って Front Door を使って最初から 2 つ以上のリージョンにデプロイしておくのが良いです。
あるいは CI と IaC で別リージョンに素早くデプロイ可能な状態にしておくことが推奨されます。
DR という観点とは異なりますが、最近では Availability Zone を有効化するとリージョン内の 3 つのデータセンターにデプロイ出来るので、可用性を簡単に高めることが出来ます。
Availability Zone を有効化する
既に App Service の Availability Zone については何回も書いているので深く説明しませんが、最低でも 3 インスタンスが必要になるのでコスト的な負担は大きくなる点だけが注意です。それ以外は通常の App Service と機能やデプロイ方法は全く同じなので非常に簡単です。
現実的には東日本の AZ が全てダメになるようなケースはかなり可能性が低いので、複数リージョンへのデプロイが必須な場合以外は Availability Zone の方が管理のしやすさからもお勧めです。
IaC (Bicep / Terraform) を導入する
複数リージョンで常にインスタンスをデプロイしておくとアクティブ・アクティブの場合以外は無駄なコストがかかるので、IaC を使って素早く同一のリソースセットを必要に応じて任意のリージョンにデプロイ可能にしておく方法もお勧めです。
Bicep や Terraform を使うと実行時のパラメータが使えるので、その際にリージョンを渡せるようにしておけば、データだけレプリケーションは必要になりますが数分で全く同じ構成で立ち上げ直すことが出来ます。
しっかりと CI も整備しておけば、新しいリージョンへのアプリケーションのデプロイもあっという間に完了するので、App Service のバックアップ自体必要なくなります。コンピューティングリソースは状態を持たず何時でも捨てられる状態にしておくのが肝ですね。
