最終更新日: 2019年12月28日
Squid Home / FAQトップ

SquidによるReverse Proxyの構築


Squid2.6STABLE8以降は、"http_port" の "accel" オプションでリバースプロキシ(アクセラレータ)を指定するようになった。

Squid-2.5以前のアクセラレータモードの動作はまったく異なるため、引き続き使用する場合は2.6以降にアップグレードすることを強くお勧めします。


このページでは、リバースプロキシ(Reverse Proxy)を使った、Webサーバのパフォーマンス改善について示します。 このページは次のような章立てになっています。
1章ではリバースプロキシの概要、2章では普通のリバースプロキシと透過モードでのリバースプロキシの比較、3章ではリバースプロキシでのキャッシュの働き、4章ではSquidをリバースプロキシとして機能させる設定

1章、リバースプロキシの概要
2章、普通のリバースプロキシと透過モードでのリバースプロキシの比較
3章、リバースプロキシのキャッシュの動き
4章、Squidをリバースプロキシとして機能させる設定

補足:

リバースプロキシやアクセラレータ(透過プロキシ)において認証機能を使う場合の注意についてはこちらも参照してください。


1章、リバースプロキシの概要

1.1 リバースプロキシ (Reverse Proxy)とは?

リバースプロシキキャッシュはWebサーバの加速器(アクセラレータ)として知られており、インターネットとWebサーバの間に入れることで、Webサーバのロードによるビジー状態を削減する方法です。また別の利点としてはセキュリティの強化も可能です。
これらは、複雑にすることなくスケーラビリティを改善する方法を提供します。 リバースプロキシの良い使い方としては、静的・動的の両方のコンテンツを提供するWebサーバの負荷を緩和させることです。 静的なコンテンツはキャッシュにより処理されるため、Webサーバは動的コンテンツの為により多くの処理時間をつかう事ができます。

■リバースプロキシ(アクセラレータ)を経由してサイトを配置する例と効果。


  • サーバを増やすことによる経費を削減できます。
  • より多くの静的コンテンツのリクエストに対応できます。
  • Webサーバはより多くの動的コンテンツに対応できます。
  • Webサイトの訪問者により早い応答でコンテンツを提供し、ダウンロード時間を加速します。
  • Webサーバの見た目の容易に性能をあげる事ができます。
  • Webサーバ単体の障害が発生しても、リクエストを処理することができます。

リバースプロキシを構築するにあたって、基となるサーバのコンテンツはプロキシを考慮して書かれるべきです。すなわちこれらは「キャッシュし易い」ようになっているべきです。もし基となるサーバのコンテンツがキャッシュの事を考慮していないなら、リバースプロキシを最大限に活用することは出来ないでしょう。

リバースプロキシモードでは、SquidプロキシサーバはクライアントにとってWebサーバのように振る舞います。
内部からのプロキシの利用と違い、外部のクライアントがプロキシのための設定をする必要はありません。 プロキシをWebサーバようにアクセスするだけです。 
実際のWebサーバはURLによって経路が決定されます。
プロキシのキャッシュによって、オリジナルサーバや内部ネットワークをファイヤーウォールで守られた背後に置く事で、基となるWebサーバを外部クライアントに晒すことなくコンテンツを送る事ができます。 

このページの目的は、SquidのWebアクセラレータおよびにリバースプロキシの実装について説明する事です。

1.2 Squidとは?

Squidは、Unixシステム上で動作するようにデザインされたオープン・ソースのハイ・パフォーマンス プロキシーです。National Science Foundation(NSF:米国立科学財団)は、Squidプロジェクトに資金を供給しています。 Squidは、たくさんのISPと世界中の会社で利用されています。 Squidほとんどのプロキシ・サーバーがすることができるl事よりも遙かに多くをすることが実現できます。

・Squidでのサポート

2章、普通のリバースプロキシと透過モードでのリバースプロキシの比較

ネットワークに構成できるプロキシの3つの機能があります。

■標準的なプロキシキャッシュ

