Azure Web Apps のオートスケールについてのメモ

Azure

こんにちは。

今回は、Azure Web Apps のオートスケールについてです。

 

このブログは、2018 年 7 月にサブスクリプション移行を行ってまして、その時に、と~~っても雑にオートスケールの設定をしていました。

で、先日なんとなくスケールの状況を見たら、4インスタンスまでスケールアウトしていたのですが、そこまでアクセスが集中するサイトではないんですよねー。

しかも、4インスタンスで動いていたのは、1月以上だったので、コスト的にもちょっと無視できないので、何故このようなことが起きたのか調べてみました。

そんなことを、今回はまとめてみようと思います。

 

Azure Web Apps のオートスケールについて

Azure Web Apps のオートスケールについては、みなさんご存知ですよね?

Web サイトの負荷に応じて、自動的にスケールアウト/インができる機能ですね。

こんな感じで設定しています。

メモリの利用率が90%超えたら1インスタンス増やして、70%を切ったら1インスタンスを減らすっていう設定です。

まぁー、このサイトはそこまで負荷が高くないので、そもそもスケールを意識する必要があるのかって言われると、全然意識しなくていいんですけど、なんとなくて設定してみたって感じです。

ただ、このブログの傾向として、大体AM10:00から一気にアクセス数が増え12:00で一度下がり13:00~19:00が割と高いという傾向にあったり、月・金はそこそこで、火~木が割と読んで頂いていて土日はほとんどアクセスがないといった感じです。

もし、最大ピークが2インスタンス必要だったとしても、1インスタンスで十分な時間はたくさんあるので、コストを抑えるために負荷が上がってきたときだけインスタンス数を増やしてコストを抑えたい。そんなときに、とっても便利な機能がオートスケールで、Azure の PaaS っぽいとてもいい機能だと思います。

まぁー、今回はそれをなんとなく使って、逆にコストが高くなっちゃったのですが。(なんとなくの度合いが適当すぎただけですけど。。)

今回過剰にオートスケールが動いた理由

ではなんで、今回オートスケールが動いてしまったかということですね。また、スケールアウトは動いたのに、スケールインが実行されずにスケールした状態が続いてしまったかということです。

別に、Azure の不具合とかではないんですよ。

 

これを説明するには、Web Apps のサービスである、App Service の説明が必要となります。

Web Apps を含む App Service は、App Service プランと、App Service の2つのリソースから構成されます。

Web Apps でいうと、概念的には、App Service プランは、オンプレでは Web サーバで、Web Apps がWeb インスタンスみたいな関係です。

ですので、1つの App Service プランの中に、複数の Web Apps を構築することができます。ちなみに、課金の単位は App Service プランです。オートスケールの対象も、App Service プランの単位となりますので、メニューにも「App Service Plan」という記載があります。

 

今回スケールが発生したのは、App Service Plan に別サイトを追加したために、デフォルトで使用するメモリ使用率が増えたのと、追加したタイミングでスパイク的な負荷でオートスケールの閾値を超えてスケールアウトが発生したと想定しています。

逆にスケールインが動かなかったのは、スケールインの閾値を当時はメモリ使用量が40%未満に下がったらという条件にしていて、これが定常的に超えている状態であったため、スケールインの動作がされなかったんだと思います。

 

でも、こんなこと意識しながら Web Apps を追加したり、オートスケールの閾値の設計をもっと綿密にやるってなると、サイジングをしなくていいという PaaS の良さを失うことになるから、やっぱりもっと雑に運用したいですよねー。

そういう意味ではこれくらい割り切った設定をしてもいいのかもって思いました。

この設定は、閾値を超えたら最初から5インスタンス(というか、対象サイトでコスト的に最大限増やしてもいい数)まで一度一気に増やして、その後、徐々にスケールインをして最適化をされるのを待つという考え方です。

なぜ一気に最大まで増やしてしまおうって考えたかっていうと、オートスケールをする際のチェック間隔は1分でかつ最小の範囲で過去5分の負荷を見て判断する仕様だからです。これは、スパイク対策ではあるのですが、急激の負荷の場合にスケールが追い付かなくなることがあり得ます。なので、一気に増やしてしまうというのは1つの解決方法です。

その代わり、スケールインするところの閾値を高めに設定していて、不要な分をどんどんドロップしてしまえば、アクセスの取りこぼしもなく数分以内に最適化が行われるという発想です。

こんくらい雑でいい気がします。

 

まとめ

今回は、Azure Web Apps の超基本的な機能のオートスケールの話でした。

ちょっと今更感が満載なのですが、皆さんのサービスにも大きな貢献を果たす機能だと思いますので、是非、コストをかけずに雑に設定していい感じにしちゃってください。

コメント

タイトルとURLをコピーしました