Nginx リバースプロキシキャッシュサーバーの構築

関連タグ：1.Nginx Ingress Controller
2. Parse nginx logs

要約：内部ネットワークからインターネットへの接続リクエスト（VPN/NAT など）をプロキシするために使用されます。

プロキシサービスは、大きくフォワードプロキシとリバースプロキシに分けられます。

フォワードプロキシ：クライアントがプロキシサーバーを指定し、本来ターゲット Web サーバーに直接送信する予定の HTTP リクエストをプロキシサーバーに送信します。プロキシサーバーは Web サーバーにアクセスし、Web サーバーの応答をクライアントに返します。

リバースプロキシ：フォワードプロキシとは逆に、ローカルエリアネットワークがリソースをインターネットに公開し、インターネット上の他のユーザーがローカルエリアネットワーク内のリソースにアクセスできるようにする場合、プロキシサーバーを設定でき、そのサービスがリバースプロキシです。リバースプロキシサーバーはインターネットからの接続を受け付け、リクエストを内部ネットワークのサーバーに転送し、レスポンスを返します。

インターネットからの接続リクエスト：

1. nginx リバースプロキシ：Web サーバーのスケジューラ

1. リバースプロキシとは、プロキシサーバーがクライアントの接続リクエストを受け付け、ネットワーク上の Web サーバー（apache、nginx、tomcat、iis など）にリクエストを転送し、Web サーバーから取得した結果を接続をリクエストしたクライアントに返す仕組みです。プロキシサーバーは外部に対してサーバーとして機能します。

上記の図からわかるように、リバースプロキシサーバーは Web サーバーのプロキシとして HTTP リクエストを受け取り、リクエストを転送します。さらに、リバースプロキシサーバーとして、nginx はユーザーリクエストの内容に応じて異なるバックエンド Web サーバーにリクエストを転送できます。たとえば、静的コンテンツと動的コンテンツの分離や、nginx 上に複数の仮想ホストを作成し、ブラウザで異なるドメイン名（URL）を入力した際にバックエンドの異なる Web サーバーや Web クラスターにアクセスできるようにすることが可能です。

2. リバースプロキシの役割とは？

(1) Web サイトのセキュリティ保護：インターネットからのリクエストはすべてプロキシサーバーを経由する必要があります。

wKioL1jsz9yAHyulAABvTU4R-Ew435.png-wh_50

(2) キャッシュ機能の設定による Web リクエストの高速化：実際の Web サーバー上の静的リソースをキャッシュし、実際の Web サーバーの負荷を軽減できます。

wKiom1jsz-nwYDqSAABjrKK3l5E661.png-wh_50

(3) 負荷分散の実現：ロードバランサーサーバーとしてリクエストを均等に分散し、クラスター内の各サーバーの負荷を均衡させます。

wKiom1jsz__Q7RpoAAJQnYSWdA8640.png-wh_50

2. nginx とは

1. nginx の概要

Nginx は軽量な Web サーバー、リバースプロキシ、およびメールプロキシサーバーです。安定性、豊富な機能セット、シンプルな設定ファイル、およびシステムリソースの低消費で知られています。Nginx（「エンジンエックス」と発音）は、ロシアのプログラマー Igor Sysoev によって開発されました。当初はロシアの大規模ポータルサイト兼検索エンジン Rambler（ロシア語：Рамблер）で使用されていました。このソフトウェアは BSD 互換ライセンスでリリースされており、UNIX、GNU/Linux、BSD、Mac OS X、Solaris、および Microsoft Windows で実行できます。

Nginx の適用状況

Nginx は既にロシア最大のポータルサイト Rambler Media（www.rambler.ru）で稼働しており、ロシアの仮想ホスティングプラットフォームの 20% 以上が Nginx をリバースプロキシサーバーとして使用しています。

中国では、Taobao、Sina Blog、Sina Podcast、Netease News、Liujianfang、56.com、Discuz。、Shuimu Community、Douban、YUPOO、Domestic、Xunlei Online などの多くのウェブサイトが、Nginx を Web サーバーまたはリバースプロキシサーバーとして使用しています。

