カテゴリー別アーカイブ: LAMP[Linux, Apache, MySQL, PHP]

　リリース前のサイトを本番環境でテストするとき、認証をかけたりするよね。
　DNSラウンドロビンとかLVSでバランシングしているときは、各ホストに.htaccessと.htpasswd書いたりするわけだけど、nginxでバランシングしている場合は、nginxの設定ファイルにまとめてかける。

server {
listen 80;
server_name hoge.tld;

location / {
auth_basic “auth”;
auth_basic_user_file “/usr/share/nginx/.htpasswd”;
proxy …
}
}

みたいな感じ。

nginxで認証を要求せず、裏のサーバが認証要求した場合には裏の認証要求が通る。
両方で認証を要求すると同じユーザ名：パスワードのセットで認証出来れば通るけど、それ以外の時は認証不能になる。

(336)

　バランシングのテストにお名前.com VPS(KVM)を3台契約して、1台をバランサ、2台をアプリケーションサーバ（Apace）として構築して試験中。

　デフォルト設定でNGINXを通すと、NGINX-Apache間がHTTP 1.0 Closeコネクションになるため、abとかで叩くとApacheのスレッドが大量に立ち上がる。　この状態だと、リクエストのたびに新しい通信が立ち上がってくるし、Apacheのプロセスが切り替わりまくるからパフォーマンス的に美味しくない。
　調べてみると、最近のNGINXではupstream.keepaliveのディレクティブを使うことで、裏の通信をKeepAlive接続にできるようになるので、早速導入して評価。

と、設定前に負荷試験。

abで同時接続100、10000回のGETを実行（400KBのHTML、GZIPで60KBになるファイル）
NGINXでGZIP/SSL処理してAPACHEにつなぐと、200requests/sec程度のスループットだった。

#nginx.conf

upstream appservers {
server 192.168.10.10:80;
server 192.168.10.11:80;
keepalive 1000;
}

server {
listen 443;
server_name _;

location / {
proxy_http_version 1.1;
proxy_set_header Connection “”;
proxy_pass http://appservers;
}
}

　upstream.keepaliveをセットするのと、proxy_http_versionを1.1に(KeepAlive実装)、proxy_set_headerでConnectionを空にする（デフォルトでは、Connection: closeを送信してしまうため）

　Apache側は

KeepAlive On
MaxKeepAliveRequests 1000
KeepAliveTimeout 15

としてみた。

　先と同じようにabを実行してみた結果、210requests/sec程度になった。　もともと、ネットワーク転送量がワイヤースピード近くに達していたため、速度的にはそれほど改善していない。
　しかし、サーバのリソース的には相当改善が見られた。　CPU使用率のSys値（ユーザプログラム以外の部分で消費される無駄）が低下した。
　重いアプリケーションを動作させている場合には、オーバーヘッドが低下する分だけ応答速度の向上が期待できそうだ。

(1965)

　Webサーバとしては使い慣れていることもあってApacheをずっと使い続けてきたが、細かい設定がしにくいという点があり、今回NGINXを使用することにした。
　ただし、今回はApacheを代替するわけではなく、Proxyとして利用することにした。
　バランシングのテストにはお名前.com VPS(KVM)を3台契約して実装してみた。

　まずは、基本のProxy構成。
　と言っても、何も難しいことはない。

server {
listen 80 default_server;
server_name _;

location / {
proxy_pass http://localhost:10080;
}
}

　これだと、NGINXがポート80で待ち受けて、すべてのリクエストをlocalhostポート10080に送る（Apache等をポート10080で待たせておく）
このままだと何も効果がないから、ここから色々追加していく。

location /php/ {
proxy_pass http://localhost:10080;
}
location /ruby/ {
proxy_pass http://localhost:20080;
}

　こうなると、/phpに来たリクエストは10080に、/rubyに来たリクエストは20080に行くので、apache + passengerを一つの入口で受けられるようになる。　localhostの部分を変えて、192.168.10.10とかにすれば、別サーバに流れていくから、一つの入口からアプリ単位で内部では別サーバで動かすことができる。

　更に、ロードバランシングも簡単に作れる。

upstream appservers {
server 192.168.10.10:80;
server 192.168.10.11:80;
}

server {
listen 80 default_server;
server_name _;

location / {
proxy_pass http://appservers;
}
}

　これで、来たリクエストは192.168.10.10と11に分配される。

　upstream.serverには簡単に重み付けが出来るので、

server 192.168.10.10:80 weight=5;
server 192.168.10.11:80 weight=10;

みたいにすることで、アプリケーションサーバの重み付けができる。

　さらに、スタンバイ構成も簡単で

server 192.168.10.10:80;
server 192.168.10.11:80;
server 192.168.10.12:80 backup;

とすると、10,11が応答しない時だけ12に振り分けることもできる（backupと書かれたサーバが正常時待機系となる）　10,11のいずれかが復帰すればbackupは待機状態に戻る。
VerisgnのSSL証明書はバランシングすると台数分の取得を要求されるが、ホットスタンバイ・コールドスタンバイであれば、同時に動作する台数分で良いのこんなかんじで設定できるのは便利。

　HTTPのgzip圧縮をNGINX側に任せられるので、アプリケーションサーバを本来の処理に専念させることもできる。

server {
listen 80 default_server;
server_name _;

gzip on;

location / {
proxy_pass http://appservers;
}
}

　また、SSL処理もNGINX側で行う事になる。

server {
listen 443;
server_name _;

ssl on;
ssl_certificate /etc/pki/tls/certs/ssl.crt;
ssl_certificate_key /etc/pki/tls/private/server.key;

location / {
proxy_pass http://appservers;
}
}

　NGINXでは帯域制限が容易にできるので、

location / {
proxy_pass http://appservers;
}

location /file/ {
limit_rate 2m;
proxy_pass http://appservers;
}

こんなふうにすると、file配下のダウンロードを2Mに制限できるので、ファイルダウンロードのせいでアプリが遅くなるみたいなことの解消が期待できる。

　また、制御構造を使って、

location / {
proxy_pass http://appservers;
if ($http_user_agent ~* “msnbot”){
limit_rate 1m;
}
}

みたいなこともできるので、BOT様の速度を制限して通常接続の帯域を確保できる。

　色々、更に便利な機能があるから、しばらく検証しよう。

(620)