[アップデート] EC2 インスタンスの無停止でのルートボリューム置き換え時に任意の AMI を復元のソースとして指定可能になりました！

コンバンハ、千葉（幸）です。

EC2 インスタンスのルートボリュームを無停止で置き換える際、任意の AMI をソースとして指定できるようになりました。

• Amazon EC2 enables easier patching of guest operating system and applications with Replace Root Volume

ここでの任意とは、置き換え対象のインスタンスおよびルートボリュームと関係ないものを指定できる、という意味で使っています。

この新機能は、OS、アプリケーションの迅速なパッチ適用を可能にするものとして想定されているようです。

何が変わったのか

実行中の EC2 インスタンスのルートボリュームを無停止で置き換える、という機能は 2021年4月にリリースされました。

ルートボリュームの置き換えはルートボリュームの復元を伴います。そうすると何をソースとして復元するかの指定が必要になるわけですが、当時は以下のいずれかのみが指定可能でした。

• インスタンスのローンチの際に指定した AMI に紐づく EBS スナップショット ^*1
• ルートボリュームから取得した EBS スナップショット

つまり置き換え対象のインスタンスに関連するものしか指定できなかったわけです。

今回のアップデートにより、任意の AMI を指定できるようになりました。

指定した AMI に紐づく EBS スナップショットが復元のソースとして利用されます。

つまりこういうことができる

アップデートのアナウンスや AWS ドキュメントの記載を見ると、今回の新機能は OS やアプリケーションの迅速なパッチ適用のために用いることを推奨していそうです。

それを踏まえて考えると、こういった使い方が想定されているのでは、と考えています。

1. パッチ適用のための一時的なインスタンスを起動し、そこでパッチ適用
2. 1.でパッチ適用が完了したらそのインスタンスの AMI を取得
3. 2.をソースとして指定し、ルートボリュームの置き換えを実施

上のイメージでは一時的なインスタンスを「置き換え対象のインスタンスと同一の AMI」から立ち上げていますが、もちろん他の AMI から立ち上げるパターンもあるでしょう。

ルートボリューム置き換えに関する注意事項

各種注意事項を確認しましょう。

• Replace a root volume - Amazon Elastic Compute Cloud

まずはルートボリュームの置き換え全般に関する内容です。

• データボリューム（ルートボリューム以外のボリューム）は影響を受けない
• ネットワーク構成やインスタンスプロファイルなどは影響を受けない
• runningの状態のインスタンスでのみ置き換えができる
• 置き換えのプロセスの中で自動的に再起動される
  • 停止は伴いませんが、再起動を伴います
• ルートボリュームがインスタンスストアボリュームの場合はサポート外
• Mac メタルインスタンス以外のメタルインスタンスはサポート外

AMI からルートボリュームを置き換える際の注意事項

ソースとして任意の AMI を指定する場合の追加の主な注意事項です。

• インスタンスで NitroTPM、ENA、または sriov-net が有効になっている場合、それらの機能をサポートするAMI を使用する必要がある
• インスタンスと異なるブートモードの AMI を指定できるが、インスタンスが当該ブートモードをサポートしていないと置き換えリクエストは失敗する
  • ブートモード参考：ブートモード - Amazon Elastic Compute Cloud
• 置き換え後のボリュームは元のボリュームのボリュームタイプ、「終了時に削除」の属性を引き継ぐ
• 元のボリュームサイズと AMI で定義されたボリュームサイズが異なる場合、大きい方のサイズが適用される
• 置き換えが完了すると、以下の情報が更新される
  • AMI ID
  • ルートボリューム ID
  • AMI によって変更された場合は各種構成情報（ブートモード、Nitro TPM、ENA、sriov-net）
• 置き換えソースの AMI が複数ブロックデバイスマッピング持っていても使用されるのはルートボリュームのみ（データボリュームが置き換えられたりしない）
• AMI は自己所有、プライベート共有、パブリックを問わないがアクセス権限を持っている必要がある
• 製品コードなしの AMI を置き換えソースに指定できるのはインスタンスが製品コードを持たない場合のみ
  • 製品コード参考：AMI ベースの製品 - AWS Marketplace
• 置き換え時にルートボリュームの暗号化ステータスを変更することはできず、元のボリュームもしくは AMI の設定を引き継ぐ

やってみた

今回はお手軽に、以下のイメージで実行します。

• 公式のコミュニティ AMI （少し古め）からインスタンスをローンチ
• 新しいコミュニティ AMI をソースにルートボリュームの置き換え

それぞれ使用する AMI は以下です。

• インスタンスのローンチに指定
  • amzn2-ami-kernel-5.10-hvm-2.0.20211103.0-x86_64-gp2
  • ami-0c446db192f569fcb
• ルートボリュームの置き換えソースに指定
  • amzn2-ami-kernel-5.10-hvm-2.0.20221004.0-x86_64-gp2
  • ami-0de5311b2a443fb89

1. インスタンスのローンチ

ami-0c446db192f569fcbを使用してインスタンスをローンチします。

• t2.micro
• 8 GiB、暗号化なし
• パブリック IP アドレス付与
• IAM ロールでSystems Managerの権限付与
• 起動時の yum アップデートを無効化

起動時の yum アップデータの無効化は、ユーザーデータに以下を入力して実現します。

#cloud-config
repo_upgrade: none

作成されたインスタンスはこちらです。

