EC2のオートスケーリングについて整理する

2021.06.15

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

Amazon EC2 Auto Scalingについて勉強していて整理がついてきたのでまとめてみました。 以下のドキュメントをもとに要約や自分で調べた加筆を行っています。

オートスケーリングについて

オートスケーリングは何らかの条件に応じて動的に計算リソースを変化させることです。 例えば、WebサーバーのCPU使用率が一定数を超えたらサーバーの台数を1増やすなどがこれに該当します。 こういった手法はAWSなどのクラウドと相性が良いです。 というのも、今回考えるEC2ではサーバーの起動など計算リソースの確保、開放が非常に用意なためです。 これを上手に活用することで様々な恩恵を受けることができます。

以下ではオートスケーリングに必要な要素を整理し、そのメリットについて考えていきましょう。

オートスケーリングの3つの要素

ここではAmazon EC2の場合にオートスケーリングを実現するのに必要な要素について説明します。 それは以下の3つです。

  1. グループ
  2. 設定テンプレート
  3. スケーリングのオプション

Auto Scaling概念図

Auto Scaling概念図

1. グループ

ここでのグループとはAWS上のAuto Scalingグループのことです。 グループの主な役割はインスタンスの管理と自動スケーリングを実行することです。 具体的には、Auto ScalingグループはEC2インスタンスの集合から構成され、インスタンス数の維持や自動スケーリングを行います。
例えば、ヘルスチェックによって異常が検知された場合にはそのインスタンスをグループから削除し、代わりのインスタンスを立ち上げてくれます。 他にも、インスタンス数を増減させる必要がある場合にはグループがインスタンスの起動と停止を行ってくれます。

2. 設定テンプレート

ここでの設定テンプレートは起動テンプレートについての話です。 起動テンプレートはEC2インスタンスを起動する際の様々なパラメーターの集まりです。
例えばベースとなるマシンイメージ、インスタンスのタイプがこのパラメーターとして挙げられます。 グループではこのテンプレートを基にインスタンスが起動されます。

3. スケーリングのオプション

グループ内のインスタンスを増減させる方針を決めるのがスケーリングのオプションです。 AWSではいくつかのスケーリング方法が用意されているのでそれを紹介します。

  • インスタンス数の維持
    • 指定された数を維持するようにインスタンスを起動する
    • ヘルスチェックに失敗した場合、異常とみなしてインスタンスの入れ替えを行う
  • 手動でのスケーリング
    • マネジメントコンソールやCLIで逐一インスタンス数を指定する
  • スケジュールによるスケーリング
    • 日時に基づいてスケーリングを行う
    • 必要なリソースが正確に予測可能な場合に便利
  • 需要に基づくスケーリング
    • 何らかの数値(メトリクス)を需要として考えそれに応じてスケーリングする
    • 例えばCPU使用率を50%に維持するなど
  • 予測スケーリング
    • 過去のデータを利用して必要なリソースを予測してスケーリングする
    • 需要より先にスケーリングを行えるため起動までの時間を最小にすることができる

オートスケーリングのメリット

以下ではオートスケーリングを行うメリットを3つ考えてみましょう。

  1. コスト最適化
  2. 可用性の向上
  3. 耐障害性の向上

1. コスト最適化

オートスケーリングをうまく活用できれば最適なリソースでサービスを運用することが可能になります。 例えば、以下のような場合です。
時間によって必要なサーバーの台数が変化するようなサービスの場合、コスト的に理想なのは時間に合わせて動的にサーバーの台数を変化させることだと思います。常に最大の台数を確保しているとそれ以外の時間はリソースが無駄になってしまいます。逆に最小に合わせてしまったら、サービスが利用できないということになります。つまりは固定されたリソース量ではコストを最適化することは難しい場合があるということです。
AWSでは従量課金制のため、使っている時間に応じて費用がかかります。そのため、必要に合わせてリソース量を変化させることで、常に最適なコストで運用できます。

2. 可用性の向上

計算リソースの動的な変化は可用性の向上にも役立ちます。 ここで言う可用性とはサービスが利用できない時間をできるだけ減らすことです。
例えば、Webサービスにおいて予期しない大量のアクセスがあった場合にリソースの上限に達してしまうとアクセスできないユーザーが発生してしまいます。こいった場合にもオートスケーリングが適切に設定されていれば、サーバーの台数を増やすことによって利用できない時間を無くす、もしくは最小限にすることができます。

3. 耐障害性の向上

オートスケーリングの際にサーバーのヘルスチェックを行うことで異常を検知し、障害に対する性能を向上させることができます。 異常なサーバーを対象のグループから排除することで、障害からシステムを守ることができます。 需要が変動しない場合でも、耐障害性を向上させるという点では有効です。
例えば、サーバーを実行しているマシンに不具合が起きた場合、そのサーバーをグループから排除し、代わりに新たなサーバーを立ち上げることで、システムを継続させることが可能となります。 複数のAZを使うような構成でオートスケーリングを設定すれば、AZの障害が起きてもサービスを続けることができます。

感想

オートスケーリングを行うメリットや、それに関わるコンポーネントについてはなんとなく理解していたのですが、より体系的に理解できた気がします。自動でスケーリングするということには様々な側面があることを確認できました。

参考資料