Redis Sentinel-高可用性：開発者からPRODまで知る必要があるすべて：完全ガイド

「Redis」という用語は実際には何を意味しますか？

リモート辞書サーバーを意味します。

Redisのさまざまな記事がたくさんありますが、開発者やdevopsエンジニアがSentinelで高可用性Redisクラスタを構築するために必要で有用な最も重要で重要なも

それでは始めましょう…

Redisは、メモリデータ構造ストア内のオープンソースであり、キャッシュ目的で使用される開発者の間で非常に人気のある選択であり、メッセージブローカーとしても使用され、主に異なるユースケースのNoSQLキー値データベースとしても使用されています。

この記事では、マスター/スレーブレプリケーション、高可用性(Redis Sentinel)、自動フェールオーバー、いくつかの本番レベルの最適化のヒント、および監視の側面とともに、Redis さらに、これらのトピックに加えて、UbuntuでRedis Sentinelを実装する際に直面した問題とエラーについても言及します。 以下は、OSバージョンとRedisバージョンの詳細を示しています。さらに、Redisのドキュメントは非常に有益であり、Redisについてさらに明確にする必要がある場合は「the go to place」であることを強調したいと思います。

Redisの基本に進みます。Redisはメモリ内のデータベースであり、単にREDISがRAM上で実行されることを意味します。 また、Redisは、文字列、ハッシュ、リスト、セット、範囲クエリを持つソートセット、ビットマップなどのいくつかのデータ構造をサポートしていることを知って さらに、文字列への追加、ハッシュ内の値のインクリメント、要素のリストへのプッシュなどのアトミックな操作もサポートしています。

さて、Redisの高可用性で物事を始めましょう。

Redis sentinelは、Redisが提供する高可用性ソリューションです。 Redisクラスターで障害が発生した場合、Sentinelは自動的に障害点を検出し、人間の介入なしにクラスターを安定モードに戻します。

Redis Sentinelの内部では本当に何が起こりますか？

Sentinelは常にRedisクラスター内のマスターインスタンスとスレーブインスタンスをチェックし、期待どおりに動作しているかどうかをチェックします。 Sentinelが特定のクラスター内のマスターノードで障害を検出すると、sentinelはフェイルオーバープロセスを開始します。 その結果、Sentinelはスレーブインスタンスを選択し、それをMASTERに昇格させます。 最終的に、残りの他のスレーブインスタンスは、新しいマスターインスタンスを使用するように自動的に再構成されます。

Sentinelは、クライアントサービス検出の設定プロバイダまたは権限のソースとして機能します。

それはどういう意味ですか？ 単純に、アプリケーションクライアントはSentinelsに接続し、Sentinelsは最新のRedisマスターアドレスを提供します。

さらに、Sentinelは堅牢な分散システムであり、複数のsentinelが与えられたマスターが利用できなくなったという事実について同意する必要があります。 その後、唯一のフェイルオーバープロセスは、新しいマスターノードの選択を開始します。 このセンチネルアグリメントは、クォーラム値に従って行われます。

クォーラムとは何ですか？

クォーラム値は、マスターが到達できないという事実について同意する必要があるセンチネルの数です。 ただし、クォーラムは障害の検出にのみ使用されます。 実際にフェイルオーバーを実行するには、歩哨のいずれかがフェイルオーバーのリーダーに選出され、続行する権限が必要です。 これは、Sentinelプロセスの過半数の投票でのみ起こります。

Redis Sentinelで手を汚しましょう。

3つのサーバーインスタンスで基本的な設定に固執します。

3つのサーバーインスタンスの基本的な設定を示す上の図を参照してください。 まず、Ubuntuインスタンスが関連するビルドの依存関係を持つ最新のものであることを確認してください。 場合によっては、jemallocも必要になることがあります。 以下に、サーバーインスタンスにRedisをインストールする手順を示します。

sudo apt-get update 
sudo apt-get install build-essential tcl
sudo apt-get install libjemalloc-dev (Optional)curl -O http://download.redis.io/redis-stable.tar.gz
tar xzvf redis-stable.tar.gz
cd redis-stable
make
make test
sudo make install

これで、redisディレクトリに両方のredisが表示されるはずです。confとセンチネル。conf設定ファイル。

Redisを実行する前に、Redisクラスターを起動して実行するために必要な基本的な構成をいくつか行いましょう。 この設定のIPアドレスは次のとおりです。

