初めに

EC2のスケーリング機能についてコスト最適化ガイドブックを読んだ中で理解できたことをまとめました。

概要

主にEC2のスケーリングの用語と各機能の違いについて説明しています。
そもそもEC2 Auto ScalingとはEC2を自動(手動も可)で増減させることで、急なアクセスの増加に対応することができます。
他にも、日中はアクセスが多いが、夜間はほとんどアクセスがないといったデータがあれば、時間帯によってEC2の数をスケーリングするといった使い方もできます。

AWSにはEC2以外にもECSやDynamoDB、Auroraなど、他にもオートスケール機能を持ったサービスがあります。

対象読書

EC2のスケーリングの概要を知りたい人。
※詳細な設定の手順は記載していません

スケーリングの種類

スケーリングにはいくつかの種類が存在します。

起動するインスタンス数を維持するスケール
手動スケール
自動スケール　
予測スケール
スケジュールによるスケール

大きく分けるとこのようになります。

スケーリングのメインとなる設定は

希望するキャパシティ
最小キャパシティ
最大キャパシティ

です。
ちなみに、希望するキャパシティというのは最初の起動時に立ち上げるEC2の数です。

起動するインスタンス数を維持するスケール

これはスケーリングという概念から意外と見落としがちですが、規定のインスタンス数を決めておくことで
サーバーの数を常に一定に保つことが可能です。
これも立派なスケーリングの一種です。

これは、なんらかのトラブルでEC2がダウンしてしまった際も自動で新しいEC2を起動するといった使い方ができます。

手動スケーリング

これは手動でインスタンス数を増減できます。
希望するキャパシティ数を変更することで起動するEC2インスタンス数へ変更することが可能です。
ただし、最小キャパシティ数と最大キャパシティ数の間の範囲のみ選択可能です。

自動スケーリング

これはCPUの使用率など、EC2のメトリクスに応じてオートスケールを行うことができます。
例えばCPUの使用率が50%以上になればインスタンスを1つ増やす。50%以下になれば減らす。といった操作を自動で行うことができます。
これはイメージしやすいかと思います。

予測スケール

こちらは過去14日間のCloudWatch メトリクスのデータを元に予測を行います。
その結果から使用率の高い時間帯にはスケールアウトを、使用率の低い時間帯にはスケールインを行います。

これは、定期的なデータ分析や
最初に例をあげた日中の使用頻度が高く、夜間での使用頻度が低いといったサイクルがすでに分かっている場合に適しています。
逆に、不定期にスパイクが発生するようなシステムには向いていません。

スケジュールによるスケール

最後にスケジュールによるスケールは、最初からユーザーで時間を設定してインスタンス数の増減を行います。
ある程度のスパイクの発生やアクセスの増減が見込まれる場合に使用されます。

これだけを見ると自動スケールによってアクセス数、使用率等のメトリクスからインスタンスの増減をすればいいのでは？と思ってしまいます。
しかし、自動スケールによるスケーリングはインスタンスの起動に多少の時間がかかります。
そのため、急激なアクセス増加が見込まれる場合は事前のスケジュールによるスケールをおこなうというのがベストプラクティスということです。

設計における注意点

オートスケールは運用や開発において非常に便利な機能だと思います。
しかし、注意点もあります。
オートスケールはステートフルなシステムには向きません。
EC2を自動で増減するため、キャッシュ等のサーバー側が保持する値をどこで管理するか？という設計が必要です。

そのため、ステートレスな設計のためにElastiCacheやDynamoDBといったサービスとあわせて使うことでオートスケールのデメリットをうめる工夫が必要です。

まとめ

オートスケールはなんとなくわかる。くらいのイメージでしたが、実際のユースケースなども交えながら勉強することで、より理解が深まりました。
実際にElastiCacheを使ったステートレスなセッション管理など試してみたいです。

参考：コスト最適化ガイドブック