Squidの更新パターンでインターネットアクセスを高速化する：Leverage OSS（1/2 ページ）

プロキシキャッシュサーバであるSquidの設定パラメータを用いてバイトヒット率を上げれば、利用可能な帯域幅を3〜6割近くも拡大できる。Webサイトの最適化を考えるあなたにはまずこれを試してみていただきたい。

[Solomon Asare，SourceForge.JP Magazine]

　帯域幅の制限は、インターネットに接続している多くの人にとっていまなお残る問題の1つだ。しかし、プロキシキャッシュサーバSquidをネットワークにインストールし、設定パラメータを用いてバイトヒット率を上げれば、利用可能な帯域幅を3〜6割近くも拡大できる。

　Squidは、きめ細かいチューニングによってさまざまなニーズに対応できる。現行の安定版には少なくとも249個のパラメータがあり、丁寧なコメントがついた設定ファイル（通常は「/etc/squid.conf」）は4600行以上もある。このボリュームには、経験豊かな管理者でも圧倒されるだろう。設定の変更はすべてこのファイル上で行う。

　1週間では一杯にならない（理想をいえば1カ月以上持つような）大きなキャッシュが欲しいところだ。実際に必要なサイズは、ネットワークのトラフィック量によって変わってくる。キャッシュのサイズが大きいほど、要求されたオブジェクトがキャッシュに保存されている可能性が高くなる。

　メモリ容量は、OSおよびSquidの実行に必要な分に加え、キャッシュサイズの約1％をキャッシュのデータベース用に確保する必要がある。つまり、100Gバイトのディスク領域をキャッシュにする場合は、そのデータベース用に約1Gバイト、OSおよびSquid用に約100Mバイトが必要になる。

　Squidでキャッシュ可能なオブジェクトの最大サイズは、デフォルトで4Mバイトである。ただし、最近のメディアリッチなインターネットの環境を考えるとこれでは少なすぎる。クライアント側で多数の動画やソフトウェアパッケージをダウンロードするなら、日常的にダウンロードされるファイルの最大サイズを考慮して値を（例えば100Mバイトに）増やすとよい。

　キャッシュによる保存と提供が行われる対象は、更新パターン（refresh pattern）によって決まる。理想的には、コンテンツを提供するWebサーバの情報に従って、キャッシュ可能な対象と期間を決められるようにしたい。こうした情報は、Squidによって処理され理解されるHTTPヘッダに記されている。残念ながら、ほとんどのサーバによって与えられる情報はWebサーバのデフォルト設定であり、帯域幅の大幅な節約にはつながらない。

　更新パターンの形式を以下に示す。

refresh_pattern [-i] regex min percent max [options]

　ここで、minとmaxは時間を分単位で指定した値、percentはパーセント値である。optionsには次のものを指定できる。

• override-expire：WebサーバからのExpires（有効期限）ヘッダを無視する。
• override-lastmod：WebサーバからのLast-modified（最終更新日）ヘッダを無視する。
• reload-into-ims：クライアントからのreload（再読み込み）要求をIf-Modified-Since（更新日による条件付き取得）要求に変換する。
• ignore-reload：クライアントのno-cache（キャッシュを利用せず元のサーバからリロード）ディレクティブを無視する。よって、キャッシュから取得可能であればそれを利用して要求に応える。
• ignore-no-cache：Webサーバからのno-cache（オブジェクトをキャッシュ不可にする）ディレクティブを無視する。
• ignore-no-store：Webサーバからのno-store（やはりオブジェクトをキャッシュ不可にする）ディレクティブを無視する。
• ignore-private：Webサーバからのprivate（同じくオブジェクトをキャッシュ不可にする）ディレクティブを無視する。
• ignore-auth：権限の承認を要求するオブジェクトをキャッシュ不可するとの 制限を無視する。
• refresh-ims：クライアントからのreflesh（更新）要求をIf-Modified-Since要求に変換する。

　これらのオプションのどれが利用できるかはSquidのバージョンによって異なるので、設定ファイルで確認すること。

　更新パターンが有効なのは、元のサーバからのExpiresヘッダが存在しない場合、あるいは利用する更新パターンにignore-expireオプションが含まれる場合である。次の例を見てみよう。

refresh_pattern -i \.gif$ 1440 20% 10080.

　これは次のような意味になる。

1. 名前が「.gif」または「.GIF」で終わるオブジェクト（つまりgif画像ファイル）のいずれにもExpiresヘッダがない場合は2）に進む。それ以外の場合は6）に進む。
2. 保存時間（オブジェクトがキャッシュサーバ上にある時間）が1440分未満の場合は、まだ新しいオブジェクトと見なしてそれを渡し、処理を終了する。それ以外の場合は3）に進む。
3. 保存時間が1万80分より長い場合は、古いオブジェクトと見なして元のサーバにアクセスして新しいコピーを取得し、処理を終了する。それ以外の場合は4）に進む。
4. 保存時間が1440〜1万80分の場合は、lm-factorを使ってオブジェクトの鮮度を判断する。lm-factorは、キャッシュサーバ上でのオブジェクトの保存時間を、元のサーバにおけるそのオブジェクトの作成または変更からの経過時間で割った値である。例えば、元のサーバで 1万分前に作成されたオブジェクトが、キャッシュサーバ上に1800分（＝保存時間）に保存されている場合、lm-factorは1800/10000で18％となる。
5. lm-factorが更新パターンの指定パーセント値（＝20％）より小さい場合、新しいオブジェクトと見なして渡し、処理を終了する。それ以外の場合は6）に進む。
6. 古いオブジェクトと見なし、元のサーバにアクセスして新しいコピーを取得する。

　動画や画像、音声、実行ファイル、アーカイブなど、ファイルの名前が同じであればその内容にも変化がないことがほとんどであるオブジェクトの場合は、更新パターンを変更して新しいオブジェクトの基準を甘くすることで、キャッシュのヒット率を上げることができる。例えば、前記の更新パターンは、次のように変更できる。

refresh_pattern ^ftp: 1440 20% 10080

refresh_pattern ^gopher: 1440 0% 1440

refresh_pattern -i \.(gif|png|jpg|jpeg|ico)$ 10080 90% 43200 ignore-expire ignore-no-cache ignore-no-store ignore-private

refresh_pattern -i \.(iso|avi|wav|mp3|mp4|mpeg|swf|flv|x-flv)$ 43200 90% 432000 ignore-expire ignore-no-cache ignore-no-store ignore-private

refresh_pattern -i \.(deb|rpm|exe|zip|tar|tgz|ram|rar|bin|ppt|doc|tiff)$ 10080 90% 43200 ignore-expire ignore-no-cache ignore-no-store ignore-private

refresh_pattern -i \.index.(html|htm)$ 0 40% 10080

refresh_pattern -i \.(html|htm|css|js)$ 1440 40% 40320

refresh_pattern . 0 40% 40320

　少なくともわれわれには理解しがたい行為だが、元のサーバ側（YouTube.comなど）があらゆる手を尽くしてコンテンツのキャッシュを困難または不可能にしようとしている場合がある。前記のオプションは、こうした制限の克服に役立つだろう。

　更新パターンは、すべての要求に対して、該当する規則が見つかるまで上位のものから順にマッチングが行われる。最後の規則はキャッチオール規則で、上位の規則のいずれにも当てはまらなかった要求はすべて、この規則とのマッチングが行われる。通常、FTPやgopherといったほかのプロトコルについては、デフォルトのキャッチオール規則をリストの最上位に別途用意し、下位の規則とのマッチングが行われないようにしておく。