Azure App Service のアプリ最大数の制限事項を超えてやらかした運用話について紹介します。
こちらの記事は私が 第42回 Tokyo Jazug Night で発表した「Azure App Service 運用体験談 ～コスト節約しようとしてダウンした App Service～」の内容を記事に起こして補足を追加したものになります。
- Azure App Service 運用体験談 ～コスト節約しようとしてダウンした App Service～
- Azure App Service 小ネタ集
- 第42回 Tokyo Jazug Night 動画の紹介
Azure App Service 運用体験談 ～コスト節約しようとしてダウンした App Service～
第42回 Tokyo Jazug Night で発表したときのスライドはこちらです。
今回はクリスマス、年末にふさわしい？Azure App Service のやらかし運用体験談についてでした。
やはり運用話って面白いよね。
Azure App Service とは
今回のお話の主役 Azure App Service についてです。「Web アプリケーションをデプロイするサービスを提供する PaaS フルマネージド プラットフォーム」です。
参考URL
App Service と App Service Plan の関係性。こちらが今回の肝となる部分ですね。App Service Plan は複数のアプリを載せることができ、いくつアプリを乗っけても費用は App Service Plan のサイズ、数で決まるというもの。
App Service Plan の価格についての参考URL
Azure App Service のアンチパターンとなるコスト節約策「1つのプランにアプリをたくさん乗せ続ける」
上述した Azure App Service の価格体系を見て思いつく悪いアイデア「1つのApp Service Plan にすべてのアプリケーション乗っけたらお得じゃない？」説。
最初は数個単位で乗っけていたアプリケーション。アプリが増えるたびにテスト環境、ステージング環境、検証用環境、本番環境関係なく乗っけていきました。
気づいたら、自主規制レベルまでアプリを積んでいました。言い訳になるんですが、最初の頃は Azure
で使える予算も少なく、なかなかプランをもう一個作れる環境ではなかったのでしょうがなくやっていたのです。
アプリを乗せ続けた結果、発生し始める不具合。最終的にダウンタイムが発生...
そのような状況で数年は運用できてましたが、あるときからこの構成が原因ゆえの不具合が増えてきます。
オートスケールでインスタンス数が最大値に張り付き続ける
- CPUが高負荷のままに
テスト環境の負荷が本番環境に悪影響を与える
- テスト環境が何かやらかすと本番の環境の動作も一緒に悪くなる
スケールアップ、インスタンス最大数を増やすことになり、増え続けるコスト
このときからアプリの数怪しいなとは思ってはいたのですが、プランのSKUをスケールアップしたり、オートスケールのインスタンス数増やしてるし大丈夫だろうと思っていた状況です。それだけアプリ使ってるんだから、コストアップもしょうがないと思っていました。
そしてとうとうプランに乗っかっているアプリケーション自体が動かなくなる現象が発生します。
スライドでは Azure 正常性アラートの通知画面を紹介していましたが、これは設定しておいて本当に良かったと思います。後日正常性アラートについても記事書こうかな。
ちなみに発表では紹介しませんでしたが、一回プラン全体が完全に落ちてます。アプリケーションがアクセス不能になり下記のようなエラーを吐いてました。
「Our services aren't available right now We're working to restore all services as soon as possible. Please check back soon.」
ここから解決編。原因は App Service Plan にアプリ載せすぎだった。
記事のタイトルでもネタバレしてますが、上記のような不調の原因は一つの App Service Plan に対してアプリを載せすぎたことが原因でした。上記の画像のようにApp Service Plan のSKUごとに最大アプリ数が設定されていてそれを超える場合、新規や既存のアプリにダウンタイムが発生する恐れがあるようです。
詳しい最大アプリ数は下記の Microsoft 公式ページをご参照ください。
App Service プラン - Azure App Service | Microsoft Learn 「アプリを新しいプランと既存のプランのどちらに入れる必要があるか」
というわけでこのような状態に陥った App Service Plan はアプリを適切に新しい App Service Plan に分離していく必要があります。
ちなみにプランに現在乗っかっているアプリ数を確認するには Azure Portal の App Service プランの概要ページより確認することができます。「アプリ/スロット」の部分から確認することができます。
この画像ですとアプリが25個、スロットが21個乗っかっています。
解決策「App Service Plan を環境ごとに分割する」
App Service Plan の分割を考える際にどのような点を考慮して分割していくのか。分割戦略を紹介しました。
スライドでは環境ごとに App Service Plan を分割した例を紹介しましたが、それ以外にもアプリケーションを完全に独立させたい場合、アプリを別のリージョンに配置したい場合は別のプランに分割する必要があります。
上記の分割案のようにプランの分割を行い、各プラン内で推奨のアプリ数内に抑えたところ、無事問題は解決されていきました。アプリケーション停止の問題だけでなく、インスタンス数やCPUの上限張り付きもなくなり、いかにアプリ数の超過がプランに影響を与えていたかがわかります。
App Service Plan の分割したことにより、問題が解決するだけでなく、様々な副次的な効果がありました。一番大きかったのはプランを増やしたにも関わらずコストが最大半分近くまで下がったことです。
コストが下がった要因としては下記の理由が挙げられます。
- 必要なプランにだけ高いSKUのプランを用いることができたこと
- 高いSKUのプランの負荷がさがったことで高いプランのインスタンス数が上がらなくなったこと
- 普段パフォーマンスを必要としない環境のプランのSKUを低くできたこと
コストダウンしただけでなく、本番環境のプランを分割することができたので本番環境のリソースに必要最小限の権限を振ることができるようになったため、ガバナンスを効かせやすくなりセキュリティ運用面での課題を解決することもできました。
結論「制限事項はしっかり守る」、「下手なコスト節約は逆効果」です
今回学んだこととして無理なコスト節約は逆にコストがかかってしまうこと。公式ドキュメントに書いてあること、特に制約事項はしっかりと見ておく必要があると実感しました。このような陥りやすいパターンはアンチパターンとして紹介されている場合も多いのでアーキテクチャを構築する際には気をつけようと思いました。
Azure App Service 小ネタ集
App Service Plan の再起動方法
App Serive Plan の再起動についてはこちらの記事で別で紹介していますのでそちらをご参照ください。
onarimon.jp
App Service Plan の変更方法について
今回App Serive Plan の分割に使用したApp Serive Plan の変更についても別記事で紹介していますのでそちらをご参照ください。詳しい方法や制限事項等をまとめております。
onarimon.jp
プランの違うステージングスロットをスワップするとプランごと入れ替わる
プロダクション環境とステージング環境でプランが違う場合、それらをスワップするとどうなるかと気になりますね。私もやってみてわかったのですが、図のようにプランごと入れ替わってしまうので注意が必要です。そのことからステージング環境は本番環境と同じプラン上に乗っけておく必要がありそうです。
第42回 Tokyo Jazug Night 動画の紹介
2022/12/22(木)開催の 第42回 Tokyo Jazug Night は毎年年末恒例のLT大会でした。詳細は下記のConpass ページをご参照ください。
jazug.connpass.com
第42回 Tokyo Jazug Night の発表動画はこちらです
youtu.be
私の発表は21:30ぐらいから始まります(このリンクからすぐに飛べるよ)。
