サバフェス！に参加したという話

全くブログを更新してなかったので、このイベントに乗って更新してしまえ。

と思ったかどうかは別として、↓↓↓なイベントに参加しました。
http://serverfesta.info/?page_id=5
イベントの名前はサバフェス！で、Twitterのタグは #サバフェス です。

簡単に言うと、「アプリを触らずに5台使ってインフラだけで1週間使って何とかする大会」です。
で、今回のアプリはWordpressでした。
まぁ、アプリを触らずにインフラだけでっていうところがとっても憎いあんちくしょーな訳で。

「インフラで何とかしてください。（ｷﾘｯ」　っていわれる運用屋の日常を地でいったような大会で、
ﾄﾞMエンジニア日本代表としては、まさにど真ん中な状態であったわけです。

まぁ、結果的に10位近辺をうろうろとしてまして。。TOP10入り出来たかな？
というところだと思います・・・。

20万円の使い道として、游玄亭で焼き肉を食べて祝勝会をするって話までしてたので、
この落ちっぷりっていったらもう・・・・なんですが、とりあえず楽しかったです。

さて、今回も頼もしい仲間と一緒に参加しました。

いーすふるで参加する大会も今回で3度目。準優勝→圏外と来たので、
3度目の正直という事で強引なスケジュールでしたが、みんなで参加する事にしました。
1人がパッケージ、1人がソース、1人が解析と役割分担をして進めました。

で、やった事をざっくり書くと、
０．環境の整備
１．バージョン/パッケージの取捨
２．ベンチ対策/ベンチマークソフト作成
３．シングル構成でのチューニング
４．構成決定/環境構築
５．LB構成でのチューニングとLB変更
という感じだったと思います。

０．環境の整備
環境といってもgitでうんちゃらとか、Chefでうんちゃらっていうのはやっていません。
コミュニケーションツールとしてインストールマニアックスの時も活躍したChatworkを採用。
GoogleDriveを使用して情報の共有を行っていました。

しかしChatworkの神ツールっぷりは凄いですね。今更なにをって感じかもしれませんが。
ログとして残せて途中参加の人でも見れるというのが、とても助かってます。

今回は音楽にも勝手にこだわりました。Zardの負けないでを局所で流す事で、
ブレイクスルー出来ない間、なんとか自分に頑張れって。メンタルマネジメントをしました。

Youtubeで聞いてたんですが、いつの間にかに揺れる想いを聞き始めていて、
気付いたら中山美穂＆WANDSですよ。もうね、なつかしさに浸る訳で。これはまずいなと。

そうそう。モーツァルトをエンドレスで掛けまくってたんですが、これもダメですね。
モーツァルトの音楽って何も考えなくなるくらい凄いんですよね。もう、考えられなくなっちゃう。
逆に言えば、音楽に没頭しちゃうんですね。気付いたらモーツァルトでヘドバンしてました。
あー、これやべーなー。って思って、ホルモンに変えたんですけど、またヘドバンしてました。

この辺のパワープレイは結果的にperfumeに落ち着きました。あ、東京ドーム見に行きます★

とりあえず、普通のブログ1話分くらい書いておいて技術の話をまるでしてないですね。
半年ぶりの更新なので許して下さい。以下、技術をちゃちゃっと。

