share facebook facebook2 twitter menu hatena pocket slack

2017.02.08 WED

スケーリングポリシーの動きを確かめてみた [cloudpack OSAKA blog]

那須隆

WRITTEN BY 那須隆

ナスです。

Auto Scaling のスケーリングポリシーを見ると、ステップで何段階かに分けて設定できることを知ったので、とりあえずやってみました。

設定してみたスケーリングポリシー

Auto Scaling Group の CPU 負荷が60〜80%未満なら1台追加する、80%以上なら2台追加する、という内容です。また CPU 負荷が 10% 以下になったら 1 台削除する、という内容です。

まずは EC2 インスタンスに stress コマンドで CPU 負荷を 99% くらいにする

最初は EC2 インスタンスを 1 台の状態で開始したので、当然アラームに引っかかります。結果どうなったかというと、2 台一気に増えました。

スケーリングポリシーでステップと書かれていますが、実際にはただの if 文だと思った方がいいですね。

stress プロセスを止めました

これで CPU 負荷が 10% 以下になります。どうなったかというと、1 台削除されました。

そのまま放っていると、1 台ずつ EC2 インスタンスが削除されていきました。

まぁこんな感じです。今までのオンプレミスでのサーバ運用の考え方や運用方法でやっていると、本当に AutoScaling で痛い目にあいます。EC2 インスタンスは死んでもいいように設計しましょう。DB は AutoScaling 外に置きましょう。ログも CloudWatch Logs に出力しましょう。これで一安心です。

元記事はこちら

スケーリングポリシーの動きを確かめてみた [cloudpack OSAKA blog]

  

那須隆

那須隆

ネットワークエンジニア、SAPコンサルタントを経て、cloudpackにJOIN。Webサイトや基幹システムのインフラ構築および運用を主に行い、シェルやPythonなどでスクリプトを組んで、インフラ運用の効率化を目指している。