EC2のインスタンスタイプによる差異

EC2に、インスタンスタイプによる差異はあるの？

こんにちは、サーバーワークスの杉村です。AWSの代表的なサービスであるElastic Computing Cloud(EC2)。

インスタンスの停止さえできれば、スペックを自由に変更できるのはとても便利です。
おかげでサーバーエンジニアは、難しくて時間のかかるサイジングから解放され、とりあえずスモールスタートで作ってみる！という手段を選択することができます。
わずか数クリックで、マシンスペックを変更できるとは、なんと素晴らしい。

ですがちょっと待ってください。
その[適用]ボタンを押す前に、チェックしておくべきことがあります。

インスタンスタイプを変えたら、今までできていた名前解決ができなくなった。
あるいは、アプリが動かなくなった。
そんなことが起こったら、インスタンスタイプ間の差異が原因かもしれません。
CPUスペックとメモリ容量以外に、異なるインスタンスタイプの間にどんな違いがあるのか見ていきましょう。

①インスタンスストアの有無

インスタンスタイプによっては、「インスタンスストア」を持っているタイプとそうでないタイプがあります。

Amazon EC2 インスタンスストア
http://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/InstanceStorage.html

インスタンスストアとは、AWSの物理ホストに直接アタッチされているストレージです。
ご存じEBSがネットワークで接続されているのに対し、インスタンスストアは物理ホストに直接アタッチされています。そのためEBSよりも高速なI/Oが期待できますが、ひとたびインスタンスを停止してしまうとその内容は煙と消えてしまいます。インスタンスストアはその性質から、Ephemeral Diskとも呼ばれます。

インスタンスタイプ
https://aws.amazon.com/jp/ec2/instance-types/

上記の一覧表で、どのインスタンスタイプがインスタンスストアを持っているのかが分かります。「SSD ストレージ（GB）」の列に「EBSのみ」と記載されているタイプにはインスタンスストアがありません。一方で「2 x 40」のように記載されているインスタンスは、40GBのインスタンスストアを2つ使用可能であることを意味しています。

インスタンスストアを使用しているインスタンスを、ストア無しのタイプに変更して起動すると、インスタンスストアが無い状態で起動します。
もしもインスタンスストアをSwap領域として使っていたり、アプリケーションが一時ファイルの出力先として使用しているなど、システムがインスタンスストアの存在を前提としている場合は、タイプを変更する前にその点を解決しなくてはいけません。

[Image.1]例えばm3.largeにはインスタンスストアが存在する（Zドライブ）
[Image.2]同じインスタンスでもm4.largeで起動しなおすとZドライブが消えている

②ネットワークインターフェースのドライバの違い

拡張ネットワーキングに対応しているインスタンスタイプと、そうでないタイプでは使用されるネットワークインターフェースのドライバが異なっています。このドライバの違いに起因して、インスタンスタイプを変更した際に静的IPの指定やDNSサーバのアドレスなどの「アダプタ設定」が消えてしまうことがあります。

Windows の拡張ネットワーキング http://docs.aws.amazon.com/ja_jp/AWSEC2/latest/WindowsGuide/enhanced-networking.html

・t2, m3等、拡張ネットワーキングをサポートしていないインスタンスタイプでは「AWS PVドライバー」が使われます。
・m4, r4, c4等、拡張ネットワーキングがサポートされているタイプでは「Intel 82599 Virtual Function (VF) インターフェイス」または「Elastic Network Adapter (ENA)」が使われます。

(インタンスタイプとしてサポートしていてもOSが拡張ネットワーキングに非対応あればAWS PVドライバーが使用されます)

例えばWindows Serverでは、静的IPやDNSサーバ等のインターフェース設定はドライバに紐づいて保存されますので、インスタンスタイプを変えた際に違うネットワークインターフェースに切り替わってしまうと、設定が失われてしまいます。(実際には設定は消えるわけではなく、元のインスタンスに戻して起動すると復活します)

とはいえ、ネットワークインターフェースに静的にIPアドレスを書くというのは、どうしても必要がある場合を除いては避けたほうがよさそうです。原則的には、IPアドレスは自動取得の設定とするのがベストプラクティスです。

[Image.3]m3.largeは拡張ネットワーキングに非対応
[Image.4]m4.largeは拡張ネットワーキングに対応。
アダプタの表示が異なっており、設定も消えてしまった

③CPUアーキテクチャの違いによる差異

旧来のインスタンスタイプでは32bitアーキテクチャのOSがサポートされているものがあります。逆に最近のインスタンスタイプだと、64bitのOSしかサポートされていません。

サポートされるプロセッサアーキテクチャ(32bit/64bit)
https://aws.amazon.com/jp/ec2/previous-generation/

また、EC2インスタンスで利用可能な仮想化方式としてHVM(Hardware-assited VM)とPV(paravirtual)が存在しています。現在ローンチ可能なAMIは基本的にHVMのものとなります。PV方式のAMIからローンチしようとしたり、かつてローンチしたPV方式のEC2インスタンスのタイプを変更しようとすると、最近のインスタンスは利用できない場合があります。

Amazon Linux AMI インスタンスタイプマトリックス
https://aws.amazon.com/jp/amazon-linux-ami/instance-type-matrix/

最後に

EC2のインスタンスタイプ間の差異について
・インスタンスストア
・ネットワークインターフェースのドライバ
・CPUアーキテクチャの違いによる差異
の3点に着目して書きました。
インスタンススペックを簡単に変更できるのがAWSやクラウドコンピューティングの強みではありますが、特に商用環境では本当にその変更で問題なくシステムが動作するのか、十分な検証をもって臨みたいですね。