# memcached ## 概要 memcachedは、メモリにキャッシュを保存するキャッシュデーモンである。複数のホストマシンで動く分散システムとして設計されており、キャッシュを共有できるため、同じキャッシュのコピーが複数存在することがない。(Source: [[@2011__OReillyJapan__ウェブオペレーション - Chapter 9 予期しないトラフィック急増への対応]] §9.7) ## 9章での扱い - [[dealnews.com]]の2006年のトラフィック急増(キャッシュスタンピード)対応の初期段階では、Apacheの再起動に加えてmemcachedのコネクション数上限への対処が必要になった。調査の結果、memcachedは多くのコネクションを扱えることがわかり、コネクション数を多めに設定した。(Source: 同 §9.3) - その後のアーキテクチャ刷新では、自作リバースプロキシの主な仕事として「memcachedから直接キャッシュを提供する」ことが据えられた。プロキシサーバはリクエストされたURIがmemcachedにあるかを確認し、あればすぐにクライアントへ返してコネクションをクローズする(非常に高速)。キャッシュが空ならアプリケーションサーバに接続してデータを受け取り、memcachedに保存する。アプリケーションサーバはHTTPヘッダでプロキシサーバにキャッシュ方法を伝える。(Source: 同 §9.7) - ファイルI/Oのボトルネックが本番負荷テストで見つかった際には、該当ファイルをmemcachedへ移動することで対処した。(Source: 同 §9.10) - PHPのmemcached拡張はC言語で書かれているため、PerlやPythonのクライアントよりオーバーヘッドが少なく、リバースプロキシのロジック実装言語としてApache + mod_phpの組み合わせが最速という結果につながった。(Source: 同 §9.3) ## 18章での扱い 『ウェブオペレーション』18章(2011、[[濱崎 健吾]])は、[[Cookpad|クックパッド]]がレスポンスキャッシュ用のKVSとしてMemcachedとTokyo Tyrantを使用し、Varnish・SquidのようなHTTPアクセラレータは用いていないと簡潔に述べる。9章のdealnews.comが自作リバースプロキシの中核技術としてMemcachedを詳細に活用するのに対し、18章は三層構成の一要素として名前を挙げるにとどまり、導入の経緯や実装詳細までは踏み込んでいない。(Source: [[@2011__OReillyJapan__ウェブオペレーション - Chapter 18 日本の料理のインフラ]] §18.1) ## 関連 - 概念: [[分散キャッシュ]](memcachedを中心とした分散キャッシュ技術の横断概念) - 実体: [[dealnews.com]](本ページの利用者) / [[Brian Moon]](9章執筆者) / [[Cookpad]](18章での利用組織) - ソース: [[@2011__OReillyJapan__ウェブオペレーション - Chapter 9 予期しないトラフィック急増への対応]] / [[@2011__OReillyJapan__ウェブオペレーション - Chapter 18 日本の料理のインフラ]] - 書籍: [[ウェブオペレーション ―サイト運用管理の実践テクニック]] ## 出典 - [[@2011__OReillyJapan__ウェブオペレーション - Chapter 9 予期しないトラフィック急増への対応]] §9.3, §9.7, §9.10 - [[@2011__OReillyJapan__ウェブオペレーション - Chapter 18 日本の料理のインフラ]] §18.1