はじめに

今までなぁなぁにしてきたRedisをいまさらながらに勉強してまとめました。
Redisって聞いたことあるけど中身はよく知らないとか、プロジェクトでなんとなく使っているけど実はよく分かっていないなどの人向けのページです。

NoSQL

Redisの前にまずはNoSQLから。

背景

ビッグデータの登場により、従来のRDBだけでは充分な処理ができなくなってきたことがNoSQL登場の背景にある。
ビッグデータの定義は色々ありますが、ここでは3V(Volume/Velocity/Variety)を満たすものをビッグデータと呼びます。

VolumeとVelocityの問題を解決するためにNoSQLが必要

Volume(大量データ)とVelocity(秒単位で大量データ)に関する問題を対処する場合、スケールアップ(メモリ増加、コア数増加、SSD化)とスケールアウトの2通りの方法がある。
しかしながら、スケールアップは物理的な限界があるし、RDBのスケールアウトは一般的に難しい。
NoSQLは一般的にRDBよりもスケールアウトが容易に行える。

Varietyの問題を解決するためにNoSQLが必要

Variety(非リレーショナルな多様なデータ)をRDBで扱うのはそもそも辛い。

特徴

4つの種類と代表的なOSS
- KVS(キーバリューストア): キーとバリューの組み合わせ
  - Redis
  - memcached
- カラム指向データベース: 列方向のデータのまとまりをファイルシステム上の連続した位置に格納し効率的にアクセスする
  - cassandra
  - HBASE
- ドキュメント指向データベース: キーに対してJSONあるいはXMLを格納する
  - mongoDB
  - couchDB
- グラフ指向データベース: グラフ理論に基づいて関連性を持たせる
  - neo4j
  - TITAN
高速
- インメモリで動作
トランザクション処理ができない
- ACID特性でない
スケールしやすい
- ただしAWSのAuroraのようにスケールが容易なRDBもでてきているためこの特徴は薄れてきている

NoSQLとRDBの使い分け

使い分け
- 基本的にはRDBを採用し、NoSQLがどうしても必要な以下のユースケースのみ導入する。
ユースケース
- リレーショナルに保存する必要のないデータを保存するケース
- 超低レイテンシーが求められるケース
- 超大容量のデータを保存するケース

Redis

いよいよRedisについてです。

特徴

Remote Dictionary Serverの略
OSS(BSDライセンス)
KVS
豊富なデータ型
- String/List/Set/Sorted Set/Hash
高速
- インメモリDBだから
永続化設定可能
シングルスレッド
- 自動的に排他的となる
Redis3.0以降ならスケールアウト可能(2018/11時点ではRedis5.0.0が最新)

豊富なデータ型

String
- 一番基本的な型
- いわゆるkey/value
List
- key(list名)/value(listに格納する値)
- listなので同じkeyに複数の値を格納できる
Set
- key(set名)/value(setに格納する値)
- setなので同じkeyに複数の値を格納できる
- set内
  - 重複を許さない
  - 順不同
Sorted Set(ZSet)
- key(set名)/value(setに格納する値とそのscore)
- set内
  - 重複を許さない
  - 順番はscoreで保持する(setへの保存時にscoreを指定する)
Hash
- key(hash名)/value(hash)
- key-valueの入れ子構造になる

図でいうとこちらの記事がイメージしやすかった。

レプリケーション

マスターのデータをスレーブにコピーすることで読み取り処理の負荷分散と耐障害性を高める方法。
マスターは読み書き両方ができるが、スレーブは読み込み専用。
マスターはスレーブは複数もつことができる。
レプリケーションは非同期に行われる。
設定方法はこちらの記事が参考になりそう。
後述するAWSのElastiCacheサービスでは、マスターのことを"プライマリノード"、スレーブのことを"リードレプリカ"と呼ぶ。

データの永続化(バックアップ)

RDBとAOFの2種類の方式が存在する。
後述するAWSのElastiCacheではAOFが利用可能だが、そもそもバックアップ機能を利用せずにMulti-AZのレプリカ構成が推奨されている。

RDB(スナップショット)

デフォルトで有効になっている方式。
定期的にデータベースの内容をディスク(dump.rdbというバイナリファイル)に保存する。
再起動時にはdump.rdbを元にデータが復元される。
故障時は最後に取ったバックアップからの差分のデータは消失してしまう。

redis.conf

#   save "" # RDBに保存しない
save 900 1 # 900秒以内に1回以上の更新があったらRDBに保存する
save 300 10 # 300秒以内に10回以上の更新があったらRDBに保存する
save 60 10000 # 60秒以内に10000回以上の更新があったらRDBに保存する

AOF(Append Only File)

