目的
- EC2のアーキテクチャをx86からArm64に移行することで性能向上させる
- Graviton基盤に移行することでEC2のコストを節約する
なぜGraviton？
GravitonとはAWSが独自に開発したプロセッサです。
簡単に説明すると処理性能が高くコストパフォーマンスが高いCPU基盤で、20%以上のコストダウンが可能になります。
2024/7/19時点で東京リージョンでGravitonプロセッサを利用できるEC2インスタンスタイプはM7g、T4g、C7g、R7gなどがあります。
Gravitonに関する概要はBlackbelt Online Seminarで詳しく説明されているのでこちらを参照してください。
なぜ移行できない？
Gravitonはコスパが良く性能が高いので今すぐにインスタンスタイプを変更したいですよね。
しかし、ワークロードをすぐには移行できないと考える方も多いようです。
容易に移行できない理由はいくつかあります。
- x86などのアーキテクチャで起動しているインスタンスタイプをシームレスに変更できない
- ミドルウェアやアプリケーションがArmアーキテクチャに対応していない
- OSに互換性がない(Windows Serverは非対応)
- 基盤の移行となるため、ダウンタイムや不具合を懸念している
このような理由があると、移行を検討するには腰が重くなりそうです。
しかし、調べてみると移行方法自体はとても簡単だということが分かりました。
移行方式
大別してオンライン方式とオフライン方式があります。
- オンライン方式はGravitonインスタンス移行元のデータをSSHでアクセスしてコピーします。
- オフライン方式ではGravitonインスタンスに既存のボリュームをアタッチしてデータをコピーします。
本番ワークロードの場合はB/Gデプロイなどを利用してダウンタイムなく移行することを検討しましょう。
移行要件の洗い出し
移行時の要件を洗い出します。
- ネットワーク
- ElasticIPなどの保持が必要か
- ミドルウェア
- x86_64形式でインストールしているかどうか
- アプリケーション
- C++やFortranなどコンパイルの必要なアプリケーションであるか
- Dockerを使用している場合はArm64用のイメージを作成する
- 移行難易度
- ワークロードのダウンタイムへの許容度など
今回は踏み台サーバ兼phpMyAdminを実行しているEC2インスタンスをGravitonに移行したいと思います。
まずは、現状のインスタンスで使用しているアプリケーションがArm64ベースのアーキテクチャに移行できるか確認しましょう。
yumでインストールしたパッケージ以外のミドルウェアはないと記憶しているのでパッケージ名で確認します。
# rpm -qa | grep httpd
httpd-filesystem-2.4.58-1.amzn2023.noarch
httpd-tools-2.4.58-1.amzn2023.x86_64
httpd-core-2.4.58-1.amzn2023.x86_64
generic-logos-httpd-18.0.0-12.amzn2023.0.3.noarch
httpd-2.4.58-1.amzn2023.x86_64
# rpm -qa | grep php
php8.2-common-8.2.15-1.amzn2023.0.2.x86_64
php8.2-cli-8.2.15-1.amzn2023.0.2.x86_64
php8.2-pdo-8.2.15-1.amzn2023.0.2.x86_64
php8.2-mbstring-8.2.15-1.amzn2023.0.2.x86_64
php8.2-opcache-8.2.15-1.amzn2023.0.2.x86_64
php8.2-process-8.2.15-1.amzn2023.0.2.x86_64
php8.2-fpm-8.2.15-1.amzn2023.0.2.x86_64
php8.2-xml-8.2.15-1.amzn2023.0.2.x86_64
php8.2-sodium-8.2.15-1.amzn2023.0.2.x86_64
php8.2-devel-8.2.15-1.amzn2023.0.2.x86_64
php8.2-8.2.15-1.amzn2023.0.2.x86_64
php8.2-mysqlnd-8.2.15-1.amzn2023.0.2.x86_64
# rpm -qa | grep mysql
php8.2-mysqlnd-8.2.15-1.amzn2023.0.2.x86_64
# rpm -qa | grep mariadb
mariadb-connector-c-config-3.1.13-1.amzn2023.0.3.noarch
mariadb-connector-c-3.1.13-1.amzn2023.0.3.x86_64
mariadb105-common-10.5.23-1.amzn2023.0.1.x86_64
mariadb105-10.5.23-1.amzn2023.0.1.x86_64
インストールされたアプリケーション名の末尾を見ます。
*.noarch → x86とArmどちらもOK
*.x86_64 → arm非対応
これらのミドルウェアの移行が必要になります。
今回は現状と同じパッケージのarmアーキテクチャ用のミドルウェアをインストール可能なので、yumでインストールします。
今回はオフライン形式の移行を試してみます。
移行元のスナップショットを作成
移行元のルートボリュームを複製するために、スナップショットを作成します。
EC2 > ボリューム > 対象のルートボリューム > スナップショットの作成
作成が完了したら、新しいボリュームに復元します。
EC2 > スナップショット > スナップショットからボリュームを作成
移行元と同じように設定してください。
ボリュームの作成が完了したら、移行先のインスタンスを作成します。
ここでは、移行元と同じ設定で起動するために対象のインスタンスと同様のインスタンスを起動します。
EC2 > インスタンス > アクション > イメージとテンプレート > 同様のものを起動
イメージが現在のインスタンスと同じAMIになっているとGravitonのインスタンスタイプを選択できないのでクイックスタートからArmアーキテクチャのAMIを選択します。
インスタンスタイプを選択します。
インスタンスタイプ以外の設定は既存のものと同じで問題ありません。
設定を確認したらインスタンスを起動します。
ここで必要なミドルウェアをインストールしてください。
移行元からデータをコピーするため、先ほど復元したボリューム起動したインスタンスにセカンダリボリュームとしてアタッチします。
EC2 > ボリューム > 作成したボリュームID > ボリュームのアタッチ
インスタンス: Arm基盤で起動したインスタンス
デバイス名: /dev/sdf
ボリュームをアタッチしたら、インスタンスに接続します。
先ほどアタッチしたボリュームのデバイス名を確認します。
$ ll /dev/ | grep sdf
lrwxrwxrwx. 1 root root 7 Jul 18 11:20 sdf -> nvme1n1
lrwxrwxrwx. 1 root root 9 Jul 18 11:20 sdf1 -> nvme1n1p1
lrwxrwxrwx. 1 root root 11 Jul 18 11:20 sdf127 -> nvme1n1p127
lrwxrwxrwx. 1 root root 11 Jul 18 11:20 sdf128 -> nvme1n1p128
ディスクのパーティションを確認します。
$ lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
zram0 253:0 0 419M 0 disk [SWAP]
nvme0n1 259:0 0 8G 0 disk
├─nvme0n1p1 259:1 0 8G 0 part /
└─nvme0n1p128 259:2 0 10M 0 part /boot/efi
nvme1n1 259:3 0 8G 0 disk
├─nvme1n1p1 259:4 0 8G 0 part
├─nvme1n1p127 259:5 0 1M 0 part
└─nvme1n1p128 259:6 0 10M 0 part
nvme1n1p1がsdfのパーティションであることが分かったので、このボリュームをマウントします。
$ sudo mount /dev/nvme1n1p1 /mnt
$ ll /mnt
total 32
lrwxrwxrwx. 1 root root 7 Jan 30 2023 bin -> usr/bin
dr-xr-xr-x. 5 root root 16384 Apr 1 19:58 boot
drwxr-xr-x. 3 root root 136 Apr 1 19:58 dev
drwxr-xr-x. 83 root root 16384 May 30 05:16 etc
drwxr-xr-x. 5 root root 53 May 24 06:27 home
lrwxrwxrwx. 1 root root 7 Jan 30 2023 lib -> usr/lib
lrwxrwxrwx. 1 root root 9 Jan 30 2023 lib64 -> usr/lib64
drwxr-xr-x. 2 root root 6 Apr 1 19:56 local
drwxr-xr-x. 2 root root 6 Jan 30 2023 media
drwxr-xr-x. 2 root root 6 Jan 30 2023 mnt
drwxr-xr-x. 4 root root 31 Jul 17 11:05 opt
drwxr-xr-x. 2 root root 6 Apr 1 19:56 proc
dr-xr-x---. 3 root root 204 Jun 18 04:59 root
drwxr-xr-x. 2 root root 6 Apr 1 19:58 run
lrwxrwxrwx. 1 root root 8 Jan 30 2023 sbin -> usr/sbin
drwxr-xr-x. 2 root root 6 Jan 30 2023 srv
drwxr-xr-x. 2 root root 6 Apr 1 19:56 sys
drwxrwxrwt. 2 root root 6 Apr 1 19:56 tmp
drwxr-xr-x. 12 root root 144 Apr 1 19:57 usr
drwxr-xr-x. 20 root root 277 Apr 12 06:38 var
ボリュームのマウントが完了しました。
ここまで出来たら、rsyncなどで必要なデータをコピーします。
例えば、ユーザーのSSHキーを移行したい場合は次のようなコマンドを実行します。
この時、ファイルの所有者や権限の変更も忘れずに実施しましょう。
$ sudo rsync -av /mnt/home/urname/.ssh /home/urname/
sending incremental file list
.ssh/
.ssh/authorized_keys
.ssh/id_ed25519
.ssh/id_ed25519.pub
データの移行が完了したら、動作確認を実施してください。
移行が完了したら移行元のボリュームをアンマウントします。
$ sudo umount /mnt
最後に、セカンダリボリューム(/dev/sdf/)をデタッチします。
必要がなくなったボリュームは削除してください。
Gravitonの性能は？
今回の作業でt2.microからt4g.nanoに移行しました。
パフォーマンスと価格の比較は下記のとおりです。
| インスタンス名 | オンデマンドの時間単価 | vCPU | メモリ | ストレージ | ネットワークパフォーマンス |
|---|---|---|---|---|---|
| t2.micro | USD 0.0152 | 1 | 1 GiB | EBS のみ | 低～中 |
| t4g.nano | USD 0.0054 | 2 | 0.5 GiB | EBS のみ | 最大 5 ギガビット |
インスタンスのサイズは半分になったもののvCPUは２倍になり基本的にはサクサク動いています。
メモリは半分のサイズになっているのでメモリを消費するワークロードはサイズを変えない方が良さそうです。
ネットワークパフォーマンスもt4g.nanoで十分と感じます。
オンデマンドの時間単価は約1/3になり、コストパフォーマンスも大幅にアップしました。
本番ワークロードでは十分な検証が必要になるものの、移行を検討する価値は十分にあると思います。
参考にさせていただいた資料
トッカシステムズは、受託開発や自社製品・サービス開発を行うエンジニアリング企業です。Webサービスやアプリ、電子マネー、認証機能などの開発や、CMSによるWebサイト構築などを行っています。 Java,PHP,React,Nextでの開発や、AWSを用いた基盤構築・運用等を行っています。
Discussion