10.52.209.46 (Initial Master Node)
10.52.209.47 (Initial Slave Node)
10.52.209.49 (Initial Slave Node)

Redisサーバーのデフォルトポートは6379で、Sentinelは26379です。 したがって、あなたが使用して、これらのポートを開くことを確認してください,

sudo ufw allow 6379
sudo ufw allow 26379

Redisの設定（両方ともredis。confとセンチネル。conf）上記のサーバーでは、次のように設定する必要があります。

上記の基本的な設定では十分ですが、本番レベルではこの記事の後半で言及されているヒントを検討してください。 Redisの唯一の違い。3つのサーバーのconfファイルは、すべてのスレーブに次の設定が必要であるということです。 10.52.209.46はマスター IPアドレスです。

slaveof 10.52.209.46 6379

slaveofは、この特定のサーバーインスタンスを指定されたマスターノード(10.52.209.46)のスレーブインスタンスとして作成するようRedisクラスターに指示します。

conf、以下の設定は、以下の初期設定でクラスタ監視を開始するためにセンチネルに通知します。 その後、この設定設定は自動的にそれに応じて更新される可能性があります。

sentinel monitor mymaster 10.52.209.46 6379 2
(This tells sentinel to monitor the master node. And the last argument which is 2 is the quorum value)

さらに、センチネル。confには以下の設定値も含まれています。

sentinel down-after-milliseconds mymaster 5000
(Means server will unresponsive for 5 seconds before being classified as +down and consequently activating a +vote to elect a new master node.)sentinel failover-timeout mymaster 10000
(Specifies the failover timeout in milliseconds.)

オキィドキィ！ さて…Redisを実行してみましょう。

Redisを実行するには多くの方法があります。 このデモでは、私は次のコマンドに固執します。その後、ps-ef|grep redisコマンドを使用してRedisプロセスを確認するだけです。 各サーバーインスタンスは、RedisプロセスとSentinelプロセスの両方を実行する必要があります。 すべてが計画に行けば、次のように2つのプロセスが実行されているはずです。

次に、次のコマンドのいずれかを使用してRedisクライアントに接続し、Redisが正常に動作しているかどうかをテストします。

redis-cli ping
or
redis-cli -h IP_Address pingYou should get a output of PONG.

これで、Redisが起動して実行されました。 マスター/スレーブレプリケーションに焦点を当ててみましょう。

マスター/スレーブレプリケーション

redisをチェックすると、今すぐ。ログ（これはredisで定義した場所にあります。各インスタンスのconf)では、マスタースレーブ同期が発生したことを確認できます。

マスターノード—redis。ログ

スレーブノード-redis。ログ

レプリケーションの状態の確認

Redis CLIのinfo replicationコマンドを使用してレプリケーション情報を確認することもできます。 Role属性の下には、その特定のノードがマスターかスレーブかが示されています(黄色のボックス)。また、マスターノードには、接続されているすべてのスレーブの詳細が表示されます。 (緑のボックス)

それでは、センチネルが何であるかを調べてみましょう。ログが表示されます。 （これは、我々はセンチネルで定義された場所に位置しています。conf)

さらに、センチネルをチェックすると。confファイルを使用すると、confファイルがsentinel known-slaveおよびsentinel known-sentinel値を含む最新の設定で自動的に更新されることがわかります。

かっこいい！ 次に、すべてのノードでサンプル値を作成しましょう。

127.0.0.1:6739> set demokey "Amila"

上の図でわかるように、スレーブは読み取り専用であるため、マスターにのみデータを書き込むことができます。 Redisは残りのすべてのスレーブと非同期でレプリケートするため、同じキーを使用して任意のRedisスレーブから挿入された値を取得できます。 また、KEYS*を介して、挿入されたすべてのキーを一覧表示することができます。 上の図は、私たちが今話したことを明確に説明しています。

それでは、Redis Sentinel自動フェールオーバーの仕組みを確認しましょう。

Redis Sentinel自動フェイルオーバー

Okiee! 自動フェールオーバーのシナリオをシミュレートしましょう。 フェールオーバーシナリオをシミュレートするには、Redisサーバーを停止するか、マスターインスタンスのRedisプロセスを強制終了します。 でも、あなたは同様にRedisのプロセスをスリープ状態にすることができます。 あなたが望むどのような方法を選択することができます。

kill -9 <process id>
or
redis-cli -p 6379 DEBUG sleep 30
or
redis-cli -p 6379 DEBUG SEGFAULT

