ElastiCacheに関して深堀して以下の2点にフォーカスして紹介したいと思います。
- ElastiCacheのエンジンの違い(MemcachedとRedis)
- ElastiCacheの使用事例
Amazon ElastiCache エンジンの違い
ElastiCacheには２種類あります。
- Amazon ElastiCache for Memcached
- Amazon ElastiCache for Redis
簡単に説明すると以下の特徴があるようです
-
Amazon ElastiCache for Memcached
- シンプルである(機能が多くなく、データ構造がString型)
- マルチスレッドでCPUのコア数によって性能UP
- ノードをアプリケーション側で管理する必要がある
-
Amazon ElastiCache for Redis
- 多機能を備えている(データ構造がKey-Value型)
- シングルスレッド
- ノードをアプリケーション側で管理する必要が無く、障害などが起きた際に勝手に切り替わったりする
詳しい比較は公式サイトで分かりやすい対比表があります。
Amazon ElastiCache for Memcachedの使用事例
今回ElastiCacheを使用するに至った経緯を説明致します。
(長くなりすぎないように、ある程度端折っております)
社内オンプレサーバーからAWS環境のクラウドサーバーへのアクセス処理において、負荷試験で発生した問題が発端です。
事象としては、大量の要求が来た際にDBの接続プールが枯渇してしまっていました。
具体的には、AWS環境にあるクラウドサーバーからDBへのアクセスが多すぎたためです。
既存の処理イメージ
というのも、AWS環境のクラウドサーバーに対してAPI要求を行う際には、以下の3つのリクエストが必要な制御が行われております。
- 認証トークン要求
- 何かしらの要求(実際に行いたい処理のリクエスト)
- 認証トークン削除 そのため、1つの要求を捌くために最大で接続プールを3つも使ってしまう状態でした。
改善後の処理イメージ
①と③については認証トークンに関する処理で、認証トークンは有効期限が来ると消える情報であるため、揮発性が高い情報であり、ElastiCacheで管理するのに最適な情報でした。
ElastiCache化課題その１
認証トークンはElastiCacheで管理することになりましたが、①の認証トークンを取得する処理では顧客情報等も見に行っているため、認証トークンをElastiCacheで管理するだけではDBアクセスは減らせませんでした。
ElastiCache化課題その１ 解決方法
CDP:Inmemory DB Cacheパターン
そこでこのクラウドパターンにあるように、DBの情報をElastiCacheにキャッシュしておくという方法を採用しました。
ElastiCache化課題その２
こうして①と③に関してはDB接続を基本的に無しにして、②の本来の要求のみが必要に応じてDBに接続するように改善しました。
単純に考えるとDB接続に関しては従来の3倍までは許容出来るような状態となりましたが、単純に置き換えただけでは今度はElastiCacheの接続プールが枯渇してしまいました。
ElastiCache化課題その２ 解決方法
ElastiCacheとクラウドサーバーの通信は、クラウドサーバー毎にBulkで行われるようにしました。
ElastiCache化完了
これで実際に計測をしてみた所、②の処理の負荷にもよりますがおおよそ3倍ほどのリクエストが捌けるようになっていました。
ElastiCache化 懸念事項
この辺りはそれぞれのシステムに応じた対策や実際のデータに応じて対策が必要となる部分だとは思いますが、簡単に紹介しておこうかと思います。
- データの整合性をどこで担保するか？
→DBの情報をキャッシュしている分の情報は不整合が発生する可能性がある。 - ElastiCacheの方が容量が少ないので、限界値などの調査が必要。
→ElastiCacheは断片化しづらいように出来ているので、キャッシュしている情報のサイズが分かれば計算自体は容易で、キャッシュ量が増えた際も概ね計算通り増えていきました。
