「M6g」インスタンスのカーネル更新の所要時間を測定し従来環境と比較してみた

AWS Graviton2 を搭載した「M6g」インスタンスで カーネル更新の所要時間を求め、既存インスタンスとの比較を試みてみました。
2020.05.22

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

AWSチームのすずきです。

Amazon Linux2のAMIで起動した ARM ベースの AWS Graviton2 を搭載した 「M6g」インスタンス。

「kernel-ng」パッケージを用いた5.4 カーネルへの更新を実施、 その所要時間を求め「M5」「A1」などの既存環境と比較を試みる機会がありましたので、紹介します。

環境

インスタンスタイプ 区分 vCPU メモリ (GiB) オンデマンド料金(USD)
m6g.large arm64 2 8 0.099
m5.large x86_64 2 8 0.124
a1.large arm64 2 4 0.0642
m3.large x86_64 2 7.5 0.193
  • オンデマンド料金は東京リージョン、Linux/Unixの1時間料金

AMI

東京リージョン、以下のAMIを利用しました。

  • amzn2-ami-hvm-2.0.20200406.0-arm64-gp2 (ami-08360a37d07f61f88)
  • amzn2-ami-hvm-2.0.20200406.0-x86_64-gp2 (ami-0f310fced6141e627)

検証方法

SSM を利用して、「Run Command」を利用して、「kernel-ng」パッケージのインストールとOS再起動を実施しました。

SSMエージェントのログ(amazon-ssm-agent.log) の 実行時刻と、Cloud-Initのログ(cloud-init-output.log) の 完了時刻を抽出、その差から所要時間を求めました。

  • Run Command
amazon-linux-extras install kernel-ng
shutdown -r now
  • amazon-ssm-agent.log
2020-05-21 13:05:59 INFO [ssm-document-worker] [x-x-x-x-x] [DataBackend] [pluginName=aws:runShellScript] aws:runShellScript started with configuration {<nil> map[id:0.aws:runShellScript runCommand:[amazon-linux-extras install kernel-ng shutdown -r now ]
  • cloud-init-output.log
Cloud-init v. 19.3-2.amzn2 finished at Thu, 21 May 2020 13:06:34 +0000. Datasource DataSourceEc2.  Up 8.33 seconds

結果

「m6g」インスタンスの所要時間が 最も短いことが確認できました。

インスタンスタイプ 区分 所要時間
m6g.large arm64 0:00:35
m5.large x86_64 0:00:41
a1.large arm64 0:00:55
m3.large x86_64 0:01:08

再起動のみ

Amazon Linux2 の標準カーネル(4.14)と、kernel-ng パッケージ(5.4)に更新後の環境で、OS再起動を3回実施。 その所要時間の平均値を求めました。

インスタンスタイプ 区分 4.14 5.4
m6g.large arm64 0:00:14 0:00:15
m5.large x86_64 0:00:22 0:00:22
a1.large arm64 0:00:20 0:00:18
m3.large x86_64 0:00:44 0:00:41

OS再起動のみの所要時間も 「m6g」インスタンスが最も短いことが確認できました。

まとめ

「m6g」インスタンス、高速なOS起動が期待出来、素早いオートスケールの実現やコストパーフォーマンスに優れた利用が出来る可能性が伺えました。

arm64用パッケージを利用したミドルウェアなどの環境構築や、その性能などについても追って紹介させて頂きたいと思います。

参考リンク