Azure App Serviceでは「Traffic Manager」でDR後のアプリ接続先を管理
NEO：ここまでお話ししたAzure Storage、Azure SQL Databaseは永続的にデータを格納するサービスでした。Azure App Serviceにホストされるアプリケーションは通常はステートレスなので永続データより話は簡単です。
WebアプリケーションやWeb APIがAzure App Serviceにホストされているケースを考えてみましょう。プライマリリージョンの障害を検出したらセカンダリリージョンのApp Serviceにアプリをデプロイするようにもできます。通常時はセカンダリリージョンに最小構成でアプリをデプロイしておいて障害検出時にはスケールアップ（上位のApp Serviceプランへの変更、上位インスタンスへの変更）することもできますし、もちろん、通常時からセカンダリリージョンにプライマリリージョンと同じ構成でデプロイしておいてもいいでしょう。
App ServiceのDRに際して考えておかなければいけないのは、アプリケーションの接続先になるAzure StorageやAzure SQL Databaseの管理や切り替えをどうするかです。Azure SQL Databaseのアクティブ地理レプリケーションを例にとってみましょう。App Serviceのセカンダリリージョンで動くアプリケーションは、セカンダリリージョンで動くデータベースに接続するようにできています。通常時にセカンダリリージョンのアプリケーションにアクセスすると、その先のデータベースは（アクティブ地理レプリケーションのセカンダリのため）読み取り専用です。ここで、ユーザーがデータベースのフェールオーバーを行うと、セカンダリリージョンのアプリケーションは読み書き可能になります。
別のアプローチは、セカンダリリージョンのアプリケーションが、通常時プライマリリージョンのデータベースに接続することです。この場合、通常時にセカンダリリージョンのApp Serviceにアクセスすると、プライマリリージョンのApp Serviceと同様に読み書き可能になります。
プライマリリージョンのAzure障害検出時には、ユーザーは、データベースのフェールオーバーに加えて、セカンダリリージョンのApp Serviceのデータベース接続文字列がセカンダリリージョンのデータベースになるように更新する必要があります。
外部のクライアント（Webブラウザやアプリケーション、APIクライアント）からApp Serviceへ接続するケースを例に説明しましょう。2つの異なるリージョンに配置されているApp Serviceは、それぞれ異なるホスト名を持っています。ここで「Azure Traffic Manager」を使うと、DNSベースで、異なるホスト名を持つ複数のサービスへのHTTPリクエストのルーティングを管理できます。
Azure Traffic Managerで、プライマリリージョンのApp Service、セカンダリリージョンのApp Serviceという優先順位を設定しておけば、プライマリリージョンのApp Serviceが正常動作している間はプライマリリージョンのApp Serviceにルーティングされ、プライマリリージョンのApp Serviceに障害が発生した場合にのみ、セカンダリリージョンのApp Serviceにルーティングさせることができます。
ASCII羽野：Azure App Serviceでは、複数リージョンにアプリケーションをデプロイして、Azure Traffic Managerを使ってAzure StorageやAzure SQL Databaseへの接続を管理することでDR構成になるのですね。
