日々のできごとと写真

EC2で利用可能なWindows Server 2003を日本語化してみる

2009-02-16 01:47 | IT | 3 コメント »

EC2上で利用できるWindowsサーバーが英語版ということもあって、日本語化したAMIイメージをいつでも利用できるようにしてみました。

なんだかものすごく長くなってしまったので、最初に目次を用意しておきます。
(目次の生成にTable of Contents Generatorプラグインを利用。これは便利。)

目次

まずはWindows Server 2003を立ち上げる

イメージ一覧を表示

インスタンスを立ち上げる

イメージを選ぶ

今回はBasic Microsoft Windows Server 2003(Microsoft Windows 2003 R2 Data Center edition 32bit)を選択します。

イメージを選ぶ

鍵ファイルを生成

「windows」という名前を付けています

鍵ファイルを生成・ダウンロード

生成完了

aws_console_for_win_04

生成が完了すると、「設定した名前.pem」というテキストファイルが自動的にダウンロードされます。

ダウンロード

外部アクセス制限(ファイアーウォール)

windows用の設定なので3389ポートのみをオープンにした「windows_default」という名前のsecurity groupを作成します。

アクセスコントロール

最終設定

インスタンス数(今回は1)とインスタンスタイプ(今回はsmall)を選びます。

最終設定

インスタンスが起動しました。

インスタンス化終了

インスタンス起動中のステータス

インスタンスはstarting→pending→runningの順でステータスが移り変わります。

ステータスの遷移

Administratorパスワードを取得

EC2のシステムでランダムに生成されたAdministratorパスワードが指定した鍵ファイルを使って暗号化(encrypt)されているので、復号化(decrypt)して取得します。

Windowsのインスタンスを選んで、Passwordをクリックします。

Passwordをクリックします

ただし、インスタンス起動直後はパスワード生成と暗号化がまだ完了していないので、2、3分待ちます。

起動後間もなくはパスワード生成ができない

正常に生成が終わっていれば、この画面が表示されます。

パスワード生成ウィンドウ

Private Keyにテキストエリアに該当する鍵情報(今回はwindows.pemファイルの中身)をペーストします。

ダウンロード済み鍵ファイルをコピペ

鍵が一致すれば復号化されたパスワードが表示されるので、記憶します。

パスワードゲット

リモートデスクトップで接続

接続の前に

既にIPアドレスがわかっているので接続できますが、「Conect」をクリックすることで、接続方法のヘルプが確認できます。
しかも、「OPTION 1: Shortcut File」にあるshortcut fileをダウンロードすることで、簡単に接続ができます。

接続するためのヘルプ

結果は同じでも2通りの方法が示されています

リモートデスクトップで接続

リモートデスクトップを起動し、インスタンスのリモートホスト名を入力、接続します。

リモートデスクトップで接続

証明書で警告がでますが、無視して進めます。

証明書エラー

無事接続できれば、ログオンダイアログが表示されます。

接続完了

さっき記憶したAdministratorパスワードを入力し、ログオンします。

先ほど生成したパスワードを入力

ログオンできれば、デスクトップが表示されます。

無事ログイン

ちなみにMacの場合は

Microsoft純正のMac版リモートデスクトップがリリースされているので、そちらをダウンロードして利用しましょう。
試してみましたが、なんの問題も無く接続できました。
Mactopia Japan : Microsoft Remote Desktop Connection Client for Mac 2

Macからでも可能です

いよいよ日本語化

日本語化するにはWindows Serverのメディア(CDのデータ)が必要になりますが、デフォルトのC、Dドライブには入っていません。

ドライブ構成はCとDのみ

スナップショット

しかし、AmazonがスナップショットイメージとしてCDのデータを提供してくれているので、EBSを経由して利用します。
まず、インスタンスのZoneを確認しておきます。今回の場合は、「us-east-1b」でした。

インスタンスのZoneを覚えておきます

EBSを利用してEドライブを作成

ELASTIC BLOCK STORE > Volumes > Create Volumeをクリックします。

EBSのVolumeを作成

ディスクサイズは 2G、ゾーンは先ほど控えたインスタンスと同じゾーンを選びます。
(ここでインスタンスと違うゾーンを選んでしまうと接続できなくなります。)