上の図に示すように、フェールオーバーのシナリオでは、マスターノードが失敗した場合、残りの2つのセンチネルがフェールオーバーを決定し、両方が一致する場合（クォーラム値が2であるため）、残りの2つのノードから新しいマスターが選択されます。

以下は、このフェールオーバシナリオのログテールを示しています。

スレーブノードのログ。

センチネルスレーブノードのログ

次に、info replicationコマンドを使用してレプリケーションの状態を確認しましょう。

ログテールをさらに詳しく説明する,

各センチネルは、+sdownイベントでマスターがダウンしていることを検出します。 (+sdownは、指定されたインスタンスが主観的にDown状態になったことを意味します。)

+new-epochは、現在のエポックが更新されたことを意味します。

+sdownイベントは後で+odownにエスカレートされ、複数のセンチネルがマスターに到達できないという事実に同意することを意味します。 (+odownは、指定されたインスタンスが現在客観的にダウン状態にあることを意味します。)

Sentinels+vote最初のフェイルオーバーの試行を開始するSentinel。

フェイルオーバーが発生します。

さらに、以下は新興ジョブを示しています。

RedisのためのUpstart

description "Redis Server"start on runlevel 
stop on runlevel script
echo $$ > /var/run/redis.pid
su - amila -c "cd /home/amila/redis-stable/src/; redis-server ../redis.conf"
end scriptpost-stop script
rm -f /var/run/redis.pid
end script

センチネルのためのUpstart

description "Redis Sentinel Server"start on runlevel 
stop on runlevel script
echo $$ > /var/run/redis.pid
su - amila -c "cd /home/amila/redis-stable/src/; redis-server ../sentinel.conf --sentinel"
end scriptpost-stop script
rm -f /var/run/redis.pid
end script

おめでとう！ それは単にそれです。 これが、Redisが高可用性と自動フェールオーバーを処理する方法です。 それでは、最適化のヒントやトリックに飛び込む前に、いくつかの興味深いRedisの事実を見てみましょう。

Redisについての興味深い事実。

Redisは最大2つの32個のキーを処理でき、インスタンスあたり少なくとも2億5000万個のキーを処理するために実際にテストされました。

空のインスタンスは約3MBのメモリを使用します。

100万個の小さなキー->文字列値のペアは約85MBのメモリを使用します。

100万個のキー->ハッシュ値は、5つのフィールドを持つオブジェクトを表し、〜160MBのメモリを使用します。

Redisはシングルスレッドです。 複数のCPU/コアを利用するにはどうすればよいですか？

通常、Redisはメモリまたはネットワークにバインドされているため、CPUがRedisのボトルネックになることはあまり頻繁ではありません。 その場合、Redisインスタンスの水平または垂直スケーリングは、CPU関連のボトルネックを軽減するのに役立ちます。

Redisはメモリ内ですが、ディスクデータベース上では永続的です。

> : 指定された間隔でのデータセットのポイントインタイムスナップショット。 (データバックアップ)|AOF:サーバーが受信したすべての書き込み操作をログに記録します。 (より耐久性のある)

Javaを使用している場合は、javaクライアントであるJedisを使用して、JavaアプリケーションをRedisに接続できます。 注:Jedisは、接続プール(GenericObjectPool)にApache Commons Poolを使用します。 A single Jedis instance is not threadsafe!これらの問題を回避するには、ネットワーク接続のスレッドセーフなプールであるJedisPoolを使用する必要があります。 デフォルトの最大接続プールサイズは8です。

ここでは、発生する可能性のある問題/エラーと、Redisの本番パフォーマンス最適化のヒントとトリックに焦点を当てましょう。

あなたが得るかもしれない問題/エラー&生産パフォーマンス最適化のヒントとトリック

まず第一に、redisで。confとセンチネル。conf、すべての設定は順序になっているので、順序を台無しにしないでください。 それ以外の場合は、次のような設定エラーが発生します。

*** FATAL CONFIG FILE ERROR ***
Reading the configuration file, at line 98
>>> 'sentinel down-after-milliseconds mymaster 5000'
No such master with specified name.

セキュリティの観点から、マスターとスレーブで認証するためのパスワードを設定します。 このためには、redisを簡単に変更できます。confとセンチネル。以下の設定値を使用してconfを設定します。

In sentinel.conf
sentinel auth-pass <master-name> <password>In redis.conf
masterauth <master-password>