更新処理ごとにその処理内容を保存し続ける。
消失する心配は減るが、更新系の処理のパフォーマンスが下がる。

redis.conf

appendonly yes
(省略)
# appendfsync always # AOFへ常に同期的に書き込む
appendfsync everysec # AOFへ1秒毎に同期的に書き込む
# appendfsync no
(省略)

Redisの使い所

有効期限のあるデータを扱う場合
- セッション、ワンタイムトークンなど
- データ保存時にexpire指定できる
ランキングデータを扱う場合
- Sorted Set(ユーザID/スコアなど)を利用する
- RDBのorder byより速い
IoTデータの一時保存先として使う場合
Pub/Subを使う場合

Redisとmemcachedの使い分け

とりあえずRedisの方が多機能だと思っていれば初心者はよさそう。

Redisを選択すべきケース

複雑なデータ型が必要な場合
永続化が必要な場合
フェイルオーバーが必要な場合
pub/subが必要な場合

memcachedを選択すべきケース

シンプルなデータ型だけで充分な場合
マルチスレッドが必要な場合

Redisをローカルで触ってみる

install(MacOSの場合)

$ brew install Redis

起動

サーバー起動

$ redis-server

クライアント起動

$ redis-cli

CLI

起動したクラアイント側でCLI操作する。
ここでは基本的な操作方法のみ記載します。
さらに細かい操作方法はこちらの記事が参考になります。
各実行例にあるflushallはDB内の全てのキーを削除するコマンドです。

String型

setでvalueを登録する。
getでvalueを取得する。

127.0.0.1:6379> set str1 hello
OK
127.0.0.1:6379> get str1
"hello"
127.0.0.1:6379> flushall
OK

setexで有効期限付きで登録する。
ttlで有効期限の確認する。

127.0.0.1:6379> setex str1 10 world
OK
127.0.0.1:6379> ttl str1
(integer) 7
127.0.0.1:6379> ttl str1
(integer) -2
127.0.0.1:6379> get str1
(nil)
127.0.0.1:6379> flushall
OK

msetで複数の登録をまとめてする。
mgetで複数の取得をまとめてする。

127.0.0.1:6379> mset str1 hello str2 world
OK
127.0.0.1:6379> mget str1 str2
1) "hello"
2) "world"
127.0.0.1:6379> flushall
OK

incrで数字をインクリメントする。
decrで数字をデクリメントする。

127.0.0.1:6379> set str1 0
OK
127.0.0.1:6379> incr str1
(integer) 1
127.0.0.1:6379> get str1
"1"
127.0.0.1:6379> decr str1
(integer) 0
127.0.0.1:6379> get str1
"0"
127.0.0.1:6379> flushall
OK

List型

lpushで先頭にvalueを登録する。
lrangeで先頭要素と末尾要素を指定して取得する。0と-1を指定した場合は全て。
lpopで先頭の値を取得する。

127.0.0.1:6379> lpush list1 abc
(integer) 1
127.0.0.1:6379> lpush list1 def
(integer) 2
127.0.0.1:6379> lrange list1 0 -1
1) "def"
2) "abc"
127.0.0.1:6379> lpop list1
"def"
127.0.0.1:6379> lrange list1 0 -1
1) "abc"
127.0.0.1:6379> flushall
OK

rpushで末尾にvalueを登録する。
rpopで末尾の値を取得する。

127.0.0.1:6379> rpush list2 abc
(integer) 1
127.0.0.1:6379> rpush list2 def
(integer) 2
127.0.0.1:6379> lrange list2 0 -1
1) "abc"
2) "def"
127.0.0.1:6379> rpop list2
"def"
127.0.0.1:6379> lrange list2 0 -1
1) "abc"
127.0.0.1:6379> flushall
OK

lremで削除する。削除する個数は指定できる。0の場合は全て。

127.0.0.1:6379> lrange list1 0 -1
1) "abc"
2) "def"
3) "abc"
127.0.0.1:6379> lrem list1 0 abc
(integer) 2
127.0.0.1:6379> lrange list1 0 -1
1) "def"
127.0.0.1:6379> flushall
OK

Set型

saddで登録する。
smembersで値を全て取得する。
sremで値を削除する。

127.0.0.1:6379> sadd set1 abc
(integer) 1
127.0.0.1:6379> sadd set1 def
(integer) 1
127.0.0.1:6379> smembers set1
1) "def"
2) "abc"
127.0.0.1:6379> srem set1 abc
(integer) 1
127.0.0.1:6379> smembers set1
1) "def"
127.0.0.1:6379> flushall
OK

setなので同じ値を登録しようとしても、登録できない。

