この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
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:0t3.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 initVmSwap
$ 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 kBps
$ 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で発生する費用の抑制にご活用ください。
17