は、TCPバックログの設定（最大接続数）が511であることを確認します。 次の手順で、それに応じて（サーバーの仕様を考慮して）その値を設定できます。

sudo nano /etc/rc.local
Add this:
sysctl -w net.core.somaxconn=65535When you reboot the next time, the new setting will be to allow 65535 connections instead of 128 as before. When you add the line to rc.local make sure it's before the exit 0.

redisから遭遇する可能性のある警告のいくつか。ログは次のようになります,

WARNING overcommit_memory is set to 0! Background save may fail under low memory condition. To fix this issue add 'vm.overcommit_memory = 1' to /etc/sysctl.conf and then reboot or run the command 'sysctl vm.overcommit_memory=1' for this to take effect.You can add this via following command as well as using a cat command you can makesure whether the value is set properly.echo 'vm.overcommit_memory = 1' >> /etc/sysctl.conf
cat /etc/sysctl.conf

THPまたはTransparent Huge Pageを無効にする必要がある場合があります。

WARNING you have Transparent Huge Pages (THP) support enabled in your kernel. This will create latency and memory usage issues with Redis. To fix this issue run the command 'echo never > /sys/kernel/mm/transparent_hugepage/enabled' as root, and add it to your /etc/rc.local in order to retain the setting after a reboot. Redis must be restarted after THP is disabled.Fixsudo nano /etc/rc.local
echo never > /sys/kernel/mm/transparent_hugepage/enabled

TCPポート6379の代わりにUNIXソケットを使用すると、Redisのパフォーマンス向上にも寄与します。

これを達成するために、redis。confは以下の設定に変更する必要があります。

unixsocket /var/run/redis.sock
unixsocketperm 777# Accept connections on the specified port, default is 6379.
# If port 0 is specified Redis will not listen on a TCP socket.
port 0

さらに、ユースケースに応じてRedis永続化オプションも設定できます。

必要に応じて、サーバーが実行されている限りデータを存在させたい場合は、永続性をまったく無効にすることができます。 注：redisのすべての「保存」行をコメントアウトすることで、RDBの永続性を無効にすることができます。confは次のようになります。

Comment out these 3 values in redis.conf
save 900 1
save 300 10
save 60 10000rdbcompression no
rdbchecksum no

AOF persistance（ファイルのみを追加）は、redisではデフォルトで無効になっています。コンフ…

appendonly no

— — — — — — — — — — — — — — — — — — — — — — — — — — — — — — —

Redisの監視

監視の観点から、Redisを監視するためのいくつかのツールがあります。 NewRelicは、”ほとんどの時間消費されたdb操作”、”スループットによる操作”、”クエリ時間による操作”など、Redisを監視および分析するための事前機能を提供します。

New Relic Redisの詳細については、こちらを参照してください。 さらに、Redis-statは優れたオープンソースのRedis監視ツールでもあります。

— — — — — — — — — — — — — — — — — — — — — — — — — — — — — — —

AWS ElasticCache

AWSは、Redisが付属している”ElastiCache”という名前のインメモリキャッシュクラウドサービスも提供しています。 これは、手動設定と管理タスクのほとんどをオフロードする効果的な使いやすいクラウドサービスとして指定することができます。

ElastiCacheは、クラウド内の分散インメモリキャッシュの起動、管理、およびスケーリングを容易にするwebサービスです。

興味深いことに、数回のクリックでシャーディングを備えたクラスターモード、自動フェールオーバーを備えたマルチAZ、保存時の暗号化、転送中の暗号化、S3へのRDB

AWS ElastichCacheの最もクールな機能は、CPU/メモリ使用率（スワップおよびフリーメモリ）、接続数、アイテム数、立ち退き、文字列、キー、ハッシュベースのコマンド数、レプリケーショ

まあ…それはこの記事のためにかなりそれです！

この記事の冒頭で述べたように、そこにはさまざまなRedisの記事がたくさんありますが、開発者やdevopsエンジニアがSentinelで高可用性Redisクラスターを構築するために必要で有用な最も重要な事実とヒントをカバーする”all in one proper article”を作成したかったのです。

この投稿を終える前に、私が見つけた興味深い記事の一つは、FlickrがRedis Sentinelをどのように実装したかでした。 その投稿も必ず確認してください。

わかった だから、この記事を読んでくれてありがとう、私は開発者としての私の経験を共有し、すぐに別の興味深い記事を思い付くことを楽しみにしています。 それまで、乾杯！ そして、幸せなコーディング！