AWSでインスタンスタイプを変更する際に考慮すべき点について

この記事を書いたメンバー:

SAITO Keita

AWSでインスタンスタイプを変更する際に考慮すべき点について

目次

はじめに

AWSでは構築したEC2インスタンスの利用傾向の変化や新しいインスタンスタイプが発表された等で、現在利用しているインスタンスタイプに比べて、他のインスタンスタイプの方がマッチしているケースが出てくる事があります。


このような場合、無条件でインスタンスタイプを変更できるかと言えば、そんなことは無く。

いくつか考慮すべきポイントがあり、EC2のユーザーガイドにインスタンスタイプの変更について記載があるため、本記事ではこの記載内容について確認していきます。

ドキュメント

そもそもすべてのインスタンスタイプに無条件で変更できるわけではなく、現在のインスタンスタイプから変更できるのは、互換性があるインスタンスタイプに変更できる事が説明されています。

仮想化タイプ

Linux AMIでは準仮想化(PV)とハードウェア仮想マシン (HVM)の2種類があり、最近構築されたインスタンスタイプについてはほぼハードウェア仮想マシン (HVM)のAMIから構築されているかと思います。

Amazon EC2 インスタンスタイプ - Amazon Elastic Compute Cloud

上記のドキュメントをみると、今現在はハードウェア仮想マシン(HVM)での構築が推奨されており、新規にPVで構築される事はないかと思います。

このため古くから稼働しており準仮想化(PV)方式で構築されたインスタンスのインスタンスタイプを変更しようとした際に、この項目がネックになってインスタンスタイプ変更ができないケースはままあります。

稼働しているインスタンスの仮想化タイプの確認

稼働しているサーバーが準仮想化(PV)なのかハードウェア仮想マシン(HVM)なのか確認する手段としては、マネジメントコンソールでインスタンスの詳細に仮想化タイプの項目があり、そこで確認ができます。







インスタンスタイプの仮想化方式の確認

Amazon EC2 の AMI タイプと特性 - Amazon Elastic Compute Cloud

上記ドキュメントにPV方式に対応しているインスタンスタイプについて下記の記載があります。

次の旧世代のインスタンスタイプは、PV AMI をサポートします: C1、C3、M1、M3、M2、および T1。現行世代のインスタンスタイプは PV AMI をサポートしません。

この記述から下記の旧世代のインスタンスファミリーのみ準仮想化(PV)方式をサポートしている事がわかります。

  • C1
  • C3
  • M1
  • M2
  • T1


またaws-cliの describe-instance-types  コマンドで方式を取得する事ができ、下記のように確認する事ができます。

aws ec2 describe-instance-types --query 'InstanceTypes[].[InstanceType, SupportedVirtualizationTypes]'

# おまけ
# 見やすい用意少しJmespathで整形
# 仮想化方式がリストなので,でjoinしてInstanceTypeでソート
aws ec2 describe-instance-types --query 'InstanceTypes[].{InstanceType:InstanceType, SupportedVirtualizationTypes: join(`, `, SupportedVirtualizationTypes)}|sort_by(@,&InstanceType)' --output text

今となっては全体からみれば準仮想化方式(PV)をサポートしているインスタンスタイプが少なくなっており、例としてはc3.largeで稼働していた準仮想化方式(PV)のインスタンスはc4.largeやc5.largeに移行できないといった事になります。

アーキテクチャ

AMIはプロセッサのアーキテクチャに固有となるため、変更後のインスタンスタイプは現在のインスタンスタイプと同じインスタンスタイプを選択する必要があります。

インスタンスタイプのアーキテクチャを確認する方法としては、EC2のマネジメントコンソールのインスタンスタイプから確認するのが簡単かと思います。

アーキテクチャ項目が表示されていない場合は、歯車マークから表示の項目の表示有無が設定できるため適宜調整してください。










ネットワークアダプタ

ドキュメントには下記のように記載があります。

ドライバーのネットワークアダプターを別のネットワークアダプターに切り替えると、オペレーティングシステムが新しいアダプターを作成したときに、ネットワークアダプターの設定がリセットされます。設定を再構成するには、管理者権限を持つローカルアカウントへのアクセスが必要な場合があります。ネットワークアダプターを別のネットワークアダプターに切り替える例を次に示します。

  • AWS PV (T2 インスタンス) からインテル 82599 VF (M4 インスタンス)
  • インテル 82599 VF (ほとんどの M4 インスタンス) から ENA (M5 インスタンス)
  • ENA (M5インスタンス) から高帯域幅の ENA (M5nインスタンス)

