リバースプロキシ ＆ ロードバランサ(reverse-proxy and load-balancer)で、 リバースプロキシ ： ブラウザからのリクエストを１台以上のバックエンド・サーバに渡す（バックエンド・サーバからは、Pound が動作しているマシンからのリクエストにみえる）。 ロードバランサ ： 複数台のバックエンド・サーバにリクエストを分配する（優先順位の設定可）。 SSLラッパ ： ブラウザからのHTTPSリクエストをHTTPでバックエンド・サーバにリクエストする（HTTPしかサポートしていないサーバをHTTPS対応にできる）。 HTTP/HTTPS サニタイザー ： 要求の正当性を確認し、正しいもののみを受け入れる。 フェイルオーバー ： バックエンド・サーバのヘルスチェックを行い、ダウンしているサーバにはリクエストを送らない。復帰を検出したら自動的に通信を再開する。 リクエス
Webサーバの負荷を軽減する方法として、リバースプロキシによる代行とロードバランサによる分散が考えられる。今回は、これらによる負荷の低減方法について解説する。（編集部） Apache自体のチューニングによる性能向上には限界があります。よりパフォーマンスを求めるなら、次にやるべきことはメモリの追加や高性能なCPUへの交換など、ハードウェアの見直しです。しかし、それにも限界があります。 リバースプロキシとロードバランサ ハードウェア単体による性能向上が限界に達した場合は、サーバ構成の見直しを行います。まず考えられるのが、リバースプロキシをWebサーバの前面に立ててクライアントからのアクセスを肩代わりさせる方法です。Webサーバがボトルネックになるのを防ぐとともに、セキュリティ向上にも寄与します。 もう1つの方法は、より高可用性を意図した構成として負荷の分散を図ることです。高可用性とは、サーバの
僕の自宅サーバには２つの Apache がインストールされていて、用途により使い分けています。 * Apache 1.3系 + mod_perl → Amazon Search / Google Similar といった高速性を求めるサービス * Apache 2.0系 → その他の静的コンテンツや 通常用途の CGI 等の動的コンテンツ なぜ使い分けるかというと、mod_perl はメモリー喰いなので、静的画像のためにプロセスがもったいない訳です。本当に必要なリクエストにのみ mod_perl をかませば良いですから。 （参考ページ：リバースプロキシ Pound を導入しました。 : NDO::Weblog） で、２つの Apache を透過的に見せてあげるために、リバースプロキシの Pound を使っています。負荷分散も実装できて優れものですが、欠点が一つ。 リクエストをリバースプロキ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
