インフラ・DevOps
Memcachedを称賛する
In Praise of Memcached (jchri.st)
要約
この記事では、高性能な分散メモリオブジェクトキャッシュシステムであるMemcachedをRedisと比較し、その運用上の利点を強調しています。Redisがデータベースとして誤用されがちなのに対し、Memcachedはそのシンプルさ、ダウンタイムへの耐性、そして永続化機能がないことから、純粋なキャッシュとしての役割に最適であると述べています。特に、クライアントサイドでのクラスタリングや、軽量で効率的な運用が可能である点が評価されています。
全文翻訳
もしあなたがシステム管理者、あるいは誰かのインフラを維持する立場にいるなら、いつか「キャッシュが必要だ」という話題が持ち上がる可能性があります。あなたは少し考え、Redisに手を伸ばします。なぜなら、それに慣れていて、フル機能で、そしてうまく機能するからです!あなたはそれが優れた堅実なキャッシュであったことを思い出し、最近のリリースがどのような新機能をもたらしたのか疑問に思い、そのホームページに向かいます。「エージェントは失敗していません。そのコンテキストが失敗しています。質問するエージェントは知りたいのです:AIアプリのリアルタイムコンテキストエンジンとしてRedis Irisをどのように使用できますか?」1 そうですね、おそらくAI2に関する何かでしょう。これはある程度理解できます。なぜならRedisは収益を上げたい企業だからです。ともあれ、Redisのホームページはさておき、あなたはそれをデプロイし、信頼できるキャッシュとして出発します。あなたはそれを要求した人々に接続文字列を渡し、仕事は終わりです。
数ヶ月後、しばらくすると、`cache.set("key", "value")`が本当に単純な抽象化であり、`INSERT INTO table VALUES ('key', 'value')`よりも間違いなく簡単であることが判明します。人々はREmote DIctionary Serverを常にそこにあるもの、データを永続化するもの、データベースとして扱い始めます。あなたはこれを知りません。あなたの運用チームの同僚もこれを知りません。したがって、キャッシュは揮発性のものとして扱われるとあなたが仮定しているため、あなたのアラートシステムもこれを知りません。あなたがRedisに何かをするときに、この状況が続いていることに気づきます。もしかしたらアップグレードしたり、別のノードに移動したり、猫がRAID0サーバーのHDDトレイのイジェクトボタンを押したりするかもしれません。問題はRedisに永続性がないことではなく、通常、Redisはキャッシュとしてスタックに導入され、人々がそのように扱うという前提で運用されていることです。通常、これに気づいたときには手遅れで、Redisはアプリにあまりにも深く絡み合っており、その場所を本当の意味で離れることはできません。代わりに、あなたはそれをペットのように維持し監視するという永遠の喜びを味わうことになります。
Memcachedの登場
まず – Memcachedとは何でしょうか?簡単です、そのウェブサイトに尋ねてみましょう:「Memcachedとは何ですか?無料でオープンソースの、高性能な分散メモリオブジェクトキャッシュシステムであり、汎用的な性質ですが、データベースの負荷を軽減することで動的なウェブアプリケーションの速度を向上させることを目的としています。」3 おお、ページの最初の文で、コード例まであります。そして、上にある可愛いマスコットたちを見てください!
MemcachedもRedisと同様にキャッシュです。Djangoのようなフレームワークを使用している場合、プラグイン可能なキャッシングをサポートしており、異なるキャッシングバックエンドを切り替えることができます。しかし、Redisよりもはるかに機能が少ないMemcachedをなぜ使うべきなのでしょうか?私が最近、常にRedisよりもMemcachedを好む理由を以下に示します。
Memcachedのダウンタイムへの対処は信じられないほど簡単です。なぜなら、クライアントライブラリは一般的に接続例外を無視するからです。例えば、サーバーがダウンしている場合、単純なgetはデフォルト値(またはなし)を返します。
Memcachedのクラスタリングは素晴らしいです。なぜならMemcachedには実際にはクラスタリングが組み込まれていないからです。それを「クラスタリング」するには、クライアントライブラリに複数のURL4を設定し、クライアントはキーをハッシュすることに基づいてターゲットインスタンスを選択します。クライアントサイドの呼び出しがインスタンスがダウンしていると検出した場合、そのノードをハッシャーから削除します。一定時間後、クライアントは自動的に再接続を試み、ダウンしたノードを使用します。
Memcachedは永続性の問題を「解決」します。なぜなら、ディスクに永続化しないからです。したがって、必要な場所にステートレスなワークロードとしてスケジュールするのに完璧に適合します。
これらのことのどれもRedisでは不可能ではありませんが、Memcachedのアーキテクチャは一般的にこれらの方向性により傾いており、運用上の観点からははるかに、はるかに簡単になります。しかし、Memcachedが比較的にシンプルなアプリケーションであるため(さらに、約64MBのキャッシュサイズとほとんどオーバーヘッドなしで数十のインスタンスを実行できるという事実も相まって)、最近キャッシュが必要な場合は、通常Memcachedに手を伸ばします。
とはいえ、「データベースが遅すぎる」問題の多くは、実際には「クエリが遅すぎる」または「インデックスが欠落している」ことから始まるため、親切な人になって開発者のクエリ最適化を支援してください。また、Memcachedの設計に関する決定事項に興味があるなら、ブログには興味深い記事があり、5月に発表されたばかりの「How Long Does That Response Take… For Real?」という記事もあります。
https://redis.io/, 2026-06-02アクセス ↩︎
とはいえ、https://redis.io はエンジニアにとって最高の入り口ではないでしょう。そのウェブサイトは購買決定を行う人々向けに作られているようです。 ↩︎
https://memcached.org, 2026-06-02アクセス ↩︎
サービスディスカバリメカニズムを使用してこの設定を自動的に生成するとボーナスポイントです。 ↩︎