2. Nginx のコア機能

(1) クロスプラットフォーム：Nginx はほとんどの OS でコンパイルして実行でき、Windows 版も提供されています。

(2) 設定は非常にシンプル：簡単に使い始められます。

(3) ノンブロッキング、高い同時接続数：公式テストでは 50,000 同時接続をサポートし、実際の本番環境では 20,000〜30,000 同時接続で稼働します。（これは Nginx が最新の epoll モデルを採用しているおかげです。）

注：

Web サーバーについて、まずリクエストの基本的な流れを確認します。接続の確立 - データの受信 - データの送信です。システムレベルでは、上記のプロセス（接続の確立 - データの受信 - データの送信）は読み取りイベントと書き込みイベントとして処理されます。

ブロッキング呼び出し方式を使用する場合、読み取りイベントと書き込みイベントが準備できていないと、待機するしかなく、現在のスレッドはサスペンドされ、イベントが準備できたときにのみ読み取りと書き込みを実行できます。

ノンブロッキング呼び出し方式を使用する場合：イベントは即座に返り、イベントがまだ準備できていないことを伝えてきます。しばらくしてからイベントを再度チェックし、準備ができるまで確認します。その間に他の処理を実行でき、イベントの準備ができたか確認しに戻ります。ブロックはされませんが、イベントの状態を随時確認する必要があり、より多くの処理を実行できる一方で、オーバーヘッドも小さくありません。ノンブロッキング呼び出しとは、結果が即座に得られない場合でも現在のスレッドをブロックしない呼び出しを意味します。

(4) イベント駆動型：通信メカニズムは epoll モデルを採用し、より大規模な同時接続をサポートします。

ノンブロッキングはイベントの状態を絶えずチェックすることで読み取り・書き込み操作を実行するかどうかを判断しますが、これにより大きなオーバーヘッドが生じるため、非同期ノンブロッキングイベント処理メカニズムが導入されました。このメカニズムにより、複数のイベントを同時に監視できます。呼び出しはノンブロッキングですが、タイムアウトを設定できます。タイムアウト時間内にイベントが準備できていれば返ります。このメカニズムは、ブロッキング呼び出しとノンブロッキング呼び出しの上記 2 つの問題を解決します。

epoll モデルを例にとると：イベントが準備できていない場合、epoll（キュー）に入れられます。イベントが準備できていれば処理し、準備できていなければ epoll で待機します。これにより、大量の同時リクエストを処理できます。もちろん、ここでの同時リクエストとは未処理のリクエストを指します。スレッドは 1 つしかないため、同時に処理できるリクエストは当然 1 つだけです。リクエスト間を常に切り替えているだけです。切り替えは非同期イベントが準備できていないために能動的に放棄されたものです。ここでの切り替えにコストはかかりません。複数の準備済みイベントをループ処理していると理解できます。

マルチスレッド方式と比較して、このイベント処理方式には大きな利点があります。スレッドを作成する必要がなく、各リクエストが占有するメモリは非常に少なく、コンテキストスイッチも発生しません。イベント処理は非常に軽量で、大量の同時接続でもリソースの無駄（コンテキストスイッチ）を招きません。apache サーバーの場合、各リクエストに専用のワーカースレッドが割り当てられ、同時接続数が数千に達すると、数千のスレッドが同時にリクエストを処理することになります。これはオペレーティングシステムにとって大きな課題です。スレッドによるメモリ使用量が非常に大きく、スレッドのコンテキストスイッチによる CPU オーバーヘッドが非常に大きいため、パフォーマンスは向上せず、高同時接続シナリオではパフォーマンスが著しく低下します。

まとめ：Nginx は非同期ノンブロッキングイベント処理メカニズムを通じて、複数の準備済みイベントをプロセスで循環処理することで、高同時接続と軽量性を実現しています。

(5) Master/Worker 構造：マスタープロセスが 1 つ以上のワーカープロセスを生成します。

