TOP
＞
システム開発
＞ Webサーバーのメモリ使用率
事例編〜Web 2.0サービスの中を見せます
第３回：Backend Evolution（前編）
著者：
はてな 伊藤 直也
2006/10/23
前のページ
1
2
Webサーバーのメモリ使用率
FastCGIやmod_perlでメモリ上にPerlプログラムを常駐させた場合、Webサーバーのプロセス1本あたりが使用するメモリ容量は非常に大きくなります。はてなブックマークの場合、httpdのメモリサイズは40MB以上になります。
通常Webサーバーは、クライアントからの1リクエストに対して1プロセスあるいは1スレッドでそれに応答します。高トラフィックなサイトではサーバーに対する同時アクセス数が大きくなるため、結果としてサーバー上ではWebサーバーのプロセス／スレッドが何本も立ち上がることになります。
すると、例えば40MBのプロセスが20本立ったとすると、それだけで800MBのメモリを消費してしまいます（注5）。
注5：
実際には親プロセスとの間でメモリを共有することになるので、単純に40MB ×20本という計算にはなりません。
1GBのメモリを搭載したサーバーで、Webサーバーのプロセスだけで800MBメモリを消費したとすると残りは200MB。OSが基本として必要とするメモリをここから差し引くと残りはわずか。
この状態では、メモリに余裕があればOSのキャッシュに入るであろうファイル群がキャッシュされなかったり、スワップが発生したりすることによってディスクI/Oが頻発し、極端なパフォーマンス劣化が起きてしまいます。
そこで、Webサーバーの処理のうちダイナミックなコンテンツはアプリケーションサーバーで、それ以外のスタティックなコンテンツは専用のWebサーバーで行うように役割を分離して対応するのが定番です。この後者の役割を担うのがリバースproxyです。
リバースproxyは、アプリケーションサーバーの前に配置されるサーバーです。リバースproxyという名前から特殊なソフトウェアを想像してしまいますが、なんのことはない、普通のWebサーバーです。クライアントから受け取ったリクエストのうち、画像などのスタティックなドキュメントは自分で返し、ダイナミックなコンテンツはアプリケーションサーバーに処理を転送するという点が通常のWebサーバーと異なります。
クライアントから、Perlプログラムが生成する必要のある動的なコンテンツ、すなわちダイナミックコンテンツの要求があった場合、
リバースproxyがアプリケーションサーバーにダイナミックコンテンツの要求リクエストを転送する
アプリケーションサーバーはリバースproxyから転送されてきたリクエストに基づいてドキュメントを生成し、リバースproxyに返す
リバースproxyは、アプリケーションサーバーから受け取ったドキュメントをクライアントに返す
といった流れで処理が行われます。
一方、Perlプログラムを必要としないスタティックなドキュメント、つまり画像やスタイルシートなどのファイルは、リバースproxy自身が直接クライアントに返します。クライアントからのリクエストはまずリバースproxyで受け取り、そのリクエストが要求するドキュメントがスタティックであるかダイナミックであるかで転送の判断をする、というわけです。
このように、アプリケーションサーバーとクライアントの間に挟まって処理を代理で行う（proxyする）のがリバースproxyです。
リバースproxyはダイナミックコンテンツを処理しなくても良いため、mod_perlを組み込む必要もありませんし、Perlプログラムを実行する必要もありません。したがって、サーバープロセス1本あたりのメモリ使用量はかなり小さくなります。
そのため、大量の同時アクセスが来た場合にも、リバースproxyならたくさんのプロセスを生成してそれに応答することができます。後ろに控えるアプリケーションサーバーはダイナミックコンテンツを生成する働きだけをすれば良く、手前にいるリバースproxyが多くの処理を行うバッファとして機能する形になるわけです。
Apacheでリバースproxyを構築する場合は、mod_rewriteとmod_proxyを使います。
前のページ
1
2
著者プロフィール
株式会社はてな 伊藤 直也
取締役最高技術責任者
ブログサービスやソーシャルブックマークなど、はてなの各種サービスの企画、開発を行う。著書に「BlogHacks」（オライリージャパン刊）。「続・初めてのPerl」(オライリージャパン）、「Perl救命病棟」(翔泳社刊）では監訳を務めた。
INDEX
第3回：Backend Evolution（前編）
Backend Evolution
Webサーバーのメモリ使用率
