はじめに
AWS を触り始めたばかりの頃にやらかした初歩的なミスをまとめたアドベントカレンダー、題して「AWS初歩ミス図鑑」の 21 日目です。
今回は Auto Scaling のターゲット追跡ポリシーを万能だと思い込んで、予期しない動作に困惑した話 を書いていきます。
やっていたこと
以前と同様、アプリケーションの負荷に応じて自動スケールする仕組みを構築していました。
いつもはスケジューリングされたスケーリングポリシーを使用することが多かったのですが、他に適切なものがあるのではないかと思い Auto Scaling の設定を調べていると、「ターゲット追跡スケーリングポリシー」 という機能を発見しました。
ドキュメントを読むと、
- CPU使用率を事前に定めた値に維持
- そのための CloudWatch アラームは自動で作成、管理
- 自動的にインスタンス数を調整、複雑な設定不要
…など、便利そうな事ばかり書いてあります。「CPU使用率を指定するだけで、あとは全部自動でやってくれるのか！」ということで、さっそくこちらを用いて「CPU使用率を 50％ に維持」という設定で構築をしてみることにしました。
結果
運用を開始してしばらくは順調そうに動いていたのですが、よくよくログやコンソールを確認してみると、予期しない動作が発生していることに気が付きました。
こちらは一日の決まった時間にものすごく負荷がかかるアプリだったのですが、その時間になると以下のようなことが起きています。
- 急激にアクセス増加
- CPU使用率 80% に上昇
- ポリシーに従い、インスタンス数が増加
- しかし CPU使用率が下がると即座にスケールイン開始
- 結果、インスタンス数が常に増えたり減ったりしている
何を考えていたのか
ターゲット追跡ポリシーの制約を理解していませんでした。ドキュメントをさらっと読んだだけの認識では CPU50%を維持するよう完璧に制御してくれる ものと思い込んでいたのですが、実際には CPU50%を目標に調整するし頑張って動いてくれるが、様々な制約が あります。
詳細はドキュメントの考慮次項に諸々書いてありますが、中でも以下の点は特に留意するべきだと思いました。
例えば、CPU 使用率に 50 パーセントのターゲット値を設定し、Auto Scaling グループがそのターゲットを超過したとします。1.5 インスタンスを追加することで CPU 使用率が 50 パーセント近くに減少すると判断される場合があります。1.5 インスタンスを追加することはできないので、これを切り上げて、2 インスタンスを追加します。これにより、CPU 使用率は 50 パーセント未満の値に下がる可能性がありますが、アプリケーションをサポートする十分なリソースが確保されます。同様に、0.5 インスタンスを削除すると CPU 使用率が 50% を超えると判断した場合、スケールインが振動を引き起こさないと考えられるほどメトリクスが十分に低くなるまでスケールインしないことを選択します。
つまり、あくまでもスケーリングポリシーに基づいて予測された値で動くため、人間の想定通りの動きをするとは限らないのです。そのため今回のような、人間目線で見ると「まだ負荷があるのにスケールインしてる、なぜ…？」というようなことが起こったりします。
まとめ
ドキュメントになんだか素敵な言葉がたくさん書いてあるので、よくわからないうちは誤解しがちかと思いますが、ターゲット追跡ポリシーは万能ではありません。
「これさえやっておけばOK！」というような設定を見つけるのは難しいですが、一つのポリシーに頼らず複数のポリシーを組み合わせることで、より安定したスケーリングが実現できる可能性もあります。種類がたくさんあって複雑ですが、そのあたりをきれいにまとめてくださっているブログもたくさんあるので、設定の際はぜひ参考にしてみてください。