たごもりすメモ

コードとかその他の話とか。

Reverse Proxyがなぜ必要か、勝手に補遺

「全体のリソース効率を上げましょう」というためのものである。

Reverse Proxy がなぜ必要か - naoyaのはてなダイアリー

これは完璧に正しくて、ただ「リソース効率」という概念はあまり具体的な想像が追い付かない人がいそうだなと思ったので、ちょっとだけ補足しようと思った。

Reverse Proxyを入れることでリソース効率の向上を狙うんだけど、それは以下のような複数の場面におけるそれぞれのリソース効率向上を複合的に狙うものだ。

  • 通常時のトラフィック配信におけるCPU・メモリ使用率を最適化する
  • バースト時(過負荷時)のトラフィックをより細かく制御可能とする
  • 障害時におけるダウンタイムおよび総合的な計算・配信能力の低下を極小化する
  • 多数のサーバによる構成全体を増強・入れ替え・移動あるいは削減する際の自由度の向上を狙う

簡単にコンピュータの性能だけで言うと最初の項目だけをリソース効率の向上ととらえてしまいがちだ。
が、Webサービスが大規模になるとその裏側のサーバクラスタにおいては常に構成変更・障害・局所的過負荷などが起きており、そういった事態への対処というものを折り込んで全体のリソース使用状況を最適化する必要がある。

こういった状況において制御可能なポイントを増やしておく*1と、何かあったときの対処が非常にやりやすい。密結合のハイパフォーマンスサーバソフトウェアひとつよりも、疎結合のそこそこパフォーマンスサーバソフトウェアいくつもの組合せの方が、最終的に高稼働率・高スループット・低コストな環境を作りやすいのだ。
ということで、Webサービス*2が大規模化することを念頭に置くと、こういったことを考える必要がある。

逆に、用途や状況が限定されたケースであれば、こういったセオリーを無視した手が打てるケースもある。銀の弾丸は無いので、自分がいる状況、払えるコスト、世の中にある選択肢*3、そういったものを勘案して最適な手を選択したいものだ。

ということで

みんなもISUCONに出てそういうことを学ぶといいね! お前らの挑戦を待っているぜ!!! かかってこいや!

ISUCON4 オンライン予選の参加登録を開始しました : ISUCON公式Blog

*1:細かい機能ごとに役割分担を分けておく、と言ってもいい

*2:に限らずネットワーク通信によりサービスを提供しているケースはみんななんだけど

*3:関連する情報が周囲から得やすいかというのは重要なファクターだ