nginxのworkerプロセス数をCPUコア数の倍数で自動的に設定できるモジュールを書いた

nginxはworkerプロセスの数をCPUコア（スレッド）数で決定するworker_processes autoという便利設定があります。

これが多用されているのは、nginxがノンブロッキングでリクエスト処理を行うため、コンテキストスイッチなどを考慮した場合に、コア数で立ち上げておけば効率よくCPUを使い切れるという前提があるからです。

一方で、例えば僕の用途では、現在画像の処理だったりとか、ngx_mrubyのようにリクエストの過程で一部ブロッキングされるような処理も増えてきているため、コア数以上の値に設定しておいた方が性能を発揮できるような状況も増えてきています。

そうなると、現状、非常に便利な設定であるauto設定を使えずに静的に数字を設定する必要があり、例えばサーバリプレース時には古いコア数を考慮した値になっていたりして、リプレース後にCPUのコア設定がそのままで性能が出せていないという事故が起きる場合もあります。また、だいたいCPUコア数の2倍ぐらいにしておけば、処理を効率的にさばけることがわかっていても、サーバのコア数に応じてworkerプロセスの値を静的に書き換えないと行けないこともあり面倒でした。

そこで、auto設定によってコア数を自動で取得した上で、そのコア数の何倍のworker数とするかをルールとして記述できるようにしておけば、サーバのコア数に依存しないworker数を定義できる上に、設定が動的になりメンテナンスしやすくなります。

ということで、論文の解放感から勢いで作りました。

github.com

設定はREADMEの通りで、例えばCPUコア数が4の場合は、autoで設定すると4個のworkerプロセスが起動します。そのような状況で、

worker_processes        auto;
worker_processes_factor 3;

のように設定すると、4コアの3倍の12個のworkerプロセスとして起動するようになります。

是非ご活用ください。

また、倍数だけでなく、autoで取得した値を色々カスタマイズできると良いなとは思っているので、何か案がありましたら是非PRを頂けるとマージします。

Webサーバのベンチマーク結果をレスポンスタイムの時系列データとして計測する簡単な方法

単純に特定のURLに対してミドルウェアの性能を計測したい場合などには、今でもabやwrk、h2loadのようなシナリオベースではないシンプルなベンチマークはとても有用です。

一方で、最近ではgatlingやtsungといった、豊富な機能やリッチな計測結果を取得できるベンチマークソフトウェアも豊富になってきました。

ただ、例えば、単に「Webサーバのベンチマーク結果をレスポンスタイムの時系列データとして計測したい」時に、僕のようなめんどくさがりの人間はcliで適当にオプションを渡して1回の実行でシュシュシュっと取りたいものですが、それができるツールが見当たらず、うーむ、gatlingやtsuningでやるかなぁとおもっていたところ、なんとApache Bench(ab)で簡単にシュシュシュっとできてしまうことに気づいたのでした。

ngx_mrubyで最初のHTTPSアクセス時に自動で証明書を設定可能にするFastCertificateの提案とPoC

Let’s EncryptやACMEプロトコルによるDV証明書取得の自動化に伴い、証明書の取得と設定が簡単になってきました。

一方で、ACMEをツール化したものが増えるに従って、ACMEってそもそもどういう動きになっているのか、とか、自分たちの用途でどういう使い方がありえるのかとかが余計にわかりにくくなってきており、どこまで自動化できるかもよくわからない場合が多いのではないでしょうか。

LinuxカーネルのTCPスタックとシステムコールの組み合わせによる手法よりも高速にポートのListenチェックを行う

まずは前回の記事で盛大な誤認をしていたことを訂正しなければなりません。

hb.matsumoto-r.jp

前回の記事では、高速にリモートホストのポートチェックを3パケットで実現する実装を行うために、RAWソケットとユーザランドの簡易TCPスタックを実装してパケットを放出しましたが、カーネルのTCPスタックによって自動的にRSTパケットが返されるため、RSTパケットが返されるよりもはやくrecvfromしないとSYN+ACKを受け取れないと述べました。

高速にリモートホストのポートがListenしているかを調べる

hb.matsumoto-r.jp

以下のエントリは一部誤認が含まれていたので、上記エントリにその旨をまとめましたので御覧ください。

