CloudFormationでPV→HVMの嵌まり所

ウィスキー、シガー、パイプをこよなく愛する大栗です。 先日CloudFormationでEC2インスタンスをPVからHVMに変更した時に嵌ったので、まとめたいと思います。

PVからHVMへ変更する理由は？

PVからHVMへ変更する理由は大きく２個有ります。

HVMにしか対応していないインスタンスタイプが有る

新しいインスタンス対応ではHVMのみに対応している物が多く有ります。現行世代でPVの対応しているのはM3、C3、HS1のみです。Amazon EC2再入門 2014年7月版に詳しくまとめていますので、ご覧下さい。 旧世代ではPV対応が5タイプ、PV対応が5タイプでしたが、現行世代ではPV対応が3タイプ、HVM対応が7タイプとなっています。今後HVMへの移行が進んで行くと思われます。

パフォーマンス

パフォーマンスというと意外に思われる方が多いと思います。ウィキペディアのXen (仮想化ソフトウェア)にも以下の記載が有る様に、一般的に完全仮想化はエミュレーションのコストが大きく性能が悪いと思われています。

完全仮想化の環境は、準仮想化方式に比べると、エミュレーションのためのコストが大きくなるが、ソフトウェアをユーザの手で変更することが難しいWindowsなどのOSも動作させることができる。

しかし、c3.2xlargeでUnixBenchを実行するとスコアがPVに比べHVMが176%になっており大幅な高速化が見られます。

※Amazon Linux 2014.03でUnixBench 5.1.3を実行

HVMでが大幅なパフォーマンスアップが望めるため、ランニングコストの低下を図れます。

HVM移行で嵌ったところ

PVかHVMを決めるのはAMIが何方で作成されているかで決まります。そのため、CloudFormationでAMI IDだけ変えれば動くだろうと思っていましたが、注意すべき事項があります。

嵌まり所１：デフォルトのインスタンスタイプ

CloudFormationでは、パラメータでインスタンスタイプを入力させる事ができます。しかし、インスタンスタイプを決め打で書いたり、デフォルトのインスタンスタイプを決めたりする事も多く有ります。 前述した様にHVMに対応していないインスタンス対応が有るため、テンプレート内に記述しているインスタンスタイプがHVMに対応していない場合には書き換えましょう。

嵌まり所２：Root Device Name

EC2のRoot DeviceのサイズやEBSの種類を指定する場合にはBlockDeviceMappingsを記述する必要が有ります。ここでRoot Dvice Nameを指定するのですが、その内容に注意して下さい。

Amazon LinuxのRoot Device Nameを確認しましょう。

$ aws ec2 describe-images --filters '[{ "Name": "name", "Values": ["amzn-ami-pv-2014.03.0.x86_64-ebs"]}]' --query Images[*].RootDeviceName
[
    "/dev/sda1"
]

$ aws ec2 describe-images --filters '[{ "Name": "name", "Values": ["amzn-ami-hvm-2014.03.0.x86_64-ebs"]}]' --query Images[*].RootDeviceName
[
    "/dev/xvda"
]

なんとPVとHVMでRoot Device Nameが異なっています。これはAmazon Linux 2014.03特有の事象なのでAmazon Linux 2014.03を使用する時にはご注意下さい。Amazon Linux 2013.09まではPVとHVMでRoot Device Nameは同じでした。

この誤りはたちが悪く、CloudFormationのStackは正常に作成できます。正常にStackが作成されたのにEC2が起動せずStoppedになっており、StartしてもすぐにStoppedになってしまうという状態になってしまいます。

MAnagement ConsoleからEC2を起動する場合には、インスタンスタイプは起動できる物のみ表示され、Root Device NameはAMIの情報がそのまま転記されます。そのため意識する事が無いと思いますが、指定を誤るとEC2が起動できない重要なパラメータです。

最後に

このブログを見ている方は大量のテンプレートを抱えていると思います？ので、この記事を参考にHVM化を試してみて下さい。