はじめに
こんにちは、クラウドワークス (https://crowdworks.jp/) でエンジニアをしているBugfireです。今回は所属しているジャンヌチームと、協力しているSREチームにおける活動をお伝えします。
クラウドワークスでは、AWS上でRailsアプリケーションを運用しており、以前はMemcachedとRedisの両方をKVSとして利用していました。最近、より効率的な運用を目指してRedisに統合しました。
MemcachedとRedisについて
MemcachedとRedisはどちらもキーバリューストア(KVS)を提供するデータベースシステムです。
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!
クラウドワークスでは、様々なポジションのエンジニアを募集しております。 ご興味のある方は、ぜひご連絡ください。