注：Master-Worker 設計モードは主に Master と Worker の 2 つの主要コンポーネントで構成されます。Master は Worker キューを管理し、リクエストを複数の Worker に送信して並列実行します。Worker は主に実際のロジック計算を実行し、結果を Master に返します。

nginx がこのプロセスモデルを採用する利点は何でしょうか？独立したプロセスを使用することで、互いに影響し合うことを防げます。1 つのプロセスが終了しても、他のプロセスは引き続き動作し、サービスは中断されません。Master プロセスは新しい Worker プロセスを速やかに再起動します。もちろん、Worker プロセスの異常終了はプログラムのバグによるものです。異常終了により現在の Worker 上のすべてのリクエストは失敗しますが、全体のリクエストには影響しないため、リスクが軽減されます。

(6) 低いメモリ消費量：大量の同時接続リクエストを処理する際のメモリ消費量は非常に小さいです。30,000 同時接続下で、10 個の Nginx プロセスでわずか 150 MB のメモリしか消費しません（15M×10=150M）。

(7) 内蔵ヘルスチェック機能：Nginx プロキシのバックエンドにある Web サーバーが停止しても、フロントエンドのアクセスには影響しません。

(8) 帯域幅の節約：GZIP 圧縮がサポートされており、ブラウザのローカルキャッシュ用ヘッダーを追加できます。

(9) 高い安定性：リバースプロキシとして使用した場合、ダウンタイムの発生確率は極めて低いです。

3. Nginx+apache による Web サーバークラスターの負荷分散構築

nginx のリバースプロキシ設定

nginx をリバースプロキシおよびロードバランサーとして設定し、キャッシュ機能を使用して nginx に静的ページをキャッシュし、バックエンドサーバーの接続数を削減し、バックエンド Web サーバーのヘルスチェックを行います。



wKiom1js0B-iFnITAACVfFt6894317.png-wh_50

1. nginx のインストール

環境：

OS: centos7.2

nginx: 192.168.31.83

apache1:192.168.31.141

apache2:192.168.31.250

zlib-devel や pcre-devel などの依存パッケージをインストールします。

[root@www ~]# yum -y install gcc gcc-c++ make libtool zlib zlib-devel pcre pcre-devel openssl openssl-devel

注：

proxy モジュールと upstream モジュールを組み合わせてバックエンド Web の負荷分散を実現します。

proxy モジュールを使用した静的ファイルキャッシュ。

nginx のデフォルトモジュール ngx_http_proxy_module と ngx_http_upstream_module を組み合わせます。

バックエンドサーバーのヘルスチェックを実装するには、サードパーティモジュール nginx_upstream_check_module も使用できます。

nginx-sticky-module 拡張モジュールを使用して Cookie セッションスティッキーネス（セッション維持）を実装します。

ngx_cache_purge を使用して、より強力なキャッシュ削除機能を実現します。

上記 2 つのモジュールはサードパーティ拡張モジュールに属します。事前にソースコードをダウンロードし、コンパイル時に --add-module=src_path オプションを指定して一緒にインストールする必要があります。



nginx のインストール

[root@www ~]# groupadd www #www グループを追加

[root@www ~]# useradd -g www www -s /sbin/nologin #nginx 実行用アカウント www を作成し、www グループに追加。www ユーザーのシステムへの直接ログインを禁止

#tar zxf nginx-1.10.2.tar.gz

#tar zxf ngx_cache_purge-2.3.tar.gz

#tar zxf master.tar.gz

# cd nginx-1.10.2/

[root@www nginx-1.10.2]# ./configure --prefix=/usr/local/nginx1.10 --user=www --group=www --with-http_stub_status_module --with-http_realip_module --with- http_ssl_module --with-http_gzip_static_module --http-client-body-temp-path=/var/tmp/nginx/client --http-proxy-temp-path=/var/tmp/nginx/proxy --http-fastcgi- temp-path=/var/tmp/nginx/fcgi --with-pcre --add-module=../ngx_cache_purge-2.3 --with-http_flv_module --add-module=../nginx-goodies-nginx-sticky -module-ng-08a395c66e42

