【Webパフォーマンスチューニング】リバースプロキシの利用メモ

今まではユーザーのリクエストをそのままWebアプリケーションが受け付ける構成だったな。
しかし、そのリクエストをリバースプロキシというものをWebアプリケーションの前段に立てる構成の方が良いらしい。

そもそもリバースプロキシとは？

ユーザーのリクエストを受け取り、上位のサーバー(アップストリームサーバー)に転送する門番的なWebサーバー。

なぜリバースプロキシを使う構成の方が良いの？

• ロードバランシング: 複数のバックエンドサーバーにリクエストを分散できる
• ファイアウォール: リクエストが直接バックエンドサーバーに届く前にセキュリティ的に問題がないかをチェックする機能をリバースプロキシに配置できるので、セキュリティ的に良い
• TLS, SSL終端: クライアントから渡ってきた暗号化、復号の処理をリバースプロキシに任せられることで、バックエンドサーバーが暗号化、復号をする必要がなくなる
• キャッシュ: 頻繁に利用される静的コンテンツをキャッシュし、バックエンドで処理せずとも高速に一部のコンテンツを送信できる。

プロセスとスレッドとは

プロセス: 実行中のプログラムのインスタンス。
特徴として、独立したアドレス空間を持っている(他のプロセスで利用しているメモリにはアクセスできない)。
例) Webブラウザ(テキストエディタやメディアプレーヤーとは独立して実行されている)

スレッド: プロセス内で並行して実行される軽量な実行単位。
アドレス空間を共有しているので、同じプロセス内の他のスレッドとアドレスを共有できる
コンピュータが備えているCPUコア上で実行されるので、異なるスレッドが異なるコア上で実行されることが可能。
例) ブラウザ内のタブ(複数のタブを配置できる)

リバースプロキシを使うメリット
→ ネットワーク回線が遅いクライアントとの通信
ネットワーク速度が遅いクライアントに対してレスポンスを送信する際、時間がかかってしまう。
その送信処理をリバースプロキシが担うことで、バックエンドサーバーが送信のためにプロセスが占有されることがなくなる。
バックエンドサーバーは安定したネットワーク通信環境にいるリバースプロキシにレスポンスを送信すればそれで良くなる。