プログラムの事とか

お約束ですが「掲載内容は私個人の見解です」

Azure App Service のスケールアウトに失敗していた件

f:id:puni-o:20210615145302p:plain

App Service 上で公開しているページが遅い (タイムアウトする) ということで見たらこんな感じでした

completed 失敗 とはいったい...

現象

  • メモリ使用量がほぼ100%
  • Auto Scale Out の設定はCPU使用率だけだったのでメモリ使用量も追加した、けどインスタンス数増えず
  • 手動でスケールアウトしようとしたけど失敗
  • ショーガナイのでスケールアップしようと思ったらこちらも失敗

スケールアウトの実行履歴を見たら上のスクショのような状態だったのでギブアップ、サポートお願いしました

回答

サポートに投げる前から向こうでも現象に気づいていたのか即答っぽいかんじ

長いので抜粋すると

  • 使っているスケールユニットのインスタンスが不足している (スケールユニットはリージョン内でみんなで使っているやつ?
  • スケールユニットも使用量に応じてオートスケールするはずなんだけど、今使っているスケールユニットはこの機能が正常に動いていない
  • マルチテナントなので他の誰かがインスタンスを解放してくれた時だけその分スケールアウトできる
  • スケールユニットの復旧はサービス一時停止してインフラ側で再構築しないとだめらしい

復旧方法

  • 待つ

そのために、もし正常に動作するように復旧される場合でも、対応までに非常に時間を要し、難航が予想されます。

待つことはやめました

  • リソースグループを新規に作ってそこに新しい App Service プランを作る

リソースグループを作り直さないとだめらしいですが、これで別のスケールユニットが使われる(可能性が高い)らしいです

リソースグループと App Service プランを作ったらそれをサポートに連絡すれば、問題のあったスケールユニットじゃないかどうかを確認してくれるらしいので、伝統に従い HogeHoge2(HogeHoge=旧リソースグループ名) という名前のリソースグループを作って現在確認中です

まとめ

今回の現象は西日本リージョンで発生しました。マルチテナントですから同じスケールユニットを使っている人がほかにもいるはずで、その人は同じ現象にあっていることでしょう(サポートから連絡が行くと思うけど)

こんなこともあるんですねぇ


追記 2021/06/17

弊社で調査させていただきました結果、(略)、障害が発生していたスケール ユニットとは異なるスケール ユニットに配置されているのを確認いたしました。 また、これ以降同じリソース グループ内で、Japan West リージョンに作成した App Service プランでホストされる App Service においても、この度 「Web App」が配置されたのと同じスケール ユニットが選ばれ、障害が発生していたスケール ユニットとは異なるユニットに配置されます

「Web App」は新しく作ったサービスプランの名前です

リソースグループで使うスケールユニットが決まったらそれ以降そのリソースグループで作る App Service プランは同じスケールユニット使うんですね