http://kokogiko.net/m/archives/001772.html
Amazon WebサービスのEC2を使ってみた
Posted by nene2001 at 06:26 / Tag(Edit): amazon ec2 / 0 Comments: Post / View / 7 TrackBack / Google Maps
たたみラボで 紹介されていたAmazon Webサービスの1つEC2（Amazon Elastic Compute Cloud：論理server）、1instance $0.10/hourだと、1ヶ月で$72.00、普通の専用サーバレンタルの最安のものと同程度か安いくらい、それで障害に対して安心なサーバとなると これはいいのでは？と思い試してみました。
試す前に準備しておく事は6つ。
- Amazon Webサービスのアカウントを取得します。
アカウントID（数字12桁） 、アクセスID（数字/英大文字20桁）、アクセス秘密ID（英数字/記号40桁）が作成されるので記録しておきます。- X.509証明書（cert-hogehoge.pem）とX.509秘密鍵（pk-hogehoge.pem）を作成し、ダウンロードしパスを張りやすいところに置いておきます。
- Java 1.5以上の実行環境を用意します。
- Javaのコマンドラインツールをダウンロード・セットアップし、環境変数（実行パス・X.509証明書/秘密鍵へのパス） を設定します。
- コマンドラインで「ec2-add-keypair」 コマンドを実行し、SSHアクセスのための秘密鍵を発行し、保存しておきます。
この時、コマンドラインシェル上でカット＆ペーストして改行がCRLFになっているとうまく動かないので、改行をLFで保存すること（ちょっとハマった）。- SSHアクセスにWindowsのputtyを使う場合は、さらに5.で作った秘密鍵を、puttygenを使ってputty形式に加工します。
以上でEC2を走らせる準備が整います。
以下、ローカルWindows上でのコマンドライン実行を「>」、EC2インスタンス上での実行を「#」として示します。
また、本当は1行の出力を2行に折りたたんでいるところは、インデントを深くして示します。まず、実行可能なイメージのリストをリストアップします。
>ec2-describe-images
IMAGE ami-5bae4b32 ec2-public-images/getting-started.manifest
206029621532 available public
IMAGE ami-68ae4b01 ec2-public-images/fedora-core4-base.manifest
206029621532 available public
IMAGE ami-69ae4b00 ec2-public-images/fedora-core4-apache-mysql.manifest
206029621532 available public
IMAGE ami-6dae4b04 ec2-public-images/fedora-core4-apache.manifest
206029621532 available public
IMAGE ami-6fae4b06 ec2-public-images/fedora-core4-mysql.manifest
206029621532 available public自分独自のイメージを作っていない当初は上記のイメージが公開されているようです。
とりあえず、ひとつのイメージを指定してインスタンスを実行してみましょう。>ec2-run-instances ami-68ae4b01 -k gsg-keypair
RESERVATION r-90d336f9 158999813159 default
INSTANCE i-0484606d ami-68ae4b01 pending gsg-keypairこれでインスタンスの実行が準備されます。
実際に起動するまでには結構な時間がかかります（少なくとも数分レベル）が、全てのインスタンスの現在の起動状況などをチェックするには以下のコマンドを使います。
起動途中の場合は「... pending ...」のメッセージが返るので、起動完了後の実行結果を示します。>ec2-describe-instances
RESERVATION r-90d336f9 158999813159 default
INSTANCE i-0484606d ami-68ae4b01
domU-12-31-33-00-04-76.usma1.compute.amazonaws.com running gsg-keypair続いて、インスタンスの外部からアクセス可能なポートを指定します（これは毎回やる必要はないようです）。
>ec2-authorize default -p 22
GROUP default
PERMISSION default ALLOWS tcp 22 22 FROM CIDR 0.0.0.0/0
>ec2-authorize default -p 80
GROUP default
PERMISSION default ALLOWS tcp 80 80 FROM CIDR 0.0.0.0/0以上の実行後、上記の緑色で示したドメインに、事前準備5.及び6.で作成した秘密鍵を用いてSSHでアクセスすると、EC2のインスタンス実行環境にアクセスできます。
これで、普通のレンタルサーバのように自由にツールインストールもシステム開発も自由自在です。
私はとりあえず、XAMPPをインストールして遊んでみました。
ただし注意すべき点として、レンタルサーバと違い飽くまでイメージを展開したインスタンスとして実行されているだけなので、インスタンスを止めるまでは状態は保持されますが、当然ながらインスタンスを止めてしまうと加えた変更は全て破棄されてしまいます。加えた変更も併せ再現可能な状況にしようと思えば、現在のインスタンスの状況をイメージ化してS3（Amazon Simple Storage Service：Amazon Webサービスのストレージサービス）上にアップロードし、イメージとして登録しなければなりません。
これを行うには、まずX.509証明書（cert-hogehoge.pem）とX.509秘密鍵（pk-hogehoge.pem）を、SCP等でイメージ化したいインスタンスのrootフォルダに転送しなければなりません。
その上で、インスタンス側で# ec2-bundle-vol -d /mnt -k ~root/pk-hogehoge.pem -u アカウントID -s 1536
Copying / into the image file /mnt/image.img...
Excluding:
sys
dev/shm
proc
dev/pts
proc/sys/fs/binfmt_misc
dev
media
mnt
proc
sys
tmp/image.img
mnt/img-mnt
1+0 records in
1+0 records out
mke2fs 1.38 (30-Jun-2005)
warning: 256 blocks unused.
Splitting /mnt/image.gz.crypt...
Created image.part.00
Created image.part.01
Created image.part.02
Created image.part.03
...
Created image.part.22
Created image.part.23
Generating digests for each part...
Digests generated.
Creating bundle manifest...
Bundle Volume complete.のようにすれば、インスタンス内にイメージが作成されます。
これ、むちゃくちゃ時間がかかります。「Create image.part.00」までのところで、普通に十数分待っている間には表示されませんでした。
待ちきれなくて、夜の1時から始めたのですが、寝てしまいまして、4時に目を覚ました時には完了していた、と言う状況なので、正確な実行時間はわかりませんでしたが...。その後、インスタンス側からこのイメージをS3にアップロードします。
下の記述中、紫色のところの名称は、イメージを識別するための名称なので、好きな文字列で構いません。私はxamppとしました。# ec2-upload-bundle -b xampp -m /mnt/image.manifest -a アクセスID -s アクセス秘密ID
Encrypting bundle manifest...
Completed encryption.
Uploading encrypted manifest...
Uploaded encrypted manifest to https://s3.amazonaws.com/xampp/image.manifest.
Uploading bundled AMI parts to https://s3.amazonaws.com/xampp/image...
Uploaded 00 to https://s3.amazonaws.com/xampp/00.
Uploaded 01 to https://s3.amazonaws.com/xampp/01.
Uploaded 02 to https://s3.amazonaws.com/xampp/02.
Uploaded 03 to https://s3.amazonaws.com/xampp/03.
...
Uploaded 23 to https://s3.amazonaws.com/xampp/23.
Uploaded 24 to https://s3.amazonaws.com/xampp/24.
Upload Bundle complete.これでS3へのイメージアップロードが終わりました。
今度はこのイメージを一覧に登録します。処理をローカルのコマンドラインに戻して、>ec2-register xampp/image.manifest
IMAGE ami-22ab4e4bこれで、インスタンス実行可能なイメージの一覧にオリジナルのイメージが加わりました。
>ec2-describe-images
IMAGE ami-22ab4e4b xampp/image.manifest 158999813159 available private
IMAGE ami-5bae4b32 ec2-public-images/getting-started.manifest
206029621532 available public
IMAGE ami-68ae4b01 ec2-public-images/fedora-core4-base.manifest
206029621532 available public
IMAGE ami-69ae4b00 ec2-public-images/fedora-core4-apache-mysql.manifest
206029621532 available public
IMAGE ami-6dae4b04 ec2-public-images/fedora-core4-apache.manifest
206029621532 available public
IMAGE ami-6fae4b06 ec2-public-images/fedora-core4-mysql.manifest
206029621532 available publicのように一覧にも出てきますし、
>ec2-run-instances ami-22ab4e4b
RESERVATION r-71d23718 158999813159 default
INSTANCE i-da8460b3 ami-22ab4e4b pendingのように実行すれば、xamppインストール済みのインスタンスを実行することができます。
実際の運用では、cronか何かで定期的にインスタンス側でのイメージを作成してS3にアップロードしておき、適宜ローカル側でイメージ登録する形で、運用環境をバックアップするようなイメージになるのかなと。さて、最後にはインスタンスを止めないと、延々と課金され続けてしまいます。
システム開発してサービスを走らせているならいいですが、今回は試してみただけなのできちんと止めましょう。>ec2-terminate-instances i-0484606d
INSTANCE i-0484606d running shutting-downこれでインスタンスも止まり、課金も止まります。
これだけ試してみてかかった利用費ですが、インスタンスの使用量が$0.40、これは4時間ほど走らせていたわけなので妥当なのですが、ネットワークの転送料金が$0.02かかっていたのにはちょっと驚きました。
ネットワークを使ったのは、XAMPPのパッケージのダウンロードと、一度XAMPPを起動させてみて、XAMPPのWeb画面が出ているのをブラウザで確認しただけなのですが、それで$0.02かかるのはちょっと思ったよりかかるな？という感じがしました。
高アクセスのWebサイトとか運営すれば、途端にネットワーク費が跳ね上がる印象が...私は転送量で課金されるサーバを使ったことがないので、ちょっと相場感が判らないのですが。以上のような感じで、準備手順はちょっとハードル高いですが、その後は割りと簡単に、インスタンスを落とすと変更内容全部消えちゃうのさえ気をつけておけば、普通のレンタルサーバと同じような感じで使えます。
今後のサーバソリューションとして、選択肢の一つにはなると思います。ご参考になれば。
No comments:
Post a Comment