基礎編：AWSのEC2 Auto Scalingってなんやねん
1. はじめに
どもども、最近初めて「バック・トゥ・ザ・フューチャー」という映画を見て、妄想に頭を膨らませている井上弥風(いのうえみふう)です
今回は「EC2 Auto Scalingってなんやねん」です
1.1 この記事を書こうと思ったきっかけ
現在、私が関わっているプロジェクトではECS on Fargateを利用しています
多くのプロジェクトで利用されていますよね
私自身も過去のプロジェクトでFargateを使用していましたが、そのときは「概要」に留まり、ECSの裏側でどのような処理が行われ、どのようなサービスと連携しているのかについては深く理解していませんでした
そのため、ECSについて深掘りした記事を情報整理も兼ねて書いていたところ、「Capacity Provider」という概念に出会いました
どうやらこれはスケーリングに関連しているようで、Capacity Providerを理解するためには、まずスケーリングの基本から理解する必要があると感じ、この記事を書くことにしました
AWSにはいくつかの種類のAuto Scalingがありますが、範囲が広がりすぎないように、この記事ではEC2 Auto Scalingに焦点を当てて解説します(若干遠回りですが基礎から理解するために^^)
1.2 記事の最終ゴール
まず前提として、「EC2 Auto Scalingってなんやねん」は以下三つのシリーズに分けて記事を書いていきます
- 基礎編：AWSのEC2 Auto Scalingってなんやねん
- 実践編：AWSのEC2 Auto Scalingってなんやねん
- 監視編：AWSのEC2 Auto Scalingってなんやねん
基礎編ではAWSマネジメントコンソールは利用せず、EC2 Auto Scalingとそれらを取り巻くリソースの基礎知識を文章ベースで説明していきます
実践編では実際に画面から対象リソース群を作成していき、実践での作成手順や設定項目を理解していきます
監視編ではEC2 Auto Scalingで問題があった際にどのような設定をしておくと良いのかといった内容を詳しく見ていきます
その上で、基礎編である当記事では以下の内容を明確にしていきます
- EC2 Auto Scalingについての理解
- 起動テンプレートについての理解
- ALBについての理解
1.3 対象読者
この記事を含め、3シリーズを読まれる方は主に以下の知識を持つ読者を対象としています
-
AWSの基礎知識について理解のある方
- ルートテーブル、インターネットゲートウェイ、セキュリティグループなど、AWSの基本的なネットワーク構成について理解している方
-
EC2について理解がある方
- EC2の基本的な操作や設定についての知識がある方
-
ロードバランサーの基本を理解している方
- 特に、AWSのロードバランサーの機能と概念についての基礎知識がある方
EC2やロードバランサーについていまいち理解できていない方は、下記の記事を先に読むことで基礎知識を理解することが出来るかと思います😁
2. EC2 Auto Scalingの全体像
ではでは、始めます🐳
2.1 EC2 Auto Scalingとは？
まずはじめに、EC2 Auto Scalingとは何でしょうか？
結論からお話しすると、「EC2インスタンスの数を処理負荷に応じて自動で増減させるサービス」です
では、そもそも「EC2インスタンスの数を処理負荷に応じて自動で増減するタイミング」って、具体的にどういったケースなのでしょうか？
例えば、私たちが野球観戦チケットの販売システムを運営してるとします
普段は日に1000〜3000人がアクセスするサービスのため、EC2インスタンスは2台で稼働しており、特段負荷が大きく掛かりシステムダウンするようなことはありません
しかし、もしスペシャルゲストとしてイチローさんが出るとなったらどうでしょうか？
世界的なスーパースターが登場するため、アクセス数は跳ね上がりそうですね
特別イベントのため、仮に一時間で10000人がアクセスして来た場合、おそらくサーバーはアクセスを捌ききれないか、最悪の場合システムダウンしてしまうかもしれません
では、もしサーバーが高負荷になった時に、自動でサーバーが増えてくれたとしたら、、、システムダウンを防げたかもしれないですね
これを実現してくれるのが「EC2 Auto Scaling」です
EC2 Auto Scalingというのはあくまでサービス名であり、このサービスに存在する実際の機能が以下の二つです
- Auto Scaling Group
- Auto Scaling Policy
2.2 Auto Scaling Groupとは？
Auto Scaling Groupとは、EC2インスタンスを運用負荷に応じて自動的に増減させるための機能です
具体的には、あらかじめ定められたメトリクス（例えばCPU利用率）に基づいてインスタンスの数を調整してくれます
例を挙げると、EC2インスタンスのCPU利用率が70%を超えると、新しいインスタンスを自動的に追加し、負荷が30%を下回ると、インスタンスを自動的に削除したりしてくれます
現実世界で例えると、プロジェクトマネージャー（Auto Scaling Group）がプロジェクトの進捗を監視し、必要に応じてチームメンバーを増やしたり減らしたりする役割に似ていますね
チームの負荷（アクセス数やCPU利用率）が高まり、プロジェクトが炎上しそうになれば新たな人材（EC2インスタンス）を追加し、状況が落ち着けば人員を削減するといった流れですね
では、Auto Scaling Groupは「何をもって」EC2インスタンスを増減するのでしょうか？
つまり、どういった条件になるとスケーリング(増減)を行うのでしょうか？
- CPU利用率？
- メモリ利用量？
- ネットワークトラフィック量？
この「何をもって、何台追加するのか、削除するのか」を定義するのがAuto Scaling Policyであり、Auto Scaling Groupはこの定義に従ってEC2インスタンスを増減します
詳しく見ていきましょう
2.3 Auto Scaling Policyとは？
Auto Scaling Policyとは、EC2インスタンスのスケーリングを「何をもって行うか」を決めるルールのことです
つまり、スケーリングの条件を定める部分ですね
Policyにはいくつかの種類があり、それぞれ異なる目的に合わせて使い分けられます
- 予定されたアクション
- 特定の時期や時間帯に合わせてインスタンスの数を調整する
- 例えば、クリスマスシーズンや日中だけインスタンスを増やすなど、スケジュールに基づいたスケーリングを行う
- 予測スケーリングポリシー
- 過去のデータ（例えば、時間帯ごとのアクセス数）を元に未来の負荷を予測(機械学習)し、それに応じて自動的にリソースを調整する
- 動的スケーリングポリシー
- リアルタイムのメトリクス（例：CPU利用率が80%を超えた場合やメモリ利用率が30%未満になった場合）に基づいて、インスタンスの追加や削除を行う
「Auto Scaling Policy」は「Auto Scaling Group」と独立した機能ではなく、実際にはAuto Scaling Groupの一機能として存在します
つまり「EC2 Auto Scaling」というサービスがあり、そのサービスの実際の機能が「Auto Scaling Group」であり、Groupの中の一つの設定項目として「Auto Scaling Policy」が存在する、といった関係性ですね！
2.4 これらのコンポーネントがどのように連携して機能するのか
Group, Policyについて軽く説明したところで、これらのコンポーネントが実際にどのように連携するのかを詳しく見ていきましょう
実際にはALBや起動テンプレートなども絡みますが、一旦以下5つのリソースに絞って説明していきます(後ほど詳しく説明します)
- EC2
- Auto Scaling Group
- Auto Scaling Policy
- CloudWatch Metrics
- CloudWatch Alarm
まず、Auto Scaling Groupは複数のEC2インスタンスを管理しています
補足ですが、どのインスタンスでも管理しているわけではなく、Auto Scaling Groupに紐づけたインスタンスのみを管理しています
つまり、Auto Scaling Groupとは論理的な枠組みであり、その枠組みの中にあるインスタンスを対象にスケーリングを行う流れです
そして、これらのインスタンスのパフォーマンスや状態はCloudWatch Metricsによってリアルタイムで監視されています
動的スケーリングポリシー（リアルタイムのメトリクスに基づいて、インスタンスの追加や削除を行う）を用いる場合、CloudWatch Metricsが収集したデータを基にCloudWatch Alarmがこれを監視し、特定のメトリクスがCloudWatch Alarmに設定されたしきい値を超えた場合、CloudWatch AlarmはAuto Scaling Groupにアラートという通知を送ります
重要な点として、アラートはAuto Scaling Groupに通知されるという点です
Auto Scaling Policyはあくまで「アラートが発生した時にどのようなアクションを取るか」を定義しているだけで、実際のアクションはAuto Scaling Groupが行います
つまり、Policyとは単なる定義書で、Groupがその内容を基にスケーリングを行う流れですね
具体的なプロセスとしては以下のようになります
- Cloud Watch Metricsがメトリクスを収集
- Cloud Watch Alarmがしきい値を超えて(下回って)いないか監視
- 閾値を超えたら「Cloud Watch Alarm」が「Auto Scaling Group」に対してアラートを通知
- Auto Scaling GroupがAuto Scaling Policyを基にインスタンス数の増減を行う
何となくわかってきましたね！
より具体的な詳細は後ほど説明しますので、まずは全体像を掴んでいきましょう^^
3. 起動テンプレートの重要性
続いて起動テンプレートについて説明します
起動テンプレートはEC2 Auto Scalingにおいて非常に重要な役割を果たすため、詳しく見ていきましょう
3.1 起動テンプレートとは？
まず、起動テンプレートとはEC2インスタンスを作成するための設計図です
AMI、インスタンスタイプ、キーペア、セキュリティグループ、サブネットなど、EC2インスタンスを作る際に必要な設定項目を事前に定義しておくことができ、このテンプレートを基にEC2インスタンスを作成することができます
ただし、起動テンプレートを作成しただけではEC2インスタンスは自動で作成されません
これはあくまでテンプレートでしかなく、実際にインスタンスを立ち上げるためには起動テンプレートを基にEC2インスタンスを作成するプロセスを別途踏む必要があります
簡単に言うと「起動テンプレートとは家の設計図であり、家そのものではない」といった所ですね
3.2 起動テンプレートとEC2 Auto Scalingの関係性
起動テンプレートは、EC2 Auto Scalingを利用する際に特に重要な役割を果たします
例えば、EC2インスタンスのCPU利用率が80%を超えた場合、Auto Scaling Groupで新しいインスタンスを自動的に追加したいケースがあるとしましょう
しかし、新しいインスタンスを追加する際、どのAMIを利用するか、どのセキュリティグループをアタッチするか、どのキーペアを設定するか、インスタンスにパブリックIPを割り当てるかどうかなど、具体的な情報が必要ですよね
もしAuto Scaling Groupがスケーリングを行う際に、追加されるインスタンスの設定がバラバラだったり、適切に設定されていない場合、そのインスタンスは利用できません
しかし、Auto Scaling Groupに特定の起動テンプレートを関連付けることにより、スケーリング時にはこのテンプレートに基づいて一貫した設定で新しいEC2インスタンスが作成することが可能になるわけです
起動テンプレートにはAMI、セキュリティグループ、キーペア、その他の設定項目が含まれるため、結果として一貫した同じ構成のインスタンスを展開することが可能になるわけですね
起動テンプレートの利用により、すべてのインスタンスが同じ条件で稼働するため、システム管理が容易になり、エラー発生率も低減されるわけです
これは特に大規模なシステムや高負荷が予想されるアプリケーションにおいて、運用の安定性と効率を大幅に向上させます
4. ALBの重要性
ALBはロードバランサーの一種のため、EC2 Auto Scalingとは一見関係がないように思えます
しかしALBを含むELBとEC2 Auto Scalingは非常に重要な連携をしているため、ここでは主にALBについて概要を説明していきます
4.1 ALBとは？
まずALB（Application Load Balancer）とは、主にHTTPやHTTPS接続時に活躍するロードバランサーです
ウェブアプリやマイクロサービスを運用する際に重要な役割を担っており、EC2やFargateなどのサーバーへのトラフィックを均等分散させてくれます
現実世界に例えると、ALBはショッピングモールの駐車場係員のようなものです
この係員は来店する車を効率よく駐車スペースへ誘導し、右や左、上の階などへと分散させることで、駐車場全体の混雑を避け、スムーズな流れを作り出してくれます
同じように、ALBもサーバーへのリクエストを適切に分配し、各サーバーの負荷を均等に保つことで、システム全体のパフォーマンスと効率を向上させます
さらに詳しい情報やロードバランサーの更なる活用方法について知りたい方は、以下の記事を参考にしてください
4.2 ALBとEC2 Auto Scalingの関係性
では、トラフィックを均等に分散してくれるALBと、インスタンス数の増減を行うEC2 Auto Scalingにはどういった関係性があるのでしょうか？
4.2.1 EC2とALBの構成の場合
まず、EC2とALBだけの単純構成を例にとって説明します
前提として、ALBは機能の一つとして、外部からのアクセスを実際に処理するリソース（EC2やFargate）に問題がないかを定期的に確認する「ヘルスチェック」という機能を兼ね備えています
このヘルスチェックは病院での定期検診のようなもので、ALBがトラフィックを健康なインスタンスにだけルーティングすることを保証してくれます
その結果、クライアントはシステムをスムーズに使用でき、仮にリソース（EC2やFargate）に問題がある場合、ALBは対象のリソースに対してルーティングをストップしてくれます
では、EC2とALBのみの構成で、あるEC2インスタンスに問題が発生した場合、ALBはどのような対応をするのでしょうか？
結論としては、ALBはそのインスタンスへのルーティングを停止し、正常なインスタンスに自動的にトラフィックをリダイレクトします
しかし、異常が発見されたインスタンスはそのまま稼働を続けるため、「そのインスタンスを停止させる or 新しいインスタンスを起動する」といった作業は手動で行う必要があるわけです
また、例として3台構成で設計されているインスタンス群で1台がダウンすると、残りの2台に負荷が集中してしまうといったこともあり得るわけですね
ここで重要なのは、ALBは問題のあるリソースへのルーティングを停止してくれるだけで、リソースの追加や削除を自動で行うわけではないという点です
次に、ALBとEC2インスタンスに加えてEC2 Auto Scalingも利用した構成を見ていきましょう
4.2.2 EC2、ALB、およびAutoScalingの構成の場合
まず、ALBはEC2 Auto Scalingと連携しているかどうかに関わらず、ヘルスチェックによって問題のあるEC2インスタンスを検出するとそのインスタンスを「unhealthy」と認識し、対象のインスタンスへのルーティングを停止します
「一番右側のレジ(インスタンス)が壊れているので、こちらのレジに進んで(アクセスして)くださーい！」って感じですね
しかし、これではレジは壊れたままです
EC2 Auto Scalingを利用すると、Auto Scaling GroupはALBからのヘルスチェック情報を監視し、ALBによって問題があると判断されたインスタンスを停止させ、新しいインスタンスを迅速に起動してくれます
つまり、Auto Scaling Groupはレジが壊れたら後日手動で直すのではなく、すぐに・自動で直すわけですね
新しいEC2インスタンスが起動されると、ALBはこれを自動的にトラフィックの対象として登録し、定められたヘルスチェックを行った後、無事に通過すれば再びそのインスタンスにトラフィックを送ります
これにより、たとえ一時的にインスタンスの障害によりインスタンス数が減ったとしても、システム全体の負荷が偏ることなく、最終的には自動的にバランスが取れるようになるわけですね
5. まとめ
いかがでしたでしょうか？
ここまでで、「基礎編：AWSのEC2 Auto Scalingってなんやねん」はクリアです
次は「実践編：AWSのEC2 Auto Scalingってなんやねん」で実際に各リソースの構築手順や設定項目を見ていくわけですが、実践編をクリアすると「俺もうEC2 Auto Scalingらへん余裕やわ...✨✨✨」と好きなあの子にかっこつけられるレベルになります
、、、が、著者であるワイが今必死に実践編をまとめている最中ですので、今しばらくお待ちください！！
もうすぐ公開します^^
最後に、ここまで読んでくださった方、ありがとうございました！！
実践編・監視編を公開したらTwitterで告知しますので、お楽しみにー！！
良かったらTwitterフォローしてねっ
Discussion