最近memcachedの話を聞きました。
Google Cloudさんでmemcachedのマネージドサービスが終了すると言う話です。
この中で、memcachedがこれからどうなのか、という話も耳にすることがあったのと、こちらのCatatsuyさんの記事にもあるようにまだまだmemcachedは終わってないぞ、と言う話もあったので個人的にどう思うかを書いてみました。
Zennに書こうと思いましたが、なんかポエムっぽいのでこっちに書こうと思いますｗ
memcachedに思うこと
前述の記事にもあります通り、今もmemcachedを使うことにメリットがあるのは間違いないです。それは高速性と、シンプルさに寄与したものです。ただ、そのシンプルさが故に現在ではデメリットもあると思っています。
クラスタリングが自前で大変
memcachedにはクラスタリングの機構がありません。スケールしたいとなった瞬間、コンシステントハッシングか自力シャード構成の二択を迫られます。
これ、やったことある人ならわかると思うんですが、結構辛いんですよね。深夜にノード障害が起きて、どのキーがどこにあるか追いかける羽目になったことがある方も多いかもしれません。
だからkumofsが出た時「それだ！！！」って飛びついた人もいたと思います。
一方Redis/Valkeyはレプリケーション、クラスタリングの機構を標準で持っておりクラスタ状態の管理はサーバー/ミドルウェア側で隠蔽してくれる、マネージドなサービスであれば特にエンドポイントを一つに見せることもでき運用負荷は低いため運用という意味で言えば今ではRedis/Valkeyを選択すると思います。
ちなみに、コンシステントハッシング
私はコンシステントハッシングは特定のKeyは特定の1ノードにしか存在しないアーキテクチャであるため今どのノードにどのデータがあるか把握するのが非常に難しいと思ってます。v-nodeなどを使うと複数ノードにも持てますが、結局ノード数の変更イベントでデータを持つ場所が変わるためきれいな運用は難しいと思います。
良くも悪くもメモリプールとしての使い方がメイン
再起動すると基本的にデータが使えなくなるため、使い方によってはサービスのダウンにつながります。メモリもOSの物理メモリの限界がハードリミットになるためアクセスパターンによってはキャッシュが必要な時に無いということになることもあります。（最近のmemcachedだともっとインテリジェンスなのかもですが）
Redis/Valkeyならキャッシュデータはダウン時にも全体が失われることはない
キャッシュがある前提でのアーキテクチャが組みやすくなります。Redisなどであればセカンダリに切り替わったうえでシンプルにいいタイミングで復旧に入れるのでその差は大きいな、と思います。
memcachedの向いているパターン
- 万が一なくなっても問題がないユースケース
- 無いなら無いなりに返せるパターンともいえる
- キャッシュがなくてもなんとかなる、という前提のアーキテクチャを組むならなぜキャッシュがいるんだ、という話につながるし、先にホットデータは突っ込んでおくと言うパターンもある、、、若干の手間が必要。
- 余り大規模ではないキャッシュのユースケース
- どうしてもシンプルなまま使いたいならある程度以上の大きさにするのは運用の手間や、障害などを考えると難しくなってくる
- マルチスレッドの暴力といえるほどの性能
- 1台あたりのインスタンスで数百万〜数千万RPSのリクエストをさばくならRedisより断然強い
- 単純さ
- シンプルな挙動、余計なことをしないからこそ予測可能で速い
結論
一言で言うと、一般的なWebサービスにはRedis/Valkeyが正解だと思います。ただしmemcachedが輝く領域も残っている、と思う。
ぼくらの青春だったmemcachedですが、この2026年においてMemcachedが輝くのは「機能要件は非常にミニマムだが、非機能要件（レイテンシ、アクセス量など）が極端に高い、そこを運用や自動化でカバーできる」という玄人好みの領域に残された聖域なのではないかと思いました。
ハマればめちゃくちゃいいけど、そうじゃないと大変、の様な。
現在の一般的なWebサービスに使用するのであれば 多くのケースでは機能、運用、永続性のバランスが良いRedis/Valkey を第一選択として選ぶのが正解なんじゃないかなーと思っています。
以上、気持ちの供養しました！
256bitのミステリ世界 
コメントを残す