snapshotで、Windows 2003 R2 Datacenter 32-bitを選びます。(違うOSを利用している場合は該当するsnapshotを選びます。)

Windows CDの中身がスナップショットとして存在

選択したsnapshotのIDと同じIDが一番下のテキストボックスに入力されたことを確認します。
(ここが空欄のままだと空のボリュームが作成されてしまいます。)

idを確認

statusがavailableになったら利用するボリュームにチェックをして、Attach Volumeをクリックします。

aws_console_for_win_28

接続先のインスタンスとデバイス(Windowsの場合はあまり関係ないですね。)を選びます。

接続先のインスタンスをよく確認

ステータスがin-useになれば、接続が完了です。

aws_console_for_win_30

インスタンスのWindowsへ戻ってみると、自動的にEドライブが認識されています。

Windows上では自動的に認識

ディレクトリ構成はこんな感じです。

ディレクトリ構成

Regional and Language Options

いよいよ、日本語化の設定です。
Regional and Language Optionsを実行します。

 

日本語化の設定をはじめます

まずLanguagesタブにある日本語(東アジア圏の言語)をインストールするためのチェックボックスにチェックを入れます。

東アジアを利用する

Advancedタブの設定も日本語(Japanese)にしておきます。

aws_console_for_win_35

OKを押すと、CD-ROMを要求されます。

CDを要求されます

ここで先ほどのドライブを指定します。今回の場合は、E:¥Disk1¥i386になります。

EBSのボリュームを選びます

ファイルのコピーが始まります。

ファイルのコピーが始まりました

全てコピーが終わった後、再起動します。

再起動を聞かれるので、Yes

再起動の確認は?

再起動をするとコネクションが切れてしまうので、再起動したかどうかはOutputを見るとわかります。

Output

再起動後、システムが正常に動いていれば「Windowos is Ready to use」というログが確認できるはずです。
ちなみにログをよく見てみると、ローカライズする前と後で日付の出力フォーマットが変わっています。 

Windowos is Ready to use

日本語の確認

再起動後、タスクバーの右下に言語切り替えが表示されています。

再起動後、日本語が・・・

フォーマットの設定を日本語してみると、きちんと日本語で表示されます。

aws_console_for_win_41

日本語の入力もできるようにキーボードの設定をします。

aws_console_for_win_42

ブラウザーを立ち上げてみると。

IEを開いてみると

このブログも化けずに表示されました。

おお、日本語だ

日本語の入力も問題なしです。

日本語も入力できます

日本語化したインスタンスをイメージ化(再利用)する

せっかく日本語化したので、いつでも利用できるようにイメージ化しようと思います。

起動中のインスタンスを選んで「Bundle」ボタンをクリックします。

aws_console_for_win_45

自分のアカウントでアクセスできるS3のバケット名とファイル名を設定します。

S3上のパスと名前を付けます

設定に問題が無ければ、すぐにイメージ作成がはじまります。

生成開始

Bundle Tasksをクリックすると、bundleの進行が確認できます。

aws_console_for_win_48

ステータスは、bundling→storing→completeと変化します。
Windowsはデータが重いので結構時間がかかります。

bundle中のステータス遷移

complete後、EC2にAIMとして登録します。
左上にあるRegister as AMIボタンはアクティブにならない(不具合?)ので、登録したいイメージの行の上で右クリックするとポップアップメニューで「Register as an AMI」が表示されるので、こちらから登録します。

登録方法は右クリックから

マニフェストファイルのパスを確認します。

登録確認

登録されました。

登録完了

登録すると、自分のAMI一覧にWindowsマークのついたAMIが表示されます。

きちんと登録されました

 

 

EC2のコマンドラインと AWS Management Consoleを比べてみた

2009-02-07 02:09 | IT | コメントをする »

AWS Management Consoleを実際に触ってみました。
今まではJavaベースのコマンドツール入れて(その前にJRE入れて)、コマンド叩いてはtypoしてイライラを募らせていたわけですが、それを解消する素晴らしいツールです。
まだBeta版ですが、*かなり* 完成度が高いです。
操作に全く疑問を抱かせない情報設計と洗練されたUI、そして安定的なシステム。素晴らしい。

今回は、コマンドでいうこれはConsoleでいうどういう操作?を比べてみました。
良く使うコマンドのみですが。

https://console.aws.amazon.com/ec2/

