クックパッドの裏側って、正にレシピのレシピですね。。
- ロードバランサー、アプリケーション、データベースの、よくある3層構造
- サーバ台数: ロードバランサー x 8, アプリケーション x 52, スレーブデータベース x 18, マスターデータ, 監視, ログなど
- ロードバランサー: Apache 2.2.3 mod_proxy_balancer(2.2.3 ということは CentOS 5系なのかもしれない、この規模で mod_proxy_balancer か...)
私も驚いたのここでした。
L7のロードバランサーのいいところは、静的ファイルはバランサー自身が返したりできるので、動的な吐き出しのみバランサーに頼れば、結構いけるとは思っていましたが、それにしてもこの規模のサイトでmod_proxy_balancerのみとは驚きました。
ProxyPassMatch ^(/.*?.png)$ !こんなかんじですかね。（未検証）
正規表現つかった方が遅いのだとしたら、静的ファイルの置き場を決めて
ProxyPass /img !ProxyPass /js !
ProxyPass /css !
こんなかんじですかね。（同じく未検証）
バランサー8台ってことなので、試しにdigしてみたら、
;; QUESTION SECTION:
;cookpad.com. IN A;; ANSWER SECTION:
cookpad.com. 300 IN A 203.183.167.214
cookpad.com. 300 IN A 203.183.167.215
cookpad.com. 300 IN A 203.183.167.217
cookpad.com. 300 IN A 203.183.222.67
cookpad.com. 300 IN A 203.183.222.68
cookpad.com. 300 IN A 203.183.167.211
TTL300secくらいで、グローバルIP6つでラウンドロビンしているので、バランサー8台というのも中の構成がよくわかりませんが、大体そんなところなんですかね。
キャッシュなんですけど、
- ページキャッシュしたデータを NFS に保存して、Apache から直接返している
- フラグメンテーションキャッシュには、memcached を使っている
ページのキャッシュも全てmemcachedでやらないのは、なぜかな。サイズがでかいんですかね？アプリケーション52台でNSF叩きまくるのにあまりいい感じがしないのですが、ここも詳細な構成が知りたい。。
しびれたのは、ここ。
無言実行: 公開前にサービスについての説明をしない
固定ユーザーも相当数いるのに、この方針はかっこよすぎ。ついつい説明したくなるところを、説明しなくてもわかるレベルまで持って行くんですから。
