こんにちは！ BFT名古屋支店の佐野です。
これまで、LambdaやAuroraServerlessなどのサーバーレスアーキテクチャの特徴や利点についてお話してきました。
変動するワークロードに対する動的な性能変更や、非使用時にはコストが抑えられるといった点はサーバーレスならではです。
しかしながら、サーバーレスに適さないユースケースであったり、今更サーバーレスに変えられない環境もあるでしょう。
そしてその環境でも、ピーク時に急増する負荷に対応することができれば…と考えることもあるかと思います。
特に今回はEC2における、一時的な負荷の増大に対応する方法についてお話していきます。
はじめに
EC2でサーバーレスアーキテクチャが行なうような動的スケーリングを実現するには、EC2 Auto Scalingを採用する必要があります。
逆を言えば、EC2を使って動的スケーリングをする方法はそれしかなく、例えばt2.mediumのようなt2系インスタンスタイプが持つ「バーストパフォーマンスインスタンス」という仕組みでは行なえません。
この「バーストパフォーマンスインスタンス」については改めてお話ししますが、今回はEC2 Auto Scalingについてと、その使い方を紹介します。
EC2 Auto Scaling
EC2 Auto ScalingはEC2の機能のひとつであり、インスタンスの集合をAuto Scalingグループとして管理し、インスタンス数の維持や自動スケーリングを行なうものです。
一般的な使用法のひとつとして、ヘルスチェックによってインスタンスグループ内のインスタンスに異常が見られた場合には、そのインスタンスをグループから削除して代わりのインスタンスを立ち上げることで、可用性の維持するといったケースがあります。
EC2 Auto Scalingではこのようなヘルスチェックによるインスタンス数の管理の他、日時スケジュールや需要に基づいたスケーリング条件を設定することができます。
例えば各インスタンスの使用率が70%を超えるようなら、新たなインスタンスを用意するといった設定が可能です。
メトリクスなどの運用データが集まってくれば、それに基づいてピーク時間帯を予測し、その時間帯までにスケーリングを行なう予測スケーリングという設定もあります。
またスケーリングの際に新たに起動するインスタンスは“起動テンプレート”の設定に基づいて作成されます。
これに特定のアプリケーションを実行するために設定したインスタンスのAMIを設定しておけば、スケーリングを行なう際もそのアプリケーション実行用インスタンスと同様のインスタンスが起動してくれます。
ここまでの話を見て「自動スケーリングというけど、新たに起動したインスタンスに負荷分散できるようにしないと意味がないのでは？」と思う方もおられると思います。
実はAuto Scalingグループを作成する際、同時にそのAuto Scalingグループ用のロードバランサーを作成することができるため、前もって作成しなくても大丈夫な仕様になっています。
もちろんそこで作成しなかった場合は負荷分散をしないAuto Scalingグループになってしまうので、一応注意すべき点とも言えます。
ちなみに、既存のロードバランサーを設定することも可能です。
Auto Scalingの仕組み
EC2 Auto ScalingはAuto Scalingグループの中のインスタンス数を、インスタンスの自動起動・自動停止という形で調整するものです。
例えば最低でも維持しておきたいインスタンスの数（最低数）を1、増やせるインスタンスの限界の数（最高数）を4、起動しておきたいインスタンスの数（希望数）を2とした場合、Auto Scalingグループは以下の図のようになります。
最初は①のようにインスタンスが2つ起動します。
その後、例えばインスタンスのCPU使用率が一定以下になるというスケールイン条件を設定している場合、それが満たされた場合は起動中のインスタンスが順次停止していき、最終的に②のようにインスタンスの数が最低数までスケールインされます。
ここからスケールイン条件を満たしても、インスタンスの数が最低数より少なくなることはありません。
その逆に、インスタンスのCPU使用率が一定以上になるスケールアウト条件を設定している場合、その条件が満たされた時にスケールアウトが行われ、新たなインスタンスが起動します。
起動するインスタンスの数は最高数よりも多くはならないため、最終的には③の状態となり、またスケールイン条件を満たし次第スケールインが行われることになります。
またヘルスチェックによるスケーリングを設定している場合、異常が検知されたインスタンスが先に削除され、その後代わりのインスタンスが起動するという動きを取ります。
なおスケールインやスケールアウトの基準は、すべて希望数に準じます。
先ほど挙げたCPU使用率によってスケールインやスケールアウトを行なわせる条件は、実際には条件に合った際に希望数を都度変更するような動きになるように設定します。
さいごに
EC2 Auto Scalingを利用することで、インスタンスレベルではありますがスケーリングを行なうことができるため、通常期と繁忙期で負荷の度合いが大きく異なる場合に駆使することで運用および実コストの低減を図ることができるかと思います。
また今回はEC2で動的スケーリングを実装するものとしてAuto Scalingを紹介しましたが、Auto ScalingはEC2以外にも使用することができます。
EC2以外でAuto Scalingを利用できるサービスや、その利用方法などは、また別の記事にて紹介します。
というわけで、今回はここまで。
また別の記事でお会いしましょう！
