38626


さくらクラウドを利用しています。

元々はサーバー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状況を追記


CC BY-SA 3.0
2017-10-12T02:58:07.970
38623
2017-10-14T01:16:16.000
2017-10-12T09:53:03.243
25729
25729
question
linux サーバー管理
ロードバランサを用いたWebサーバ複数台構成にNFSファイル共有を使用したが応答速度が遅い


NFSを使用するということは

  * サーバーBの当該ファイルI/OがサーバーBのネットワークを経由してサーバーAのネットワークにも及ぶということ、つまりサーバーA・B双方のネットワークI/Oが増加する
  * サーバーAとしてもローカルアクセスからネットワークアクセスに変更されるため、ファイル操作の一つ一つにオーバーヘッドがかかるようになる
  * もちろんサーバーAはNFSサーバーとしての負荷もかかる

という影響がでるわけですが、この辺りはご認識の上での設計かと思います。

その上で環境に目を向けますと、5000PV/hourつまり2PV/sec程度の処理にCPU 20コア・メモリ
32GBを要してなお足りないとのこと。根拠のない個人的な感想ですが、PHPスクリプトの処理がここまで効率が悪いとざるで水をすくうようなものでハードウェアをいくら増強しても解決しないような気がします。


CC BY-SA 3.0
2017-10-12T03:45:29.230
38624
2017-10-12T03:45:29.230
4236
38623
answer


**提案1**  
応答速度の改善につながるかは分かりませんが、サーバAについては  
自身をNFSマウントする設定は冗長な気がします。  
(サーバBと設定を揃えるためあえてそうしてるのかもしれませんが)

ローカルのディレクトリをマウント、もしくはシンボリックリンクで  
十分なのではないでしょうか。

**提案2**  
NFS共有するデータを最小限に絞る = 共通に読み書きする **データ** のみNFSで参照し、  
スクリプトは各マシンのローカルに置いてみる(必要時にrsync等で同期する)。


CC BY-SA 3.0
2017-10-12T05:02:39.357
38626
2017-10-12T05:02:39.357
3060
38623
answer


質問文は訂正済みですが、`eth0`の帯域使用量が80Mbpsと記載されていたので、サーバAとサーバB間の通信帯域が一杯のように予想します。(サーバ間の通信帯域は100Mbpsと(さくらクラウドのページからは)読み取りました)

＃1Gbpsなのは外部との通信帯域と読み取りました。

その場合、ネットワークサービスの追加契約等でサーバ間の通信帯域を広げるとよいかと思います。

＃理想的には、外部通信とは別のネットワークセグメントが設定でき、NFS通信はすべてそこを通せるとよいです。


CC BY-SA 3.0
2017-10-12T10:38:49.553
38642
2017-10-12T10:38:49.553
20098
38623
answer


NFS経由での

  * アクセスに伴うファイルやスクリプトの読み込み
  * 書き込みの排他制御

のどちらかまたは両方がボトルネックになっている、というのが単純に考えられる理由です。

しかし、PHPでファイルを操作する程度のWebサーバにしてはサーバのスペックが異常に高く、これが必要とされるものだとすると処理の規模や内容がちょっと想像出来ません。一方で、システム構成やネットワーク構成や性能情報は極断片的なものなので、回答も場当たり的なものにしかなりません。ひょっとすると全然別のところの問題かも知れません。

場当たり的な解決策で仮に解決できたとしても、早晩次のトラブル(ありがちなのはデッドロックかファイル破損)に見舞われるでしょう。

データの共有にはRDBMSを使う一般的なシステム構成に見直されることをお勧めします。


CC BY-SA 3.0
2017-10-14T01:16:16.000
38686
2017-10-14T01:16:16.000
5793
38623
answer