ぱぱネット（仮）

_ [開発][Linux] Amazon Auto Scalingのパラメータについて考える

Amazon EC2 + ELB + Auto Scalingは、動的サイトを自動的にスケールアウトするための、恐らく最も簡単で最もパワフルな解法だと思いますが、やっぱりそれなりの調整は必要です、という話をします。

世の中にあるCPU利用率によるアラームの例

凡例としては一番簡単な設定ですが...実際にやると、どうにもうまくいかないんですよ。

• CloudWatch無料枠だとAlarmが5分間隔しかない
• EC2インスタンスが起動して利用可能になるまで時間がかかる
• そもそも「高負荷」の条件はCPU Boundなのか

という3つの問題があります。つまり、急激にトラフィックが増減するアプリケーションにAmazon Auto Scalingはむいていないようです。 確かにベンチマークなどで負荷をかけるとインスタンスは順次起動されますが、Initializingの待ちが相当まだるっこしいですな。

【チューニング1】スペアサーバを沢山用意しておく

予め需要トラフィックが捌けるだけの台数を用意しておけば、 スケーリングする必要がありません。対策としては基本過ぎるのですが、 新規サービスで需要を予測するのはかなり難しいです。

【チューニング2】 増減するサーバ数を増やす

Alarm発報からインスタンスが起動するまで10分だとすると、10分間はサービスが怪しくても、10分後にはかっちりアクセスを捌けるようになりたいですね。なので、auto-scaling-policyのサーバ増加台数をチューニングすることが重要になってきます。もっとも、トラフィックが減ってもサーバ台数が減らないと課金で死ぬんで減少台数も見極めましょう。

【チューニング3】 高負荷条件を見直す

つまり 「いち早く兆しを掴んでAlarmを発報する」 今回言いたいのはコレ。。文章にすると当たり前ですが....条件は当然アプリによって異なるので難しいです。

私が今作っているサービスの場合、そこそこ重い処理をApp(Web)サーバでやっていて、負荷をかけるとCPUが上昇する前に、503 service unavailableを返すことがわかりましたので、これで条件設定をしています。

一つ前のプルダウンメニューで統計情報を「合計(sum)」に変更しています。（多分）5分間に補足された503エラーの合計...という意味になると思います。

今度はうまくいったようです。

_ [開発][Linux] 同じEC2を使っていても....

EC2で、それこそ私のような素人でも膨大なコンピューティングパワーが使えるようになりました。昔は多少金があっても物理的にできなかったわけですから、大きな進歩があります。

一方で、実際のアプリケーションにあわせたチューニングは何も変わっていないというか、むしろ重要度を増している（＝ハード的に準備できないからいいや、と放置していた問題が顕在化する）とさえ思います。

小さな企業でもインフラエンジニアの存在が重要になってきていると感じます。