EC2で利用されるネットワークドライバには、大きく分けて下記の3種類のネットワークドライバがあり。

  • PVドライバー(Paravirtualization Driver)
  • Intel 82599 VF(Virtual Function)
  • ENA(Elastic Network Adapter)

かなり雑にまとめると、

  • PVドライバーは古いインスタンスで利用されていたネットワークドライバ
  • Intel 82599 VF(Virtual Function)は特定のインスタンスタイプ( C3、C4、D2、I2、M4 (m4.16xlarge を除く)、R3 ) で拡張ネットワークを利用する際に必要
  • ENA(Elastic Network Adapter)はNitro世代で利用されるネットワークドライバ
    • m5からm5nインスタンスなど同じENAでもENAから広帯域幅のENAではネットワークアダプタが切り替わるよ。

上記のようになっており、インスタンスタイプによって使われるドライバが変わってきます。

インスタンスタイプを切り替える際に、方式が変わる事によってネットワークアダプターが切り替わり設定がリセットされる点に注意が必要です。


またそもそもインスタンスタイプ変更前に、インスタンスタイプ変更後に利用する方式のネットワークドライバーがインストールされていない場合などは、インスタンスタイプ変更前に事前にネットワークドライバーをインストールしておく必要があります。

Nitro以前に構築されたインスタンスを、Nitoro世代のインスタンスタイプに変更する場合は、どのネットワークアダプタを利用されるのか、ネットワークドライバーはインストールされているかを確認する必要があります。

拡張ネットワーキング

インスタンスタイプによっては拡張ネットワーキングがサポートされている、されていないの違いあり。

拡張ネットワーキングがサポートされているインスタンスでは、Intel 82599 VF(Virtual Function)またはENAドライバーが必要となります。

インスタンスタイプ変更後に拡張ネットワーキングを利用するためには、適切なドライバーがインストールされているか事前に考慮する必要があります。

NVMe

Nitro世代のインスタンスではEBSでNVMeドライバを利用します。

古い世代のインスタンスから、Nitro世代のインスタンスタイプへ変更する際にはNVMeドライバがインストールされていない可能性が大きいためインスタンスタイプ変更前にNVMeドライバをインストールする必要があります。

ボリュームの制限

インスタンスにアタッチできるEBSボリュームの最大数は、インスタンスタイプによって異なります。

このためインスタンスタイプ変更を行う際には、変更後のインスタンスタイプのEBSボリュームの最大数が、現在アタッチされているボリューム数以上である事を事前に確認しておく必要があります。


Amazon EC2 インスタンスの Amazon EBS ボリューム制限 - Amazon Elastic Compute Cloud

インスタンスタイプごとのEBSボリュームの最大数については上記にドキュメントがあり、

Nitro世代、インスタンスタイプ、OS、ドライバ、専有、共有、例外など複数の要素で決定されます。

インスタンスタイプによって最大数が決まるような要素ではないため、逐次確認が必要とはなりますが。

例外的なインスタンスタイプを使用してない限りは、基本的には24個以下のEBSくらいではそうそう引っ掛かるケースはなさそう。

NitroTPM

Amazon EC2 インスタンスの NitroTPM - Amazon Elastic Compute Cloud

Amazon EC2 インスタンスで NitroTPM を使用するための要件 - Amazon Elastic Compute Cloud

NitroTPMが有効になっているAMIをNitoroTPMをサポートするインスタンスタイプで起動すると自動でNitroTPMが有効な状態で起動されます。

NitoroTPMが有効な状態のインスタンスは、変更後のインスタンスタイプについてはNitoroTPMをサポートするインスタンスである必要があります。

なおインスタンスタイプによってNitroTPMが有効な状態かどうかは下記のコマンドで一覧を取得できます。

aws ec2 describe-instance-types --query 'InstanceTypes[*].[InstanceType,NitroTpmSupport]|sort_by(@,&[0])'


総評

ドキュメントを確認するとインスタンスタイプ変更と一口に言っても、様々な考慮点がある事がわかります。

適切に対応しないとインスタンスタイプ変更後にOSが起動しなかったり、接続できなかったり事故が発生してしまいます。

本番運用されているインスタンスでは停止タイミングの調整が難しいケースも多いため、インスタンスタイプ変更時に事前に確認できるポイントで引っ掛かってしまわないように注意しましょう。



カテゴリー
タグ

この記事を書いたメンバー

SAPシステムや基幹システムのクラウド移行・構築・保守、
DXに関して
お気軽にご相談ください

03-6260-6240 (受付時間 平日9:30〜18:00)