Amazon Linux 2023 の EC2 インスタンス起動時間

先日、Amazon Linux 2023 が GA になりました。
今回は、Amazon Linux 2023 の AMI を使った EC2 インスタンスの起動時間がどの程度高速化されているのかを見ていきます。

https://aws.amazon.com/jp/linux/amazon-linux-2023/

Amazon Linux 2 と Amazon Linux 2023 の違い

Amazon Linux 2023 の登場に際して最もよく言及されている変更点のひとつといえば、アップストリームプロジェクトの変更ではないかと思います。
これまでに提供されていた Amazon Linux では、CentOS (Amazon LinuxCentOS 6 、Amazon Linux 2 は CentOS 7 ) がベースになっているとされてきました。
一方、Amazon Linux 2023 (以下、AL2023) は Fedora をアップストリームとしていることが明言されています。

そして、アップストリームプロジェクトの変更だけに留まらず、AL2023 では以下のように様々な変更が行われていることが公式ドキュメントで紹介されています。

  • SELinux のデフォルト有効化(従来はデフォルト無効)
  • ライフサイクルポリシーの導入(2年毎のメジャーバージョンリリース、5年サポート)
  • 最適化による起動時間の短縮

etc.

https://docs.aws.amazon.com/linux/al2023/ug/compare-with-al2.html

インスタンス起動時間の計測

上記のドキュメントでも紹介されているとおり、AL2023 では EC2 アーキテクチャへの最適化によってインスタンスの起動時間が従来より改善されているようです。

AL2023 は起動時間を最適化し、インスタンスの起動から顧客のワークロードの実行までの時間を短縮します

https://docs.aws.amazon.com/linux/al2023/ug/compare-with-al2.html

詳細は こちら にも記載されています。

今回は、実際にいくつかのインスタンスタイプで AL2023 の AMI を使って EC2 インスタンスを起動するときの所要時間を計測し、Amazon Linux 2 (以下、AL2) と比較してどの程度起動時間が短くなっているかを見ていきたいと思います。

計測条件

インスタンスの起動にかかる時間は、インスタンスの CPU やメモリ、CPU アーキテクチャなどによって違いが出るのではと考え、以下の AMI とインスタンスタイプの組み合わせで全 6 パターンを検証しました。

AMI

  • Amazon Linux 2023 AMI 2023.0.20230315.0 x86_64 HVM kernel-6.1 (ami-02f3f602d23f1659d)
  • Amazon Linux 2 Kernel 5.10 AMI 2.0.20230307.0 x86_64 HVM gp2 (ami-005f9685cb30f234b)

インスタンスタイプ

  • t2.micro -> 検証用途、汎用
  • c6i.large -> コンピューティング最適化、Intel 製 CPU の標準的なインスタンスタイプ
  • m6a.large -> メモリ最適化、AMD 製 CPU の標準的なインスタンスタイプ

計測にあたり、インスタンスの起動にかかった時間の開始と終了は以下の定義としました。
こちらを参考にさせて頂き、ユーザーデータの実行可能になっている=ユーザアプリケーションの処理が開始できるようになっていると見立て、このタイミングでインスタンスの起動が完了したとみなします。
起動開始の指標とした LaunchTime はミリ秒以下の情報が省略されているため、少々荒い計測ではありますが秒の精度で比較したいと思います。

なお、起動時間にはある程度ばらつきが出ると予想されるため、各 AMI x インスタンスタイプの組み合わせで 10 回ずつ試行し、その平均値を取ることとしました。

ユーザーデータの内容は以下のとおりとしました。

#!/bin/bash
date >> /tmp/start_time

インスタンスの起動は awscli から行いました。
コマンドの一例を以下に示します。

$ aws ec2 run-instances --image-id ami-02f3f602d23f1659d --count 10 --instance-type c61.large --key-name ******* --subnet-id subnet-******* --security-group-ids sg-******* --user-data file://userdata.txt

検証結果

検証結果は以下のとおりとなりました。

Amazon Linux 2 Kernel 5.10 AMI 2.0.20230307.0 x86_64 HVM gp2

  • t2.micro ... 48 秒
  • c6i.large ... 21 秒
  • m6a.large ... 20 秒

Amazon Linux 2023 AMI 2023.0.20230315.0 x86_64 HVM kernel-6.1

  • t2.micro ... 36 秒
  • c6i.large ... 13 秒
  • m6a.large ... 14 秒

最も起動時間の短い組み合わせは AL2023 x c6i.large の 13 秒でした。
最も起動時間の長い組み合わせは AL2023 x t2.micro の 48 秒でした。
すべてのインスタンスタイプにおいて、AL2023 は AL2 比で 25 %以上起動時間が短縮される結果となりました。

ちなみに、Graviton 2 インスタンスにはより最適化されているという記載を見かけたため、以下の組み合わせも追加で計測してみました。

Amazon Linux 2023 AMI 2023.0.20230315.0 arm64 HVM kernel-6.1 (ami-05fab674de2157a80)

  • c7g.large ... 13 秒

考察

すべてのインスタンスタイプで AL2 よりも AL2023 のほうが起動時間が早く、AL2023 の最適化の効果が伺える結果となりました。
急速なリクエスト増などでスピーディなオートスケールが求められるようなケースではこの差が効いてくる可能性もあるのではないでしょうか。

ちなみに今回は large のインスタンスサイズを中心に検証しましたが、t2.micro を使った計測では c6i.large や m6a.large と比べて起動までに 2〜3 倍程度長い時間がかかったため、マシンリソースの多少によって起動時間が変わってくる可能性は考えられそうです。
(ある程度のところで頭打ちもあると思うので、8xlarge や 16xlarge などのより大きいインスタンスサイズを使ったからといってより早くなるという単純な話ではないと思いますが)

一方、同じ AMI を使った c6i.large と m6a.large のインスタンス起動時間にはほぼ差がないように見受けられるため、AL2023 の AMI を利用する際にインスタンスファミリーや CPU アーキテクチャによって起動時間の顕著な違いは無さそうです。
Graviton 2 インスタンスではより最適化されているという触れ込みでしたので c7g.large についても追加で検証しましたが、今回の簡易な計測では顕著な差は見られませんでした。
どちらにしても仮想マシンの起動が十数秒で行えている時点で十分早いとは思います。

以上より、Amazon Linux 2023 (AL2023) の EC2 インスタンスの起動にかかる時間は、large サイズであればインスタンスファミリーや CPU アーキテクチャに関わらず 10〜20 秒程度と思っておいても良さそうです。

まとめ

Amazon Linux 2023 の AMI を使った EC2 インスタンスの起動は、従来の Amazon Linux 2 を用いる場合よりも高速化されていることが確認できました。
あくまで個人による簡易な検証結果ですが、何かのお役に立てば幸いです。