Hello, everyone.
It's Shun.
今回は「AWS Auto Scaling（オートスケーリング）」についての概念をまとめてみました。
「こういったことができるだ、へー、便利だね」くらいに感じていただけると、幸いです。
Auto Scalingのユースケース
全体的に見ると必要なリソース量は少ないが、瞬間的にリソースが必要になる場合があり、一番リソース量が増える時のリソース量にサーバーのスペックを合わせているオンプレミス環境構成で運用をしている場合。
こういったケースに、Auto Scalingを使用すると、コストを最適化することができます。
以下、Auto Scalingあり/なしの場合のイメージを図で示してみました
Auto Scalingあり/なし比較
Auto Scalingなし
実際には使用していない部分（上図ピンク塗り箇所）が使用料の2倍以上あるため、必要なリソース量に対してマシンのスペックが見合っていない。
Shun「なんで、実際にはサーバーを使っていない時間帯が多いのに、こんなに使用料を払わなきゃいけないんだよ・・・はぁ、萎える。」みたいな状態です。
コスト最適化の面で改善の余地がかなりあります。
Auto Scalingあり
オートスケーリングあり
実際には使用していない部分がないため、必要なリソース量に対してマシンのスペックが見合っている。
Shun「今月はこんだけサーバーを動かしたんだ。それにしてもリソースの使用料は変わらないのに、Auto Scalingしていない頃と比べてこんなに費用を削減できるんだね、すごい・・・じゃあ、浮いたお金で美味しいもの食べにでも行きますかね^-^」みたいな状態です。
コスト最適化がされています。
Auto Scalingのトリーガー
Auto Scalingありの図中の吹き出しでご説明いたしました、この部分ですが、
必要なリソース量が増えれば、そのリソース量に応じてマシンの性能を拡張し、必要なリソース量が減ると、そのリソース量に応じてマシンの性能を縮小する
どういった条件の場合（（例）CPU使用率が80%を超えたら）にマシンの性能を拡張し、どういった条件の場合（（例）CPU使用率が70%を割ったら）にマシンの性能を縮小するといったようなことを設定できます。
→Amazon Cloud Watchと組み合わせて使用します（Cloud Watchはざっくりご説明すると、マシンの使用量などを図で視覚的に見ることができるものとでも覚えておけば、まずはよろしいのではないかと思います）
条件の設定値はマネージメントコンソール上からいつでも簡単に変更することができますので、運用していく中でマシンの設定値をチューニングしていくのがいいと思います。
最後に
以上、「Amazon Auto Scaling」の概念をかいつまんでご説明させていただきました。
コスト最適化については、環境構成を変更したり、マシンのスペックを下げたりとその他にも色々考えられることはあると思いますが、今回ご紹介させていただきました「Amazon Auto Scaling」は特に、コスト最適化の面で貴人の大きな助け舟になると思います。
必要な分だけ使って、使った分だけ使用料を払いたいですね。
それでは、今回はこの辺で。
Thank you so much, see you next time✋