127.0.0.1:6379> sadd set1 abc
(integer) 1
127.0.0.1:6379> sadd set1 abc
(integer) 0
127.0.0.1:6379> flushall
OK

Sorted Set型

zaddでscoreと併せて登録する。scoreの値はマイナスでも構わない。
zrangeで先頭要素と末尾要素を指定して取得する。0と-1を指定した場合は全て。
zremで削除する。

127.0.0.1:6379> zadd zset1 5 abc
(integer) 1
127.0.0.1:6379> zadd zset1 -10 def
(integer) 1
127.0.0.1:6379> zrange zset1 0 -1 withscores
1) "def"
2) "-10"
3) "abc"
4) "5"
127.0.0.1:6379> zrem zset1 abc
(integer) 1
127.0.0.1:6379> zrange zset1 0 -1 withscores
1) "def"
2) "-10"
127.0.0.1:6379> flushall
OK

Hash型

hsetで登録する。
hgetでvalueを取得する。
hgetallでまとめてhashを取得する。
hdelでhashを削除する。

127.0.0.1:6379> hset hash1 field1 abc
(integer) 1
127.0.0.1:6379> hget hash1 field1
"abc"
127.0.0.1:6379> hset hash1 field2 def
(integer) 1
127.0.0.1:6379> hgetall hash1
1) "field1"
2) "abc"
3) "field2"
4) "def"
127.0.0.1:6379> hdel hash1 field1
(integer) 1
127.0.0.1:6379> hget hash1 field1
(nil)
127.0.0.1:6379> flushall
OK

Python(redis-py)

有名な言語であればライブラリが用意されているが、ここではPythonを例にまとめる。

install

$ sudo pip install redis

接続

コネクションプールを使う方法と使わない方法の2パターンがある。
コネクションプールを使う方が速いらしい。

コネクションプールを使う方法

import redis
pool = redis.ConnectionPool(host='localhost', port=6379, db=0)
r = redis.StrictRedis(connection_pool=pool)

コネクションプールを使わない方法

import redis
r = redis.StrictRedis(host='localhost', port=6379, db=0)

操作

ここではString型の簡単な例だけ記載する。
他の型やもう少し詳しい使い方はこちらの記事を参考にするとよさそう。

example

r.set("key1", "hello")
print(r.get("key1"))

実行結果

b'hello'

pub/sub

概要

publishとsubscribeの略。
あるクライアントがpublish(チャンネルにメッセージを送信)すると、subscribe(チャンネルを購読)しているクライアントがそのメッセージを受け取れる機能。
RedisはKVS的使い方以外にも、pub/sub機能を有している。

使い方

サーバー起動する。

$ redis-server

クライアントAを起動し、チャンネルをsubscribeする。

$ redis-cli
127.0.0.1:6379> SUBSCRIBE sample_channel
Reading messages... (press Ctrl-C to quit)
1) "subscribe"
2) "sample_channel"
3) (integer) 1

クライアントBを起動し、チャンネルにPUBLISHする。

$ redis-cli
127.0.0.1:6379> PUBLISH sample_channel "Hello! World!"
(integer) 1

クライアントA側でクライアントB側でPUBLISHされたメッセージが確認できる。（★マーク）

$ redis-cli
127.0.0.1:6379> SUBSCRIBE sample_channel
Reading messages... (press Ctrl-C to quit)
1) "subscribe"
2) "sample_channel"
3) (integer) 1
1) "message" ★
2) "sample_channel" ★
3) "Hello! World!" ★

ElastiCache

ElastiCacheはAWSのインメモリキャッシュに関するマネージドサービスです。
キャッシュエンジンはRedisとmemcachedが選択可能。
ノード、シャード、クラスタの単位が存在する。

ノード(Node)

キャッシュサーバ。
ElastiCacheの最小単位。
選択したノードタイプによって性能(メモリやCPUなど)が異なる。

シャード(Shard)

ノードをまとめるグループ。
1つのシャードにプライマリノード(読み書き可)1個と、リードレプリカ(読み込み専用)0〜5個を持つ。

クラスタ(Cluster)

シャードをまとめるグループ。
クラスタ毎にキャッシュエンジンを選択可能。
クラスタモードは有効と無効を選択可能。

クラスタモード無効

上図はレプリケーションも有効のものです。

クラスタ1つにシャード1個を持つ

クラスタモード有効

上図はレプリケーションも有効のものです。

クラスタ1つにシャード1〜15個を持つ
スケールアウト/スケールイン可能
- シャード数の増減により変更

スケールアップ/スケールダウン

スケールアップ可能
- ノードタイプをAPIを利用して変更
スケールダウン不可

Multi-AZ

