Aerospike(1) EC2でクラスタを立てる #Aerospike

チーム内でDynamoDBをやめてAerospikeを使おうかどうしようかということで、調査依頼を受けたのでログをメモしておく。
1. サーバ構築
2. ベンチマーク
3. データ型
4. UDF

さらっと立ててみた作業ログをメモしておく。
公式に丁寧に書いてあるので、最新情報であるそっちを見たほうがいいです。

とりあえず公式に書いてあったイチオシインスタンスの r3.2xlarge を 3台構成でお試し

サーバ構築

ami があります。つまり楽勝
https://aws.amazon.com/marketplace/pp/B00LW9382A/
公式ドキュメント的にはインスタンスは r3.2xlarge がオススメらしい
ネットワークは適当にいじる
port 3000 ~ 3004 と 8001 は開けておく

各サーバのコンフィグを修正

Aerospikeの設定ファイルは /etc/aerospike/aerospike.confにあります

ネットワーク設定ドキュメントを見ると、同じ設定でノードを立てると、勝手にクラスタに参加するよ的な書いてあるが、AWSはGCP等、マルチキャスト通信に対応していない環境では、設定ファイルをmeshネットワーク設定に修正し、再起動する必要があるらしいです。よくある話。

と、思っていたのですが、設定の変更自体は、公式を良く読んだら再起動しなくても設定によってはコマンド的なので変更できるみたいですね。
http://www.aerospike.jp/docs/reference/configuration/

設定例
```
network {
heartbeat {
mode mesh # ユニキャスト用の同期
port 3002 # Heartbeat port for this node.

        mesh-seed-address-port xxx.xxx.xxx.xxx 3002 # 自分
        mesh-seed-address-port xxx.xxx.xxx.xxx  3002 # 友達A
        mesh-seed-address-port xxx.xxx.xxx.xxx  3002 # 友達B

        interval 250
        timeout 10
    }

}
```

ネームスペース設定いわゆるスキーマ的なやつ。設定ファイルに追加する必要がある。

namespace benchmarks {
        replication-factor 2
        memory-size 8G
        default-ttl 90d

        storage-engine memory
}

他にも設定があるので、きちんと全項目をきちんと精査して設定値検討すること。
設定を適当にしてしまうと思わぬ重大な障害を発生させ、やらかしマン扱いされるのでかならず見てほしい。(遠い目)

起動

サービス起動 ssh で各サーバに入って起動する

# 起動
$ sudo service aerospike start
Starting and checking aerospike:                           [  OK  ]

# 確認
$ sudo service aerospike status
asd (pid 1138) is running...

AMC(Aerospike Management Console)起動ついでにモニタリングのサービスも起動

# 起動
$ sudo service amc start
Starting httpd:                                            [  OK  ]
AMC is started.

# 確認
$ sudo service amc status
AMC is running.

port 8081 で AMC につながります
http://xxx.xxx.xxx.xxx:8081/#dashboard

初期状態だと認証が必要なので、ユーザはamc、パスワードはEC2のインスタンスIDを入れます

全サーバでコンフィグ設定 ~ aerospike起動を行う。（AMCは一台だけ起動でおｋぽい）

AMIがあるので一瞬で終わりました。

続く