オートスケーリングを試す(2)
AutoScalingサービスの設定
前回の続きです。 早速AutoScalingサービスを使っていこうと思います。
Auto Scalingサービスの有効化
メニューよりAutoScalingを選ぶと、 上記のような画面が出てきますので、今すぐ有効化をクリックします。
利用規約に同意すると、支払い画面になりドキッとしますが、ここで何か料金がかかるわけではありません。 マニュアルには、
とあります。AWSと同様ですね。 しばらくすると以下のようなメールがきます。
メール本文内ではAutoScalingサービスではなくElastic Scaling Service(ESS)と書いてありました。AutoScalingなのか、ESSなのかハッキリしてほしいところです。
さて、AutoScalingサービスにアクセスすると、権限設定を行うよう言われました。クイックスタートガイドを見るとAliyunESSDefaultRoleというロールにオートスケーリングに必要な権限が付与されているようなのでそのまま使います。
すると
スケーリンググループ一覧の画面が表示されました!当然ですがまだ何もありません。
スケーリンググループの追加
次に、実際にスケーリンググループを追加していきます。
最大インスタンス数は4、最小インスタンスを1に設定してみました。 何らかのイベントによりスケーリングルールがトリガーされた場合、最大4台までインスタンスが自動起動する訳ですね。
次にスケーリング設定を作成していきます。
スケーリング設定
前回に作成したものと同じBurstable Type t5を選択しました。
スケーリング設定が終わるとインスタンスが1台起動されます。
スケーリングルールの作成
さて、実際にオートスケーリングが必要となるようなイベントが起きると、インスタンス台数を増やしたり減らしたりすることになるのですが、そのルールを作成しておきます。
とりあえずCPUの負荷が高かったら1台インスタンスを増加するルールを追加しました。 ただ、実際にCPUの負荷を監視してトリガーする仕組みとして、アラームタスクというものを別途設定する必要があります。
アラームタスクの作成
CPUの負荷が設定した閾値を越えるとスケーリングルールがトリガーされるようにしようと思います。 ただし、アラームタスクを設定する前に、ECSイメージにCloud Monitor Agentというものをインストールしておく必要があるようです。
マニュアルよりインストールコマンドをコピー&ペーストしてインストールしましょう。 順番が前後してしまいますが、スケーリング設定で選ぶイメージは、このCloud Monitor Agentが導入済みのものを選択する必要がありますね。
擬似的な障害を起こしてみる
稼働している1台目のインスタンスに接続し、yesコマンドでCPU負荷を限界まで上げてみます。
CPU負荷が上がってきました。
無事スケールアウトして1インスタンスアタッチされました。
今日のところはここまでです。
この記事が気に入ったらサポートをしてみませんか?