最近は立て続けに Amazon Web Services が新しいサービスを発表していますので、ちょっと触ってみることにします。
アカウントの登録
アカウントの登録などはよくあるパターンなので何となく進めていけば分かりました。 S3 (データを乗せるためのもの) と EC2 (処理系を乗せるためのもの、仮想環境) はアクティベーションが別のようで、 S3 を使える状態にしても EC2 は使えないようです。 EC2 を使えるようになると VPC、SNS、MapReduce なども使えるようになりました。 この辺は事前にドキュメントに目を通した方が良いかもしれませんが、読むべきドキュメントの量が多すぎますので、 実際に何かを進めながらその都度調べる方が効率的なように思います。 なお、EC2 のアクティベーションでは (自動応答の) 英語で電話がかかってきますので、ドキドキするかもしれませんね。
インスタンスを起動する
console.aws.amazon.com が Web インターフェイスのコンソールになっており、 ボタンをポチポチと押していくと簡単に Linux サーバを起動できます。
ここでは AMI (Amazon Machine Image) の 64bit を使うことにします。 Windows Server 2008 も使えるようですが、そこは Azure を使えば良いような気がしますのでスキップします。 あと、セキュリティグループの設定で22番ポート (SSH) に加えて80番ポートも開放しておきます。
秘密鍵をローカルディスクに保存し、EC2 インスタンスの Public DNS を確認したら ssh でログインしてみます。 ここでは、秘密鍵は ~/.ssh/ec2dev.pem として保存しておきます。
ssh -i ~/.ssh/ec2dev.pem ec2-user@{YOUR-INSTANCE-PUBLIC-DNS}
AWS コンソールの [Instance Actions] -> [Connect] で表示される Connect Help では root でログインするように書いてありますが、 実際にやってみると弾かれます。セキュリティポリシーを変更したのかもしれませんね。
"Please login as the ec2-user user rather than root user."
ログインできることを確認したら CPU の情報を見ておきます。
$ cat /proc/cpuinfo |head -5 processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 23 model name : Intel(R) Xeon(R) CPU E5430 @ 2.66GHz
数年ほど前に自宅サーバを作ったりしていた頃とは隔世の感があります。 これが時間貸しとは素晴らしいですね。当然ながらファンの音もありませんので快適です。
ソフトウェアの情報も確認しておきましょう。
$ gcc -v; java -version; ruby -v; python -V; ant -version; easy_install --version -bash: gcc: command not found java version "1.6.0_20" OpenJDK Runtime Environment (IcedTea6 1.9.1) (amazon-44.1.9.1.16.amzn1-x86_64) OpenJDK 64-Bit Server VM (build 19.0-b06, mixed mode) ruby 1.8.7 (2010-08-16 patchlevel 302) [x86_64-linux] Python 2.6.6 -bash: ant: command not found distribute 0.6.10
gcc と ant は入っていません。 Java は SunJava ではなく OpenJDK のようですね。 ということを確認したら一旦ログアウトします。
接続する度に ssh の引数を覚えておくのは大変なので ~/.ssh/config にメモしておきます。
HOST ec2dev
User ec2-user
HostName {YOUR-INSTANCE-PUBLIC-DNS}
IdentityFile /Users/shigeru/.ssh/ec2dev.pem
これで ssh ec2dev で接続できます。
ミドルウェアをインストールしてみる
よくある流れですが、Web サーバとして Apache をインストールしておきます。
$ sudo yum -y httpd $ sudo service httpd start
これで Web ブラウザから Public DNS のアドレスにアクセスすると Apache のテストページが表示されます。
Apache のリバースプロキシを使うと、バックエンドでいくつかのアプリケーションサーバを動かすことが簡単になりますので、 その辺にも目を通しておきます。
$ grep proxy /etc/httpd/conf/httpd.conf LoadModule proxy_module modules/mod_proxy.so LoadModule proxy_balancer_module modules/mod_proxy_balancer.so LoadModule proxy_ftp_module modules/mod_proxy_ftp.so LoadModule proxy_http_module modules/mod_proxy_http.so LoadModule proxy_ajp_module modules/mod_proxy_ajp.so LoadModule proxy_connect_module modules/mod_proxy_connect.so # enable the proxy server: #<IfModule mod_proxy.c> # CacheRoot "/var/cache/mod_proxy" # End of proxy directives.
mod_proxy の公式ドキュメントに詳しい説明がありますので、 とりあえずテスト用に簡単な設定を行います。 次のようにするとカレントディレクトリのファイルを HTTP 経由 (/app パス) で配信できます。
$ cat <<'EOF' |sudo tee /etc/httpd/conf.d/proxy.conf
ProxyPass /app http://{YOUR-INSTANCE-PUBLIC-DNS}:8080
EOF
$ sudo service httpd restart
$ python -m SimpleHTTPServer 8080
ホームディレクトリのドットファイルを配信しても面白みがない、というよりはセキュリティ面でも危ないので、 Ctrl+C で Python モジュールを停止させます。
もう少し実用的な例として、検索サーバとして有名な Apache Solr を使えるようにしてみます。
$ cat <<'EOF' |sudo tee -a /etc/httpd/conf.d/proxy.conf
ProxyPass /solr http://{YOUR-INSTANCE-PUBLIC-DNS}:8983/solr
EOF
$ sudo service httpd restart
$ mkdir src && cd src
$ wget http://ftp.riken.jp/net/apache/lucene/solr/1.4.1/apache-solr-1.4.1.tgz
$ tar xzf apache-solr-1.4.1.tgz ; cd apache-solr-1.4.1
$ cd example && java -jar start.jar
これで Web ブラウザから /solr/admin パスを指定すると Solr の管理画面にアクセスできます。 実際にドキュメントを検索できる状態にするためにはインデクスにデータを追加する必要がありますが、やめておきます。 前段に Apache を使うと、管理画面に BASIC 認証をかけるなど、エンドポイントごとにアクセスを制限できます。 インデクスの追加は特定のノードからのみ許可し、検索クエリはどこからでも自由に発行できるようにするなど、 Apache のお作法に則ることができそうです。
インスタンスを停止する
インスタンスを停止するためには "Terminate" と "Stop" があります。 EBS volume が残るか残らないか？という違いがあります。 EC2 は使った分だけ課金されますので、テスト用にちょっと使っただけでもう使わない、というインスタンスは "Terminate" が良いようです。一時的に停止させる場合は "Stop" にします。 "Stop" してから再度起動させると、マシン名は一緒であるものの IP アドレスなどは変わるようです。
- FAQ 149 - What's the difference between Terminating and Stopping an EC2 Instance? (RightScale Cloud Management Support Portal)
時間を区切って作業するような場合は at コマンドと相性が良さそうです。
Web コンソールを使わず、Amazon EC2 API tools を使う方法もあるようです。API Tools は Windows 端末かも使えますので便利そうです。 zip パッケージを展開し、環境変数 EC2_HOME を設定することで使えるようになります。 必要に応じて PATH も通すと便利になるはずです。
終わりに
AWS の開発者登録を行い、EC2 で Apache 越しに Solr を動かしてみました。
EC2 に Solr を乗せた、という話では、 guardian.co.uk の What's powering the Content API? - The Guardian speaks at Lucene Eurocon 2010 が大きな事例だと思いますが、 比較的簡単にデプロイできそうな感じですので、分散処理、並列処理とは相性が良さそうです。 また、そもそも Elastic MapReduce がありますので、Hadoop 関連のバージョン差異に悩むことも少ないのかもしれません。
最近発表された Beanstalk (Introducing AWS Elastic Beanstalk, 日本語) によって、 JVM で動作するアプリケーションのデプロイがより一層簡略化されましたので、 データ置き場に関する従来からの懸念はあるものの、クラウド環境へ移行するアプリケーションも増えることでしょう。
また、ソフトウェアのコンパイルやオープンソースのビルド環境では個人ユースでも十分に使えるそうです。
AWS によって物理的なマシンの管理を気にすることが減少していきますので、 "run or deploy" ではなく "develop" に注力できるようになります。 近日中にすべてが変わるわけではありませんが、徐々にメンタルモデルを変えないといけないな、と実感しました。 Designing for Cloud-Optimized Architecture などにも注意が必要そうです。
0 件のコメント:
コメントを投稿