自分のイメージファイルを作ろう

先述したように，EC2ではインスタンスを止めてしまうと，ディスクの内容はすべて消失してしまいます。それでは困ってしまうので，現在の状態をイメージファイル（AMI）にする方法を解説します。

準備

試しに，先ほど起動したインスタンスにPukiWikiをインストールします。

ec2# wget -O - http://globalbase.dl.sourceforge.jp/pukiwiki/12957/pukiwiki-1.4.7_notb.tar.gz|tar xvfz -
ec2# chown apache pukiwiki-1.4.7_notb

ブラウザで「http://ec2-72-44-50-86.z-1.compute-1.amazonaws.com/pukiwiki-1.4.7_notb/」を開くと，PukiWikiの画面が表示されます。

それでは，この状態をイメージ化しましょう。

イメージファイルの作成

イメージの作成にはX.509証明書が必要です。作業マシンから.pemファイルを/mntディレクトリに転送しておきます。

$ scp -i testmachine.id *.pem root@ec2-72-44-50-86.z-1.compute-1.amazonawcom:/mnt

イメージ化には「Account Number」も必要です。Account Numberは図2の利用状況ページの上部に表示されている「xxxx-xxxx-xxxx」という数字です。これをコマンドに与えます。

それではEC2上で，ディスクの内容をイメージ化しましょう（図16）。これで，このインスタンスがイメージがされました。

ec2# cd /mnt
ec2# ec2-bundle-vol -d /mnt --privatekey <Private Keyファイル名> --cert <Certificateファイル名> --user <Account Number>
Please specify a value for arch [i386]:  そのまま[Enter]
Copying / into the image file /mnt/image...
Excluding:
.....しばらくかかります.....

気をつけなければいけないのは，sda1しかイメージ化されないことです。sda2は/mntにマウントされており，こちらはイメージに含まれません。

イメージファイルをAmazon S3へアップロード

今作成したイメージからほかのインスタンスを起動するために，S3にアップロードしましょう（図17）。これで，S3に今のイメージが登録されました。

ec2# ec2-upload-bundle --bucket <アップ先のバケット> --manifest image.manifest.xml --access-key <Access Key ID> --secret-key <Secret Access Key>
Setting bucket ACL to allow EC2 read access ...
....
Uploading manifest ...
Uploaded manifest to https://s3.amazonaws.com:443/webdbpress/image.manifest.xml.
ec2-upload-bundle complete

イメージファイルの登録

今アップしたイメージをリストに登録します（図18）。この操作は，一度EC2を抜けて作業用のマシンで行ってください。

$ ec2-register <アップしたバケット>/image.manifest.xml
$ ec2-describe-images -o self
IMAGE  ami-3929cc50  webdbpress/image.manifest.xml  956688471479  available private

新たなインスタンスの起動

今アップしたイメージを使って，もう一つインスタンスを立ち上げてみましょう。作業マシンで次のコマンドを実行します。

$ ec2-run-instances ami-3929cc50 -k testmachine
$ ec2-describe-instances

起動後にそのホスト名にアクセスすると，PukiWikiがインストールされた状態で起動されています。

このように一度イメージを作ってしまえば，何個でもその状態で起動できるのがEC2の大きな特徴です。

インスタンスを停止する

さて，一通りテストが終わったので，起動したインスタンスを一度停止しておきましょう。起動したままにしておくと，その分お金がかかってしまいます。

インスタンスを停止する際には，インスタンスIDが必要です。インスタンスIDはec2-describe-instancesコマンドで取得できます（図19）。INSTANCE行2列目の「i-」で始まる番号がインスタンスIDです（ここでは「i-a09969c9」と「i-a2354d43」）。複数起動している場合は，マシン名などでインスタンスを選んでください。

$ ec2-describe-instances
RESERVATION  r-eac62d83 956688471479  default
INSTANCE     i-a09969c9 ami-25b6534c  ec2-72-44-50-86.z-1.compute-1.amazonaws.com    domU-12-31-36-00-29-D4.z-1.compute-1.internal running testmachine 0
RESERVATION  r-563af98d 478394t34853  default
INSTANCE     i-a2354d43 ami-3929cc50  ec2-32-44-90-22.z-1.compute-1.amazonaws.com    domU-22-31-46-00-29-D4.z-1.compute-2.internal running testmachine 0
$ ec2-terminate-instances i-a09969c9
INSTANCE     i-a09969c9 running       shutting-down
$ ec2-terminate-instances i-a2354d43
INSTANCE     i-a2354d43 running       shutting-down
.....少し待ちます.....
$ ec2-describe-instances
RESERVATION  r-eac62d83 956688471479  default
INSTANCE     i-a09969c9 ami-25b6534c  terminated  testmachine 0
RESERVATION  r-563af98d 478394t34853  default
INSTANCE     i-a2354d43 ami-3929cc50  terminated  testmachine 0

インスタンスIDがわかったら，ec2-terminate-instancesコマンドに停止させたいインスタンスIDを与えて実行すると，そのインスタンスを停止できます。

ec2-terminate-instancesコマンドを実行後少し待ってから，ec2-describe-instancesコマンドを再び実行してみると，停止したインスタンスからホスト名などが消えて「terminated」になっていることが確認できます。

フレキシブルなサーバ構成

今回作成したイメージを使うことで，コマンド一つで新しいサーバを起動させることができるようになりました。これをうまく使うことで，アクセスの多い時間帯はアプリケーションサーバの台数を増やすなど，図1で紹介したようなフレキシブルな構成にすることができるようになります。

しかし，これにはいくつかのコツが必要です。

リバースプロキシサーバ

EC2では，インスタンスを停止して再起動すると，違うIPアドレスが発行されます。そのため，時間帯によってマシンを増減させるとそのたびにマシンのIPアドレスが変わってしまい，リンク切れなどの不都合が起こります。

そこで，リバースプロキシになるインスタンスを
1つ起動し，これを常に稼働させておくようにします（図20）。

データベースサーバ

データベースの増減もなかなか難しい分野です。動的にクラスタリングの構成を変更できるような環境はまだ少ないので，負荷に合わせてデータベースサーバを増減させるのは難しいです。

ですので，データベースについては始めから複数台用意しておくなど，対策をとる必要があります。

アプリケーションサーバ

残りはアプリケーションサーバです。ここは，マシンの台数を増やすと，その分スケールしていくような構成が取りやすい部分です。

ただしこの場合，アプリケーションサーバのインスタンスには一切データを保存しないようにする必要があります。インスタンスごとにデータを保存する場合は別途レプリケーションのしくみなどが必要になるでしょう。

おわりに

いろいろ考慮すべき事柄はありますが，急に負荷が増えたときにも即座に対応できるしくみを構築できるのが，EC2のおもしろいところです（筆者は，コンピュータが自己増殖的な動きをするものに無駄に萌えます）。