#はじめに
AWSにて冗長性かつスケーラビリティのあるシステム構成を構築するにあたり、「AutoScaling」、「ELB (Elastic Load Balancing)」、「CloudWatch」の組み合わせが可能ですが、個人的に各々の設定の関連性で時に混乱してしまうため、整理をしてみました。
#前提
整理をするにあたり、今回構築したAWSの構成図は以下の通りです。
「ELB (Elastic Load Balancing」、「AutoScaling」、「CloudWatch」を同時に考えると混乱してしまいますので、以下の2つの組み合わせごとに分解して整理をしてみます。
| 番号 | 組み合わせ |
| １ | AutoScalingとALB |
| ２ | AutoScalingとCloudWatch |
※1. 今回、ELBの種類としてはALB (Application Load Balancer) を選択しました。
※2. Private SubnetにマルチAZでのRDSを配置し、EC2インスタンスにはWordPressをインストールすることで、ブログサービスとして構築しましたが、今回のテーマにフォーカスするため、以降の図ではPrivate Subnetは省略します。
###1. AutoScalingとALB
AutoScalingとALBについて主要な設定項目を構成図に記載しました。
各々の設定で関連性のある項目を赤字としています。
■ ALB側の設定 ～冗長化/負荷分散～
ALBでターゲットグループを設定することで、冗長性を実現し、ユーザからくるHTTPリクエストをターゲットグループ内で負荷分散します。仮にEC2#1がシャットダウンされた場合も、EC2#1のヘルスチェックステータスは「unused」になり、以降のHTTPリクエストはEC2#2のみで処理します。
以上のように、ALBのみでは冗長化/負荷分散が可能ですが、スケーラビリティは備えていません。
そこでスケーラビリティを加えるためにAutoScalingの設定を組み合わせます。
■ AutoScaling側の設定 ～スケーラビリティ～
上図のAutoScaling Groupで赤字の設定をすることにより、ALBのターゲットグループにスケーラビリティを加えることができます。その際、AutoScaling GroupのヘルスチェックとしてALBの設定を指定します。以上より、仮にEC2#1がシャットダウンされて、HTTPリクエストを処理できるインスタンスがEC2#2の1台に減ったとしても、希望する容量として「2」に設定しているため、新たなインスタンスを1台、自動生成することが可能になります。
2.AutoScalingとCloudWatch
AutoScalingとCloudWatchについて主要な設定項目を構成図に記載しました。
各々の設定で関連性のある項目を赤字としています。
上図の構成のように、AutoScalingとCloudWatchアラームを組み合わせることにより、より柔軟にスケーリング設定をすることができます。
■ CloudWatch側の設定
CloudWatch側ではAutoScalingGroupの名前とスケーリングのアクションを指定して、アラームを作成します。
今回の場合は、AutoScalingGroup内の平均CPU使用率が70%以上の時にアラームする「CPU_High」と30%以下の時にアラームする「CPU_Low」を作成しました。各々について、アラーム発動時にAutoScalingのアクション「CPU_Add」、「CPU_Remove」が実行されます。
■ AutoScaling側の設定
AutoScaling側ではCloudWatchアラームを指定して、スケーリングポリシーを作成します。
今回の場合は、「CPU_High」のアラームが発動された際にインスタンスを1台追加する「CPU_Add」と、「CPU_Low」のアラームが発動された際にインスタンスを1台削除する「CPU_Remove」を作成しました。
以上により、CloudWatchとAutoScalingを組み合わせることにより、AutoScaling内の平均CPU使用率に応じて、インスタンス数を最小2台、最大4台にスケールする構成とすることができました。
#まとめ
今回の記事作成を通し、「AutoScaling」、「ELB (Elastic Load Balancing」、「CloudWatch」を組み合わせた構成における、各々の役割と設定項目の関連性を整理することができました。
以上、最後まで読んで頂きありがとうございました！
※この記事はAWS初学者を導く体系的な動画学習サービス「AWS CloudTech」の課題カリキュラムで作成しました。