Amazon EC2でCassandra 0.7.4をインストールし、実行する
Cassandraを複数のノードで試そうと思ったが、VPSサービスをいくつか契約する必要があり
性能的にどれがよいのか分からなかったのでとりあえず、Amazon EC2で試してみることにしました。
ここでいろいろストレステストや癖を試してみて、さくらVPSで運用できそうだったらさくらVPSの1.5 G版
か4 G版を検討してみたいとおもいます。*1
前提
- Amazon Web Servicesにアカウントが登録済みであること
参考：「AWSの概要と登録手順〜Amazon EC2/S3環境構築のすべて〜」
- Amazon EC2を操作するコマンドラインツールが登録済みであること
参考：「Amazon EC2を操作するコマンドラインツール」*2
実行環境では、3月24日時点でダウンロードできる「ec2-api-tools-1.4.1.2」を利用しました。
Amazon EC2 API Toolsからダウンロードできます。
- private keyがコマンド作業環境に保存されていること
参考：「インスタンス起動に必要となる設定」
利用できるAMIイメージ（Amazon Machine Image）がないかどうか探してみる
「ec2-describe-images -x all」を利用すると、「公開イメージの一覧を表示」を取得することができます。
ただ、利用したいイメージがあるか分からないので、「ec2-describe-images --region ap-northeast-1 -x all | grep CentOS
」とコマンドを実行してみます。
$ec2-describe-images --region ap-northeast-1 -x all | grep CentOS IMAGE ami-96e84297 411009282317/RightImage_CentOS_5.4_x64_v5.6.28_EBS 411009282317 available public x86_64 machine aki-a409a2a5 ari-a009a2a1 ebs paravirtual xen IMAGE ami-a8eb41a9 644846711624/CentOS_5_4_i386_v5_6_8_1_EBS 644846711624 available public i386 machine aki-a209a2a3 ari-9e09a29f ebs paravirtual xen IMAGE ami-beeb41bf 644846711624/CentOS_5_4_x64_v5_6_8_1_EBS 644846711624 available public x86_64 machine aki-a409a2a5 ari-a009a2a1 ebs paravirtual xen IMAGE ami-7605ae77 aoi-ami-jp/CentOS_5.2_x64_V1.manifest.xml 367998583407 available public x86_64 machine aki-a409a2a5 ari-a009a2a1 instance-store paravirtual xen IMAGE ami-2a0ea52b 411009282317/RightImage CentOS5_2_X86_64_V4_1_10 411009282317 available public x86_64 machine aki-da09a2db instance-store paravirtual xen IMAGE ami-300ea531 411009282317/RightImage CentOS_5.2_i386_v4.2.4 411009282317 available public i386 machine aki-a209a2a3 ari-9e09a29f instance-store paravirtual xen IMAGE ami-360ea537 411009282317/RightImage CentOS_5.2_x64_v4.2.4 411009282317 available public x86_64 machine aki-a409a2a5 ari-a009a2a1 instance-store paravirtual xen IMAGE ami-3c0ea53d 411009282317/RightImage CentOS_5.4_i386_v4.4.10 411009282317 available public i386 machine aki-a209a2a3 ari-9e09a29f instance-store paravirtual xen IMAGE ami-480ea549 411009282317/RightImage CentOS_5.4_x64_v4.4.10 411009282317 available public x86_64 machine aki-a409a2a5 ari-a009a2a1 instance-store paravirtual xen IMAGE ami-ce0ea5cf 411009282317/RightImage_CentOS_5.4_i386_v5.5.9 411009282317 available public i386 machine aki-a209a2a3 ari-9e09a29f instance-store paravirtual xen IMAGE ami-aee842af 411009282317/RightImage_CentOS_5.4_i386_v5.6.28 411009282317 available public i386 machine aki-a209a2a3 ari-9e09a29f instance-store paravirtual xen IMAGE ami-760ea577 411009282317/RightImage_CentOS_5.4_x64_v5.5.9 411009282317 available public x86_64 machine aki-a409a2a5 ari-a009a2a1 instance-store paravirtual xen IMAGE ami-98e84299 411009282317/RightImage_CentOS_5.4_x64_v5.6.28 411009282317 available public x86_64 machine aki-a409a2a5 ari-a009a2a1 instance-store paravirtual xen
リージョン(--region)もオプションで指定してますが、「ec2-describe-regions」というコマンドで利用できるリージョン一覧を確認することができます。
REGION eu-west-1 ec2.eu-west-1.amazonaws.com REGION us-east-1 ec2.us-east-1.amazonaws.com REGION ap-northeast-1 ec2.ap-northeast-1.amazonaws.com REGION us-west-1 ec2.us-west-1.amazonaws.com REGION ap-southeast-1 ec2.ap-southeast-1.amazonaws.com
結果一覧の「ap-northeast-1」が日本を表しているので、今回は日本リージョンを利用することとします。*3
立ち上げる仮想マシーンのタイプも検討する必要があります。「利用可能なインスタンスタイプ」
をみるといろいろあることがわかります。
| No | インスタンス名 | CPU | Mem | Disk | arch |
|---|---|---|---|---|---|
| 1 | スモール インスタンス（デフォルト） | 1 EC2 Compute Unit | 1.7 GB | 160 GB インスタンスストレージ (150 GB ＋ 10 GB ルートパーティション) | 32bit |
| 2 | ラージ インスタンス | 4 EC2 Compute Unit(2仮想コア) | 7.5 GB | 850 GB インスタンスストレージ (2×420 GB ＋ 10 GB ルートパーティション) | 64bit |
| 3 | エクストララージ インスタンス | 8 EC2 Compute Unit(4仮想コア) | 15 GB | 1,690 GB インスタンスストレージ (4×420 GB ＋ 10 GB ルートパーティション) | 64bit |
| 4 | マイクロ インスタンス | 最大 2 EC2 Compute Unit | 613 MB | EBS ストレージのみ | 32bit or 64bit |
他にも「ハイCPU インスタンス」や「クラスターコンピュート インスタンス」、「クラスターGPU インスタンス」なども
あるみたいです。詳しくは、Amazon EC2 インスタンスタイプをご覧ください。
今回は、「instance-type」として、t1.micro（マイクロ インスタンス）を利用したいと思います。
マイクロ インスタンスは、「EBS ストレージのみ」のサポートなので、「ec2-describe-images」コマンドで参照した
AMIの内、「instance-store」ではなく、「ebs」を利用しなければいけません。*4
セキュリティグループの作成
立ち上がったインスタンスへのアクセス制限をする為に、ポートの設定をします。インスタンス立ち上げ時に何も
指定しないとdefaultというグループが設定されます。新しいグループを作成し、SSH（22番ポート）HTTP（80番ポート）
の設定をします。
ec2-add-group grp-cent-test --description cent_security_group --region ap-northeast-1 ec2-authorize grp-cent-test -p 22 --region ap-northeast-1 ec2-authorize grp-cent-test -p 80 --region ap-northeast-1
設定したセキュリティグループを確認します。
ec2-describe-group --region ap-northeast-1 GROUP sg-963a8d97 43********** grp-centos-test centos_security_group PERMISSION 43********** grp-centos-test ALLOWS tcp 22 22 FROM CIDR 0.0.0.0/0 ingress PERMISSION 43********** grp-centos-test ALLOWS tcp 80 80 FROM CIDR 0.0.0.0/0 ingress
インスタンスの起動
今まで設定した内容を元にインスタンスを実行します。
| No | インスタンス名 | リージョン | インスタンスタイプ | セキュリティグループ |
|---|---|---|---|---|
| 1 | CentOS_5_4_x64_v5_6_8_1_EBS | ap-northeast-1 | t1.micro | grp-centos-test |
ec2-run-instances ami-beeb41bf --region ap-northeast-1 --instance-type t1.micro --group grp-fedora-test --monitor -k fedora_test_jp
インスタンスの実行後、若干、立ち上がりに時間がかかりますが、数分後、以下のコマンドで実行されていることを確認します。
ec2-describe-instances --region ap-northeast-1
ステータスが「running」となっていれば、インスタンス構築の完了です。
インスタンスにログインしてみる
ec2-describe-instancesで確認した時に表示されていたドメインネームを利用して、ssh経由でインスタンスにログインします。
ssh -i fedora_test_jp.id root@ec2-1**-4*-2**-43.ap-northeast-1.compute.amazonaws.com
CentOS上に、Cassandraを構築する。
念のため、OSのバージョンを確認します。
cat /etc/redhat-release CentOS release 5.4 (Final)
Javaをインストールし、Cassandraをインストールして、立ち上げます。
一瞬、はまった箇所といえば、conf/cassandra.yamlのlisten_address:にグローバルIPを設定したら下記のような
エラーログが出力されました。
ERROR [main] 2011-03-23 04:31:36,356 AbstractCassandraDaemon.java (line 196) Fatal configuration error
org.apache.cassandra.config.ConfigurationException: Unable to bind to address /1**.4**.2**.4**:7000. Set listen_address in cassandra.yaml to an interface you can bind to, e.g., your private IP address on EC2
at org.apache.cassandra.net.MessagingService.listen(MessagingService.java:176)
at org.apache.cassandra.service.StorageService.joinTokenRing(StorageService.java:424)
at org.apache.cassandra.service.StorageService.initServer(StorageService.java:404)
at org.apache.cassandra.service.AbstractCassandraDaemon.setup(AbstractCassandraDaemon.java:192)
at org.apache.cassandra.service.AbstractCassandraDaemon.activate(AbstractCassandraDaemon.java:314)
at org.apache.cassandra.thrift.CassandraDaemon.main(CassandraDaemon.java:79)
どこで、確認しているか分かりませんが、「on EC2」と実行環境を判別することができるようです。
stressテスト用のJavaを実行してみる
apache-cassandra-0.7.4-src内に「contrib/stress/bin/stress」というスクリプトがあります。
このスクリプトを利用して、さくらVPSとstressの結果を比較してみたいと思います。
EC2上で実施すると下記のようなエラーがでました。
contrib/stress/bin/stress: line 49: 6196 強制終了 $JAVA -server -cp $CLASSPATH org.apache.cassandra.contrib.stress.Stress $@
OOM killerっぽい挙動かな？と思いメモリを確認してみるとSwapが0なのでした。
free -m
total used free shared buffers cached
Mem: 622 81 540 0 0 8
-/+ buffers/cache: 72 549
Swap: 0 0 0
このまま実行できないのもアレなので、memory overcommitを少しいじってみました。
$cat /proc/sys/vm/overcommit_memory 0 $vi /etc/sysctl.conf vm.overcommit_memory = 1 vm.overcommit_ratio = 99 $/sbin/sysctl -p $cat /proc/sys/vm/overcommit_memory 1
再度、実行してみると、若干うごきました。
# contrib/stress/bin/stress -d 10.146.89.114 Keyspace already exists. total,interval_op_rate,interval_key_rate,avg_latency,elapsed_time 20319,2031,2031,0.002240710664894926,45 56004,3568,3568,0.002166932884965672,96 contrib/stress/bin/stress: line 49: 6196 強制終了 $JAVA -server -cp $CLASSPATH org.apache.cassandra.contrib.stress.Stress $@
結局、実行することができなかったので、次は、「Small Instance」あたりで試してみようと思います。
