人間とウェブの未来

「ウェブの歴史は人類の歴史の繰り返し」という観点から色々勉強しています。

PHPが動くApacheのコンテナ環境をhaconiwaで1万個動かそうとしてみた

研究 運用

RubyKaigiに行くと本にサインを求められるすごいエンジニアが書いたhaconiwaというmruby製のコンテナエンジン（コンテナ環境構築の基盤ツール）があるのですが、少し試してみようと思って、とりあえず1サーバ上に1万コンテナぐらい動かそうとしてみました。久々に今回は自分の作ったOSSではなく、OSSの検証レポート的な記事になります。

haconiwaは僕の好きなOSSの一つで、それはなぜかと言うと、

  • haconiwaでコンテナを作る際に、haconiwa実行環境にはコンテナの要素機能が全て入っている必要はない
  • 必要なコンテナの要素機能を簡単に組み合わせて、自分が実現したいコンテナ、あるいは、それに準ずる環境を作れる
  • haconiwaによるコンテナ定義をRubyのDSLで表現でき、動的な設定や組み合わせの設定を簡単にかける

ということができるからです。その特性から、CentOS6のような比較的ライブラリが古い環境でも、要求に応じて簡単に動かす事ができます。

続きを読む

Pmilter: Programmable Mail Filter Serverを作った

プログラミング 研究

Pmilterというサーバソフトウェアを作りました。

github.com

PmilterはProgrammable Mail Filterの略で、SMTPサーバ（送信や受信）とmilterプロトコルで通信し、SMTPサーバの送受信の振る舞いをRubyでコントロールできるサーバソフトウェアです。

これまでにも、milter managerやRubyのgemを使ってmilterサーバを作るといった素晴らしいソフトウェアがありました。ですが、今回僕がフルスクラッチで作りたかった理由としては、

  • とにかくインストールや設定がシンプルで運用しやすいサーバソフトウェアにしたい
  • ミドルウェアとして振る舞いを設定する感覚でRubyで制御する事に専念したい
  • 依存ライブラリを減らしワンバイナリでサーバに配置できるようにしたい
  • 設定変更に再起動することなくRubyを変更するだけで振る舞いを変えられるようにしたい
  • インフラエンジニアも楽しく簡単にコードを書きながらメールサーバを運用したい
  • spamメールや踏み台などに対して独自のアルゴリズムを簡単に実装してメールキューに入る前にrejectしたい

などがあったのと、後はWebばっかりじゃなくてメールに関するソフトウェアもちゃんと作っておきたいなと思ったからです。

実際作ってみるとSMTPやmilterプロトコルを勉強することにもなって、すごく楽しかったです。

ということで、以下にpmilterの使い方を簡単に紹介します。

続きを読む

博士課程の予備審査にいってきました

思った事

僕が博士課程で研究していた「Webサーバの高集積マルチテナントアーキテクチャに関する研究」という内容で、僕が通っている京都大学大学院情報学研究科博士課程の予備審査にいってきました。研究室は岡部研究室になります。

予備審査は、僕が所属する大学院の場合、基本的には博士課程の研究で3本以上ジャーナルを通す事を条件に、内容的にも指導教員の許可が受けられれば予備審査へと進むことができます。

続きを読む

CPU使用率100％のWebサーバをOSのチューニングだけでCPU使用率20%まで改善する

Webサーバ 研究 運用

こんばんは、 @matsumotoryです。

hb.matsumoto-r.jp

上記エントリにおいて、プロセスの大量メモリ確保に伴うページテーブルサイズとベージテーブルエントリ数の肥大化によるcloneやexecveの性能劣化とCPU使用時間の専有問題、および、それらの解決方法についてシステムコールレベルで確認しました。

そこで今回は、システムコールやそのカーネル内部の処理の性能、というよりは、より実践的な環境であるApache httpdとmod_cgiを用いて、phpinfo()を実行するだけのCGIに対してベンチマークをかけた時にどれぐらいCPUのidleが空くか、システムCPUの使用量が変わるかを、前回示した解決方法の1つであるHugePagesを使うかどうかの観点で比較してみましょう。

特定条件下のWebサーバ環境のシステムCPUに起因する高負荷問題から、システムコールやカーネルのソースコードを読みながら根本原因の仮説をたて、それを前回エントリで検証してミクロな視点で効果を確認した上で、今回は再度実践的な環境で負荷検証を行って、OS・カーネルレベルの対応が全体として実践的な環境でどれぐらい効果があるかを確認したいという意図です。

続きを読む

特定条件下のclone(2)を4倍速くする

運用 Webサーバ

とあるサーバで妙にシステムCPUの使用率が高い現象が置きておりました。

そこで、まずはざっくりとperf topでプロファイルをとってみると、以下のようになっていました。

 22.38%  [kernel]             [k] copy_pte_range
 18.44%  [kernel]             [k] zap_pte_range
 11.13%  [kernel]             [k] change_pte_range
  3.58%  [kernel]             [k] page_fault
  3.32%  [kernel]             [k] page_remove_rmap

また、各プロセスのstraceを眺めていると、cloneで0.05秒とかなり時間がかかっているようです。これだと単純計算で1コアで秒間20回のcloneでコア100%占有してしまう程度の非常に低速な処理しかできないことになります。

sudo strace -T -o/dev/stdout -p pid | perl -ane '/<([\d\.]+)>/; print $_ if $1 > 0.01;'
...
clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0x7f97ea77ea10) = 7333 <0.051777>
clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0x7f97ea77ea10) = 7334 <0.053510>
clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0x7f97ea77ea10) = 7335 <0.053426>
...

このサーバはforkを沢山するサーバで、そのfork元のプロセスはRSSが2GBとかなりメモリ多めのプロセスとなっていました。単純にはこの時点で、fork時の中で呼ばれるclone(2)から何らかの形でcopy_pte_rangeなどが呼ばれ、そこで処理に時間がかかって、clone自体が時間がかかっている、と予想できます。

しかしなんだろこれ、ということでKernelのコードからその原因を調査していきました。

続きを読む

エンジニアが技術力を高めるもう一つの理由 - はてな・ペパボ技術大会を経て

思った事 発表

はてなさんと共催で行った「はてな・ペパボ技術大会＠京都」と「ペパボ・はてな技術大会＠福岡」が無事終わりました。

http://developer.hatenastaff.com/entry/2016/06/21/131302

ペパボ社内では、はてなサービスとその技術力の高さのファンが多く、はてなさんと一緒にこんな技術イベントできるなんて！！と喜んでいる人たちも沢山いましたし、僕自身もご一緒できてとても嬉しかったです。技術大会後の打ち上げも含めて、すごく盛り上がったしとにかく最高でめちゃくちゃ楽しかったです。

id:y_uukiさんをはじめ、はてなさんの若手エンジニアのスキルは圧倒的に高く、id:ichirin2501さん、id:masayoshiさん、id:taketo957さん、そして、技術大会で諸々沢山調整してくださった、id:wtatsuruさんとid:tomomiiさん、座談会をモデレータをやってくださったid:stanakaさんありがとうございました！

続きを読む