「Redisクラスタ 1」で、これから環境構築する上で出てくる用語について説明し、
「Redisクラスタ 2」で、実際に環境構築し、
「Redisクラスタ 3」で、データがシャーディングされる様子を確認し、
「Redisクラスタ 4」で、マスターノード障害時にレプリカノードがマスターノードに昇格する様子を確認しました。

AWS・Azure・GCPはそれぞれに Redisをキャッシュとして使うサービスを提供しております。

このホームページのように、自宅環境で細々とお勉強した事はパブリッククラウドサービスを使う時に役に立つのか？

試しに AWSの「Amazon ElastiCache for Redis」について、触ったこともないのにドキュメントだけでレビューをしてみたいと思います。

対象のドキュメントは「Amazon ElastiCache for Redis ユーザーガイド」になります。


１．2つのモード

ElastiCache for Redis のドキュメントを読むと、至る所で「(クラスターモードが無効)」「(クラスターモードが有効)」という表現が出てきて混乱します。

ドキュメントでは以下の箇所にこの 2つの違いの表があります。
ElastiCache for Redis レプリケーション

図にするとこんな感じになるようです。

「(クラスターモードが無効)」の方はレプリカノードの有無でこの 2パターン。

「(クラスターモードが有効)」の方もレプリカノードの有無でこの 2パターン。


マスターノードが 1つか 2つ以上かによって、何でこんな風にモードが 2つに別れているのか。

今回の実験で Redisクラスタを作る際、[/etc/redis/redis.conf]ファイルを以下のように変更しました。

#cluster-enabled yes
↓
cluster-enabled yes　　← コメントアウト[#]を外して有効化します。

また Pythonスクリプトでは、Redisサーバーにセッションを張るのに、クラスターじゃない場合には [Redis]クラスを、クラスターの場合は [RedisCluster]クラスを使いました。

Redisの歴史を紐解いてみると、クラスターが使えるようになったのは Ver.3からです。

状況からは、Redisは取って着けたような感じでクラスター機能を後から追加したということが推測できます。

多分、クライアント⇔サーバー のアプリケーションプロトコルの時点で結構違っちゃっているんでしょうね。


もう一つの側面として、AWSは ElastiCache for Redisのユーザーをどういう人達と想定しているかというと、過去に他で Redisを使っていて AWSにやってきた人達、としていると感じます。

当サービスの売りが「皆さんが作った Redisを使うクライアントアプリを一切変更しないで良いです」って言っています。

これらを総合して鑑みると、AWS独自のサービスにしたいけど Redisの仕組みを無視するわけにもいかないってジレンマがあるように見えます。

少なくとも、ここでやったようなお勉強で素の Redisに触れていると、この 2つのモードに別れてるってのは Redisの仕組み由来なんだなって分かります。


２．1ノード＝1シャード

ドキュメントにこの説明が丹念にしてあって「重要な事柄なのか？意図は何？」と思ってしまうのですが、多分そんなに重要ではない気がします。

ここで行った実験では、Ubuntu Server 1つに Redisを 1つ立ち上げていましたので、期せずして「1ノード＝1シャード」のクラスタになっていました。

しかし参考にしている Redisのドキュメントのチュートリアルでは、1つのサーバーでポートを変えながら 6つの Redisを立ち上げてました。

実際の現場でそういう構成をしている例があるのか分かりませんが、そういう構成もできますし、Dockerなどのコンテナを使えば 1つのサーバーに複数の Redisが立っている構成を作ることは可能です。

ElastiCache for Redisでは、Redisを稼働させる実体は EC2のような仮想マシンであり、ユーザーは要件次第でどのサイズの仮想マシンを使うかを選択できます。

パフォーマンスの計りやすさや構成のシンプルさ等の複数の理由があって「1ノード＝1シャード」という形態に固定しているんでしょう。

ただそれだけの事なんでしょうが、Redisのチュートリアルでああいうことをやってたって知らなかったら、深読みし過ぎてしまったかも知れません。


３．ノードは最大で 500個

一つのクラスター内に収められるノードは、マスター・レプリカ合わせて 500も行けるそうです。

マスターノードだけなら 500シャード、(1マスター + 5レプリカ)だと 83シャード、そんな計算になるとのこと。

1秒にン億回の処理を実現する程だそうです。
オンプレのサーバールーム利用者からは想像ができませんね。
パブリッククラウドならではの規模です。

一つのサービスのために EC2を 500個借りるって考えると、いくらするのか恐ろしいですが…。


＝＝＝＝＝＝＝＝＝＝
何かとりとめなくなっちゃったんですが、先に Redisをイジってから AWSのドキュメントに進んでみると、そんなに混乱しなかった気がします。

AWSの公式ドキュメント全般に通じる文化なのか ElastiCache for Redisだけなのか分かりませんが、ElastiCache for Redisのドキュメントに限って言うと、Redisを知ってるのが前提になっていると感じました。
結構敷居が高い。

この感じからすると、AWSで初めて Redis環境を用意する事にことになったクラウドエンジニアは、結局どこかの時点でここでやったような検証をしないと ElastiCache for Redisの理解が覚束ないってことになる気がします。


OSSベースのサービスの場合、素のものを触ってからクラウドでどう変わっているのかの差分をお勉強する方が最終的には早いと思います。

ただ、「急ぎなんで〜」等、その時々の事情がありますからそうも行かないんでしょうけどね。


というわけで、Redisクラスタの巻はこれで終わりでございます。