読者です 読者をやめる 読者になる 読者になる

おもしろwebサービス開発日記

Ruby や Rails を中心に、web技術について書いています

最近の Rack サーバ事情について

rails ruby

先月、heroku の推しサーバが unicorn から puma に変わったという発表がありました。unicorn だとスロークライアントの影響を受けやすいというのが理由なようです。

もう少し詳しく調べてみましょう。

そもそもスロークライアントってなに

その名の通り遅い回線のクライアントです。3G環境のモバイル端末などが該当します。

「unicorn だとスロークライアントの影響を受けやすい」とは

unicorn はプロセスモデルのサーバであり、blocking I/O モデルを採用しています。つまり、クライアントとの通信中プロセスが専有されるということです。

例えば unicorn がワーカプロセスを3つ立ち上げていて、そこへ通信完了に10分かかるようなスロークライアントが3つ接続されたら…、続くクライアントはスロークライアントの通信が完了するまで実行を待たなければならなくなります。プロセスの数をもっと増やせば対応できますが、それはその分メモリやサーバ台数、最終的には月額のサーバ費用に影響を与えます。

unicorn はなぜそんな設計になっているのか

unicorn は、「ひとつのことをうまくやる」unix哲学に則っており、その上で "バックエンドの" アプリケーションサーバとして作られています。

つまり、nginx などのリバースプロキシを前面にたてるのを前提とした作りになっているわけです。

The Philosophy Behind unicorn

リバースプロキシを使うと、unicorn はレスポンスをリバースプロキシまで届ければよくなります。リバースプロキシはたいてい同一ネットワーク内にあるので、とても早く通信できます。スロークライアントが通信するのはリバースプロキシです。これにより、スロークライアントが unicorn のプロセスを長時間専有するのを防ぐことができます。

nginx & unicorn は、heroku 以外の Rails アプリケーション環境では現時点で一番多い構成なのではないでしょうか。

heroku にはリバースプロキシはないのか

ないようです。ただ、heroku の HTTP Routing のドキュメントを見ると、1MB まではレスポンスをバッファしてくれるようですね。

HTTP Routing | Heroku Dev Center

puma に変更したら全て解決するのか

この発表このへんの文章を見ると、puma にしたらオールオッケーなように読めてしまいますが、そんなことはありません。

この記事 の Multi-threaded blocking I/O の箇所を読むと分かるのですが、確かにスレッドベースのサーバを採用すると、1スレッドがスロークライアントで専有されても別のスレッドが処理を受け持つことができます。ただし、全てのスレッドがスロークライアントと通信したら、結局同じことです。

同じメモリ量でも、プロセスベースのサーバより、スレッドベースのサーバの方が作成できるスレッド数が多いので、スレッドベースのほうがスロークライアントに強いということは言えると思います。

puma にすることによるリスク

puma はスレッドベースのサーバです。ということは、アプリケーションの書き方によっては race condition を引き起こす可能性があります。普通に Rails アプリケーションを書けばスレッドセーフになるはずですが、その辺りをよくわかっていない初心者が安易に手を出すのは危険なのかなと思います。

よくわからない人は Working With Ruby Threads を読みましょう。

unicorn の方が優っていることもあります。この間 ginza.rb で unicorn や puma などの Rack サーバのベンチマーク結果を比較をしました。結果としては、大量アクセス時の処理としては unicorn の方が puma よりも安定している印象でした。

「puma が不安定だ」とは思わないのですが、安易に「herokuが推奨してるからこれからは puma だ! unicorn はオワコン!」とならないようにリスクについても書いてみました。

まとめと雑感

基本的に、リバースプロキシのない heroku を使うのであれば、現時点では puma が適していると思います。しかしその場合はスレッドセーフなコードを書くよう気をつけなければなりません。

また、heroku 以外の環境ではリバースプロキシが使えるため、puma にすることのメリットは(heroku ほどには)ないと言えます。まだまだ nginx & unicorn の天下が続くのではないでしょうか。

リバースプロキシ内蔵のプロセスベース(スレッドベースにもできる)のサーバである raptor (passenger 5) 正式版ががそろそろリリースされます。以前の ginza.rb でベンチマークをとった時は beta2 だったのでまだまだ不安定な印象でしたが、正式版になって安定したら、heroku 環境での鉄板サーバになるかもしれません。

取り急ぎこのブログ(heroku & lokka)を passenger 5.0.0.rc2 にしてみました(注: はてなではなく、以前使っていたブログの時の話です!)。このブログは特にアクセス数が多いわけではないので高負荷時の安定性などはわかりませんが、とりあえず普通に動きますね。