はじめに
WebサイトやWebアプリを作りたくなった時には、WebAppsを使うと簡単にアプリを公開することができます。リッチに作りこみたい時はWebAppsに様々な関連機能が備わっていますので基本的に困ることはありません。
逆にさくっと作りたい時はStatic WebAppsを使えばあっという間にサイトが出来上がります。
私も、仕事でWebAppsをよく使います。（コンテンツではなくプラットフォーム側の構築・管理が中心です。）これまでWebAppsを触ってきた立場で困ったことやハマったことを備忘の意味も含めて書き残したいと思います。
WebAppsとは
WebAppsは、AppServicesというAzureサービスの１サブセットです。WebAppsの兄弟としてはLogicAppsやFunctionAppsがあります。最近は各サービスが独立して成長していますが、基本的な内部アーキテクチャは同じになっています。
WebAppsは、いわゆる「PaaS（Platform as a Service）」ですので、Webアプリケーションサーバでいうと、ホストから実行基盤（ランタイム）までがマネージドサービスとして提供されることになります。ユーザはその範囲の管理はWebAppsに任せておいて、その上で動作するWebアプリの開発に集中することができます。つまりアプリケーションコードをプログラムするだけでよいということになります。実際にWebAppsを使う際には、OS（Windows/Linux）やランタイム(Java/PHP/Python・・・)を選択していくだけで、あっという間に実行環境が出来上がります。さらに、実際に運用していくために必要な、TLS/SSL化、認証、バックアップ、監視運用などといった機能もAzureの関連サービスと連携しながら非常に簡単に実装することができます。
留意点としては、WebAppsの範囲はMicrosoftが責任をとってくれますが、その上のWebアプリやデータについては、ユーザが責任をもって管理する必要があります。これは「責任分解レベル」というもので、クラウドを使う上では極めて重要な考え方ですので、きちんと理解しておきましょう。
出典：https://docs.microsoft.com/ja-jp/azure/security/fundamentals/shared-responsibility
WebAppsの注意点
私はこれまでお客様環境で様々なWebAppsを構築してきました。基本的にはよくできたサービスなので、構築時点で困ることはないのですが、運用の中でいくつかハマりどころがありましたのでここで共有したいと思います。皆様の参考になれば幸いです。
※私が実際に対応してきた課題をつらつらと書いているだけなので網羅性はありません。また、内容に対するWebAppsの細かい仕様説明はしませんのでご容赦ください。
カスタムドメイン有効期限に注意（自動更新設定にリスクあり）
いきなりWebAppsから若干離れてしまいますが、カスタムドメインのお話です。Azureではカスタムドメインを簡単に購入することができます。このカスタムドメインの有効期限は「１年」です。カスタムドメインはデフォルトで自動更新が有効になっているので、更新作業を忘れていても勝手に更新してくれるのですが、この自動更新処理は下記のスケジュールで動きます。
失効期限から、
・48時間(2日)以内に自動更新処理
・（自動更新失敗の場合）120時間(5日)後にドメイン使用不可
・（自動更新失敗の場合）720時間(30日)後にドメイン消滅
ここで、自動更新処理時に例えばクレジットカードの決済方法に問題があった場合、その3日後にDNS名前解決ができなくなります。これは実質システムにアクセスできなくなりますので本番ワークアラウンドでは重大障害になります。当時担当していたシステムでは、このリスクを許容できなかったため、保険として自動更新設定は残しておくものの、結局年次運用として手動更新する方針になりました。（手動更新は更新期限の90日前から実施可能です。）
これはWebAppsではなく、一般的なドメイン運用でも同じかと思いますが、覚えておいた方が良いです。
SSL証明書の有効期限にも注意
また有効期限問題です。AppServiceではカスタムドメインに対して、AppService証明書というEV証明書を簡単に購入することができます。これにも有効期限が１年です。
AppService証明書にも自動更新の機能があり、さらにKeyVault連携ができますので、手前にApplicationGatewayを配置する場合もKeyVault連携で自動的にApplicationGatewayに登録する証明書を更新してくれる、という便利なものがあります。
このAppService証明書ですが、395日ごとに「カスタムドメインの検証」という作業をする必要があります。（395日を経過しても次回の証明書の更新まで証明書が有効状態として利用可能）これは自動運用ができませんので、結局ほぼ１年に１回手動運用がはいることになります。ですので、当時の担当システムでは、証明書についても結局年次運用で手動更新することにしていました。なお、AppService証明書が手動更新可能となるタイミングは、[自動更新]有効時で31日、無効時で60日です。
ランタイムのバージョンアップ
WebAppsはPaaSですので、ホストから実行ランタイムはマネージドサービスとして提供されていますが、そこで使われているOSや実行ランタイムについては旧バージョンのリタイアメントがありますので、WebAppsについても定期的にバージョンアップが走ります。オンプレシステムであれば塩漬け対応（正しく対応ではありませんが）が可能としては可能ですが、WebAppsでは問答無用でバージョンアップ対応が余儀なくされるので、その分の対応コストをあらかじめ見ておいてください。
マルチテナントであるということ
WebAppsはマルチテナントなので、１物理ホスト上に複数のWebAppsがデプロイされています。ユーザ視点に立つと開発環境/本番環境を分けているつもりでも、実ホストが同じ可能性があります。もちろんテナント自体の独立性は担保していますが、WebApps間のアクセス制限する際に、自Appsのアクセス元が自ホストのIPだったり、開発環境、本番環境それぞれにアクセス制限をいれようとしても、IPレベルでは本番感興と開発環境で一致している可能性もあります。お客様によっては物凄く気にしますので、あらかじめご注意ください。
よっぽど気にされれる場合は、利便性は下がりますが、ASEを利用いただくことをお勧めします。
Application InsightsのInstrumental Keyの注意点
新規でWebAppを構築するときにApplication Insightsも一緒につくってしまうのが一般的かと思います。この時、Application InsightsとWebApp（AppService）の紐づけを行っているのがInstrumental Keyです。Instrumental Keyの失敗談ですが、ARMテンプレートを用いて環境の複製をする際に、Instrumental Key自体は変わりませんので、既存面のInsightsにログを吐いてしまっていた、ということがあります。環境複製時には十分ご注意ください。
リソースロックとスケールアウト設定
こちらは、厳密にはAppService Planリソースになります。例えばAppService Planリソースに「読み取り専用ロック」をつけている場合WebApps他AppServviceのAuto Scaleが反応しません。AppServie Planリソースについては「削除ロック」に留めておきましょう。
おわりに
今回はWebAppsを使うときに注意しておくべき事項を紹介しました。時間の関係でここまでとしましたが、他にも思いついたことがあれば更新していきますので、今後ともよろしくお願いいたします。