ec2-describe-images(Alias=ec2dim)

S3上に登録されているインスタンス化可能なイメージ一覧を取得するコマンド

Consoleでは左メニュのAMIsをクリックするだけで一覧がでます。

ec2-describe-images

しかも、イメージの種類(Amazon謹製イメージ、公開イメージ、個人イメージ、自分のイメージ、アーキテクチャ別)で選べる上、

イメージの種類

OS(CentOS,Debian,Fedora,Gentoo,Open Solaris,Red Hat,SUSE,Ubuntu,Windows)も合わせて検索できます。
これは便利ですね。

プラットフォームから検索

例)公開イメージの中からCentOSを選んだ状態

公開済みのCentOSのイメージ一覧

ec2-register(Alias=ec2reg)

S3上にあるイメージファイルをEC2に登録するコマンド

ConsoleではAMIsから上部メニュにある「Register New AMI」をクリックすると、ダイアログウィンドウがでるので、S3上にあるマニフェスト(xml)ファイルを指定します。

ec2-register

ec2-add-keypair(Alias=ec2addkey)

ログイン用の暗号キーを生成、登録するコマンド

Consoleでは、「Key Pairs」→「Create Key Pair」と進めていくと、秘密鍵の名前を聞くダイアログがポップアップします。

ec2-add-keypair1

名前を入れ「Create」を実行すると、実行結果の表示と秘密鍵のダウンロードが始まります。

ec2-add-keypair2

ec2-delete-keypair(Alias=ec2delkey)

生成済みのログイン用の暗号キーの登録を削除するコマンド

Consoleでは、「Key Pairs」→削除したいキーを選択→「Delete」→「Yes, Delete」で完了です。

ec2-add-keypair3

ec2-run-instances(Alias=ec2run)

登録済みイメージからインスタンスを起動するコマンド

ダッシュボードトップから、「Launch Instances」をクリック

ec2-run-instances1

Launch Instancesから起動したいイメージを選び、「Select」をクリック

ec2-run-instances2

KeyPairもFirewallもすでに設定済みの場合は、一気に起動設定の項目まできます。
起動するインスタンス数、インスタンスの種類、利用するキー、Firewallのグループをすべて選び、「Launch」

ec2-run-instances3

無事起動すると、完了画面が表示されます。

ec2-run-instances4

ec2-authorize(Alias=ec2auth)

外部からどのポートにアクセスを許可するのか設定するコマンド

「Security Groups」を開くと、すでに設定済のものがあれば一覧が表示されます。
右上のリストを選ぶと、右下に詳細設定画面が表示され、ここで設定できます。
許可リストなので、LinuxでWebサーバーならば、22番と80番を許可したリストを作って「web_on_linux」などと名前を付けて用意しておくと便利かもしれません。
許可リストは複数作成してAND条件で複数指定できるようなので、linux_defaultで22番/webで80番と作って2つをセットする使い方が美しいですね。

ec2-authorize

ec2-terminate-instances(Alias=ec2kill)

起動中のインスタンスを停止するコマンド

Instancesを選び、インスタンス一覧から停止したいインスタンスをチェックし、「Terminate」をクリック

ec2-terminate-instances1

確認ダイアログがポップアップするので、「Yes, Terminate」を実行。

ec2-terminate-instances2

あーもう絶対コマンド使わなくなるな。

Aptana Cloudがとても簡単なのでかけ足で紹介

2008-12-22 01:46 | IT, エントリー | 1 コメント »

Aptana Cloudを利用してみました。
統合開発環境のAptana Studioで有名な米Aptana社が運営しているWebアプリケーションのホスティングサービスです。

AmazonのEC2よりも上位層のアプリケーションレベルのホスティングなので、Google App Engineと同等のホスティングと言えます。

Eclipseからサインアップをしてみる

EclipseにAptanaのプラグインをインストールして、My Aptanaを開きます。

My Aptanaトップ

サイト名(サブドメイン名)と利用方法を決めます。今回は、21日間無料トライアルを利用しました。

サインアップ1

Aptana IDを持っていない場合は、ここでアカウントを作ります。

サインアップ2

利用規約をよく読んで同意します。

サインアップ3

アプリケーションサーバーの環境構築処理が始まります。

サインアップ4

アプリケーションサーバーの構築が完了しました。

サインアップ5

