3日間で去年一年間分の花粉が悲惨したようです。元気です。
「HTTPコンテンツ圧縮はどのレイヤーで行うのがいいか」で書いたあたりと問題は共通しているのですが、大規模サイトの運用で最近割とボトルネックとなりやすいのはラック-集約スチッチ間のトラフィックです。1台あたりの性能が飛躍的に向上し、画像転送では100Mbps〜300Mbps、それ以上ぐらいは楽に吐き出すようになっているので、ラックスイッチの1Gbpsのuplinkではすぐに詰まってしまいます。この対策として、高トラフィックのサーバを分散配置したり、link aggregationにて2Gbps-4Gbpsに増速したり、あるいは10Gの導入を検討すると思いますが、それには手間もお金もかかるので、まずはトラフィックを減らせないか考えるわけです。
そこで最近、2カ所ほどでとった方法が、フロントのReverse Proxyで短時間、キャッシュする方法です。
上の図は、画像を配信するようなシステムの構成図です。フロントにNginxがあり、consistent-hashingでリクエストを分散してSquidにアクセスしています。キャッシュの空間効率から言えば、Squid にだけキャッシュを保存するのが良いのですが、そのために、Nginx-Squid間の通信が必ず発生してしまいます、そこで空間効率を多少あきらめ、Nginx側でもキャッシュを有効にします。NginxはロードバランサーやDNS-RRなどで分散されるので同じ画像のキャッシュを複数台でもってしまうことになりますが、その分お互いにやりとりを行う通信をなくせるのでトラフィックは減らすことができます。
これでトラフィックの問題は解消されますが、キャッシュの場所を増やすことで別の問題が現れます。それはキャッシュデータの削除の問題です。CGMデータの場合理由は様々ですが、オリジナルデータの変更／削除が頻繁に行われます。そしてオリジナルデータが変更された場合、速やかにキャッシュも更新される必要があります。Consistent-Hashingの場合、キャッシュデータの削除時にもConsistent-Hashingを使えます。キャッシュの削除の方法にはこんな方法があります
しかし、Reverse Proxyのキャッシュはすべてのサーバにデータが存在する可能性があるので多少面倒です。もっとも簡単で確実なのは、Reverse Proxyのリストを管理し、全台に対して削除のためのリクエストを発行することですが、そこまで厳密性を求められない場合、キャッシュの有効期限を短く設定し、Expiresされるのを待つという手段も考えられます。これを勝手にShort-term Edge Cacheと呼んでみました。
NignxでShort-term Edge cacheを行うには
proxy_buffering on;
proxy_cache_path /dev/shm/nginx/cache levels=1:2 keys_zone=cache-space:20m max_size=300m inactive=10m;
proxy_cache_key "$scheme$host$request_uri";
proxy_cache cache-space;
proxy_cache_valid 200 302 5m;
こんな感じ。正常なレスポンスを5分キャッシュしています。
Apacheでは、moddiskcacheとcronを使う手があります。httpd.confにてdisk_cacheを有効にし、
CacheEnable disk /
CacheMaxExpire 300
CacheRoot /dev/shm/disk_cache
CacheDirLength 4
cronでcacheのcleanupを行います。
/usr/bin/find /dev/shm/disk_cache -type f -mmin +6 | /usr/bin/xargs rm -f >/dev/null 2>&1
これを毎分〜5分間隔で動くようセットします。
上の設定は、キャッシュ時間を5分にしていますが、コンテンツの性格やキャッシュ削除に求められる厳密性によって数分から数十分までの間で設定ができる思われます。また、同じコンテンツに対するアクセスの集中度合いによってShort-term Edge Cacheの有効性も変わってきます。実際に導入する際にはコストの削減メリットとサポートのリスクとを実際に業務に関わる人と調整することが必要となるかもしれません。