標準のプロキシキャッシュ機能で、静的なコンテンツ(htmlイメージ)をキャッシュし、クライアントからのリクエストに1/2の時間で応答する事ができます。 HTTPリクエストは目的のWebサーバではなくプロキシを経由することをブラウザに明示的に指示する必要があります。

■透過キャッシュ(Transparent Cache)

透過キャッシュ機能は、ブラウザに標準的なプロキシと同じ機能を提供します。 ただし、標準的なプロキシではクライアント側でプロキシを利用することを明示的に指示する必要がありましたが、透過キャッシュではプロキシを使うことをブラウザ側で指示する必要がありません。 透過キャッシュではクライアントからのHTTPリクエストをHTTPトラフィックフィルター(ポート80)でネットワークの途中で捕まえて、その要求がキャッシュにあるかを確認し処理します。 もし要求されたものがキャッシュになければオリジナルサーバへ要求を転送します。
Linuxにおいては、iptablesやipchainsといったネットワークフィルタと一緒によく利用されます。 透過キャッシュは、クライアント側での設定が不要ということでISPにとっては非常に有用です。 
透過プロキシについては、FAQ-17を参照してください。

■リバースプロキシキャッシュ(アクセラレータ)

リバースプロキシは、クライアント要求による上流ネットワークの帯域削減よりもむしろ、オリジナルサーバの処理(ロード)削減を目的においており、標準や透過のキャッシュとは異なります。 リバースプロキシはクライアントからのWebサーバへの静的コンテンツへのリクエストを処理します。 リバースプロキシはWebサーバへのリクエストをすべて途中で捕まえて、キャッシュされている内容への要求である場合にはWebサーバへリクエストを転送せずに、リバースプロキシだけで処理させます。

3章、リバースプロキシのキャッシュの動き

クライアントブラウザがHTTPをリクエストした時、DNSは実際のWebサーバではなくリバースプロキシを指し示すようにしておく。
リバースプロキシは要求されたアイテムがキャッシュに無いかを確認する。もし本当にキャッシュにない場合には実際のWebサーバに要求を転送し、その内容をダウンロードします。

CGIスクリプトやアクティブサーバページズなどの動的なコンテンツはキャッシュする事ができません。 プロキシは静的なページのコンテンツのみをキャッシュできます。

リバースプロキシにおいてブラウザに返すコンテンツを、オリジナルサーバとするかキャッシュとするかの判断に使われる4つの重要なヘッダータグが存在します。

例: デフォルトでアクティブサーバページズが戻すヘッダーには「Cache-control: private.」が付いてきます。 このため、このページはキャッシュされません。

4章、Squidをリバースプロキシ(HTTPアクセラレータ)として機能させる設定

この設定は squid.conf においてフォワードプロキシの設定(http_access等)よりも前に設定されている必要があります。 そうでない場合には、標準のプロキシのアクセスルールによってアクセラレータはブロックされます。

4.1 Webサーバが1台だけで、そのアクセラレータとして上位にSquidを配置する場合

HTTPアクセラレータとしてSquidを機能させるのは、squid.confをほんの少し修正するだけで簡単です。 大抵の場合このファイルはRedHatなどの場合には /etc/squid か /usr/local/etc/squid のどちらかで見つけられる事でしょう。 ソースコードらSquidをコンパイルした場合には、/etc/squid にあると思います。 squid.confを編集するためにrootになった後、以下の項目を修正することで、リバースプロキシ(HTTPアクセラレータ)とることができます。

■ リバースプロキシと別のマシンでWebサーバが動いている場合:

まず、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に指示する必要があります。
cache_peer backend.webserver.ip.or.dnsname parent 80 0 no-query originserver name=myAccel
そして最後に、他のWeb要求をWebサーバーにプッシュすることなく、サイトへのアクセスを許可するアクセス制御を設定する必要があります。
acl our_sites dstdomain your.main.website.name
http_access allow our_sites
cache_peer_access myAccel allow our_sites
cache_peer_access myAccel deny all
これで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を使ったリバースプロキシの構築についてはこちらをご覧ください。

Squid Home / FAQトップ

参考: