質問: さくらクラウドを利用しています。 元々はサーバー1台で稼働させていたのですが、ピーク時のスケールアウトのため、ロードバランサを用いて以下のような2台構成を試みたところ、1時間あたり5000PVを超えたあたりからWebサーバーの応答速度が非常に遅くなる(chromeのデベロッパーズツール->networkでTTFBが3秒以上)現象が発生し、その後PVの増加とともに応答速度の遅延時間が伸びていきました。 ただ、応答速度が遅くなるにもかかわらずサーバーA、サーバーBともCPU、メモリ、ロードアベレージ、DiskI/O等についてはサーバー監視ソフトのMuninで確認したところ、使用率が突出するといったことは見受けられませんでした。 追記: 当時のCPUのIO WaitとメモリのSWAPです。 [IO Wait(%)]サーバーA ・時間帯 4:50~5:50 特に動作に問題が無かった時間帯 Cur:2.93、Min:1.98、Avg:3.10、Max:4.39 ・時間帯 6:25~7:25 応答が遅くなっていた時間帯 Cur:1.84、Min:1.81、Avg:3.17、Max:4.61 [IO Wait(%)]サーバーB ・時間帯 4:50~5:50 特に動作に問題が無かった時間帯 サーバーBはこの時間帯記録の取得に失敗しておりました ・時間帯 6:25~7:25 応答が遅くなっていた時間帯 Cur:7.64、Min:4.80、Avg:6.34、Max:8.00 [SWAP(GB)]こちらはサーバーA,B共に0.00 ・時間帯 4:50~5:50 特に動作に問題が無かった時間帯 Cur:0.00、Min:0.00、Avg:0.00、Max:0.00 ・時間帯 6:25~7:25 応答が遅くなっていた時間帯 Cur:0.00、Min:0.00、Avg:0.00、Max:0.00 設定や構成等を見直せば改善するのか、そもそもnfsによるスクリプト&データの共有によるサーバー分散構成に無理があるのか、といった部分が判断できず質問させていただきました。 CentOS6.9でファイルシステムはext4を利用しています。 (以下IPアドレスはダミーです) 【さくらクラウド上のサーバースペック】 ・サーバーA CPU:20コア、メモリ:32GB ・サーバーB CPU:16コア、メモリ:32GB ・ロードバランサ ハイスペックプラン、冗長化なし 送信トラフィック: 1Gbps、受信トラフィック: 500Mbps、セッション数: 10,000、セッション、毎秒接続数: 3,000cps程度 【ディレクトリ共有に関する設定】 ・サーバーA(IP=99.100.101.1) Webサーバーとして稼働、またデータ(テキストファイルベース)とPHPスクリプトを格納。 /var/www/scripts/ ・・・自身の/var/www/scripts_src をnfsでmount /var/www/scripts_src/ ・・・ここをnfsにより共有。PHPスクリプトとデータが格納されているディレクトリ ※自身のディレクトリをnfsでマウントしている理由は、PHPのflockをサーバー間で機能させる目的です。 ・サーバーA側の/etc/exports設定 /var/www/scripts_src 99.100.101.*(rw,no_root_squash,async) ・サーバーB(IP=99.100.101.2) Webサーバーとして稼働、データやPHPスクリプトはサーバーAのものを使用 /var/www/scripts/ ・・・サーバーAの/var/www/scripts_src をnfsでmount ・サーバーA、Bの/etc/fstabによるマウント設定 99.100.101.1:/var/www/scripts_src /var/www/scripts nfs rsize=32768,wsize=32768,hard,intr,async 0 0 【その他】 ・なお上記構成前は、サーバーAの1台のみで稼働させており、50000pv/h程度でも問題なくさばけていたが、70000pv/h程度でCPUの頭打ちが出始めたため、上記複数台構成を検討しました。 他にも確認すべき点がございましたら、ご指摘いただければ幸いです。 【質問の修正履歴】 -Firewall Throughputとeth0 traffic、ロードバランサの「反映」に関する記述を見直しました -2台構成以前でのサーバーの応答状況を追記しました。 -サーバーAが自身のディレクトリをNFSでマウントしている理由につき、追記しました。 -質問文の構成を見直しました。 -サーバー監視にMuninを使用している旨を追記 -CPUのIO wait とメモリのSWAP状況を追記
回答: NFSを使用するということは * サーバーBの当該ファイルI/OがサーバーBのネットワークを経由してサーバーAのネットワークにも及ぶということ、つまりサーバーA・B双方のネットワークI/Oが増加する * サーバーAとしてもローカルアクセスからネットワークアクセスに変更されるため、ファイル操作の一つ一つにオーバーヘッドがかかるようになる * もちろんサーバーAはNFSサーバーとしての負荷もかかる という影響がでるわけですが、この辺りはご認識の上での設計かと思います。 その上で環境に目を向けますと、5000PV/hourつまり2PV/sec程度の処理にCPU 20コア・メモリ 32GBを要してなお足りないとのこと。根拠のない個人的な感想ですが、PHPスクリプトの処理がここまで効率が悪いとざるで水をすくうようなものでハードウェアをいくら増強しても解決しないような気がします。