RedisRaftとは?Redisに強い一貫性をもたらす新しいクラスタリングモジュールの解説

RedisRaft(開発中)は、オープンソースのRedis向けの新しいモジュールで、複数のRedisサーバーを単一のフォールトトレラントかつ強い一貫性(strong consistency)を持つクラスタとして運用することを可能にします。その名のとおり、Raft合意アルゴリズムと、それを実装したオープンソースのCライブラリを基盤としています。

RedisRaftは、Redisおよびそのエコシステムに、厳密な直列化(シリアライゼーション)を伴う新しい強一貫性デプロイオプションをもたらします。この新しいモジュールにより、既存のRedisクライアント、ライブラリ、データ型をそのまま活用しながら、高い信頼性と一貫性が求められる「キャッシュ用途を超えた」シナリオでもRedisを使用できるようになります。

RedisRaft誕生の経緯

RedisRaftは、Redis 5のリリース直前に実験的な「サイドプロジェクト」として始まりました。RedisモジュールAPIはRedis 4で導入されたもので、主に新しいデータ型やコマンドを実装するモジュールをサポートするために設計されています。私たちは、このAPIをどこまで拡張できるかを探り、モジュールを使ってRedisをさらに根本的な形で拡張したいと考えました。同時に、最終的には実用的なもの——つまりRedisのための強一貫性デプロイオプション——を作り上げたいという狙いもありました。

RedisRaftクラスタは、ZooKeeperやEtcdといった信頼性の高い有名データストアから期待されるのと同等の一貫性と信頼性を提供します。簡単に言えば、RedisRaftでは以下が保証されます。

• 確認応答(ACK)を受け取った書き込みは、必ずコミットされ、決して失われないことが保証されます。
• 読み取りは常に、最新のコミット済み書き込み結果を返します。

このレベルの一貫性を提供する信頼性の高いデータストアに期待されるように、こうした保証にはパフォーマンスと可用性におけるトレードオフが伴います。RedisRaftの場合:

• クライアント操作はクラスタノード間のメッセージ交換に依存するため、ネットワークレイテンシの影響を受けます。
• 書き込みは完了前にディスクへフラッシュされる必要があるため、ディスクI/Oレイテンシの影響を受けます。
• クラスタは、過半数のノードが稼働・正常であり、相互に通信可能である場合にのみ利用できます。

RedisRaftの仕組み

RedisRaftモジュールをRedisにロードすると、クラスタノード間の通信、Raftログやスナップショットのレプリケーション、永続化などをモジュール側が引き受けます。Redisコアはこれらを一切認識せず、コアから見れば、クラスタリングも永続化もレプリケーションもないスタンドアロンサーバーとして動作している状態です。

3ノード構成のRedisRaftクラスタのセットアップは、3つのRedisサーバーを起動するだけと非常に簡単です。

redis-server --loadmodule /path/to/redisraft.so

最初のサーバーに接続し、Raftクラスタを作成する方法は次のとおりです。

10.0.0.1:6379> RAFT.CLUSTER INIT
OK 989645460313dd2ddb051f033c791222

続いて、残りの2台のサーバーに接続し、クラスタへ参加させます。

10.0.0.2:6379> RAFT.CLUSTER JOIN 10.0.0.1:6379
OK
10.0.0.3:6379> RAFT.CLUSTER JOIN 10.0.0.1:6379
OK

クラスタへのアクセス

RedisRaftのセットアップが完了したら、さっそくクラスタにデータを書き込んでみましょう。

10.0.0.1:6379> INCR counter:1
(integer) 1

レスポンスを受信できたということは、この書き込みがクラスタノードの過半数(今回の例では2ノード)以上にレプリケートされ、それぞれの永続ストレージにコミットされたことを意味します。

Raftは強力なリーダー概念(strong-leader)に基づいているため、すべてのクライアント操作はリーダーノードに送られ、そこから開始される必要があります。上記の例では、クライアントは偶然リーダーに接続していましたが、クラスタのリーダーシップは動的に変化するため、クライアントが常にリーダーを把握しているとは限りません。

同じ操作をフォロワー(非リーダー)ノードに対して実行すると、次のようなレスポンスが返されます。

10.0.0.3:6379> INCR counter:1
(error) MOVED 10.0.0.1:6379

クライアント側では、このエラーを捕捉し、指定されたリーダーノードへの接続を確立し直して、コマンドを再試行することができます。

しかし、既存のアプリケーションを修正したくない場合はどうすればよいのでしょうか。幸い、RedisRaftにはこれを自動的に処理する設定も用意されています。フォロワープロキシモード(follower proxy mode)を有効にすると、クラスタノードが自動的にリクエストをリーダーへ転送し、結果が得られた時点でレスポンスを返してくれます。

10.0.0.3:6379> RAFT.CONFIG SET follower-proxy yes
OK
10.0.0.3:6379> INCR counter:1
(integer) 2

もちろん、こちらの方がはるかにシンプルですが、非リーダーノードへのアクセスは余分なネットワークホップを発生させるため、レイテンシとネットワーク負荷に影響します。

クラスタ構成の変更

先ほどクラスタをセットアップした際、実際には3つの異なる操作を行っていました。

1. 単一ノード上でクラスタを作成する。
2. 2番目のノードを追加する。
3. 3番目のノードを追加する。

RedisRaftのクラスタ構成は静的なものではなく、クラスタ作成後も稼働中のままノードの追加や削除が可能です。

たとえば、3番目のノードを置き換える必要が生じたとしましょう。まず、置き換え用となる新しいノードをクラスタに参加させます。ここで「削除してから追加」ではなく「追加してから削除」の手順を採るのは、移行期間中にクラスタと大切なデータが冗長性の低下した状態に陥るのを避けるためです。

10.0.0.4:6379> RAFT.CLUSTER JOIN 10.0.0.1:6379
OK

次に、3番目のノードにランダムに割り当てられたIDを確認します。

redis-cli -h 10.0.0.1 --raw RAFT.INFO | grep 10.0.0.3
node2:id=1739451728,state=connected,voting=yes,addr=10.0.0.3,port=6379,
last_conn_secs=3537,conn_errors=0,conn_oks=1

そして、そのノードを削除します。

10.0.0.1:6379> RAFT.NODE REMOVE 1739451728
OK

RedisRaftのリリース状況

RedisRaftの開発の一環として、分散システムの安全性と正しさを検証するための著名なフレームワークであるJepsenを使用した分析・テストについて、Kyle Kingsbury氏(Aphyrとして知られる)と協業しています。この協業による成果物として、すでに公開されている分析レポートがあります。

まだ開発途上ではありますが、RedisRaftの基本機能の大部分はすでに実装済みです。現在は最初のプレビュー版に向けて作業を進めており、数ヶ月以内に公開される見込みです。一般提供(GA)開始時には、GNU AGPLv3またはRedis Source Available License(RSAL)のデュアルライセンスのもとでリリースされる予定です。