各種 ID を確認しました。先に結論も添えてしまいますが、置き換えによる変更有無は以下の通りです。

• AMI ID：ami-0c446db192f569fcb（変わる）
• インスタンスID：i-006582c08ddcb2c42（変わらない）
• 予約ID：r-0561eb05c6464897e（変わらない）
• ルートボリュームID：vol-0e3784fe72562be07（変わる）
• ENI ID：eni-0339face078fbde18（変わらない）

セッションマネージャーで接続し、カーネルの情報を確認します。

sh-4.2$ uname -a
Linux ip-192-168-0-79.ap-northeast-1.compute.internal 5.10.68-62.173.amzn2.x86_64 #1 SMP Fri Sep 24 18:24:14 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux

インストール済みのパッケージも確認します。量が多いので、末尾に比較表を載せます。

sh-4.2$ sudo yum list installed
Loaded plugins: extras_suggestions, langpacks, priorities, update-motd
Installed Packages
GeoIP.x86_64                                                                  1.5.0-11.amzn2.0.2                                                     installed
PyYAML.x86_64                                                                 3.10-11.amzn2.0.2                                                      installed
...以下略

2. ルートボリュームの置き換えの実施

起動したインスタンのルートボリュームを置き換えていきます。ストレージの詳細画面から選択するか「アクション」→「モニタリングとトラブルシューティング」から実行できます。

復元のソースとして Image（AMI）を選択し、ami-0de5311b2a443fb89を入力、「置き換えタスクを作成」を押下します。

↑なお、ここで元のルートボリュームの削除有無の指定、タグの付与も指定できます。

ちなみに Image を選択する際には候補の AMI が表示されるのですが、わたしの環境ではひとつだけ表示がありました。状況から見るに「プライベートかつ自己所有でない」イメージが表示されるのか……？という気がしています。

パブリックなものはともかく自己所有のものも出てこないのは少し意外でした。ここでの検索に期待するより、AMI ID をあらかじめ控えて入力するのが良さそうです。

今回のケースではあっという間に置き換えタスクが完了しました。開始時刻と完了時刻を見ると 30秒足らずで完了しています。

↑ルートボリュームの ID は新しいものになっており、それに伴いアタッチ時刻も更新されています。

この一連の作業の前後で手元の端末からインスタンスに Ping を打ち続けていたのですが、再起動が発生するので一時的に通信断が発生しています。

% ping --apple-time 52.196.42.159
……（略）……
19:26:08.969646 64 bytes from 52.196.42.159: icmp_seq=615 ttl=38 time=22.918 ms
19:26:09.973254 64 bytes from 52.196.42.159: icmp_seq=616 ttl=38 time=23.394 ms
19:26:10.978572 64 bytes from 52.196.42.159: icmp_seq=617 ttl=38 time=23.260 ms
Request timeout for icmp_seq 618
Request timeout for icmp_seq 619
……（略）……
Request timeout for icmp_seq 657
Request timeout for icmp_seq 658
19:26:53.132643 64 bytes from 52.196.42.159: icmp_seq=659 ttl=229 time=20.664 ms
19:26:54.138866 64 bytes from 52.196.42.159: icmp_seq=660 ttl=229 time=22.038 ms
19:26:55.148799 64 bytes from 52.196.42.159: icmp_seq=661 ttl=229 time=24.520 ms

↑置き換えが完了しても数十秒は Ping を受け付けられなかったようです。流石に再起動の完了を見届けて置き換え完了とする、という気の利いたことはしてくれないということですね。

3. 置き換え後のインスタンスの確認

置き換えが完了したインスタンスの情報を確認します。

インスタンス ID は変わっておらず、AMI ID が変更になっています。起動時刻は置き換えによっては更新されないようでした。

ふたたびカーネルの情報を確認すると、バージョン・リリース番号が変わっていることがわかります。

sh-4.2$ uname -a
Linux ip-192-168-0-16.ap-northeast-1.compute.internal 5.10.144-127.601.amzn2.x86_64 #1 SMP Thu Sep 29 01:11:59 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux

比較すると以下の通りです。

また、sudo yum list installedでパッケージの情報を確認します。詳細は末尾に記載しますが、置き換え前の状態と比べてアップデートされているものが確認できました。

再起動こそ伴ったものの、停止をすることなくルートボリュームを置き換えできました。

終わりに

実行中の EC2 インスタンスのルートボリュームの置き換えを行う際、復元のソースとして任意の AMI を指定できるようになった、というアップデートでした。

従来の手法でのルートボリュームの置き換えはトラブルシュート・障害復旧の意味合いが強かったですが、今回のアップデートはパッチ適用の方に重きが置かれていそうです。

置き換えのソースとして指定できる AMI は幅広いですが、そのぶん実行中のインスタンスとの組み合わせは考慮する必要があります。本格的に採用される際には一連の流れをきちんと確認し、置き換え後も正常稼働するかを事前に押さえることをおすすめします。

以上、 チバユキ (@batchicchi) がお送りしました。

置き換え前後のパッケージバージョン差異

再掲するとそれぞれの AMI は以下の通りです。

• 置き換え前
  • amzn2-ami-kernel-5.10-hvm-2.0.20211103.0-x86_64-gp2
  • ami-0c446db192f569fcb
• 置き換え後
  • amzn2-ami-kernel-5.10-hvm-2.0.20221004.0-x86_64-gp2
  • ami-0de5311b2a443fb89

脚注