Redis Labs、強い一貫性を保ちつつRedisを高可用クラスタ化する「RedisRaft」発表
インメモリキーバリューストアのRedisを開発するRedis Labsは、複数のRedisをクラスタ化することで高い可用性を実現しつつ、クラスタ内で強い一貫性の保持を実現するクラスタ化ソフトウェア「RedisRaft」を発表しました。
Introducing RedisRaft, a new strong-consistency deployment option for Redis in beyond-cache scenarios requiring a high level of reliability and consistency. #RedisRaft https://t.co/2l5dmiVFpk
— Redis Labs (@RedisLabs) June 23, 2020
Redisはメモリ上でキーバリューデータを扱うインメモリデータベースで、その高速性が大きな特長です。2015年に登場したRedis 3.0からはRedis Clusterによるクラスタ機能を備えており、データに対して自動的にシャーディングが行われてクラスタ内の複数のRedisノードに対して分散配置されることで、大規模かつ高可用性を備えた分散キーバリューストアとして機能するようになりました。
そのうえでRedisRaftはクラスタ内で強い一貫性を実現するものだと、次のように説明されています。
A RedisRaft cluster offers the same level of consistency and reliability expected from reliable, well-known data stores such as ZooKeeper or Etcd. In a nutshell, in RedisRaft:
RedisRaftクラスタはZooKeeperやEtcdでよく知られているようなものと同等の一貫性と信頼性を提供する。すなわち、次のようなものだ:
- Acknowledged writes are guaranteed to be committed and never lost.
- 認識された書き込みはコミットが約束されており、失われることはない。
- Reads will always return the most up-to-date committed write.
- 読み込みは常に、最新のコミット済みの書き込まれた値を返す。
RedisRaftの一貫性は、名前の由来でもある分散合意アルゴリズム「Raft」によって実現される予定とのこと。ただし、強い一貫性を保つためのトレードオフとして、以下のような条件や制限があると説明されています。
- Client operations depend on cluster nodes exchanging messages, so they become bound to network latency.
- クライアントからの操作は、クラスタノードのメッセージ交換に依存するため、ネットワークの遅延に拘束されます。
- Writes must be flushed to disk before completing, so they become bound to disk I/O latency.
- 書き込みは、完了前にディスクへフラッシュする必要があるため、ディスクのI/Oレイテンシに拘束されます。
- The cluster is available only as long as a majority of the nodes are up, healthy, and able to communicate with each other.
- クラスタは、大多数のノードが、稼働し、健全で、相互に通信できる状態、という場合に限り稼働します。
現在RedisRaftのプレビューに向けて開発が進んでおり、数カ月以内に公開される予定。正式版は「GNU AGPLv3」と「Redis Source Available License(RSAL)」のデュアルライセンスになるとのことです。
あわせて読みたい
Kubernetesを自動車に載せる/Google、セキュリティスキャナー「Tsunami」公開/デベロッパーの5割以上が「フルスタック」を自認ほか、2020年6月の人気記事
≪前の記事
Twitter、コードやドキュメント内の用語「Whitelist/Blacklist」「Master/Slave」「Dummy value」などを好ましい用語へ置き換え、具体例も発表