AWS EC2のコストを見直していて、既存のx86_64環境からAWS Gravitonを利用したarm64環境へ変更しようとしました。
最初は、
EC2を停止して、インスタンスタイプをGraviton系へ変更すればいいのでは？
くらいに考えていました。
しかし、実際には既存のx86_64向けAMIをそのままarm64のインスタンスタイプへ変更することはできません。
今回は、x86_64とarm64の違いと、Graviton環境へ移行するときに確認したことを備忘録としてまとめます。
x86_64とarm64とは
EC2では、インスタンスによってCPUアーキテクチャが異なります。
大きく分けると、
x86_64
と、
arm64
があります。
IntelやAMDベースのEC2では主にx86_64が使用されます。
一方、AWS Gravitonプロセッサを搭載したインスタンスではarm64が使用されます。
例えばGraviton系には、
t4g
m7g
c7g
などがあります。
現在のアーキテクチャを確認する
Linux上では、以下のコマンドで確認できます。
uname -m
x86_64環境なら、
x86_64
arm64環境なら、
aarch64
などと表示されます。
インスタンスタイプを変えるだけでは移行できない
ここが今回引っかかったポイントです。
例えば、
x86_64のAMI
↓
x86_64対応EC2
で動いている既存環境を停止して、
Graviton（arm64）対応のインスタンスタイプ
へ変更しようとしても、そのまま移行することはできません。
OSを含むAMI自体がCPUアーキテクチャに対応している必要があるためです。
イメージとしては、
x86_64用AMI
↓
x86_64インスタンス
○
x86_64用AMI
↓
arm64インスタンス
×
となります。
AMIのアーキテクチャを確認する
AWSマネジメントコンソールでは、AMIの詳細からArchitectureを確認できます。
例えば、
Architecture: x86_64
であればx86_64向けです。
Gravitonへ移行する場合は、
Architecture: arm64
に対応したAMIを使用する必要があります。
今回はarm64対応AMIから新しいEC2を作成
既存のx86_64インスタンスをそのままGravitonへ変更することはできなかったため、今回はarm64対応のAmazon Linux 2023 AMIから新しいEC2を作成し、必要な設定を移行することにしました。
大まかな流れは以下です。
既存EC2（x86_64）
↓
BINDの設定・ゾーンファイルをバックアップ
↓
同じVPCにarm64対応AMIから新規EC2を作成
↓
既存環境を参考にSecurity Groupを設定
↓
BINDをインストール
↓
設定・ゾーンファイルを移行
↓
BINDの設定チェック
↓
名前解決・ゾーン転送を確認
1. arm64対応AMIからEC2を作成
新しいEC2では、arm64対応のAmazon Linux 2023 AMIを選択しました。
インスタンスタイプもGravitonに対応したものを選択します。
起動後、アーキテクチャを確認します。
uname -m
以下のように表示されればarm64環境です。
aarch64
2. 既存環境に合わせてネットワークを設定
今回は既存DNSサーバーと同じVPC内に新しいEC2を作成しました。
Security Groupについても既存環境を参考に、DNSサーバーとして必要な通信が許可されるよう設定しました。
DNSでは一般的に53番ポートを使用しますが、UDPだけでなくTCPも使用する場合があります。
そのため、既存環境の設定をそのままコピーするのではなく、現在どの通信が必要なのかを確認した上で設定します。
また、SSHによる管理が必要な場合は22番ポートについても必要な接続元に限定して許可します。
3. BINDをインストール
新しいAmazon Linux 2023へBINDをインストールします。
sudo dnf install bind bind-utils -y
インストール後、バージョンを確認します。
named -v
4. 既存サーバーの設定を移行
既存サーバーからバックアップしておいた、
/etc/named.conf
/var/named/
などのBIND設定・ゾーンファイルを新しいサーバーへ移行しました。
今回は事前にtar.gz形式でバックアップを作成しています。
移行後はファイルの配置場所だけでなく、所有者や権限についても確認します。
5. BINDの設定をチェック
設定ファイルを配置したら、いきなりBINDを起動するのではなく、まず設定を確認しました。
sudo named-checkconf
ゾーンファイルについても確認します。
sudo named-checkzone example.com /var/named/example.com.zone
問題がなければBINDを起動します。
sudo systemctl enable --now named
状態も確認します。
sudo systemctl status named
6. 名前解決とゾーン転送を確認
BINDが起動しただけでは移行完了とはせず、実際にDNS問い合わせを行って確認しました。
例えば、
dig @<新しいDNSサーバーのIPアドレス> example.com
などで名前解決を確認します。
今回はMaster/Slave構成だったため、MasterとSlave間でゾーン転送が正常に行われることも確認しました。
ここまで確認できて、ようやく新しいarm64環境でDNSサーバーが正常に動作していると判断しました。
結果として今回は、
既存EC2のCPUアーキテクチャを変更する
のではなく、
新しいarm64環境を作成し、必要な設定とデータを移行する
というサーバー移行になりました。
Amazon Linux 2023はx86_64とarm64の両方で提供されているため、新規EC2作成時にarm64対応AMIを選択できます。
ソフトウェアもarm64対応を確認する
OSだけでなく、その上で動かすソフトウェアについても確認が必要です。
例えば、
- 利用しているパッケージ
- 外部からダウンロードするバイナリ
- 独自に導入したツール
- コンテナイメージ
などです。
パッケージマネージャーから導入する一般的なソフトウェアであればarm64版が提供されていることも多いですが、すべてのソフトウェアが必ず対応しているとは限りません。
今回利用していたBINDについては、Amazon Linux 2023でarm64向けパッケージが提供されています。
設定ファイルやデータは別途移行する
CPUアーキテクチャが違うからといって、すべてのデータが利用できなくなるわけではありません。
例えばBINDで使用している、
/etc/named.conf
や、
/var/named/
のゾーンファイルなどはテキストベースの設定・データです。
そのため、必要なファイルをバックアップして、新しいサーバーへ移行する方法を取りました。
ただし、実際に移行する場合は、新環境のソフトウェアバージョンや設定仕様に差異がないかも確認します。
移行前に確認しておきたいこと
今回のようにx86_64からarm64へ移行する場合は、少なくとも以下を確認しておくと安心です。
現在のCPUアーキテクチャ
uname -m
利用しているAMI
AWSマネジメントコンソールなどから、
Architecture
を確認します。
インストール済みソフトウェア
dnf list installed
などで確認できます。
独自バイナリの有無
パッケージマネージャー以外からインストールしたソフトウェアがある場合は、arm64版が提供されているか確認します。
移行する設定・データ
設定ファイルやデータについて、
何をバックアップするか
何を新規構築するか
を分けて考えておくと移行しやすくなります。
移行後の確認
新しいarm64環境を構築したら、
uname -m
を実行します。
aarch64
と表示されれば、arm64環境で起動しています。
その後、
- サービスが正常に起動しているか
- 設定ファイルが正常に読み込めるか
- 通信できるか
- アプリケーションが正常に動作するか
などを確認します。
今回のDNSサーバーであれば、BINDの状態や名前解決、Master/Slave間のゾーン転送なども確認しました。
まとめ
EC2をx86_64からGraviton（arm64）へ移行するときは、単純にインスタンスタイプを変更するだけでは移行できませんでした。
CPUアーキテクチャが異なるため、
既存のx86_64環境
↓
必要な設定・データをバックアップ
↓
arm64対応AMIから新しいEC2を作成
↓
ソフトウェアを再構築
↓
設定・データを移行
↓
動作確認
という流れで考える必要があります。
最初は「インスタンスタイプを変更するだけでは？」と思っていたので、x86_64とarm64ではAMIから考える必要がある、という点を備忘録として残しておきます。