PlackをProxyサーバーに使う意義

ircで聞いたときはうまく説明できなかった＆tokuhiromさん、Yappoさん、kazuhoさんに直接教えてもらったのでまとめとくなり。

Proxyサーバーを作ることになった。

こんな感じのやつ。

で、これの問題として対抗のサーバーの応答速度が遅い場合があってそこにProxyサーバーが引きずられる点がある。つまりクライアントからの毎コネクションが比較的長くなりがちなサーバーをいかに効率よく組むかという課題がある。

最初は勘違いして他のサーバーへの問い合わせの間に他のことをして全体の応答速度を速くする、つまり非同期化によるメリットを模索していたんだけど、1回の応答で他サーバーへの問い合わせがたくさんあるようなクローラーみたいなことをする場合はメリットがあるけど、基本的に1回の応答で他サーバーへの問い合わせは1回だし、コンテンツを持ってくる以外にも処理はあるけど、処理時間の多くはこの1回のコンテンツの取得なのでそもそもこの部分の非同期化の恩恵はあまり受けられない。これはちゃんと理解してなかったので馬鹿みたいな勘違いだった。

対抗のサーバーからの応答が遅い以上、コネクション毎の応答速度を上げることは無理なのは明白なので、同時接続数をなるべく多く確保できる仕組みが要求される。つまり1回のコネクションリソースが少ないもの、もしくはIO待ちが発生している時にリソースの有効利用ができるもの。

となると、preforkではなくマルチスレッドやノンブロッキングIOの上で動く軽量HTTPサーバーの検討に入ったときにPlackが目の前に転がっていた。今回の要件ではコンテンツを持ってくるだけじゃなくてさらに色々処理が発生するのでロジックをPerlで書けることも要件になっていたし、すでにCoroやAnyEventなどの実装を持っているPlackは非常に取っ付きやすかった。今回は単機能なProxyでディスパッチなどは必要ないため、Plackの上にWAFなどは作らず直接実装していくと思う。

ただ、ここで問題なのがユーザーからのリクエストを直接Plackのサーバーが受けられればいいのだが、SSLなどを受ける必要が出てきたときにPlack::Implでは実装しない場合、前にReverse ProxyとしてApacheなどを立てた場合、今度はここでの同時接続が問題となる可能性があるので、ここは考えていかなければいかないと思う。

全体的に理解が浅いしまだまだ勘違いしていることが多そうだけど、問題の局所化はできたので色々ベンチを取りながら色々試していく感じ。