こんにちは。Forkwell の中の人、大岡（おおか）です。
前回の記事「なぜ Forkwell はリリース初日にサーバダウンを繰り返したのか」の反響が大きく、一時はホッテントリに入るほどで正直驚きました。
Twitter や ブックマークコメント でご意見も多くいただいたので、今回はそれに対するフォローの記事を書きたいと思います。
一番多かったご意見は、
- 本当に Unicorn が悪かったのか。worker_proccesses の設定値が小さすぎただけじゃないのか。
- ちゃんと原因究明してないのに、Unicorn を悪者にするのは Unicorn がかわいそうです(´；ω；`)
といったものでした。
500エラーが頻発し出した午前11時すぎから、Passenger への入れ替えを決断した午後5時くらいまでの約6時間、私たちが行っていたのは Webサーバ、アプリケーションサーバ、DBサーバの設定値を片っ端から試してみて、エラーが起こらない最適値があるのかといった試行錯誤でした。
アプリケーションサーバである Unicorn ももちろんその対象であり、最初の worker_proccesses 値は4でしたが、この間に2〜128までのほとんど全ての2の乗数は試してみました。
それでも MissingAttributeError は、一向に止む気配すら見せませんでした。
それでも唯一効果があったのは、前回書いた通り Nginx の同時接続数を絞ったときに多少マシになったこと。
スタックトレースを見れば原因はわかるだろうと言われるかもしれませんが、低負荷時に全く起きなかったありとあらゆる全ての Model において脈絡なく上がってくるエラーの中身を読んだところで、何の見当もつきません。
また、「復旧後になぜそうなったのかちゃんと調査したのか」という疑問の声も聞かれました。
Unicorn にデバッグコードを入れて、JMeter 等で高負荷をかけてひとつひとつ紐解いていけば、それも可能かもしれません。
しかし正直なところ、Passenger でちゃんと動いているのでそこまでして Unicorn での不具合の究明にリソースを割けないというのが弊社の事情です。
Forkwell は必要最小限の人員で開発・運営していますので、日々のバグ修正、機能改善、新機能の追加、その他プロモーションのための施策等で現状は手一杯です。
それでも「自分なら原因を究明してみせる！」という方がいらっしゃいましたら、ぜひ弊社までお越しいただき、秘密保持契約を結んだ上で各種ログをお見せしますので（DBは見せられませんが）、どうぞお申し出ください。
次に Passenger について。
- Passenger に変えてうまくいったというのは結果論ではないのか。無条件に Passenger を奨めるのはどうかと思う。
というご意見がありました。
これについては、ユーザーの方からご紹介いただいたページが参考になると思います。
■ apache,nginx × passenger,unicornのベンチをとってみた - CubicLouve
こちらのページでは Nginx + Passenger の組み合わせは再ビルドが発生するので見送ったそうですが、Unicorn の worker_processes を60、Passenger はデフォルト設定で、
Apache + Passgenger ＞ Nginx + Unicorn ＞ Apache + Unicorn
というベンチマーク結果が出ています。
ここから推測するに、おそらく Nginx + Passenger の組み合わせがこの4つの中では最もパフォーマンスが高くなるものと思われます。
もちろんマシンスペックやその他の設定値によってこの結果が変わってくる可能性も否定できませんが、このような結果が出ている以上、Passenger に一日の長があるのはほぼ間違いなさそうです。
さらにこのベンチマークに使用したのはシンプルなアプリだったということですが、現状の Forkwell のような1アクセスで膨大なクエリーが発生するアプリでは Unicorn は単純なパフォーマンスの話だけでなく、DB接続周りに不具合が出てしまうのではないかというのが、今回のことから推察されます。
今回の Forkwell のような事態が起きたときに、ちゃんと原因を追求できるリソースが確保でき（理想としては専門のインフラエンジニアがいること）、サーバのリソースにも十分な余裕があるのであれば、Unicorn を使用するのも妥当な判断なのでしょう。
ただ弊社のようなスタートアップで全てのリソースに余裕がない場合、チューニングなしのデフォルト設定でそれなりのパフォーマンスを発揮する Passenger が無難なのではないかというのが大岡の言いたかったことです。
あと、どうも誤解を招いている点について補足説明したいと思います。
現在、Forkwell はいちおう安定運用できているのですが、「まだ重い」という声もちらほら聞こえます。
計測するとHTMLページ自体は400ms〜500msで返しており、速いとは決して言えませんが「重い」と言及されるほどのレベルではないようです。
これについて、「Forkwell 重いよ。ユーザーの声が信じられないのか」「『重くない』って、対策する気はないの？」のようなご意見がありましたが、そんなことは全くありません。
wget でトップの index.html（そんなファイルはありませんが、ここは便宜的に）をダウンロードしたときにかかるのが400ms〜500msということで、それ自体はエンジニアとしては遅いと思うが一般ユーザーとして考えるなら、他のサイトと比較してもそれほど「重い」とは言えない。
ただしブラウザでページが表示されるまでは早くて2500ms、遅ければ8000msもかかることがあり、それは単純にサーバが負荷に耐え切れずにパフォーマンスが落ちているからとか、膨大なクエリーをさばききれずに時間がかかっているからという問題ではなく、Facebook からのプロフィール画像のリダイレクト含みの読み込みや、各種静的画像やWebフォントおよびJSやCSSファイルの読み込み、レンダリングに使用している JavaScript ライブラリの実行等が大きく影響しているので、それについてはひとつずつ順次対応していくと。
そう申し上げたつもりだったのですが、言葉足らずで伝わらなかったようです。
Forkwell はこれからもパフォーマンス改善に向けて随時対応していきますし、それによりトップページももっと快適に閲覧できるようになるはずです。
先述したようにリソースが不足しているため、今日明日で目に見えて改善していくということはありませんが、それについてはどうか長い目で見ていただけましたら。
前回のお話のフォローはこのへんで。
私も忙しさにかまけて負荷テストを忘れてしまうような人間なのでこれからも至らぬ点が目につくかもしれませんが、ユーザーの方々にご意見いただくことでいっしょにこのサービスを育てていけたらと思っています。
