ElastiCache Redisについて色々調べてみた記事です。
具体的には以下のことを調べてみました！
- 特徴
- 使うメリット
- 注意点
- memcachedとの比較
- 用途
- 可用性を意識した設定（クラスターモードの有無とか）
まずは特徴について記載していきます。
ElastiCache Redisの特徴
まずはメリットについてです。
使う際のメリット
メリットは大きく2つ紹介します！
高速に動作するデータストアです
有効期限（TTL）を設定できる
高速に動作するデータストアです
公式記事にミリ秒未満のレイテンシーと記載があります。
非常に高速です。これが一番のメリットかと思います。
Amazon ElastiCache for Redis は、ミリ秒未満のレイテンシーを実現する非常に高速なインメモリデータストアで、インターネット規模のリアルタイムアプリケーションを強化できます。
有効期限（TTL）を設定できる
有効期限（TTL）を設定できます。有効期限（TTL）を設定して登録したデータは、有効期限になると勝手に消えてくれます。
次に使う際の注意点を記載します！
使う際の注意点
RedisはNoSQLであるという点
インメモリデータストア
RedisはNoSQLであるという点
NoSQLとは、リレーショナルデータベース（RDB）ではないデータベースです。
- テーブルを他のテーブルとJoinして検索などリレーショナルな概念がそもそも存在しません。
- リレーショナルな概念を捨て去ってRDBとは別物として考える必要がある
インメモリデータストア
すべてのデータがメモリ上に保持されています。メモリ上という特性上、最悪の場合、データが消えることもあります。以下のような感じです。
- メモリ上にデータが保持されている
- メモリ上だから処理が早いよ
- メモリは揮発性だよね
- メモリ上だから処理が早いよ
また、メモリに乗り切るデータ量しか扱えません。
データがメモリに乗り切らない場合、以下のような挙動になります。有効期限(TTL)は設定しておいた方が良さそうですね。
- 有効期限（TTL）を設定していれば、いい感じにデータ消去してくれる
- 削除アルゴリズムはRedisの公式ドキュメントをご参照ください。
- 有効期限（TTL）が設定されていない場合
- 手動でメモリ解放が必要
- メモリ解放しないと新規にデータ追加ができない状況に陥ります
- 手動でメモリ解放が必要
次はmemcachedとの比較をしていきます！
memcachedとの比較
Redisと同様に、memcachedも以下のような特徴を持ちます。
高速で動作する
NoSQL
インメモリデータストア
Redisとmemcachedの違い
可用性の観点で違いがあります。
可用性の面ではRedisの方が優れています。
- Redisはレプリケーションができる
- レプリケーションしておき、プライマリノード＋レプリカノードの構成にしておく
- プライマリノードに障害があれば、レプリカノードがプライマリに昇格する
- レプリケーションしておき、プライマリノード＋レプリカノードの構成にしておく
- memcached
- レプリケーション不可
次はRedisの用途についてです！
ElastiCache Redisの用途
セッションストアとして使う
RDSのデータキャッシュ
セッションストアとして使う
特徴で記載した以下のようなことからセッションストアとしての用途が考えられます。
- 高速
- セッションストアは高速の方がサイトレスポンスが良くなるから良い
- 有効期限(TTL)を設定できる
- セッションは有効期限あるからTTL設定できると便利
- データが消えてしまうことがある
- 最悪消えてしまってもログインし直せば良いよね
という感じです。
RDSのデータキャッシュ
RDSのデータ(Select結果)のキャッシュとしての用途です。
RDSよりRedisの方が高速なため、サイトのレスポンス速度が向上します。
以下のようなイメージです。
- 初回はRDSのデータを取得し、Redisに取得したデータを格納
- Redisにデータ格納する際は有効期限(TTL)を設定する
- サイト表示はRDSのデータを使う
- Redisにデータ格納する際は有効期限(TTL)を設定する
- 2回目以降はRedisのデータを使用してサイト表示をする
- 有効期限(TTL)によりデータがなくなった場合は、RDSのデータを取得し、Redisに取得したデータを格納
ECサイトのTOPページの商品情報など、以下のような特徴を持つ場合に有効と考えます。
- よくアクセスされる
- リアルタイムに表示内容を変更する必要がない
注意点としては、適切に有効期限(TTL)を設け、情報が古くなってしまわないようにすることです。
Redisへ情報格納する際は
- キー：SQLをハッシュ化したもの
- バリュー：SQLの実行結果
としておくのが良いと思われます。
次は、ElastiCache Redisの設定について記載します！
可用性を意識した設定（クラスターモードの有無とか）
インフラ的観点での設定について考えていきます。
細かく考えると難しいので、
簡単に「こういう時はこういう構成を考える」といった考え方のみ記載します。
開発環境とか本番でもRedisが落ちても問題ない場合
プライマリノードのみあれば良いので、以下の設定で作成します。
- シャードの数：1
- シャードあたりのレプリカ：0
本番環境の最小構成(クラスターモードなし)
プライマリノードとレプリカノードがあれば良いので、以下の設定で作成します。
- シャードの数：1
- シャードあたりのレプリカ：1
プライマリノードの障害時は、レプリカがプライマリに昇格します。
本番環境のクラスターモードあり方式
以下を最小構成とします。
- プライマリ：3台
- レプリカ：3台
プライマリが複数ある(データが分散されて保持される)ため、負荷分散、可用性に長けています。
クラスターありの場合の注意点は以下の記事ご参照ください
まとめ
色々な場面でElastiCache Redisを使えそうですね。
可用性を意識した設定は良く考えて設定する必要がありますが、そこさえクリアすれば、高速なストレージを使用した開発が可能です。
同じNoSQLのDynamoDBの記事もよろしければ、ご参照くださいー