生成されたURLにアクセスすると、なんと、すでに利用可能に。

環境構築後のトップページ

コントロールパネルから全容を把握してみる

Aptana Cloudの構築が終わると、My AptanaにMy Cloudとうタブが加わります。
Aptana Cloudへのアクセスは基本的にこのコントロールパネル上から行います。

Overview

コントロールパネル1

Settings

コントロールパネル2

Stats

コントロールパネル3

Services

コントロールパネル4

Logs

コントロールパネル5

less httpd access_log

コントロールパネル6

アプリケーションのデプロイ

構築はあっという間でした。
Aptana Cloudの最大のメリットはIDEとの連携、そのシームレスさにあります。
Eclipseで開発を行う場合は、そのプロジェクト単位でアプリケーションの開発をおこないますが、そのプロジェクトとCloudをシンクロさせることが可能です。

アップロード

フルスタックのWebアプリケーションフレームワークを利用して開発を行う場合は、フレームワークのプロジェクト=Ecliplseのプロジェクトとすることで、このツールでシンクロし、幾つかコマンドを叩くだけですぐにアプリケーションが利用可能となります。

このスムーズさは感動的です。

ネットワークの近さをみる

pingを使ってみてみましょう。

PING ms76.aptanacloud.com (207.7.120.111): 56 data bytes
64 bytes from 207.7.120.111: icmp_seq=0 ttl=240 time=134.128 ms
64 bytes from 207.7.120.111: icmp_seq=1 ttl=240 time=121.795 ms
64 bytes from 207.7.120.111: icmp_seq=2 ttl=240 time=124.219 ms
64 bytes from 207.7.120.111: icmp_seq=3 ttl=240 time=120.803 ms

今回割り当てられたIPを逆引きをすると、207-7-120-111.joyent.comとなるので
インフラはJoyentを利用しているようです。

tracerouteでは

#snip
10  xe-3-2-0.edge1.LosAngeles9.Level3.net (4.53.228.13)  137.081 ms  112.595 ms  113.381 ms
11  ge-2-1-0-69.bbr2.LosAngeles1.Level3.net (4.68.20.2)  119.894 ms ge-3-0-0-79.bbr1.LosAngeles1.Level3.net (4.68.20.65)  112.601 ms ge-6-2-0-99.bbr1.LosAngeles1.Level3.net (4.68.20.193)  112.317 ms
12  as-2-0.mp2.SanDiego1.Level3.net (64.159.1.138)  110.432 ms as-1-0.mp1.SanDiego1.Level3.net (64.159.1.29)  117.113 ms as-2-0.mp2.SanDiego1.Level3.net (64.159.1.138)  119.620 ms
13  so-8-0.hsa2.SanDiego1.Level3.net (4.68.112.138)  122.329 ms  122.332 ms  122.253 ms
14  sd-gw01-hsa2.nextlevelinternet.com (4.79.33.246)  123.228 ms  122.413 ms  121.994 ms
15  207-7-101-53.sd.nextlevelinternet.com (207.7.101.53)  116.279 ms  116.652 ms  117.598 ms
16  207-7-100-52.sd.nextlevelinternet.com (207.7.100.52)  110.002 ms  111.936 ms  110.253 ms
17  207-7-120-111.joyent.com (207.7.120.111)  115.965 ms  115.817 ms  115.724 ms

LosAngeles、SanDiego(ルートによってはSeattle)などの地名がみえるので
サーバーは北米西海岸にある模様。
EC2よりネットワーク的に速いのは地理の要因でしょうか。

ログインしてシステムをみる

なんとSSHでシェルにも入れます。

            __                       __             __
 ___ ____  / /____ ____  ___ _  ____/ /__  __ _____/ /