t2以外のノードタイプであればMulti-AZが選択可能。ノードをMulti-AZに配置することができる。
昔はmemcachedはMulti-AZが不可だったが、最近はmemcachedも対応したため、Redisにとってそこでの優位性は失われた。

障害発生時

障害発生時には自動フェイルオーバー(故障ノードから新しいノードへの切り替え)する機能が用意されている。

プライマリノードが故障した場合

リードレプリカの1つ(複数ある場合は最も最新のデータが記録されているものが自動選択される)がプライマリノードに昇格する
フェイルオーバー中はプライマリノードへの書き込みは不可
昇格して減った分のリードレプリカは新しく補填される

リードレプリカが故障した場合

新しいリードレプリカノードを自動生成し、故障したノードから切り替える
フェイルオーバー中の読み込み処理は他のノードに負荷が集中する

クラスタ全体が故障した場合

シャードもノードも自動で再作成
永続化していない場合データは失われる
- 永続化は非推奨なのでどうしても永続化したいデータは定期的にRDBに格納すべし

使ってみた

クラスタモード無効

クラスターエンジン
- Redisを選択
クラスターモードを有効のボタン
- チェックつけない

ポート番号
- デフォルトの6379
パラメータグループ
- cluster.onが付いていないもの
ノードタイプ
- 検証用のため最も安いもの(t2.micro)を選択
レプリケーション数
- リードレプリカの数のこと
- 2を選んだ場合はクラスタの中にプライマリが1台とリードレプリカが2台生成され、合計3台になる

Multi-AZ
- ノードタイプがt2なので選択不可

セキュリティグループ
- 同一VPC内のEC2インスタンスからの6379を受け入れるセキュリティグループを作成して選択する
  - 同一VPC内のEC2インスタンス以外からも接続はできるがVPNの設定とかめんどい
保管時の暗号化
- 保管したデータを暗号化するかどうか
送信中の暗号化
- EC2インスタンスやノード間の通信を暗号化するかどうか

バックアップ
- ノードタイプがt2なのでバックアップは選択不可

メンテナンス
- ElastiCacheのパッチ適用が発生した場合に、パッチを適用する時間を指定できる。
- 運用サービスのメンテナンス時間やリクエストが少ない時間帯に設定するのが良さそう。
- 通知方法も指定できる。
- 今回は検証用なので設定しない。

最終的にこんな感じ

クラスタモード有効

上のクラスターモード無効の例との違いがある部分だけ説明します。

クラスターモードを有効のボタン
- チェックする

パラメータグループ
- cluster.onが付いているもの
ノードタイプ
- m3.medium(検証用にMulti-AZやバックアップ機能を確認するために選択)

Multi-AZ
- チェックつけて有効化
スロットおよびキースペース
- シャードの負荷分散方法を選択する
- デフォルトの均等分散を選択
アベイラビリティゾーン
- ノード単位でアベイラビリティゾーンを指定可能
- 今回は指定なし

バックアップ
- 自動バックアップを有効化
  - AOF

作成後の変更できることできないこと

キャッシュエンジンのバージョン変更
- アップグレード可能
- ダウングレード不可
パラメータグループ変更可能
バックアップ設定変更可能
通知方法変更可能
シャード数の増減可能
レプリカ数の増減可能

感想

ローカルにインストールするにしてもElastiCacheを利用するにしても簡単にRedisを使い始めることができる
単純なデータしか扱えない分、覚えることが少ないので学習コストは低い
とりあえずRedisが使えるようになっておけばmemcachedもいけそう

RedisとElastiCacheを分かりやすくまとめてみた

はじめに

NoSQL

背景

VolumeとVelocityの問題を解決するためにNoSQLが必要

Varietyの問題を解決するためにNoSQLが必要

特徴

NoSQLとRDBの使い分け

Redis

特徴

豊富なデータ型

レプリケーション

データの永続化(バックアップ)

RDB(スナップショット)

AOF(Append Only File)

Redisの使い所

Redisとmemcachedの使い分け

Redisを選択すべきケース

memcachedを選択すべきケース

Redisをローカルで触ってみる

install(MacOSの場合)

起動

サーバー起動

クライアント起動

CLI

String型

List型

Set型

Sorted Set型

Hash型

Python(redis-py)

install

接続

操作

pub/sub

概要

使い方

ElastiCache

ノード(Node)

シャード(Shard)

クラスタ(Cluster)

クラスタモード無効

クラスタモード有効

スケールアップ/スケールダウン

Multi-AZ

障害発生時

プライマリノードが故障した場合

リードレプリカが故障した場合

クラスタ全体が故障した場合

使ってみた

クラスタモード無効

クラスタモード有効

作成後の変更できることできないこと

感想