---

とある事情でミドルウェア上から高速にリモートホストのポートのListenチェックをしたくなりました。ローカルホストのポートであれば、/procやnetlinkなどを使って素早くチェックする方法がありますが、今回は対象がリモートホストなのでソケットでなんとかする必要があります。

そこで、誰もがまず思いつくのは、connect()システムコールによってリモートホストのポートに接続しにいって、connectできればOK、できなければNGと判定する方法があり得るでしょう。（高負荷時に接続できないパターンはListenしていないと判定してよい）

自分のスタイルを作り上げること

小中高と自分のいた環境には、当時は悔しくて言えなかったけど、勉強についてはもうなんというか圧倒的な才能の差としか言えないような人達が沢山いた。

一緒に同じことをやっていても何もかもが速いし、理解力、そこから出す結果もすごかった。自分が楽しいと思えたことでも、多少の差は埋まってもその圧倒的差を埋めることは到底不可能に感じた。その頃から、ああ、こんなにも違う人達がいるのかをというを日々実感していた気がする。

だから今の僕は、ハッキリ言ってそういう意味で才能は無いだろう。いたって普通だろうという自覚はある。あの時の彼らが自分と同じように今ここにいて、同じ内容をやっていたら到底かなわないだろうと思う。

だから、僕がやれることはたった一つしかないと思っている。それは、自分がやると決めたことをとにかく継続的にやっていく、ただそれだけなのだ。周りを気にせず、一つのことを諦めずやり続け、そこから寄り道することがあったとしても全力で継続的に寄り道する。すると、玉ねぎの形のようなイメージで、下の芯からはじめた様々な寄り道が膨らみながら、芯の先でまた繋がり大きな実となる時が来る。芯が通ったその実がもたらす価値は線の繋がりとは比べ物にならないほどに自分に進化をもたらす。

人が持つ時間は一握りだ。だから僕は寄り道も含めて、やろうと決めたことをとにかく継続的にやり続けることに時間を使い続けるしかない。そうすると、そうやって思うがままに取り組んできたことが一つぐらいは実(身)になるかもしれない。それが自分だけのスタイル、自分だけの才能を作り上げることにもなるのだろう。

好きなことをして生きていくこと

実はとても難しいことなのである。

hb.matsumoto-r.jp

上記エントリで述べた通り、僕は結局コードを書き、コンピュータサイエンスを学び、フィードバックを頂きながら試行錯誤してOSSを作り続けることが好きで楽しいからずっと続けられているといった。でもそれは決して、好きなことだから楽に人生を過ごしてこれたというわけではない。好きなことだから仕事が楽であるわけでもない。

好きなことをして生きていくために、僕は大学の時から自分のキャリアを明確に定め、企業に就職した後に、そこで得た社内の評価、そして、毎月の給料を全て捨て、大学院の博士課程に飛び込んだ。その上、最初は審査で不合格になっている。なぜそれができたのか。それは、好きなことをして生きていきたいからだ。以前、その人生をキャリア・キーノートとしてまとめた。

技術者と研究者の狭間で得たたったひとつの教訓 2016 / career-keynote-2016 // Speaker Deck

好きなことをして生きていく。それは言いかえれば、自分の好きなことによって与える自分以外への影響とその価値を最大化することである。好きなことをすることで、身近な人が幸せになり、お世話になっている人々、そして、コミュニティや組織が幸せになり、自分自身もそこで得られる報酬によって生かされている。好きなことをして生きていくこととは、試行錯誤しながら、その道を模索し、学び、行動し続けることにある。時には、好きなことをするために、好きなこと以上に別のことをやらなければいけない時もあるだろう。でも、好きであるからこそ、情熱を持って行動できるであろうし、好きなことをして生きていく道を見つけられるかもしれないということを以前まとめた。

hb.matsumoto-r.jp

好きなことをして生きていくことはとても難しいと冒頭で言った。しかし、もし、幸運にも人生の中でその道を見つけることができたのであれば、自然と自分の生産性を最大化可能な生活が得られ、最後にはきっと幸せが待っているだろうと思う。是非ともそういう人達が増えることを願う。自分は何をやりたいのか、それを忘れてはいけない。