ElastiCacheのオートディスカバリを目で見てみる

はじめに

本日発表された新機能で、ElastiCacheのmemcacheエンジンで複数AZに分散したクラスタグループを作成することが出来るようになりました(【ElastiCache】memcachedのMulti-AZ構成が来ました！！！ ｜ Developers.IO)

今までのようにそれぞれのAZに別々のキャッシュクラスタを作る事無く、一つのキャッシュクラスタでAZを分散してキャッシュノードを配置することに出来ます。AZ分散したオートディスカバリが使えるということですね。

そこで改めてオートディスカバリについて調べてみました。

オートディスカバリ

オートディスカバリとは、複数のキャッシュノードのそれぞれのエンドポイントを意識せず使うための機能です。具体的には、ElastiCacheクラスタには、クラスタを示すユニークなコンフィグレーションエンドポイントを持っています。

このコンフィグレーションエンドポイントは、常に少なくとも1つのキャッシュノードを指しています。例えばコンフィグレーションエンドポイントが「smokeycache.16bbhn.cfg.apne1.cache.amazonaws.com」で、ノード数が2つの場合、各エンドポイントをdigしてみると

$ dig smokeycache.16bbhn.cfg.apne1.cache.amazonaws.com

;; ANSWER SECTION:
smokeycache.16bbhn.cfg.apne1.cache.amazonaws.com. 60 IN	A 172.31.11.218

$ dig smokeycache.16bbhn.0001.apne1.cache.amazonaws.com

;; ANSWER SECTION:
smokeycache.16bbhn.0001.apne1.cache.amazonaws.com. 60 IN A 172.31.22.213

$ dig smokeycache.16bbhn.0002.apne1.cache.amazonaws.com

;; ANSWER SECTION:
smokeycache.16bbhn.0002.apne1.cache.amazonaws.com. 60 IN A 172.31.11.218

のように返ってきましたので、この時点でのコンフィグレーションエンドポイントは、0002のキャッシュノードを指していることになります。もし0002のキャッシュノードが削除された場合にはまた別のキャッシュノードのIPアドレスを指します。つまり「コンフィグレーションエンドポイントに繋げば、必ずキャッシュクラスタに所属しているどれかのキャッシュノードに接続出来る」わけですね。

そして、コンフィグレーションエンドポイントに接続してconfig get clusterコマンドを実行することで、そのキャッシュクラスタに所属しているノードの一覧を取得することが出来ます。

$ telnet smokeycache.16bbhn.cfg.apne1.cache.amazonaws.com 11211
Trying 172.31.11.218...
Connected to smokeycache.16bbhn.cfg.apne1.cache.amazonaws.com.
Escape character is '^]'.
config get cluster
CONFIG cluster 0 142
1
smokeycache.16bbhn.0001.apne1.cache.amazonaws.com|172.31.22.213|11211 
smokeycache.16bbhn.0002.apne1.cache.amazonaws.com|172.31.11.218|11211

END

現時点では以下のように2台のキャッシュノードがあります。[Add Node]からキャッシュノードを1台追加してみます。

キャッシュノードが3台になりました。

すると、config get clusterコマンドの結果として、3台のノードクラスタの情報が返ってきます。

config get cluster
CONFIG cluster 0 211
2
smokeycache.16bbhn.0001.apne1.cache.amazonaws.com|172.31.22.213|11211 
smokeycache.16bbhn.0002.apne1.cache.amazonaws.com|172.31.11.218|11211 
smokeycache.16bbhn.0003.apne1.cache.amazonaws.com|172.31.3.104|11211

END

次に、[Delete Node]ボタンからキャッシュノードを1台削除してみます。

以下のようにStatusが"deletting"になります。しばらく待つと完全に削除されます。

この状態でconfig get clusterコマンドを実行すると、0002のキャッシュノードが削除され、0001と0003がクラスタに所属しているという情報が返ってきます。

config get cluster
CONFIG cluster 0 141
3
smokeycache.16bbhn.0001.apne1.cache.amazonaws.com|172.31.22.213|11211 
smokeycache.16bbhn.0003.apne1.cache.amazonaws.com|172.31.3.104|11211

END

以上から、アプリケーションとしては、コンフィグレーションエンドポイントに接続してconfig get clusterコマンドを実行すれば、そのタイミングでキャッシュクラスタに所属しているノードの情報が取得出来ます。このためアプリケーションではキャッシュノードの増減を意識すること無く使うことが出来ます。これがオートディスカバリの機能です。

そして今回の新機能によって、AZを分散した形でオートディスカバリが使えるようになりました。これはアプリケーションの可用性を高める上で大きな機能拡張では無いでしょうか。

ElastiCache Cluster Client

このオートディスカバリを活用するために、AWSではElastiCache Cluster Clientというライブラリが用意されています。

• Amazon ElastiCache Cluster Client for Java - enhanced library to connect to ElastiCache clusters.(Java版)
• Installing the ElastiCache Cluster Client for PHP(PHP版)

これらのライブラリを使うことで、アプリケーション側で複雑な分散処理を書くことなく、手軽にオートディスカバリのメリットが享受出来ますので、活用をお勧めします。

なお、ElastiCache Cluster Clientが使えないなどでオートディスカバリ機能を有効活用出来ない場合には、アプリケーションとしてキャッシュノードを複数指定するような実装が必要です(参考:Connecting to Cache Nodes Manually)

前述の通りコンフィグレーションエンドポイントはキャッシュクラスタに所属するキャッシュノードに紐付けられていますので、直接get/putすることも可能です。しかし紐つけするキャッシュノードの指定は出来ないため、どのキャッシュノードに対してget/putしているのかは分かりません。このためキャッシュしたはずのデータがヒットしない、というような状況が起こりえます。

コンフィグレーションエンドポイントはあくまでキャッシュノードの一覧を取得するためにのみ使用し、アプリケーションとしてはキャッシュノードのエンドポイントに対してget/putする、というのが正しい実装です。

まとめ

自分の認識が甘いところを、手を動かして学ぶのは大事だな、と改めて思った次第です。という感想です(笑)