負荷の傾向とチューニングポイントベンチマークおわりに今回はConoHaのロードバランサーを使って、1000req/secをさばけるWordPressのクラスタ構成を作ってみます。WordPressの負荷軽減策やスケールアウトはよく語られるテーマではありますが、今回はロードバランサー、イメージ保存、1Gbpsのローカルネットワークなど、ConoHaならではの機能を使って構築してみます。その際のチューニングポイントなども解説します。こちらはConoHa以外の環境でもきっと有用だと思います。このページではあまり限界性能を引き出すチューニングを目指すのではく、実際に皆様がConoHa上でクラスタ構成を構築する際に、どういう構成を作れば良いのか、どんなオプションを使えば良いのか、スケールするにはどういうチューニングを行うのか、などの参考にしていただくのが目的です。WordPressは利用者も多く、PHPで書かれていてMySQLへの接続も必要な、かなり重量級のアプリケーションで、事例にするには良いでしょう。実際にConoHa上でVPSがどのくらい必要で、どのくらいのコストがかかるのか、ご参考になれば幸いです。今回の構成をご説明します。ロードバランサー、Webサーバー、DBサーバーという基本的な構成です。ConoHaのロードバランサーを使い、配下にWordPressの稼働しているWebサーバーを配置していきます。ローカルネットワークにMySQLサーバーを配置します。MySQL(5.5)という環境です。ロードバランサーはConoHaのロードバランサーを使います。これはL4ロードバランサーで、今回はラウンドロビンでWebサーバーにトラフィックを分散します。このロードバランサーは100万Req/secでも余裕で捌けるので、今回はボトルネックにはなり得ません(ロードバランサーの性能についてはまた今度。2GBメモリ)を使用しています。テストには運用環境に近いWordPressを使用WordPressもインストールしただけの状態では、負荷も低くベンチマークも良い結果が出ます。実際には、テーマをカスタマイズしてプラグインを入れて使われることがほとんどでしょう。今回はConoHaのオフィシャルサイトのWordPressをコピーしてきてそのまま使います。テーマもかなり作り込まれていますし、プラグインも多く使われています。負荷的にも一般的なWordPressサイトに近いと思います。実際、初期状態のWordPressとベンチマークを比較すると、倍以上負荷がかかっていました(後ほど掲載)。キャッシュは無効nginxやFastCGIのキャッシュの使用はWordPress高速化の常套手段ですが、今回はアプリケーションの負荷を見たいので、キャッシュ類は無効にしています。PHPも実行され、MySQLへの接続/クエリの実行も全てのリクエストで実行されています。PHPのOPCacheやWordPressのキャッシュ系プラグインはそのまま使っています。イメージ保存によるインスタンスイメージの複製ConoHaには「イメージ保存」というVPSのストレージをそのまま保存する機能があり、保存したイメージからは新規にVPSを作成することができます。今回の構成ではWebサーバを大量に複製する必要があるので、イメージ保存はとても便利です。ConoHaのAPIを利用することでVPS作成を自動化することができます。これにより、大量のサーバー構築を手間をかけずに行うことができます。2015年9月号にも書きましたので、良かったらご覧下さい。以下のURLからもご覧いただけます。負荷の傾向とチューニングポイント今回の構成でのチューニングポイントや設定値などをご紹介します。サイトの組み方にもよりますが、WordPressシステムの場合、最も多くCPU時間が必要になるのはPHPの処理です。MySQLに大きな負荷はかかりません。PHP自体の性能向上はあまりできません。OPCacheというオプコードキャッシュを入れたり、HHVMなどにする方法がありますが、取れる策はこれくらいでしょう。今回のシステムでは、Webサーバーの数を増やすことで性能向上を図ります。MySQLには大量のDB接続が来るので、Webサーバーが増えても接続エラーなどが出ないようなチューニングを行います。結論から言ってしまうと、Webサーバ30台でWordPressを1,000リクエスト/秒で捌くことができました。以下はそのときの設定とチューニングポイントです。php-fpmphp-fpmはPHPのFastCGI実装です。prefork型なので、基本的には子プロセスの起動数等の調整を行うことになります。MPMと同じような感じですね。Manager(FPM)/etc/php-fpm.confや/etc/php-fpm.d/などに設定があります。pm.max_spare_serversphp-fpmプロセスの並列数を調整します。ディレクティブの説明はPHPのマニュアルにあります。重要なのはpm.max_childrenで、これはphp-fpmのプロセス数の上限を決めます。増やすと並列数が上がり同時に処理できるリクエスト数が増えますが、増やすとその分メモリを食うのでトレードオフになります。基本的にはswapに落ちないように増やしていけば良いのですが、WordPressのように重いアプリケーションを動かす場合、先にCPUが頭打ちになることもあります。今回はCPUが3コアしか無いので、php-fpmのプロセス数20くらいでCPU占有率100%になりました。なると20以上に増やしても性能は期待できません。nginxここはボトルネックにはなりません。以下の設定以外は、デフォルトのまま使いました。今回MySQLサーバーは一つです。WordPressが発行するクエリは単純なSELECTばかりなのと、クエリキャッシュなども効きやすいので負荷はそんなに上がりません。HTTPリクエストの度にMySQLへ接続が来るので、コネクションの数はそれなりに大きくなります。MySQLのパラメータで気をつけるのはこのあたりでしょうか。back_logmax_connectionsはMySQLサーバに同時に接続できる上限値です。接続数が増えると当然メモリの使用量が増えるので、トレードオフを見ながら調整します。今回の構成では1500前後の同時接続数になりましたので、それより大きな値にします。thread_cache_sizeは、一度作成したスレッドをMySQLがキャッシュする数です。スレッドの作成は重い処理です。以下のように、負荷をかけながらThread_createdの値をチェックし、増加し続けているならこの値を増やす必要があるでしょう。一般的にもmax_connectionsと同じ数を設定するのが良いようです。sec)back_logはOSがTCP接続要求を受けつけてアプリケーションが処理する開始するまでのキューの長さです・・・。アプリケーションがlisten(2)で接続を受け付け、クライアントからTCP接続要求が来ると、それはカーネルのlistenキューに格納されます。このlistenキューの長さがbacklogです。接続要求はアプリケーションがaccept(2)するとデキューされます。backlogが一杯の状態で新規にTCP接続要求がきた場合(クライアントがSYNパケットを送った場合)、サーバー側はそれを無視します。そのためクライアントは何度かSYNパケットを送り、再送回数を超えた場合タイムアウトと判断します。再送回数は/proc/sys/net/ipv4/tcp_syn_retriesから取得できます。接続数が多いと、クライアント側でタイムアウトが増え、スループットが上がらないという問題になります。実際、backlogの変更をせずに負荷をかけてみたところ、MySQLサーバー側でSYNパケットの取りこぼしが発生しました。-sの以下の項目で確認できます。取りこぼしがなければ、これらの項目は現れません。droppedさて、backlogの設定は、MySQL側とカーネルパラメータの両方を変更する必要があります。MySQLのback_logはデフォルトで50、カーネル側は多くの場合128です。これは少なすぎなので1024にします。カーネルの方は設定値の2/3が使われるので、少し多めに設定します。thread_cache_sizeと併せて、my.cnfを設定します。1024カーネルパラメータの設定は/etc/sysctl.confに書きます。2048sysctlコマンドで設定を有効化します。1024これでSYNパケットの取りこぼしがなくなります。ネットワーク受信キューの調整もう一つ、今回のMySQLサーバーのように大量のパケットが届くサーバーでは、ネットワークの受信処理が1つのコアに集中し性能が落ちることがあります。以下は負荷をかけているときのMySQLサーバのtopコマンドの実行結果です。siとソフトウェア割り込みが多く、負荷の高い状態です。Steering)を使用することで複数コアに分散させスループットを上げることができます。RPSはNICのバッファから取得したデータをソフトウェア的に処理する前に複数CPUに分散してくれます。RPSについては以下のリンクなどを参照していただければと思います。(RPS)Linuxでロードバランサやキャッシュサーバをマルチコアスケールさせるためのカーネルチューニング設定は以下のコマンドで行います。CPU2となっています。今回はCPUが3コアなので0111の十進表現で7を設定します。4コアの場合は”f”になります。/sys/class/net/eth1/queues/rx-0/rps_cpusこうすると以下のように均等に負荷が分散されました。今回は3コアですが、コア数が多い場合は更なるパフォーマンス改善を期待できそうです。stベンチマークではベンチマークです。今回はwrkを使用しました。tool”とのことで、C言語で実装されていて、スケーラブルなマルチスレッドをサポートし、一つのマルチコアCPUで動作することを想定して開発されたツール、だそうです。Luaスクリプトでいろいろカスタマイズできるようですが、残念ながら私が知らないため試せてません。2h)-cで接続数、-tでスレッド数(並列数)、-dで実行時間を指定します。-latencyオプションで応答時間の統計が表示されるので、これも指定します。実行結果は以下のようになります。17.36MBベンチマーク結果は以下のようになりました。接続数200~300くらいに性能のピークがありそうです。それ以上になると応答時間が長くなってきます。全てのベンチマーク結果はこちらのGistをご覧下さい。VPS一台に対して行ったベンチマークはこちらで、37req/secくらいでした。台数に応じて性能が上がっていると思います。最後にWordPressをインストールしただけの状態のベンチマークはこちらです。67req/secほど出ています。これはConoHaのWordPressアプリケーションイメージを使い、PHPの設定だけ今回の環境に合わせたものです。テーマを作り込んでプラグインをインストールするだけでも、WordPress自体の負荷がかなり増えることがわかります。おわりにというわけで、ベンチマークとチューニングポイントなどをご紹介しました。ConoHaはイメージ保存やロードバランサーなど、Webアプリケーションをスケールアウトするのに便利な機能がそろっています。一方で、サーバーを増やしたときに、それに応じてきちんと性能が上がるような設定を行うのも、非常に重要になります。ボトルネックになるポイントを見つけるのは難しいこともありますが、このエントリが何かお役に立てれば幸いです。no-cache」と吐いていて一日無駄にしたりしました・・・。問題は解決できましたか?はいいいえご回答ありがとうございます。送信ご回答受け付けました。ご協力ありがとうございました。