１．バージョン/パッケージの取捨
先ず、以下を最新のstableでソースからインストールしました。
Apache2.4、php-fpm（php5.5+zendopcache）、MySQL5.6で-c100でlocalhostでabしてみました。
Requests per second:    18.07 [#/sec] (mean)

っで、次にApache2.4をNginx1.5に変更すると、
Requests per second:    22.46 [#/sec] (mean)

ここまでは想定内。で、proxy_cache。
Requests per second:    10711.23 [#/sec] (mean)

まぁ、そうなりますよね。で、この状態で初日は3位でした。

これでいけるかなーと思いつつも、SSL等、入らないものは外していましたが、
適当にコンパイルしていたので、念のためパッケージでも確認。

チームメイトに確認してもらったところ、!!(⊃ Д)⊃≡ﾟ ﾟ　な結果に。
nginx1.4.4、php-fpm(PHP 5.4+zendopcache）、MySQL5.5.34
Requests per second:    26.49 [#/sec] (mean)

Nginx1.0系だと22.79程度まで下がったので、1.4にした効果は相当あった模様。

後述のベンチツールで比較してもパッケージの方が早かったので、
この結果から、基本的にパッケージ(殆どyum)で対応しようという話に。

最適なコンパイルオプションを考えるのがだるかったのと、
もし本当にテンプレ化された時に、運用も楽なのでパッケージを採用しました。

あ、zendopcacheのみソースインストールです。
git cloneで持ってくるとcheckoutしないとdev版が入るし、そもそも全てパッケージにした為、
gitをインストールする意味も無くなったので、普通にtarをwgetで持ってきてコンパイルしました。

２．ベンチ対策/ベンチマークソフト作成
ベンチ対策として負荷確認の為に、sysstatを1分更新にして、
psやnetstat、vmstatの状態を毎分取得するスクリプトを作ってcronに仕込みました。

ミドルウェアのログはWebサーバを慣れているapacheにしてログを詳細に記録。
MySQLはbinlog、slowlog全部だし。php-fpmも出しました。
この時点ではphpが重く、php-fpmのCPU使用が顕著でした。
解析してたチームメイトが独自のベンチマークソフトを作ってくれました。それを使用して確認しました。

３．シングル構成でのチューニング（最終日前日）
この状態でphpが重くてpostがネック！っていうのは解っていたので、
php-fpmのプロセス数を調整したり、mysqlのメモリ調整をしたりなどをしました。
EngineはMyISAMでもInnoDBでも変わらなかったので、InnoDBに変更しました。

４．構成決定/環境構築（最終日前日）
構成ですが、nginxのproxy_cacheよりvarnishの方が高速だったので、varnishにしました。
localhostに対して-c100のabをかけると、nginxだと10000～11000だったのが、varnishだと、
Requests per second:    15202.19 [#/sec] (mean)

14000～15000くらいで安定しました。もちろんvarnishもyumです。

負荷分散については
LVSが全員苦手で良いイメージが無いので、
書き込みと読み込みを分けるかも？という今後の展開を考えてhaproxyにしました。
これがこの後悪夢を生むことも知らず・・・。

kernelも最新だった3.12.1に変えてみましたが、苦労と時間の割に殆ど変らなかったので、
こちらも運用面や今後を考えて使用しませんでした。

構成は、3層+リバプロにしました。アクセス順で書くと、
LB： HAProxy
ReverseProxy： Varnish
WebServer： Nginx
AppServer： php-fpm
DBServer： MySQL
という構成で、Nginxとphp-fpmはUnixSocketで連携しようって話になったので、
Varnish～php-fpmをスケールアウトしていく方針にしました。

５．LB構成でのチューニング（最終日）
さて、HAProxyでバランシングしたのは良いんですが、Getが伸びません。
Postはスケールアウトした分だけ伸びるので、想定通り。ですが、Getが何をやっても伸びない。
modeをTCPにしようが、Listenにしようが変わりません。

GETスコアも80000位をいったりきたりしており、ここが壁となりました。
前述したZardの負けないで連発ポイントです。ほんとくじけそうでした。
気分転換に散歩してる時に思いついたのが、

１．そもそもGetの後にPostしてるんだからL7要らないよね？（今更感）
２．65536に近い値だったので、何かしらの上限に引っかかってる？

という２点。
とりあえず、TCP周りを少しいじって２の様子をベンチで見てみましょうという話に。
それから１を考えていくという方針になりました。

既にエラーとして出ていたsyncookiesを外したりportレンジ上げたり。
TIMEWAITの数を減らす為にtw_recycleとfin_timeoutを短くしたり。

net.ipv4.tcp_syncookies = 0
net.ipv4.ip_local_port_range = 10000
net.ipv4.tcp_tw_recycle = 1
net.ipv4.tcp_fin_timeout = 10

あとはopenfileまわりもすこしいじってdstatかけながらベンチを待ちました。

で、ここで想定外の事態。ベンチが来ないｗ
待てど暮らせどベンチが来ない。ビリージョエルベスト(1h10m)１周しても来ない。
New York State of mindをリピートし続けますが来ない。
そうこうしてるうちに何と計測時間終了・・・。3時間待ちでベンチ来ませんでしたorz

さあ、、、どうしようという話をしていたところ、
LVSはHAProxyの2倍以上の性能差との資料を発見。それからLVSにするという動きが活発に。
LVSでDSRをしてやればこの状況もブレイクスルー出来るのでは？

しかしながら、LVSでドハマりした経験ばかりの3人は空を見上げてました。

（あれ・・・・Applicationうんちゃらっていうテンプレートが使えたような・・・。）

レギュレーションを見直すと使えるって書いてありました。これ、使っちゃおうぜ。
って事で、LVSをこのテンプレートを使ってインストール。

WebUIもあって楽ちんに誰でもLB管理が出来て、対話方式でインストールできます。
これ、ほんと楽です。もうベンチが来なかった事は許しましょう！！ｗｗｗ
ここからLVSへの組み直しを実施。インストール後はデフォルトでDSRの状態。
iptablesの使い方まで教えてくれる親切っぷりでした。
今回のイベントって、これ使ってほしかったのかな？・・・・。

簡単にベンチをとってみると、明らかに数字が伸びていました。
今度はGETもスケールしただけ増えていきました。
ただ正式なベンチは終わった後だったので、実際どうなるかは解りませんが・・・
最後にブレイクスルーした？筈なので、何とか戦えた感があって良い終わり方でした。

寝ようと思った矢先、そういえばbeta版もダメだったよな・・・
APCuがbeta版でした。使ってないのにとりあえず入れたっていう訳わからない状態だったので、
APCuについてはコメントアウトして使用しないようにしました。
最後に再起動テストを行って完了！時間は5時でしたｗ

最終的な構成は以下の通り。

Web専用機 3台
DB+WEB機 1台
LB機 1台

Web構成(基本的にパッケージ)
-varnish(80/1180)
-nginx(1180/UnixSocket)
-php-fpm(UnixSocket)
-php54(zend_opcache)

Web+DB構成(基本的にパッケージ)
-varnish(80/1180)
-nginx(1180/UnixSocket)
-php-fpm(UnixSocket)
-php54(zend_opcache)
-mysql5.5

LB+web構成(基本的にパッケージ)
-LVS

やらなかった事や、やり残した事は以下の通り

１．varnish+nginxを複数インスタンス立ち上げる
GET時はvarnishのCPU負荷は20%程度だった為、ポートを変えてvarnish+nginxを増やしていけば
その分だけGETも増える筈です。煩雑になるし、そんな使い方しないよなっ。という理由で止めました。

２．オンメモリ化
M8インスタンスでメモリが売るほど余っていたので、当初は全てオンメモリにする予定でした。
ただし、突然落ちた場合にデータが消える等、運用上の様々の問題を考えると難しいかなと。
そもそもGETはcacheだし、MySQLもInnoDBにして殆どI/O負荷がなかったのでオンメモリ化も控えました。

３．ip_conntrackの設定
やらなきゃってタスクだしもしていたのにすっかり忘れてました。
いつもは機能分離で、FWは別にやらせてiptablesを起動する事自体が少ないのですが、
今回はiptablesを起動している事をすっかり忘れてました。普通に使えばハマらないのですが、
iptablesご使用の際にはきっと・・・になります（微笑）

４．LVSサーバの有効活用最後の最後に変更したため、色々移す気力がありませんでしたorz
本当はDBをLVSサーバに持って来て、WEB専用機をもう１台作ろうと思ってました。
かなり勿体ない事をしたかなと思ってます。

こんな感じで１週間を過ごしました。
Wordpressのインフラをここまで考えた事が無かったので、とても良い刺激になりました。
途中どうなるのか（微笑）っていうスコアも出てましたが、運営のベンチ変更は適切だったと思います。

次回はec-cubeあたりでしょうかｗ　次回のサバフェスでは今回をふまえてリベンジしたいと思います！