Why?
AWS Elastic Beanstalkで環境構築自動化という事をやったりしたわけなので、
複数サーバ間でセッションを共有したいのであります。
通常サーバ上で動作させるredisやmemcachedはお互いのIPを知っていればサーバ間でデータが共有できるんですが、
オートスケールで追加されたEC2インスタンスのIPを調べて、
それぞれのサーバに通知して、
クラスタを追加
みたいな動きをつくるのも、クラスタ接続時に問題起きない？とか考えるのもマジ面倒。
もういい、使おうElastiCache！
Cache Cluster Create
Get Startd Now!!
それぞれ入力していきましょう。
memcachedよりリッチなredisを使います。
そのリッチさの代償ゆえか同じインスタンスタイプでもredisの方が使えるメモリ量が少ない
とかどこかで読んだけど未検証。
ノードタイプは以下にしてみました。スペックを考慮するとたぶんお得なお値段。
参考：料金表
- ハイメモリ エクストララージ キャッシュノード（cache.m2.xlarge）
16.7GB メモリ
6.5 ECU（3.25 ECU × 2 仮想コア）
64ビットプラットフォーム
高速 I/O 性能
SNSはEBで生成されたのがあったので設定しておいた。
主に障害やメンテナンスの通知が飛んでくるとのこと。
S3 Snapshot Locationという項目を見て、
「もしや自動でスナップショットをS3上にアップしてバックアップ&永続化をサポートしてる！？」
と思ったら、起動時に初期データの取り込みを行うための用途でした・・・
とはいえ、インスタンス側から指定S3バケットにスナップショットとっておいてここに設定しておけばスケール時やメンテ時にウォームスタートできるやないかーい。
起動後に設定してみようと思いつつそっとNEXTを押す。
セキュリティグループなぞなぞを設定していくと、
Maintenance Window？なんぞや？他記事では No Preferenceであっさりスルーしていくんですけどちゃんと調べた。
Q: メンテナンスウィンドウとは何ですか?ソフトウェアメンテナンス時に Cache Nodes を利用できますか?
Amazon ElastiCache のメンテナンスウィンドウは、要求または必要とされるイベントで、ソフトウェアのパッチ適用が発生した際に、それをコントロールする機会として考えることができます。「メンテナンス」イベントが特定の週に予定されている場合、お客様が特定した60分のメンテナンスウィンドウ中の一定の時点で、開始されて完了します。
ソフトウェアのパッチ適用が予定されている場合、メンテナンスウィンドウの間にキャッシュノードに多少のダウンタイムが発生する可能性があります。詳細については、「キャッシュエンジンバージョン管理」をご覧ください。パッチ適用は、ユーザーからリクエストすることができます。例えば、キャッシュソフトウェアのアップグレード、または必要に応じてそう判断した場合（システムまたはキャッシングソフトウェアにセキュリティ上の脆弱性を当社が識別した場合）。このようなパッチ適用は頻繁に発生するものではありません（通常数ヵ月に一度です）。また、お客様のメンテナンスウィンドウのごく一部以外を使用する必要があることは稀なはずです。キャッシュクラスタの作成時点で、希望する週間メンテナンスウィンドウが指定されていない場合は、60分のデフォルト値が割り当てられます。メンテナンスが実行される時期を変更したい場合は、AWS Management Console で DB インスタンスを変更するか、または ModifyCacheCluster API を使用して、変更を行うことができます。各キャッシュクラスタに、個々に異なるメンテナンスウィンドウを選択することができます。
ふーん、こういう時ウインドウって言葉使うんだ?おそらく窓口という意味合いなんだね。
運用するサービスにメンテナンス期間が定められているならそのスケジュールを設定しておくと良さそう。
ひとまず水曜日の00:00に設定してみた。
次！む？Enable Automatic Backup・・・だと・・・？
バックアップと聞くととりあえず設定したくなる衝動を押さえつつ、
僕：「でも、、お高いんでしょう？バックアップのサイズ分メモリとか消費しちゃったりするんでしょう？」
Amazon：「Amazon ElastiCache は、アクティブな Redis 用 ElastiCache クラスターごとに、1 つのスナップショットのストレージ領域を無料で提供しています。追加のストレージは、スナップショットで使用される容量に基づいて、毎月 0.085 USD/GB（すべてのリージョンで同じ価格）で課金されます。また、スナップショットを使用したデータ転送は無料です。」
僕：ポチり(即)
ただし、
スナップショットの作成はパフォーマンスにどのような影響がありますか?
スナップショットの作成中に、短い時間ですが、ノードでレイテンシーが増える場合があります。スナップショットは Redis の組み込み BGSAVE を使用し、その強度と制限による影響を受けます。具体的には、Redis プロセスは分岐し、親は継続してリクエストに対応しますが、子はデータをディスクに保存すると終了します。この分岐により、スナップショット生成中はメモリの使用量が増えます。このメモリ使用がキャッシュノードの使用可能なメモリ容量を超えるとスワップがトリガーされ、ノードがさらに低速になる場合があります。このため、スナップショットを（マスターではなく）リードレプリカのいずれかで生成することをお勧めします。また、予約メモリパラメータを設定してスワップの使用量を最小化することをお勧めします。詳細については、こちら をご覧ください。
なので念のため注意してください。
保持期間は
保持期間は、自動スナップショットが保持される期間です。例えば、保持期間が 5 に設定された場合、本日作成されたスナップショットは削除されるまでに 5 日間保持されます。1 つ以上の自動スナップショットをコピーし、手動で保存するように選択すると、保持期間が過ぎても削除されません。
です。保存データのプライオリティと相談してください。
以上で構築完了、リザーブドインスタンス買うとやっぱり安いね！
Cache Clusters => Nodesタブ と進むと起動されたクラスタノードが表示されるので
エンドポイントを確認しておく。
EC2から使ってみよう
ノードに定期用したセキュリティグループに穴を開けておきましょう。
デフォルト：6379を自分のEC2にだけ許可してログイン。
デフォルトのyumリポジトリにはないっぽくepelから
# yum install -y redis --enablerepo=epel
redis-cliというコマンドラインツールがインストールされているので、
$ redis-cli -h [ElastiCache Endpoint]
redis Endpoint:6379> _
として接続できればOK。
# ステータス確認
> info
redis_version:2.8.6
redis_git_sha1:00000000
redis_git_dirty:0
redis_build_id:37f1586c49770bbe
redis_mode:standalone
os:Amazon ElastiCache
arch_bits:64
multiplexing_api:epoll
gcc_version:0.0.0
process_id:1
run_id:8bcc1b7d554db514ebddf51fc46cdc2052ef380e
tcp_port:6379
uptime_in_seconds:7223
uptime_in_days:0
hz:10
lru_clock:1429074
config_file:/etc/redis.conf
...いろいろ出る
# 1秒毎にタイムスタンプをsetしてヘルスチェック的な動き
> monitor
# Get Set
> set hoge fuga
OK
> get hoge
"fuga"
All right。
各言語のクライアント一覧
これなら言語間でのデータのやりとりもラクラクダ。