Optimizerの推奨を利用してEC2のスペック変更を実施してみた

AWS Compute Optimizer を 利用して、稼働中のEC2インスタンスのスペックを見直してみました。
2020.09.09

AWSチームのすずきです。

AWS Compute Optimizer を 利用する事で、 EC2 インスンタンス の 稼働実績に基づいた 最適なインスタンスタイプの推奨を受ける事ができます。

今回、Optimizer が「プロビジョニング不足」と判定した EC2インスタンスを対象に、変更を試みる機会がありましたので、紹介させていただきます。

Optimizer

設定有効化

Optimizer の初回利用時、 AWS Compute Optimizer のダッシュボードで 分析を「開始」します。

EC2メモリ監視

診断対象のEC2、事前に CloudWatch Agent を利用したメモリ監視設定を実施しました。

「Optimizer」の利用にあたりメモリ監視の設定は必須ではありませんが、より正確な推奨を得るために有効です。

  • CloudWatch Agent メモリ監視設定スクリプト (AmazonLinux 2,AmazonLinux)
    INSTANCEID=`http://169.254.169.254/latest/meta-data/instance-id`; AMIID=`curl http://169.254.169.254/latest/meta-data/ami-id`; INSTANCETYPE=`curl http://169.254.169.254/latest/meta-data/instance-type`
    sudo mkdir -p /opt/aws/amazon-cloudwatch-agent/etc/
    cat <<EoF | sudo tee /opt/aws/amazon-cloudwatch-agent/etc/amazon-cloudwatch-agent.json 
    {"metrics":{"append_dimensions":{"ImageId":"${INSTANCEID}","InstanceId":"${AMIID}","InstanceType":"${INSTANCETYPE}"},"metrics_collected":{"mem":{"measurement":["mem_used_percent"],"metrics_collection_interval":300}}}}
    EoF
    sudo rpm -Uvh https://s3.amazonaws.com/amazoncloudwatch-agent/amazon_linux/amd64/latest/amazon-cloudwatch-agent.rpm
    sudo /opt/aws/amazon-cloudwatch-agent/bin/config-translator --input /opt/aws/amazon-cloudwatch-agent/etc/amazon-cloudwatch-agent.json --output /opt/aws/amazon-cloudwatch-agent/etc/amazon-cloudwatch-agent.toml --mode ec2
    sudo /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-ctl -a start

ダッシュボード

Optimizer 設定後、半日程度で経過すると、推奨レポートが確認可能になります。

「プロビジョニング不足」と判定された「t3.meduim」のインスタンスを是正対象としました。

推奨内容

「t3.medium」から「c5.large」「r5.large」「c5.xlarge」への変更が推奨されました。

統計値を「平均」→「最大」に変更すると、CPU、メモリ使用率とも高い時間帯が存在していました。

今回、CPU、メモリとも2倍の強化となる「c5.xlarge」に変更。 一定期間経過した後 Optimizer を再確認し、過剰と判定された場合には、「m5.large」「c5.large」のなどの推奨インスタンスに再度変更する事としました。

変更

対象EC2を一時停止するメンテナンス日程の調整後、EC2ダッシュボードを利用して、

  • 対象インスタンスの「停止」
  • インスタンスタイプの変更
  • 対象インスタンスの「開始」(再度起動)

を順に実施しました。

PV専用のAMIや、Nitro世代に対応しないAMIなどでは「Optimizer」により推奨された 最新世代のインスタンスタイプが利用できない場合があります。

今回は「T3」→「C5」同世代の変更であったため省略していますが、 事前にAMIを取得し、コピー環境での起動やアプリケーションの動作影響を事前に検証されることをおすすめします。

結果

Optimizer は「最適化」と判定されるようになりました。

CPU

「t3.meduim」→「c5.xlarge」への変更により、CPU使用率の半減と、CPUクレジットの管理が無くなったことが確認できました。

メモリ

メモリを4GBから8GBに増量した事で、従来発生していたスワップ利用の抑制が確認できました。

c5.xlarge(変更後)
$ top -b -n1
top - 11:51:52 up 1 day,  1:34,  0 users,  load average: 0.00, 0.00, 0.00
Tasks: 107 total,   1 running,  71 sleeping,   0 stopped,   0 zombie
Cpu(s):  1.5%us,  0.1%sy,  0.0%ni, 98.3%id,  0.1%wa,  0.0%hi,  0.0%si,  0.0%st
Mem:   7809520k total,  1977132k used,  5832388k free,   182600k buffers
Swap:   655352k total,     7936k used,   647416k free,   393344k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
    1 root      20   0 19696 2492 2240 S  0.0  0.0   0:00.90 init
    2 root      20   0     0    0    0 S  0.0  0.0   0:00.00 kthreadd
    3 root      20   0     0    0    0 I  0.0  0.0   0:00.54 kworker/0:0
t3.meduim(変更前)
$ top -b -n1
top - 09:31:22 up 34 days,  1:23,  0 users,  load average: 0.00, 0.00, 0.00
Tasks:  94 total,   2 running,  65 sleeping,   0 stopped,   0 zombie
Cpu(s):  2.4%us,  0.2%sy,  0.0%ni, 96.8%id,  0.1%wa,  0.0%hi,  0.0%si,  0.5%st
Mem:   3980112k total,  1503896k used,  2476216k free,   175964k buffers
Swap:   655352k total,   544520k used,   110832k free,   391768k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
14525 wpuser    20   0  699m  96m  14m R 41.8  2.5   0:37.01 httpd
 2173 mysql     20   0 1770m 153m 6204 S  2.0  3.9  73:55.48 mysqld
    1 root      20   0 19692 1392 1140 S  0.0  0.0   0:01.25 init
VmSwap
$ grep VmSwap /proc/*/status | sort -k 2 -nr | head -n 3
/proc/2173/status:VmSwap:         520988 kB
/proc/1598/status:VmSwap:           8100 kB
/proc/2245/status:VmSwap:           4036 kB
ps
$ ps u -p 2173
USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
mysql     2173  0.1  3.9 1813152 156860 ?      Sl   Aug05  73:56 /usr/libexec/mysql56/mysqld --basedir=/usr --datadir=/var/lib/mysql --plu

まとめ

多くのシステムではワークロードは変化します。 AWS Compute Optimizer による推奨レポートを EC2のリソース不足に起因するサービス障害の回避や、 過剰なEC2で発生する費用の抑制にご活用ください。