イラストで理解するElastiCache
はじめに
今回はAWSのElastiCacheについて学んでいきます。
ElastiCacheはインメモリ型のデータベースです。
ElastiCacheは聞いたことあるけど、インメモリデータベースってなんだっけ？という人はぜひ読んでみて下さい。
それからElastiCacheのElastiCache for MemcachedとElastiCache for Redisの違いについても解説します。
あまり詳しい部分は触れていませんが、よかったら読んでみてください。
前置き
クラスターやシャード、ノードといった具体的な仕組みや、Lazy Load, Write Throughといったキャッシュの方法についてもこの記事では解説していません。
クラスターやシャードについてはこちらの記事を参考にして下さい。
ElastiCache
まずはElastiCacheがなぜ必要なのかを考えていきましょう。
以下はEC2上のアプリケーションからRDSのデータベースに対してデータを読み書きする図です。
これは一般的なアプリケーションとデータベースのやりとりですが、
アプリケーションが大きくなり、このやりとりが増えるとどうなりますか？
データベースへの読み書きが増えて、データベースからのレスポンスが遅くなることが考えられます。
そんな時、ElastiCacheを使うことでアプリケーションへのレスポンスを高速に行うことができます。
それはなぜか...?
それはElastiCacheがインメモリデータベースだからです。
インメモリデータベースって何？
ではインメモリデータベースとはなんでしょうか？
インメモリデータベースはデータの保存、処理をメモリ上で行うということです。
これだけではイマイチピンと来ませんね。
では、RDSとElastiCacheがデータを処理する流れの違いを見てみましょう。
RDSでは、処理はメモリ、データはストレージで保管しています。
それに比べてElastiCacheはメモリで処理をしてデータもメモリに保存します。
なんでインメモリデータベースは早いの？
アプリケーションからのリクエストを考えると
RDSはストレージから取ってきたデータをメモリでソートなどの処理を行います。
この場合、ストレージからデータを取得するのに少し時間がかかります。
ElastiCacheの場合は、メモリにデータを保管しています。
メモリはSSDやHDDの何十、何百倍の処理速度です。
そのため、メモリ上のデータをメモリを使って処理することで
より早くアプリケーションにデータを渡すことができます。
ここで、思います。
じゃあ全部メモリに置いとけばよくない？と。
しかし、それはできません。
なぜならメモリは揮発性という特性があるからです。
揮発性とは、再起動などによって電源供給が絶たれるとデータが消えてしまうことを言います。
仕事は早いけど、忘れっぽいんですね〜
ということは、大事なデータを保存するのには向いていないということです。
さらに、メモリは容量あたりの費用も高いので、データの永続化には向いていません。
ElastiCacheの使い方
ElastiCacheの使い方としては名前の通り、「キャッシュ」です。
キャッシュは、よく使うデータを一時的にElastiCacheに保存しておいて、いつでもすぐに渡せる状態にしておくということです。
インメモリデータベースのいいところをうまく活用していますね。
こうすることで、アプリケーションは一度ElastiCacheに問い合わせして
ElastiCacheがデータを持っていなければRDSに取りに行くという仕組みができます。
RDSかElastiCacheではなく、
RDSとElastiCacheを使うことで、データをより効率的にアプリケーションに渡すことができるということです。
疑問
インメモリデータベースの特徴に、データをキーバリュー型で保存するというものがあります。
これに関して疑問に思ったことを書きます。
RDSのようなリレーショナルデータベースは行と列の表形式のデータベースです。
しかし、ElastiCacheはキーバリュー型です。
では、どのようにして表形式のデータをキーバリュー型で保存しているのでしょうか？
例を見てみましょう。
このように、表形式のデータをJSONのようなキーバリュー型で保存することができます。
これは、ElastiCacheが勝手にやってくれる訳ではなく、アプリケーション側で実装する必要があります。
そのため、ElastiCacheの導入にはアプリケーションの変更が必要になる場合があります。
ElastiCacheの種類
ElastiCacheでは以下のOSSをサポートしています。
- Memcached
- Redis
この二つにはそれぞれ特徴があります。
先に書きますが、よく使われているのはRedisです。
それは、Redisの方が色々な機能に対応しているからです。
ここからは、二つの違いを見ていきます。
マルチスレッド
Memcached
Memcachedはマルチスレッドに対応しています。
マルチスレッドに対応していると何がいいのかというと、
一回で複数の処理が可能になります。
例えば、複数のユーザーの接続処理を行う場合を考えましょう。
マルチスレッドのMemcachedであれば、複数の処理を同時に行うことができます。
単純なデータを扱うだけであれば、Memcachedは高い性能を発揮します。
Redis
Redisはシングルスレッドです。
この点においては唯一Memcachedに比べて劣っている部分となります。
データ型
データの型は圧倒的にRedisが柔軟です。
Memcached
Memcachedは文字列のみをサポートしています。
Redis
一方、Redisは文字列、リスト、セット、ソートセット、ハッシュテーブル、地理空間、ストリーム、etc...
というように、様々なデータ型をサポートしています。
地理空間というのが気になったので、調べてみましたが
緯度経度をデータとして保持することができるようです。
これを使えば、地図系のアプリケーションにも使用できそうですね。
バックアップ
インメモリデータベースの弱点は、再起動するとデータが消えてしまうということでした。
ではデータを永続化することはできないのでしょうか？
いいえ、バックアップを取ることでデータの永続化が可能です。
Memcached
残念ながら、Memcachedはバックアップをサポートしていません。
Redis
Redisはバックアップをサポートしています。
定期的にスナップショットを取ることでデータを永続化することができます。
スナップショットはS3に保存されます。
可用性
では、次に可用性です。
可用性はMultiAZに対応しているなど、障害時にも対応できるか？ということです。
Memcached
MemcachedはMultiAZに対応していません。
Redis
RedisはMultiAZに対応しています。
RDSと同じように、PrimaryのデータベースとReplicaのデータベースを配置することができます。
障害時は自動フェイルオーバーによってReplicaがPrimaryに昇格します。
ユースケース
では、最後にそれぞれのユースケースを見てみましょう。
とは言ったものの、ユースケースを調べてもRedisがほとんどでした。
Memcachedのユースケース
Memcachedのユースケースはあまり出てきませんでした。
以下は公式ドキュメントで紹介されているユースケースです。
ここでは、野球の試合を分析したり、広告を分析するデータ収集システムに使われていると書かれています。
私の感想にはなってしまいますが、Redisはマルチスレッドに対応しているので、
データの永続化が不要な大量のデータ処理などに使われているのかな？という印象を受けました。
Redisのユースケース
Redisはゲームのリアルタイムのランキング表示のように
継続的にデータが変化するようなアプリケーションに向いています。
ゲームをしていると画面の端っこに出ているランキングようなイメージですね。
このようなリアルタイムのランキングでは常にデータが追加され、ソートによって順位が変動します。
これはソートセットに対応したRedisの代表的な使用例です。
他にも、複数のEC2で構成されるアプリケーションのセッション管理に使われます。
ALBのスティッキーセッション機能もありますが、より可用性を高めるためにもElastiCacheを使うケースが多いようです。
以下はAWSの公式ドキュメントに書かれている使用例です。
この記事からも分かるように、ユースケースとしてはRedisが圧倒的に多いようです。
色々と使用例があるので、気になる方は読んでみてください。
まとめ
今回は、ElastiCacheの基礎的な部分と、MemcachedとRedisの違いについて書きました。
色々調べていく中で、やはり圧倒的にRedidsが使われているんだな〜という印象を受けました。
あまり深い部分には触れていないので、次回はクラスターやノードといった、より具体的な仕組みの部分について書きたいと思います。
参考資料
Discussion