Amazon Web Servicesの勘所第2回

AMI = Amazon Machine Image

EC2インスタンスの起動時には、Amazon Machine Image、略してAMIを選択します。（図3）。AMIは大雑把に言えば、EC2インスタンスの起動ドライブの内容をテンプレート化したものです。例えばAmazon LinuxのAMIの場合、その中にはFedoraをベースにカスタマイズされたLinuxの起動ドライブのイメージが入っており、インスタンスの起動時には仮想マシンの起動ドライブにAMIの内容がコピーされ、仮想マシンがブートされることになります。

図3：Amazon Machine Image（クリックで拡大）

例えるなら、AMIとEC2のインスタンスとの関係は、オブジェクト指向言語におけるクラスとインスタンスの関係のようなものです。AWSのデータセンターのサーバー群は、メモリ空間に当たると考えてもらえば良いでしょう。1つのクラスからは、いくつものインスタンスを生成することができます。

EC2を使い始めたときに悩むのが、「AMIがたくさんありすぎて、どれを使えば良いのか分からない」という点かも知れません。AMIは、ユーザーがカスタマイズして独自に作成したものを公開することもできるため、非常に多くの種類が登録されています（図4）。

図4：登録されているAMIの一覧（クリックで拡大）

ただし通常の場合は、LinuxであればAWS自身によってメンテナンスされているAmazon Linuxや、Ubuntuの公式のAMIを使えば良いでしょう。Windowsの場合は、Microsoftの公式のAMIがあります。Windowsの公式AMIには、OSのみのものもあれば、IISやSQL Serverがインストールされているものもあります。

また、AMIには32bit/64bitアーキテクチャの区別と、root device（起動ドライブ）がEBSベースかインスタンスストレージベースかといった区別があります。現在では、32bitアーキテクチャのAMIを利用しなければならない理由はほとんどありません（32bitアーキテクチャを選択する必要があるのは、インスタンス上で動かすアプリケーションが32bit環境でしか動かない場合だけでしょう）。

root deviceについては、通常はEBSのものを選択しておけば良いでしょう。EBSベースのインスタンスは、使わなくなった場合にそのまま停止させておくことができますが（停止中に生ずる課金はEBSのストレージ容量の分だけです）、インスタンスストレージの場合は、インスタンスは終了させることしかできません。
通常のPCに例えるなら、前者はPCの電源を切ってそのまま置いておくことに、後者はPCを完全に廃棄してしまうことに相当します。インスタンスストレージをベースのAMIは、起動が速い（すなわちスケールアウトが高速に行える）という利点があるので、後に取り上げるAuto Scalingと合わせて使う場合にメリットがあります。

AMIのカスタマイズ

公式のAMIから立ち上げられるインスタンスを、実運用のシステムでそのまま使うことはあまり多くありません。EC2のインスタンスも障害を起こすことがあるので、通常はアプリケーションなどをインストールしたカスタムのAMIを作成し、そのAMIからインスタンスを起動しさえすれば、すぐにアプリケーションが利用できるようにします。

AMIのカスタマイズはそれほど難しくありません。特にEBSベースのAMIの場合、基本的には必要なアプリケーションやライブラリをインストールしてからいったんインスタンスを停止しておき、Management Consoleのポップアップメニューで「Create Image」を選択するだけです。こうして作成したカスタムのAMIは、その後EC2インスタンスを立ち上げる際のAMIの選択画面で「My AMI」に表示されるようになるので、すぐに利用できるようになります。

AMIのカスタマイズは、AWSを利用する上で非常に重要です。この後取り上げるAutoScalingを使って冗長性を持たせたシステムの構築においても、自動的にインスタンスを立ち上げたり終了させたりするために、カスタムのAMIを用意することが必要になります。

様々なインスタンス