MemcachedからRedisに変更しました

はじめに

こんにちは、クラウドワークス (https://crowdworks.jp/) でエンジニアをしているBugfireです。今回は所属しているジャンヌチームと、協力しているSREチームにおける活動をお伝えします。

クラウドワークスでは、AWS上でRailsアプリケーションを運用しており、以前はMemcachedとRedisの両方をKVSとして利用していました。最近、より効率的な運用を目指してRedisに統合しました。

MemcachedとRedisについて

MemcachedとRedisはどちらもキーバリューストア(KVS)を提供するデータベースシステムです。

Memcachedはシンプルで高速な一方、Redisは豊富な機能を備えています。詳細は以下の公式ページからご確認ください。

• Memcached
• Redis

移行の背景

当初は Memcached のみを利用していましたが、後にRedisを追加しました。セッション管理とキャッシュに Memcached を、その他のKVS要件にはMemcachedとRedisを併用していました。しかし、インフラとコードの管理を単純化するために、Redisに一本化する決定をしました。

移行プロセス

セッションストア

最初のステップとして、セッションストアをMemcachedからRedisに切り替えました。具体的には、

ActiveSupport::Cache::MemCacheStore から ActiveSupport::Cache::RedisCacheStore への切り替えを行いました。この変更はトラフィックの少ない時間帯に実施しました。

セッション用にはEviction*1されないことを期待するRedisインスタンスを利用しています。

キャッシュストア

次に、RailsのキャッシュメカニズムをMemcachedからRedisに切り替えました。これは単純に設定ファイル内の

config.cache_store の値を :mem_cache_store から :redis_cache_store に変更することで実現しました。

こちらはセッションストアと違い、Evictionを許容するRedisインスタンスを利用しています。

DalliとRedis gemのケース

直接KVSとしてDalliã‚„Redisを使用していて揮発しても構わないものは、キャッシュストアを利用する Rails.cache に置き換えました。これにより、多くの直接的なKVS利用をRailsのキャッシュ機能でカバーしました。

揮発が許されないデータ

揮発が許されないロックデータ等に関しては、Evictionを許容しないインスタンスに対してRedis gemを直接利用して実装するように変更しました。

CachedCounter

当社が開発したCachedCounterの利用を、Redis gemを直接使用する形に置き換えました。

データ移行を伴うケース

一部のデータは保持したまま移行するため、TTLに合わせた30日の移行期間をとりました

• 30日間
  • 読み込み時に旧データを読み込む
  • 書き込み時に新旧の両方にデータを書き込む
• 30日後
  • 新データを読み書きする

と二段階に分けて更新しました。

滅多に読み書きしないケース

3ヶ月毎に実行するバッチで利用しているケースでは、念の為次回の実行タイミング直前に移行して、万が一のためのリカバリープランを準備しました。

まとめ

片手間でありつつも、半年間をかけたこの移行作業は、Memcachedへのアクセス数が減少するのを見ると共に、大きな達成感を感じました。

今回の移行とは独立した話ですがRedisのSCANコマンドをもちいて、原因不明だったTTL未定義のKeyを探し出して削除できたのも成果でした。

We're hiring!

クラウドワークスでは、様々なポジションのエンジニアを募集しております。 ご興味のある方は、ぜひご連絡ください。

crowdworks.co.jp

*1:EvictionとはMemcached, RedisではTTL(Time-To-Live: データの保持期間)と独立してメモリ不足により一定のルールでデータの削除を行うことがあります。対策としては空きメモリ容量を見積もりと監視により十分に保つこと。