[root@www nginx-1.10.2]# make && make install

注：nginx のすべてのモジュールはコンパイル時に追加する必要があり、ランタイムで動的にロードすることはできません。

4. 負荷分散のその他のスケジューリング方式：

ここでは、nginx の負荷分散モジュールがサポートするその他のスケジューリングアルゴリズムを紹介します。

ポーリング（デフォルト）：各リクエストは時系列順に異なるバックエンドサーバーに 1 つずつ割り当てられます。バックエンドサーバーが停止した場合、障害のあるサーバーは自動的に除外され、ユーザーのアクセスに影響はありません。weight はポーリングの重みを指定します。weight の値が大きいほどアクセス確率が高くなり、主にバックエンドの各サーバーのパフォーマンスが均一でない場合に使用されます。

ip_hash：各リクエストはアクセス IP のハッシュ結果に基づいて割り当てられるため、同じ IP からの訪問者は同じバックエンドサーバーにアクセスでき、動的 Web ページのセッション共有問題を効果的に解決します。もちろん、このノードが利用できない場合は次のノードに送信され、その際にセッション同期がない場合はログアウトされます。

least_conn：現在のアクティブ接続数が最も少ない実サーバーにリクエストが送信されます。weight の値も考慮されます。

url_hash：この方式はアクセスした URL のハッシュ結果に基づいてリクエストを割り当てるため、各 URL は同じバックエンドサーバーにルーティングされ、バックエンドキャッシュサーバーの効率をさらに向上させます。nginx 自体は url_hash をサポートしていません。このスケジューリングアルゴリズムを使用する場合は、nginx のハッシュパッケージ nginx_upstream_hash をインストールする必要があります。

fair：上記 2 つよりも高度な負荷分散アルゴリズムです。このアルゴリズムはページサイズと読み込み時間に基づいてインテリジェントに負荷分散を行います。つまり、バックエンドサーバーの応答時間に基づいてリクエストを割り当て、応答時間が短いサーバーを優先します。nginx 自体は fair をサポートしていません。このスケジューリングアルゴリズムを使用する場合は、nginx の upstream_fair モジュールをダウンロードする必要があります。

5. 負荷分散とヘルスチェック：

厳密には、nginx には負荷分散バックエンドノードのヘルスチェック機能はありませんが、デフォルトの ngx_http_proxy_module と ngx_http_upstream_module の関連ディレクティブで実現できます。バックエンドノードが障害を起こした場合、自動的に次のノードに切り替えてアクセスを提供します。

weight：ポーリングの重み。ip_hash でも使用可能で、デフォルト値は 1 です。

max_fails：リクエストの失敗を許可する回数。デフォルトは 1 回です。最大回数を超えると、proxy_next_upstream モジュールで定義されたエラーが返されます。

fail_timeout：2 つの意味があります。1 つは 10 秒以内に最大 2 回までの失敗を許可すること。もう 1 つは 2 回の失敗後 10 秒間はこのサーバーにリクエストを割り当てないことです。

6. nginx のプロキシキャッシュの使用：

キャッシュとは、バックエンドサーバーからの js、css、画像などの静的ファイルを nginx が指定したキャッシュディレクトリにキャッシュすることです。これによりバックエンドサーバーの負荷を軽減するだけでなく、アクセス速度も向上しますが、キャッシュをタイムリーに削除することが課題となるため、ngx_cache_purge モジュールを使用して有効期限前に手動でキャッシュを削除する必要があります。

proxy モジュールでよく使用されるディレクティブは proxy_pass と proxy_cache です。

nginx の Web キャッシュ機能は、主に proxy_cache、fastcgi_cache ディレクティブセットおよび関連ディレクティブセットで構成されます。proxy_cache ディレクティブはバックエンドサーバーの静的コンテンツのリバースプロキシキャッシュを担当し、fastcgi_cache は主に FastCGI 動的プロセスキャッシュに使用されます。