/ _ `/ _ \/ __/ _ `/ _ \/ _ `/ / __/ / _ \/ // / _  /
\_,_/ .__/\__/\_,_/_//_/\_,_/  \__/_/\___/\_,_/\_,_/
   /_/ Welcome to ms76.aptanacloud.com!               

/!\ Warning!
SSH access to Aptana Cloud is provided pursuant to the Aptana Cloud
Terms of Service.  See http://www.aptana.com/cloud/tos for important
information related to your access to various areas of your Cloud
Site.  

Aptana does not warrant any Services modified by you via SSH, nor will
we be obligated to support fixing problems that may arise as a result
of such modifications.

無事ログイン。

まずはunameをチェック。

-bash-3.2$ uname -a
SunOS 9a2640a1.joyent.us 5.11 snv_89 i86pc i386 i86pc

もうちょっと詳しく。

-bash-3.2$ cat /etc/release
Solaris Nevada snv_67 X86
Copyright 2007 Sun Microsystems, Inc.  All Rights Reserved.
Use is subject to license terms.
Assembled 18 June 2007
-bash-3.2$ cat /var/sadm/system/admin/INST_RELEASE
OS=Solaris
VERSION=11
REV=0

Solaris Nevadaということがわかります。

続いてハードウェアをチェックしてみます。

メモリ

-bash-3.2$ /etc/prtconf
System Configuration:  Sun Microsystems  i86pc
Memory size: 32763 Megabytes
System Peripherals (Software Nodes):

CPU

-bash-3.2$ /usr/sbin/psrinfo -v
Status of virtual processor 0 as of: 12/18/2008 15:57:29
on-line since 10/03/2008 03:21:40.
The i386 processor operates at 2660 MHz,
and has an i387 compatible floating point processor.
Status of virtual processor 1 as of: 12/18/2008 15:57:29
on-line since 10/03/2008 03:21:42.
The i386 processor operates at 2660 MHz,
and has an i387 compatible floating point processor.

#snip

Status of virtual processor 6 as of: 12/18/2008 15:57:29
on-line since 10/03/2008 03:21:42.
The i386 processor operates at 2660 MHz,
and has an i387 compatible floating point processor.
Status of virtual processor 7 as of: 12/18/2008 15:57:29
on-line since 10/03/2008 03:21:42.
The i386 processor operates at 2660 MHz,
and has an i387 compatible floating point processor.

ディスク

-bash-3.2$ df -h
Filesystem             size   used  avail capacity  Mounted on
/                        0K   2.1G   4.9G    30%    /
/dev                     0K     0K     0K     0%    /dev
/lib                   2.0G   505M   1.4G    26%    /lib
/platform              2.0G   505M   1.4G    26%    /platform
/sbin                  2.0G   505M   1.4G    26%    /sbin
/usr                   3.9G   888M   3.0G    23%    /usr
proc                     0K     0K     0K     0%    /proc
ctfs                     0K     0K     0K     0%    /system/contract
mnttab                   0K     0K     0K     0%    /etc/mnttab
objfs                    0K     0K     0K     0%    /system/object
swap                    72G   176K    72G     1%    /etc/svc/volatile
/usr/lib/libc/libc_hwcap1.so.1
                       3.9G   888M   3.0G    23%    /lib/libc.so.1
fd                       0K     0K     0K     0%    /dev/fd
swap                   256M    96K   256M     1%    /tmp
swap                    72G    12K    72G     1%    /var/run

8つのCPU、32GBのRAMを仮想サーバー(Solaris コンテナ)でシェアしている模様。
この当たりはもともとJoyentの仕様っぽいですね。

すぐに使える言語やサービスをみる

Webアプリケーションに利用する言語やミドルウェアをチェックしてみましょう。

Ruby

-bash-3.2$ ruby -v
ruby 1.8.6 (2007-09-24 patchlevel 111) [i386-solaris2]
-bash-3.2$ gem -v
1.3.1
-bash-3.2$ rails -v
Rails 2.2.2

PHP

-bash-3.2$ php -v
PHP 5.2.5 (cli) (built: Feb  4 2008 23:39:26)
-bash-3.2$ pear info pear
Packaged With PEAR  1.5.4

Perl

-bash-3.2$ perl -v
This is perl, v5.8.8 built for i386-solaris-thread-multi
-bash-3.2$ cpan -v
cpan script version 1.03
CPAN.pm version 1.7602

Java

-bash-3.2$  java -Xmx32m -version
java version "1.6.0_06"
Java(TM) Platform, Standard Edition for Business (build 1.6.0_06-b02)
Java HotSpot(TM) Server VM (build 10.0-b22, mixed mode)

Python

-bash-3.2$ python -V
Python 2.4.4

Apache

-bash-3.2$ apachectl -v
Server version: Apache/2.2.8 (Unix)
Server built:   Feb  4 2008 23:16:59

MySQL

-bash-3.2$ mysql -V
mysql  Ver 14.12 Distrib 5.0.51, for sun-solaris2 (i386) using readline 5.2

PostgreSQL(未起動)

psql (PostgreSQL) 8.2.6
contains support for command-line editing

SQLite

-bash-3.2$ sqlite -version
2.8.16

この辺りはEC2と違ってはじめから全部入りの模様です。
Google App Engineが現在はPythonのみをサポートしていることを考えると、対象の開発者は絶対的に多いはずです。
しかし、逆にメモリが苦しいからPHP外したいとか、passengerではなくmongrelで動かしたいとかいうワガママは通らないようです。

自分のドメインで利用する

Aptana Cloudを構築するとサブドメインとグローバルなIPアドレスが振られます。
なので、DNSでAレコード、もしくはCNAMEレコードを設定するだけです。
この辺りはFAQに載っています。

追記
12/22 13:40 タイトル変更しました。

Amazon CloudFrontを体験してみた

2008-12-15 01:30 | IT, エントリー | 1 コメント »

遅くなりましたが、CloudFrontを体験してみました。

実験の前に参考サイト

CloudFrontの設定方法や、ダウンロードのベンチマークなどは以下のサイトを参考にしましょう。(と丸投げ)

実験の方法

今回やりたかったことは、ブラウザーを使って普通にブラウジングをしてみて、体感を測ることです。

  1. HTMLファイル    1
  2. JSファイル    5
  3. CSSファイル    2
  4. 画像ファイル    25

合計33ファイル、163KBのページを表示して、ページがロードされる具合を体感してみました。

EC2単体で体感実験

まずは、全てをEC2のスモールインスタンス上にアップした状態で体感。
Apacheは2.2.9、設定はrpmのデフォルト。KeepAliveはOFF。

EC2スモールインスタンスへアクセス

やはりもっさり感は否めません。(4.6秒)

CloudFrontで体感実験

では1のHTML以外をS3にアップロードして、CloudFront経由で体感してみます。

CloudFront経由で体感

これは明らかに速い(1.16秒)。EC2の場合は「ただいま画像1つ1つをロードしてます」って感じで画像が描画されるまでもたもたしていましたが、CloudFront経由の場合はページのロードと同時に画像も描画されました。

Etagもきっちり返してくれるので2回目以降のアクセスには304が返ってきますし、gzipを利用したhttp圧縮も行われているので、cssやjsなどのテキストファイルは効率よく転送されるはずです。

CloudFrontアクセス時のヘッダ

ただし、最初のアクセス時はキャッシュサーバーにデータが届いていないため、キャッシュする為にS3サーバーからの転送時間が加わるので、もっさり感を感じます。2回目はX-Cacheヘッダーが上画像のように変わります。

まとめ

実に簡単な体感実験ですが、CloudFrontの実力は歴然でした。
イメージサーバなどの用途で静的なファイルを負荷分散をするサーバーを立てるケースを想定すると、アクセス急増時にロードバランサー配下のリアルサーバーを増やしたり、静的なファイルを共有する、もしくは分散する仕掛けを用意したり、トラッフィクに注意したり、メンテナンスと運用にかかる時間と人のリソースは、想像に難しくありません。

上記のような心配が必要なサービスを運用している会社さんの場合は、当然既にakamaiなどのCDNを利用していると思いますが、それでもファイル転送元のリアルサーバーは持っている必要があります。
CloudFrontの場合は、配信元サーバーがS3なので、そこのリソースも気にしなくて済みます。

社内でかかるメンテナンスコスト(ベンダー保守、社内保守・監視、対応)、電気代、帯域代、ラック代、サーバー代など様々なコストを考えると、すべて込み込みで1GB/30円っていうのはかなり魅力的ではないでしょうか。

EC2用にCentOS5.2のAMIを作ってみた

2008-12-01 01:33 | IT, エントリー | 3 コメント »

CloudFrontで生まれ変わるか

EC2は日本からだと相変わらず帯域がもっさりしているんですが、Amazon CloudFrontがリリースされて、利用方法を工夫すれば、まともに使えるのでは?と俄然注目です。
CloudFrontはS3上に配置したファイルを展開するCDNで、しかもキャッシュサーバーが日本国内にもあるので、静的なコンテンツはCloudFrontで配信、動的なコンテンツはEC2で配信と分散すれば体感はだいぶ速くなるんじゃないでしょうか。

Amazon Machine Image(AIM)を作る

その実験に先立って、いざという時に安心して使えるEC2用のイメージを持っておこうと思い、使い慣れているCentOSのオリジナルイメージを作ってみました。
作成したイメージファイルを圧縮・分割してS3上に置いた上で、EC2にAIMとして登録を行うと、いつでもそのイメージファイルからインスタンス(サーバー)が起動できるようになります。
当然S3に保管しておくのに料金がかかりますが、月$0.15/GBなので、圧縮したイメージファイルが一つ500Mくらいですから、毎月$0.05(5円)程度ととても経済的です。
(実際、毎月のクレジットの明細にきっちり$0.05が請求されています。請求の手間の方がかかるような気が)

【参考】
RightScale
がCentOSのイメージを公開しているので、それでも問題ない場合はそれを利用した方が楽です。
ami-1363877a    rightscale_images/CentOS5_2V4_0_2_Beta.manifest.xml

大まかな流れは

  1. 空のimgファイルにyumを使ってOSをインストールし、AMI用に各種設定を行う
  2. S3にアップロードする前にimgファイルを分割してマニフェスト(xmlの設定ファイル)を作る
  3. 分割したimgファイルとマニフェストをS3にアップロードする
  4. アップロードしたimgを自分のAMIとしてEC2に登録する

参考にしたサイト

とてもよくまとまっています。
ここを参考に作業を進めていけば、かなりスムーズにいきます。
なので、ここでは環境の問題などで詰まった部分や補足を説明します。

AMI tools は ruby が必要

EC2用のコマンドツール群はEC2のインスタンスを立ち上げたり、情報を取得したり、操作をしたりするec2-api-toolsと今回利用するAMIを作成したり、アップロードしたりするec2-ami-toolsがあります。
後者はrubyが必須で、前者はJava VMが必須です。

yum で 作ったイメージに CentOS 5 をインストールする

ここでyumのgroupinstallオプションでインストールをするわけですが、最初CentOS4.6上で作業した時にはここで躓きました。yumのバージョンが全然違うので、当たり前っていえば当たり前です。
CentOS5のイメージを作成する際に利用する作業マシンのOSはyum > 3 のものを利用しましょう。
(CentOS4系にyum3系インストールするのは依存関係が半端無く、萎えますのであきらめましょう。)

アップロード

ec2-upload-bundleコマンドでアップロードします。
今回はWindows Vista上のVMWareのゲストOS(CentOS5)で作成、そのままアップロードを行いました。
が、VMWare上ではゲストOSの時刻が狂うという問題がありまして、アップロード中にサーバー(S3)の時刻とクライアントの時刻が狂っているとエラーが発生し、正常にアップロードできません。
最終的には、S3Foxを使って手作業でアップロードして、該当するbucketのACLを修正して対応しました。
ACLの設定は「za-team」ユーザーにRead権限を与えます。

以降はスムーズに行くと思います。

インスタンスを立ち上げた後

無事立ち上がった後、このイメージをベースにするため、自分で利用しやすいように環境を整えます。
いきなりhttpdやpostfixなどミドルウェアを入れにいってもいいのですが、どんなサーバーに利用しても必要となる最低限の環境を整えることが今回の目的なので、
ユーザーの作成や、sysstatのインストール、yumレポジトリの追加を行いました。

ベース環境の設定が終わったら、今度はこのインスタンスをイメージ化するため、インスタンス上にprivatekeyファイルとcertificateファイルをコピーして、
ruby、ec2-ami-toolsのインストールからS3へのアップロード、EC2への登録まで、全く同じ手順で行います。
作業の途中、「ec2-bundle-vol」コマンドがエラーで止まってしまうはずなので、

こちらを参考に、EC2カーネル用モジュールをコピーして、依存を修正します。

これでようやく汎用的なマイイメージが出来上がりです。

今後はこれにhttpdを入れればWebサーバに、PerlやPHPを入れてAPサーバーに、MySQLやPostgreSQLを入れてDBサーバーにと、ベースのインスタンスを拡張していろいろな用途のサーバーを自由に、いつでも用意できるようになります。

次回はこのインスタンスを使って、Webサーバーを立てて、CloudFrontの実用性を検証してみたいと思います。