CloudWatchカスタムメトリクスに基づいたスケーリング – 接続数バージョン
以下のページで、Auto Scalingグループにおいて、メモリの使用量に応じてスケーリングする方法をご紹介しました。
https://awstut.com/2022/03/05/scaling-by-custom-metrics
EC2インスタンスにCloudWatchエージェントをインストールし、メモリの使用量をカスタムメトリクスとして配信することで、この値に応じてスケーリングするというものです。
今回はユーザの接続数に応じてスケーリングする方法を確認します。
構築する環境
基本的には冒頭でご紹介した構成と同様です。
スケーリングポリシーがポイントです。
本構成では、ユーザ接続数に応じてスケーリングするように設定します。
CloudFormationテンプレートファイル
上記の構成をCloudFormationで構築します。
以下のURLにCloudFormationテンプレートを配置しています。
https://github.com/awstut-an-r/awstut-dva/tree/main/03/007
テンプレートファイルのポイント解説
本ページでは、カスタムメトリクスとしてユーザ接続数を設定して、これに応じてスケーリングする方法を中心に取り上げます。
CloudWatchエージェントの設定
Resources:
CloudWatchConfigParemeter:
Type: AWS::SSM::Parameter
Properties:
Name: AmazonCloudWatch-linux
Type: String
Value: |
{
"agent": {
"metrics_collection_interval": 60,
"run_as_user": "root"
},
"metrics": {
"append_dimensions": {
"ImageId": "${aws:ImageId}",
"InstanceId": "${aws:InstanceId}",
"InstanceType": "${aws:InstanceType}",
"AutoScalingGroupName": "${aws:AutoScalingGroupName}"
},
"metrics_collected": {
"netstat": {
"measurement": [
"netstat_tcp_established"
],
"metrics_collection_interval": 60
}
},
"aggregation_dimensions": [["AutoScalingGroupName"]]
}
}
Code language: YAML (yaml)CloudWatchエージェント用の設定をSSM Parameter Storeに登録します。
CloudWatchエージェントに関する詳細については、以下のページをご確認ください。
https://awstut.com/2021/12/28/cloudwatch-agent-linux
metrics_collectedで収集するメトリクスを指定します。
指定できるメトリクスは以下のページにまとめられています。
今回はユーザの接続数に応じてスケーリングさせますので、収集するメトリクスにnetstat_tcp_establishedを指定します。
このメトリクスは確立されたTCP接続の数を意味します。
つまりTCP接続数をユーザの接続数に見立て、この値に応じてインスタンス数をスケーリングさせるということです。
スケーリングポリシー
Resources:
ScalingPolicy:
Type: AWS::AutoScaling::ScalingPolicy
Properties:
AutoScalingGroupName: !Ref AutoScalingGroup
PolicyType: TargetTrackingScaling
TargetTrackingConfiguration:
CustomizedMetricSpecification:
Dimensions:
- Name: AutoScalingGroupName
Value: !Ref AutoScalingGroupName
MetricName: netstat_tcp_established
Namespace: CWAgent
Statistic: Average
Unit: Count
TargetValue: !Ref TargetTrackingConfigurationTargetValue
Code language: YAML (yaml)今回はターゲット追跡タイプのスケーリングポリシーを設定します。
こちらの詳細につきましては、以下のページをご確認ください。
https://awstut.com/2022/02/20/ec2-auto-scaling-target-tracking-policy-cpu-utilization
TargetTrackingConfigurationプロパティ内のMetricNameプロパティに、先述のnetstat_tcp_establishedを指定し、この値に応じてスケーリングするように設定します。
環境構築
CloudFormationを使用して、本環境を構築し、実際の挙動を確認します。
CloudFormationスタックを作成し、スタック内のリソースを確認する
CloudFormationスタックを作成します。
スタックの作成および各スタックの確認方法については、以下のページをご確認ください。
https://awstut.com/2021/12/02/cloudformation-nested-stacks
各スタックのリソースを確認した結果、今回作成された主要リソースの情報は以下の通りです。
- ALB：dva-03-007-ALB
- ALBターゲットグループ：dva-03-007-ALBTargetGroup
- ALBのドメイン名：http://dva-03-007-alb-602194787.ap-northeast-1.elb.amazonaws.com/
- Auto Scalingグループ：dva-03-007-AutoScalingGroup
AWS Management Consoleから各リソースを確認します。
Auto Scalingグループを確認します。
正常にAuto Scalingグループが作成されています。
希望数および最小数が1、最大数は2です。
スケーリングポリシーを確認します。
確かにスケーリングポリシーが設定されています。
このグループ内のインスタンスにおけるnetstat_tcp_establishedの平均値が、10を基準としてスケールアウト/インする内容です。
現在のグループ内に作成されているインスタンスを確認します。
インスタンスが1つ作成されています。
希望数通りにインスタンスが生成されてました。
動作確認
準備が整いましたので、動作を確認します。
ALBのDNS名に対して、複数回接続し、同時ユーザ数を増やします。
今回はApache Benchを使用して同時接続を再現します。
例えば、以下のコマンドを実行します。
% ab -c 15 -t 10000000 -k http://dva-03-007-ALB-602194787.ap-northeast-1.elb.amazonaws.com/
Code language: Bash (bash)cオプションは並列数を指定するパラメータですが、これを15とすることで、スケールアウトする条件(10)を超えるように調整します。
しばらく待った上で、CloudWatchのメトリクスを確認します。
カスタムメトリクスとして、netstat_tcp_establishedの値が配信されていることがわかります。
そして閾値を超えていることもわかります。
これをきっかけとしてスケールアウトが開始されるはずです。
Auto Scalingグループのアクティビティを確認します。
確かに2台目のインスタンスが起動しました。
このようにユーザ接続数に応じてスケーリングすることができました。
まとめ
EC2インスタンスにCloudWatchエージェントをインストールし、ユーザの接続数をカスタムメトリクスとして配信することで、この値に応じてスケーリングすることができました。