このページでは、リバースプロキシ(Reverse Proxy)を使った、Webサーバのパフォーマンス改善について示します。 このページは次のような章立てになっています。
1章ではリバースプロキシの概要、2章では普通のリバースプロキシと透過モードでのリバースプロキシの比較、3章ではリバースプロキシでのキャッシュの働き、4章ではSquidをリバースプロキシとして機能させる設定
1章、リバースプロキシの概要
2章、普通のリバースプロキシと透過モードでのリバースプロキシの比較
3章、リバースプロキシのキャッシュの動き
4章、Squidをリバースプロキシとして機能させる設定
補足:
リバースプロキシやアクセラレータ(透過プロキシ)において認証機能を使う場合の注意についてはこちらも参照してください。
リバースプロシキキャッシュはWebサーバの加速器(アクセラレータ)として知られており、インターネットとWebサーバの間に入れることで、Webサーバのロードによるビジー状態を削減する方法です。また別の利点としてはセキュリティの強化も可能です。
これらは、複雑にすることなくスケーラビリティを改善する方法を提供します。 リバースプロキシの良い使い方としては、静的・動的の両方のコンテンツを提供するWebサーバの負荷を緩和させることです。 静的なコンテンツはキャッシュにより処理されるため、Webサーバは動的コンテンツの為により多くの処理時間をつかう事ができます。
リバースプロキシを構築するにあたって、基となるサーバのコンテンツはプロキシを考慮して書かれるべきです。すなわちこれらは「キャッシュし易い」ようになっているべきです。もし基となるサーバのコンテンツがキャッシュの事を考慮していないなら、リバースプロキシを最大限に活用することは出来ないでしょう。
リバースプロキシモードでは、SquidプロキシサーバはクライアントにとってWebサーバのように振る舞います。
内部からのプロキシの利用と違い、外部のクライアントがプロキシのための設定をする必要はありません。 プロキシをWebサーバようにアクセスするだけです。
実際のWebサーバはURLによって経路が決定されます。
プロキシのキャッシュによって、オリジナルサーバや内部ネットワークをファイヤーウォールで守られた背後に置く事で、基となるWebサーバを外部クライアントに晒すことなくコンテンツを送る事ができます。
このページの目的は、SquidのWebアクセラレータおよびにリバースプロキシの実装について説明する事です。
Squidは、Unixシステム上で動作するようにデザインされたオープン・ソースのハイ・パフォーマンス プロキシーです。National Science Foundation(NSF:米国立科学財団)は、Squidプロジェクトに資金を供給しています。 Squidは、たくさんのISPと世界中の会社で利用されています。 Squidほとんどのプロキシ・サーバーがすることができるl事よりも遙かに多くをすることが実現できます。
・Squidでのサポート
ネットワークに構成できるプロキシの3つの機能があります。
標準のプロキシキャッシュ機能で、静的なコンテンツ(htmlイメージ)をキャッシュし、クライアントからのリクエストに1/2の時間で応答する事ができます。 HTTPリクエストは目的のWebサーバではなくプロキシを経由することをブラウザに明示的に指示する必要があります。
透過キャッシュ機能は、ブラウザに標準的なプロキシと同じ機能を提供します。 ただし、標準的なプロキシではクライアント側でプロキシを利用することを明示的に指示する必要がありましたが、透過キャッシュではプロキシを使うことをブラウザ側で指示する必要がありません。 透過キャッシュではクライアントからのHTTPリクエストをHTTPトラフィックフィルター(ポート80)でネットワークの途中で捕まえて、その要求がキャッシュにあるかを確認し処理します。 もし要求されたものがキャッシュになければオリジナルサーバへ要求を転送します。
Linuxにおいては、iptablesやipchainsといったネットワークフィルタと一緒によく利用されます。 透過キャッシュは、クライアント側での設定が不要ということでISPにとっては非常に有用です。
透過プロキシについては、FAQ-17を参照してください。
リバースプロキシは、クライアント要求による上流ネットワークの帯域削減よりもむしろ、オリジナルサーバの処理(ロード)削減を目的においており、標準や透過のキャッシュとは異なります。 リバースプロキシはクライアントからのWebサーバへの静的コンテンツへのリクエストを処理します。 リバースプロキシはWebサーバへのリクエストをすべて途中で捕まえて、キャッシュされている内容への要求である場合にはWebサーバへリクエストを転送せずに、リバースプロキシだけで処理させます。
リバースプロキシにおいてブラウザに返すコンテンツを、オリジナルサーバとするかキャッシュとするかの判断に使われる4つの重要なヘッダータグが存在します。
例: デフォルトでアクティブサーバページズが戻すヘッダーには「Cache-control: private.」が付いてきます。 このため、このページはキャッシュされません。
HTTPアクセラレータとしてSquidを機能させるのは、squid.confをほんの少し修正するだけで簡単です。 大抵の場合このファイルはRedHatなどの場合には /etc/squid か /usr/local/etc/squid のどちらかで見つけられる事でしょう。 ソースコードらSquidをコンパイルした場合には、/etc/squid にあると思います。 squid.confを編集するためにrootになった後、以下の項目を修正することで、リバースプロキシ(HTTPアクセラレータ)とることができます。
まず、Squidにポート80(通常)でリッスンするように指示する必要があるため、http_portオプションにdefaultsiteオプションを設定して、Squidにこのサイトのアクセラレーターであることを伝えます。
http_port 80 accel defaultsite=your.main.website.name no-vhost
- accel はSquidに、このポートに着信するリクエストをWebサーバーであるかのように処理するよう指示します。
- defaultsite=X は、ドメインXがこれを必要としている事を Squid に指示します。
- no-vhost によって Squid-3.2以降では HTTP/1.1のドメインベースの仮想ホスティングサポートを無効にします。 古いSquidバージョンには、このオプションはありません。
次に、実際のWebサーバーの場所をSquidに指示する必要があります。
そして最後に、他のWeb要求をWebサーバーにプッシュすることなく、サイトへのアクセスを許可するアクセス制御を設定する必要があります。
これでSquidは、リクエストをHTTPサーバーのように処理します。
リバースプロキシのテストは、本番環境で使用されるSquidが適切に構成された状態で行う必要があります。
しかし、公開DNS設定はそれをプロキシを指してないでしょう。 そのような場合はリクエストするテストマシンの/etc/hostsファイルを変更して、バックエンドWebサーバーではなくsquid のIPにテストリクエストを送信できます。
そのテストで正常に機能するとき、公開DNSを更新してリクエストをバックエンドWebサーバーではなくSquidプロキシに送信することができ、アクセラレータが直ちに開始されます。
■ バックエンドのWebサーバが複数の場合:
バックエンドに複数のWebサーバが控えている場合、それらに分散してリクエストするには、以下のように設定します。acl our_sites dstdomain your.main.website.name
cache_peer backend.webserver.ip.or.dnsname parent 80 0 no-query round-robin weight=50 originserver forceddomain=your.main.website.name name=myAccel1
cache_peer backend.webserver.ip.or.dnsname2 parent 80 0 no-query round-robin weight=50 originserver forceddomain=your.main.website.name name=myAccel2
cache_peer_access myAccel1 allow our_sites
cache_peer_access myAccel2 allow our_sites
cache_peer_access myAccel1 deny all
cache_peer_access myAccel2 deny all
http_access allow our_sites
尚、SSLを使ったリバースプロキシの構築についてはこちらをご覧ください。
参考: