ロードバランサーのNginxにキャッシュさせる設定

ロードバランサーになっているNginxにキャッシュさせてバックエンドにあるサーバーに問い合わせないように設定したときの覚書。

環境： CentOS 6.6, nginx 1.6.2

サーバー構成はこんな感じ。

参考にしたサイト

キャッシュ機能を有効に
静的サイトはまるっとキャッシュ
動的サイトは一部分キャッシュ
キャッシュを削除

１．キャッシュ機能を有効に

nginx.confを編集して、proxy_cache_pathを追記する。

# cd /etc/nginx/
# vi nginx.conf

http {
    # Proxy Cache
    proxy_cache_path /var/cache/nginx/cache_www levels=1 keys_zone=www:4m inactive=7d max_size=50m;
    proxy_cache_path /var/cache/nginx/cache_web levels=1 keys_zone=web:4m inactive=7d max_size=50m;
}

ゾーン名：www, web
保持期間：７日間
最大サイズ：50M

２．静的サイト用にまるっとキャッシュ

静的サイトは全てに対して1日キャッシュする設定にする。

デフォルトでPOSTはキャッシュしない。proxy_cache_methodsを設定すればPOSTもキャッシュすることが可能になる。

# vi conf.d/www.conf

upstream webs {
    ip_hash;
    server web01.hoge.com;
}
server {
    listen       80;
    server_name www.hoge.com;

    #
    # Header
    #
    add_header X-Cache $upstream_cache_status;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header Host $http_host;

    #
    # Proxy Cache
    #
    proxy_cache www;
    proxy_cache_key $host$uri$is_args$args;
    proxy_cache_valid any 1d;

    #
    # Web
    #
    location / {
        proxy_pass http://webs;
    }
}

「add_header X-Cache $upstream_cache_status;」はキャッシュが利用されたか分かって便利（参考：Module ngx_http_upstream_module）。

Nginx再起動
# /etc/rc.d/init.d/nginx configtest
# /etc/rc.d/init.d/nginx restart

別サーバーからApache Benchで試してみる。
# ab -n 50 -c 5 http://www.hoge.com/
同時接続数：5
リクエスト回数：50

３．動的サイトは一部分だけキャッシュ

CSS, JS, 画像はキャッシュを使うようにした。

< 2015/04/12 Modified >
なぜかCSSやJSの読み込みに失敗する現象が発生。バックエンドのサーバーは200を返しているけど、キャッシュサーバーが304を返し、ブラウザでは「fails」になる。nginx 1.6.3

spdyとnginxのcache機能の組み合わせで起こるみたい。設定ファイルの書き方がダメなのかも。。。

ひとまずspdyを使わないようにした。

# vi conf.d/web.conf

upstream webs {
    ip_hash;
    server web01.hoge.com;
}
server {
    #listen       443 ssl spdy;
    listen       443 ssl;
    server_name hoge.com;

    root /home/httpd/httpdocs/;

    #
    # SSL
    #
    ssl on;
    ssl_certificate      /etc/nginx/ssl.d/2014_hoge_cert.pem;
    ssl_certificate_key /etc/nginx/ssl.d/2014_hoge_nopass_key.pem;
    ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
    ssl_ciphers ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:ECDH+3DES:DH+3DES:RSA+AESGCM:RSA+AES:RSA+3DES:!aNULL:!MD5:!DSS;
    ssl_prefer_server_ciphers   on;
    ssl_session_cache shared:SSL:10m;
    ssl_session_timeout 10m;

    #
    # Header
    #
    add_header X-Cache $upstream_cache_status;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto https;
    proxy_set_header Host $http_host;

    #
    # Proxy Cache
    #
    proxy_cache web;
    proxy_cache_key $host$uri$is_args$args;

    #
    # Static Contents
    #
    location ~* \.(?:ico|css|js|gif|jpe?g|png)$ {
        proxy_cache_valid any 1d;
        access_log off;
        proxy_pass http://webs;
    }

    #
    # Web
    #
    location / {
        # Disable Proxy Cache
        proxy_no_cache 1;
        proxy_cache_bypass 1;

        # Proxy Backend Servers
        proxy_pass http://webs;
    }
}

実際はincludeを使ってファイルを分けてる。

nginxの設定方法で分かったこと。

locationは一致した一つのみ適用される。breakして他のlocationへ移動したり、mixinみたいなことは出来ない。
→ if文で制御する方法
→ 共通項をincludeで別ファイルにする方法

キャッシュについて

バックエンドがWordPressで、ログインしているとレスポンスヘッダーに「pragma:no-cache」が出力されるので、自動でキャッシュが無効になると思いきや、すでにバックエンドに処理が移っているので意味がない。

キャッシュが効いているかはバックエンドのアクセスログを監視しながら確認すると間違いない。

Apache Benchについて

ベンチマークをしてみるとhttpに比べて異様に遅い。
# ab -n 50 -c 5 https://hoge.com/demo/wp-content/themes/test/_inc/css/common.css?ver=4.1

トップはある程度速くなった。
# ab -n 50 -c 5 https://hoge.com/demo/

ブラウザで表示すると速い。レスポンスヘッダーに「x-cache:HIT」が表示されているので問題ないと思う。

SSLの復号化に時間が掛かっているのかな？

４．キャッシュを削除

コンテンツをアップデートした際に手動でキャッシュをクリアにする。
# rm -rf /var/cache/nginx/cache_www/*

< Related Posts >

Search

SE奮闘記