Yuya Takeyama

500 円玉貯金が N 万円貯まったので Thunderbolt Display を購入しました。
現在の開発環境の様子です。
画面が広いと Vim で複数ファイル広げたり、ファイル更新時にはその横でユニットテストが自動実行されたり、別のペインで tig や htop を実行しておくこともできるので便利ですね。
あとは最近少女革命ウテナ DVD-BOX を買ったんですが、これも大画面で観られるようになりました。

そんな大画面でつくった gem を紹介します。

Mr. Mongo とは

yuya-takeyama/mr_mongo

MongoDB の MapReduce の定義を Ruby の内部 DSL で記述し、実行するためのフレームワークです。
Ruby で、といっても map/reduce の関数は JavaScript です。

例えばワードカウントであれば、以下のような記述になります。

map/reduce を __END__ 以降に記述できるのが特徴です。
ここでは使われていませんが、finalize も同様に定義できます。

なお、__END__ 以降の読み込みについては先日開発した InlineTemplateLoader を使用しています。

何で DSL が必要か

ひとつは書き方・定義の仕方を統一するため、もうひとつはユニットテストのためです。

書き方を統一する

MongoDB 標準のやり方にしろ、各言語向けのドライバを使うにしろ、そのままだと人によって書き方がいろいろ異なります。
そこにこの Mr. Mongo を導入することで、「1 ファイル 1 ジョブ」というルールが強制されるようになります。

MapReduce をユニットテストするということ

MongoDB における MapReduce のユニットテストについては、ほとんど言及されることが無いと思いますが、やはり重要なんじゃないかと考えています。
上記のような単純なワードカウント程度の例ならともかく、大量のデータを、複雑に処理し、しかも長期的にメンテナンスを行うのであれば、回帰テストとしてのユニットテストが無くては安心できません。

また、テスト駆動で開発することでより効率よく開発できるケースもあるでしょう。

Mr. Mongo でどうユニットテストを書くか

これについては現状でもできなくはないのですが、フレームワークとしてのサポートがまだ貧弱な状態です。
mr_mongo-rspec-matcher なんてのを作って RSpec でのユニットテストをやりやすくする、というアイディアはあるものの、まだ実装できていません。

一応現在のコードベースでも MapReduce のユニットテストはできています。
MapReduce をオンメモリで実行し、その結果を連想配列と比較しています。

これをもっとフレームワークっぽいやり方でできるようになれば、いろいろ捗るんじゃないかと思っています。

あと、以前作った mongo_require.js を併用することで、MapReduce ジョブをある程度モジュール化して記述すれば、これもまたメンテナビリティに寄与すると思われます。

まとめ

MongoDB の MapReduce を効率よく開発・管理するためのフレームワーク Mr. Mongo について紹介しました。

おやすみなさい。

ちょっと CakePHP を使う機会があったのでソースコードを眺めていたところ、ちょいとしたバグが見つかりまして、すぐにパッチを書き Pull Request を行ったところ、ものの数時間でマージされました。

バグというのが、「alphaNumeric バリデータにおいて、改行で区切ってしまえばどんな文字列も通してしまっていた」ということです。

修正は以下の 1 コミットのみ。

Fix alphaNumeric validation · 14c81fe · cakephp/cakephp

preg_match や preg_replace をはじめ、PCRE を使った正規表現で、このような 1 行の文字列にバリデーションを行う際は、正規表現の修飾子として D (PCRE_DOLLAR_ENDONLY) を使用しないと、末尾の改行に対して検出漏れが発生してしまいます。

それどころか、m (PCRE_MULTILINE) なんてつけていると各行に対してパターンマッチングを行い、preg_match の場合はどれかひとつでもマッチすれば 1 を返すので、例えば以下のような文字列も OK、という恐ろしいことが起こってしまいます。

$result = preg_match('/^[\p{Ll}\p{Lm}\p{Lo}\p{Lt}\p{Lu}\p{Nd}]+$/mu', "abc\n<script>alert(1)</script>");
var_dump($result);
// => int(1)

あくまでユニットテストレベルでの検証ですが、このような恐ろしいことが起こっておりましたので、早いところ次のリリースが行われることを願うばかりです。
CakePHP 2.3.2 当たりで取り込まれることが予想されます。

こういう正規表現を書いていると徳丸先生方面から斧が飛んで来る可能性があります。
予め徳丸本等を読んで対策を行うことをオススメ致します。
あとは PHP のマニュアルとか PCRE 自体のマニュアルの PASSING MODIFIERS TO THE REGULAR EXPRESSION ENGINE 付近とか。
(なお、徳丸本の 81 ページによると ^ の代わりに ¥A を、$ の代わりに ¥z を使って、「行の」先頭・末尾ではなく「データの」先頭・末尾を示すようにせよ、とあります。)

なお、その他のバリデータも同様の問題をはらんでいる可能性もありそうですが、普段 CakePHP を使わない私としてはそこまで見切れないので、仕事等で CakePHP を利用している方は、是非とも contribute してみてはいかがでしょうか。

2 月はブログを書くことなく終わってしまいました。
3 月も半ばを過ぎようとしていますが、久々のブログ更新です。

ちょいとした Web アプリケーションを書くとき、やっぱり選んでしまうのは Sinatra。
とにかくサクっと作れるし、ファイルとかも少なくて済む。

中でもズボラ的に便利だと思うのがインラインテンプレートと呼ばれる機能です。
以下のように、プログラムの末尾にテンプレートをそのまま書けるというものです。

このインラインテンプレートがそれだけで gem 化されていれば、あらゆるフレームワークや DSL にこれを組み込めるのではないか、ということで作ってみました。

yuya-takeyama/inline_template_loader

inline_template_loader という名前で rubygems.org に登録済みですので、gem コマンドなり bundler なりでインストールできます。

使い方はこんな感じ。

InlineTemplateLoader.load でインラインテンプレートを Hash として読み込みます。

インラインテンプレートを読み込むファイルを load に引数として渡すこともできますが、省略時は caller を使ってバックトレースから呼び出し元を調べて、そのファイルから読み出すようにしています。

これを何らかのフレームワーク等に組み込む場合は、少し工夫が必要です。
普通は InlineTemplateLoader.load をラップして使うことになると思いますが、その場合は上記のように引数を省略してしまうと、ラッパーメソッドが存在するフレームワークのライブラリそれ自体からインラインテンプレートを読み込んでしまうことになります。

それだと困るので、引数に整数値を渡した場合は caller が返す配列のうち、整数値分だけ後の要素を呼び出し元とすることができます。

文だけだと訳がわからないと思うので、例を示します。

まずは DSL を用いた何らかのプログラム。
インラインテンプレートはこのファイルにあります。

次に InlineTemplateLoader をラップして何らかの処理を行う内部 DSL の処理系です。

このように load に整数値 (ここでは 4) を渡すことで、その文だけバックトレースを遡り、DslUsesInlineTemplateLoader.dsl の呼び出し元のファイルからインラインテンプレートを読むことができます。

来週あたりには、これを用いて MongoDB を操作する DSL なんかを紹介できればと思ってます。

そんじゃーね。

あけましておめでとうございます。
年末年始は実家にも帰らず、Kindle Paperwhite で本を読みあさったり、Hulu でプリティーリズムオーロラドリームを視て泣いたり、小林賢太郎の公演を DVD で視て笑ったり、あとは近所の土手を走ったりしてきました。
1km あたり 4 分をなかなか切れずにいます。

そんな感じでインプット中心に年末年始を過ごしてしまったわけですが、そろそろアウトプット期に転換していこうということで、みんな大好き fluentd に以下のような Pull Request を送ってみました。

Config DSL by yuya-takeyama · Pull Request #97 · fluent/fluentd

今のところ Proof of Concept レベルで、マージをお願いできるようなレベルにはなってないと思います。
こういうのどうっすかね、という感じで識者の皆様にコメントなど賜りたいと思っている次第です。

とりあえずは既存の設定ファイルも今まで通り使えるように、fluentd 起動時の -c オプションで指定した設定ファイルの拡張子が .rb だったときだけ、DSL として解釈するようになってます。

これによって fluent.conf は以下のような fluent.conf.rb として書けるようになります。

また、複数のサーバに転送する場合など、イテレータを使えれば、コピペ要らずで DRY な感じの記述ができます。

他にも、対象サーバの一覧を REST API から取得する、みたいな感じにしてみれば、fluentd のクラスタ構成の変更をする際は、サーバリストを管理するサーバに情報を登録して、各クラスタにシグナルを送って再起動すれば反映される、みたいな自動化も柔軟にできるんじゃないでしょうか。

さて、私自身は今のところ fluentd を使っているわけではなかったりします。
ここ最近はデータ分析・閲覧のための基盤を MongoDB や GrowthForecast 等を使って構築しているのですが、各サーバ感のログのやり取りが日次で rsync、という具合で、いちいち設定が面倒な上に、リアルタイム製にも欠けてしまいます。
そういう問題を解決する上で fluentd はすごく便利そうなので、今年はアレコレ調べたり contribute していければと思っている次第です。

それでは皆様今年もよろしくお願い致します。

MongoDB で使用する JavaScript 関数をモジュール化して Nodeunit でユニットテストしよう、という話です。

2012 年 12 月現在の Wikipedia によると MongoDB は CommonJS の処理系ということになっているようですが、CommonJS Spec Wiki にその名は見当たりません。
CouchDB は入ってるんですが。

MongoDB を CommonJS 処理系として見たとき、まず一番に辛いのが require 関数が無いことです。
(そもそも require が CommonJS の仕様において必須なのかどうかとかはよく知らない)

require が無くて何が困るかというと、MapReduce に使う関数なんかをモジュール化して書けないので、ユニットテストを書くのが困難、ということです。

そこで、MongoDB において JavaScript コードのモジュール化を促すものを作ってみました。

yuya-takeyama/mongo_require.js

MapReduce に使用するモジュールを作成する

mongo_require.js を使えば、CommonJS と同様のやり方で JavaScript モジュールを作成し、それを MongoDB 内で使用することができます。
それでは定番の WordCount をやってみましょう。

CommonJS のやり方に従って、exports オブジェクトのプロパティとして mapper と reducer の関数をそれぞれセットしています。
ちなみに、ここでは使用していませんが module.exports も使用できます。

これをモジュールとして読み込んで、実際に MapReduce を実行してみましょう。

まず、mongo_require.js を適当な場所に保存します。

そして、MapReduce を実行するのは以下のスクリプト。

はじめに mongo_require.js を読み込むことで、mongo_require() 関数を有効にします。
mongo_require() 関数は CommonJS の require 関数とほぼ同様に使用できます。

ここでの mr オブジェクトにはプロパティとして mapper と reducer それぞれの関数を持っているので、それをそのまま mapReduce 関数に渡しています。

実際に実行すると、以下のように正しく単語数が集計できていることがわかります。
ここではあらかじめ texts コレクションに文が入っていたものとしています。

このように、関数をモジュール化した上で、それを利用しての MapReduce ができました。

モジュールをユニットテストする

関数をモジュール化できたのであれば、それをユニットテストするのも容易になります。

ユニットテストには Node.js など、別の CommonJS 処理系の、既存のテスティングフレームワークを使用することができます。

フレームワークは何でもいいのですが、とりあえずシンプルなもの、ということで今回は Nodeunit を使用してみます。
個人的に Node.js でモジュールを書くときは Jasmine で BDD スタイルに書くのが好きですが、今回のようなシンプルなモジュールであれば、Nodeunit ぐらい素朴なフレームワークの方が向いているのではないでしょうか。

ここでのモジュールの読み込みには普通に require() 関数を使用します。

これを実行すると以下のような結果が得られます。

このユニットテストのポイントとしては以下が上げられます。

• Mapper 関数内で使用する emit() の大体となる関数をグローバル空間に定義している
• Mapper 関数をテストするアサーション関数として mapperEmits() 関数を定義している

mapperEmits() 関数は第一引数として Mapper 関数、第二引数として処理するレコードを受け取り、そのレコードを処理したときに emit() されるレコードが第三引数と一致するかをチェックします。
(emit() と mapperEmits() については npm でパッケージ化することを考えています。)

ところで、グローバル関数に依存したテストを書くことは、本来であればアンチパターンとされています。
例えば大規模なプロジェクトにおいてはグローバル関数は極力避けることが望ましいのですが、ここではひとつの MapReduce をひとつの小規模なプロジェクトとして考えています。
プロジェクトの規模が小さければ、グローバル空間汚染によるコンテキストの複雑化もそれほどは問題にならないでしょう。

Reducer 関数については、通常は入力値を元に値を返すだけの参照等価な関数なので、特にこういった特別な関数を用意せずとも deepEquals() 関数でアサーションができます。

まとめ

mongo_require.js を使って MongoDB で使用する関数をモジュール化する方法と、そのモジュールを Nodeunit でユニットテストする方法について紹介しました。

MapReduce は元々 Mapper と Reducer というシンプルな二つの関数の組み合わせで大規模な計算を行う、というアイディアのもとに考えられています。
このシンプルな関数さえ正しく動作することが保証できれば、多少複雑な集計も安心して実装することができますね。ハピラキ。

レガシーコードと戦っていると、「このコードのどこをどう通ってこういう結果になってしまっているのか」がわからなくなることがあります。

初見でコードを理解する能力は、コードを読んできた経験が多ければ多いほど、向上するものだと思います。
とは言っても、構造化やモジュール化が適切でなく、スコープの長大なコードなどは、人間の限界を超えているものもあるでしょう。

ステップ実行のできる IDE などを使う、という選択もあると思いますが、僕は重厚な IDE を好みません。
もっと楽にできる方法で、コードパスを解析する方法があれば、ということで作ってみました。

yuya-takeyama/code_path_analyzer

元になっているのは、仕事の時にコード中にベタ書きした関数です。
Gist に公開したところはてブが 10 ぐらい付いたのと、次必要になったときにすぐ使えるようにしておきたかったので、ライブラリ化しました。

使い方

Composer でインストールできます。

Composer を使っている場合は気にする必要が無いのですが、例えば PHP 5.2 などの環境で Composer やそのオートローディングの仕組みが使えない、という場合を想定して、ファイルツリーを適当に配置したら、./src/Yuyat/CodePathAnalyzer/Registrar.php 1 ファイルを読み込むだけで、他に必要な全てのファイルを読み込むようになっています。
パフォーマンスを気にするのであればオートローダを使いたいところですが、デバッグ時しか使われないので、それぐらいの妥協はいいんじゃないでしょうか。

解析対象のできるだけ先頭に以下のように記述すれば、そのファイルを解析することができます。

解析結果は以下のようなテキストファイルとして出力されます。

先頭に + (プラス) が付いているのが、実際に実行された行です。
これを見ることで、どのようにこのプログラムが実行されたのか、を把握しやすくなります。

仕組み

XDebug のコードカバレッジ解析の仕組みを利用しています。

Yuyat_CodePathAnalyzer_Registrar::registerDefault() の実行時に xdebug_start_code_coverage() を実行することで XDebug のカバレッジ解析を有効にするのと同時に、register_shutdown_function() で終了時に解析処理をフックするようにしています。
解析処理の中では xdebug_get_code_coverage() を実行することで収集した解析データを XDebug から取得し、CodePathAnalyzer の各コンポーネントが協調して結果の出力を行います。

出力形式の変更について

現在はテキストファイルへの出力のみに対応していますが、HTML 形式などに出力できたほうがより見やすいでしょう。

AnalysisHandlerInterface を実装したクラスを用意することでそういった拡張にも行えるようにしていますが、個人的にはテキストファイルだけで充分だったので、詳細は割愛します。
要望があればその辺の情報もちゃんとドキュメント化するかもしれません。 (めんどくさくてやらないかもしれません)

そもそもコードパスって…

完成してから気づきましたが、これを持ってコードパス解析、というのはどうかなー、という気がしています。
コードパスというのは「コードの経路」ですから、「この行は実行されたか」といった点の情報ではなく、「どのような順番で実行されたか」という線の情報だと思うので、これだとコードパスとは言えないんじゃないかなーと。

XDebug には IDE でのステップ実行のためのインターフェイスもあったと思うので、それを使って、例えば Socket.IO なんかでブラウザ上に表現できればよりかっこいい！なんていう気はするのですが、今のところそこまでのものは必要としていないので、多分作らないと思います。

まとめ

気軽にコードパス (?) を解析できる CodePathAnalyzer について紹介しました。
そんなに気の利いたツールではないですが、この程度情報があればちょっと楽になる、ぐらいのときに使っていただければ幸いです。

昨日の ParallelHttp の話に引き続き、PHP でのバッチ処理のパフォーマンス改善の話です。
あと、昨日と同じく PHP 5.2 で使えるライブラリを開発した話でもあります。

バルクインサートとは

ひとことで言えば「複数のレコードをまとめてインサートすること」です。

例えば MySQL で言えば、

INSERT INTO `users` (`name`) VALUES ('foo');
INSERT INTO `users` (`name`) VALUES ('bar');
INSERT INTO `users` (`name`) VALUES ('baz');

ではなく

INSERT INTO `users` (`name`) VALUES ('foo'), ('bar'), ('baz');

というようにやることです。

これで何が嬉しいかというと、サーバにクエリを投げてその結果を受け取って、という往復が少なくて済むので、その分効率よくたくさんのレコードを INSERT でき、実行時間が節約できます。

このように手書きで SQL を書く分には何てこと無いですが、プログラムの中でやるとなると微妙に面倒だったりします。

バルクインサート専用ライブラリ Bulky

というわけで作りました。

yuya-takeyama/bulky

Bulky は DB へのバルクインサートだけを行うためのライブラリです。
SELECT や UPDATE といったことは一切できません。

Perl とかだとバルクインサートのできるライブラリがいくつか見つかるのですが、PHP だと今のところ見つけられてません。
皆さんどうやっているんでしょうね。

Bulky を使うと、以下のように一見バルクインサートを思わせないコードで、バルクインサートを実行することができます。
この例では、10 万件のレコードを 50 件ずつバルクインサートしています。

Bulky によるバルクインサートの仕組み

$queue->insert() メソッドを読んだ瞬間は実際の INSERT は実行されません。
とりあえずはキューに溜めて、設定した数 (ここでは 50) に達したタイミングで自動的に $queue->flush() メソッドが呼ばれて 50 件分のバルクインサートが実行されます。

50 件に達しなかった場合も、$queue->flush() を明示的に呼べばキューに溜まっている分だけのレコードをバルクインサートします。
仮に明示的に呼ばなかったとしても、デストラクタで $queue->flush() を実行するようになっているので、暗黙的に全てのレコードが INSERT されるようになっています。

Bulky でのエラーハンドリング

上記の例では、$queue->insert() 呼び出し時にエラーハンドリングを行っていません。
何故かというと、そもそもできないからです。
$queue->insert() は特に値を返しません。
(引数のレコードのカラム数が一致しなければ例外は投げます)

INSERT が成功したかどうかは実際にバルクインサートが実行されるまでわかりません。
なので、予めエラーハンドラをコールバックとしてセットしておき、INSERT に失敗したときにはそれが呼び出されるようになっています。

バルクインサートでは 1 つでも失敗すると、そのクエリ中の全てのレコードが失敗になります。
この例でいうと、1 度の失敗は同時に 50 レコード分の INSERT に失敗したことになります。

エラーハンドラではその 50 レコード全てを配列で引数に受けるので、どのレコードの INSERT に失敗したのかをログに残すなりアラートを飛ばすなりできるようになっています。

MySQL 以外への対応について

この記事のタイトルには MySQL としていますが、Bulky の設計上は特に MySQL には依存していません。

DB 操作それ自体には様々なライブラリを使用できるよう、GoF パターンでいうところの Adapter Pattern を用いて実装しています。
現在のところは PdoMysqlAdapter というアダプタだけが実装されていて、これを使えばデータベース操作は PDO によって行われます。

PDO は様々なデータベースの差異を吸収してくれる組込みライブラリですが、敢えてここで MySQL としているのは、僕が他の DBMS でのバルクインサートをやったことが無いからです。
DBMS によっては同じ形式のクエリでは動かないかもしれないし、動くかもしれない、ということでとりあえずは自分に必要な MySQL 以外については放置しています。

簡単なベンチマーク

Bulky を使うことでどれだけパフォーマンスに違いが見られるか、ということで簡単なベンチマークを行いました。

使用したサーバは仕事で使っている開発用サーバです。
開発用サーバとはいえ、そのサーバ内ではいろんなものが動いていて、無風状態とは言えない適当なベンチマークなので、その辺りはご了承ください。
マシンの詳細なスペックも省略します。

また、適当なので time コマンドを使って、PHP スクリプトの実行時間を計測しています。
スクリプトの実行前には予め対象テーブルを TRUNCATE しているので、一応は平等な条件のもとで計測しています、と言えるんでしょうか。

まずは通常の INSERT の計測です。
何てことは無い、PDO でベタ書きの INSERT 文を実行するだけのものです。

結果は 1m25.381s、約 1 分半もかかってしまいました。

以下は、最初に掲載したサンプルコードを元に、バルクインサートの単位だけ調節しつつ計測したものです。

この環境では同時インサート数 50 前後でのバルクインサートが一番処理時間が短く、それより多くても少なくてもより多くの処理時間がかかってしまうことがわかります。

予想としては 500 や 1000 ぐらいが一番効率いいんじゃないか、とか思っていたんですが、意外と少ない方がいいようです。

詳しい検証は全くできていませんが、同時インサート数が多いときは何がネックになっているんでしょう?
クエリの組み立てロジックが適当なので、そこら辺の文字列操作がネックになっているのかもしれません。
または、MySQL サーバ側でも、あまりクエリが大き過ぎるとかえって非効率になったりするんでしょうか?

ともかく、今回の場合は同時インサート 50 のときのパフォーマンスで充分だったので、とりあえずはこのまま実運用に投入する方向で検討しています。

Bulky を使ってみる

ParallelHttp と同様、Packagist に登録してあるので、Composer を利用してインストールできます。
Composer をよく知らないという方はこのあたりの資料をご覧ください。

まとめ

MySQL による大量の INSERT を高速化する方法と、それを手軽に実現するライブラリ Bulky について紹介しました。

仕事でコードを書く機会が減りつつある今日この頃ですが、休日にこういう便利で着実に効率の上がるライブラリを開発しつつ、日々の仕事にフィードバックしていくのが 20 台後半に差し掛かった自分なりの生存戦略かなぁと考えています。
あと、今回は要件が PHP 5.2 だったのでニッチな感じになってしまいましたが、チャンスがあれば割とイケイケな OSS 方面にももっと貢献していきたいと考えているので、皆様今後ともよろしくお願い致します。
(React の件いろいろ放置してて本当に申し訳ございません…)

最近は Admiral Sir Cloudesley Shovell というバンドの 1st フルアルバム Don’t Hear It… Feat It をよく聴いています。
Sir Lord Baltimore のような、骨太なリフと、ブルージーでドラマ性もある楽曲が魅力のバンドですが、現在進行形で活動中のバンドです。
ストーナーロックとか好きな人は是非。

ここから本題です。
あるところに、Web API を数十万回単位で叩きまくる、PHP で書かれたバッチプログラムがあったとしましょう。
処理件数が増えるごとに処理時間が増大するので、いつしか 1 日経っても終わらないようになってしまいました。

そのプログラムは HTTP リクエストを直列に行っていたので、それを並列化させれば何とかなるのではないか、と考えて作ったのが以下のライブラリ。

yuya-takeyama/parallel_http

念のため書いておくと、全然プロダクションレベルにはなってないので、その辺りは自己責任でご利用ください。

試してみる

Packagist に登録しているので、Composer を使用してインストールすることができます。
Composer をよく知らないという方はこのあたりの資料を参考にすると良いのではないでしょうか。

composer install してやると EDPS (エディプス) というキラキラネームのライブラリも一緒にインストールされます。
これは Événement という PHP 5.3 または 5.4 以降で動作するイベントディスパッチャライブラリを 5.2 でも動くように移植したものです。

これを使えば、以下のように、Node.js ライクなコールバックスタイルで HTTP リクエストを行い、そのレスポンスを処理することができます。

PHP で並列 HTTP リクエストを実現する方法

PHP で並列に HTTP リクエスト、といえば curl_multi_* 系の関数がおなじみで、ちょっとググるだけでも以下のような記事が見つかります。

• PHPでマルチスレッド(バックグラウンド処理)を実現する方法
• APIとの通信効率をよくする実装例(1) curl_multi
• curl_multiでHTTP非同期リクエストを行うサンプル

今回作った ParallelHttp も同様に curl_multi_* 系の関数を使用しての並列リクエストを行っています。

また、僕は以前にも HTTP_Parallel というライブラリを作ったことがあって、これも curl_multi_* 系の関数を使用しています。
上記の記事は curl_multi_* 系関数の紹介ということもあって、わりとゴリゴリと実装されていて再利用しづらいので、オブジェクト指向なインターフェイスにラップしよう、というモチベーションのもとに作りました。

既存のやり方がダメだった理由

先に紹介した記事の方法や、それを応用した HTTP_Parallel では、今回の問題に対応することができませんでした。

これらに共通するのは、「リクエストは並列に行うが、レスポンスの処理は最後に全部まとめてやる」というところです。
HTTP リクエストが 1 つでも残っている限りは他のタスクを一切行わず、最後のレスポンスが返ってくるまでただ待ち続けることになります。

これではリクエストを並列化させているだけで、非同期処理とは言えないでしょう。

そこで ParallelHttp は以下のようなフローで HTTP リクエストと、そのレスポンスの処理を行っています。

1. イベントループにリクエスト情報とコールバックを登録 ($client->get($url, $cb))
2. イベントループを開始 ($loop->run())
3. 登録されたリクエストを同時に実行
4. 終わったリクエストが無いかチェックし、終わったものから逐一コールバックで処理、まだ終わってないものは引き続きチェック
5. 全てのリクエストが終了したらイベントループを抜ける

リクエストを待つ間に、先に処理できるレスポンスを処理することで、待ち時間を有効に活用することができます。
数 10 件程度のリクエストなら大した差は出ないと思いますが、今回のように数 10 万規模のリクエストを行うとなると、かなりの差が出ることが予想されます。

処理件数によるさらなる問題

レスポンスの処理を逐一行うことで、処理効率を上げられそうな感じがしてきました。
が、問題はその手前にありました。

前のセクションに書いた通り、イベントループを開始すると、登録されたリクエストを同時に実行することになるので、素直に実装するとものすごい数のリクエストが全て同時に行われてしまいます。

そうなると以下のような問題が発生します。

1. ものすごい数の処理を同時に実行するので、CPU 等のマシンリソースを大量に消費する
2. 対象のサーバが単一または小数だった場合には DoS 攻撃になってしまう
3. それ以前に全てのリクエスト情報とそのコールバックの分のメモリを確保する必要がある

これらについても解決しないと、今回の問題に ParallelHttp を使うことはできませんでした。

対策 1. 並列数を保てるようにする

同時に行うリクエストの数を設定として持たせ、最大でもその数までしか並列化させなければ、ローカルマシンにもリモートマシンにも優しくなります。

ParallelHttp ではイベントループの内部にキューを持っており、並列数が最大になるまでは curl_multi リソースにリクエスト情報を登録していきます。
curl_multi に登録したリクエスト情報が最大に達すると、その後のリクエストはとりあえずキューの中にためておいて、1 つでもレスポンスが返ってきたらそれを処理しつつ、キューから次のリクエスト情報を curl_multi リソースに登録する、という方法を採りました。

イベントループの生成時に以下のようなオプションを指定することで、並列数を指定することができるようになります。

デフォルトでは 10 になっているので、必要に応じて調節することで、さらなるパフォーマンスを得たり、マシンリソースに気をつけて処理を行ったりすることができます。

これで、前のセクションで示した問題のうち最初の 2 つが解決されました。

対策 2. リクエスト情報の登録を少しずつにする

最後に残るのは、リクエスト情報とコールバックのために、大量のメモリを確保する必要がある、という点です。

結論からいうと、これは ParallelHttp の実装だけで解決することはできませんでした。
そこで、ParallelHttp の使い方を工夫することにしました。

例えば、処理対象の URL がデータベースに 30 万件入っていて、それらの全てにリクエストを行う場合を考えてみましょう。

memory_limit の設定値等にもよりますが、普通は $loop->run() の手前で、メモリ使用量が上限を超えて強制終了になるでしょう。
URL 30 万件程度ならメモリを多めに確保しておけば何とかなりますが、ParallelHttp の内部で生成しているリクエスト情報を保持したオブジェクトであったり、コールバックに使う無名関数であったりでメモリを大量に消費します。

コールバックに使う関数が単一でよければループの手前で変数にいれておき、それをコールバックとして登録するようにすれば、コールバック分のメモリは節約できます。
ですが、クロージャを使用する場合等はリクエストごとにユニークなコールバックを生成することになるので、そういうわけにもいきません。

URL を一度にまとめて取得し、その全てをイベントループに登録するのではなく、少しずつの URL をイベントループに登録し、そのリクエストが全て終わった段階で新たに URL を登録していく… というのを延々繰り返すようにしてみます。

これは擬似的な例ですが、実際にこういうのを作ってみてとりあえず 1 週間はまともに動かすことができました。

ここで UrlIteratorIterator としているものについて、具体的に説明すると、外側のイテレータはデータベースから URL の一覧を LIMIT 1001 で取得し、1000 件分の URL を内側のイテレータとして返します。
LIMIT 1001 としたのはまだデータベース内に次の値があるかどうかをチェックするためで、1001 番目の要素に値があれば、オフセットを適当に指定しつつ次の 1001 件を取得する、といったことを繰り返しています。

まとめ

PHP 5.2 で動作する非同期 HTTP 処理ライブラリ ParallelHttp について紹介しつつ、その中で直面した問題と、その解決について説明しました。

高いパフォーマンスを得る上で非同期処理は大変魅力的ではありますが、それはそれで別の問題が生まれるので、一筋縄では行きません。
とはいえ、筋のいいライブラリであったり、実装パターンを使用することである程度は緩和することができるでしょう。

今回作った ParallelHttp については React や Node.js の標準ライブラリのコードを大いに参考にさせていただきました。
また、前にブログで紹介した AsyncMysql を実装した経験も大いに活かすことができました。

いろんな実装パターンを学んで、フレームワークや言語にとらわれないプログラミングスキルを身につけて行きたいと感じました。

特別何かする必要があるわけではないんですが、最新の php-build の master ブランチに 5.5snapshot の定義ファイルが入りました。
これで Generator や finally が使えます。
しかしながら World domination は含まれないことになりました。
残念でしたね。

GitHub 上の php/php-src の HEAD を .tar.gz で落としてきてるだけなので、運悪くビルドが壊れていれば入らないこともあると思います。

個人的には前にも紹介した方法で phpenv と連携させて phpenv install 5.5snapshot などとしてインストールしています。

なお、最新の php-build は GitHub 上の好きなリポジトリやブランチを選んでビルドできるようになっています。
例えば以下のような定義ファイルを /usr/local/share/php-build/definitions 辺りに入れてやれば、リスト内包表記の実装された魔改造 PHP がビルドできます。

また、php-build を最新のバージョンにアップグレードする方法については、以下の記事が参考になります。

phpenv+php-build環境の構築と運用

個人的には面倒なんでまっさらにインストールし直したりしています。 (特に秘伝の設定ファイルとか書いてたりするわけではないので)

取り急ぎ、報告までとさせていただきます。
以上、何卒よろしくお願い致します。

個人的な日記として書きます。
発表についてのフォローとかは特にありません。

去年に続き二年連続で枠をいただけたので、話してきました。

去年は 5 分間に 26 枚のスライドを詰め込みましたが、今年は 3 分間に 34 枚を詰め込みました。

内容については、今日たまたま見ていた PyCon JP 2012 の gevent についての発表が基礎からわかりやすく解説されていて素晴らしかったので、そちらを観るのがいいのではないでしょうか。
gevent と gunicorn については気になったのでソースコードを読んでみようと思いますし、コルーチンベースということなので PHP 5.5 なら Generator を使って同様のアプローチができないか、とかいろいろワクワクしてしまいますね。

他の方の発表を観た中では、最先端 Web 開発の話がダントツで良かったです。
特に「誰もこれない場所へ行くのではなく誰もがこれる場所を作る」というのは心に刺さる名フレーズだったと思います。
あとは Pull Request で仕事を進めていくのも凄くうらやましいですし、自分の会社でもそういう風にしていけたらと感じています。

ボクも元々はこういう日々の開発についての話がしたかったのですが、まだ自信を持って「成果があった」と言い切れる状態では無いので、他の人と被らなさそうなところで話を選んでみました。

この発表では「フルスタックフレームワークは夢」という話もあり、ボク自身も同じことを強く感じています。
最近は週末に単機能ライブラリを開発して GitHub に公開しておき、平日にそれを社内のコードベースに取り込む、みたいなことをしているのですが、諸般の事情によりいずれも PHP 5.2 で書かれているので、PHP 5.4 まで stable としてリリースされている今ではあんまりウケないんじゃないか、と思いました。
ところが今回のカンファレンスの基調講演によると PHP 5.2 はまだまだ使われているらしく (というかこのグラフ的には一番多い)、それらについても機会があれば話してみたいと思いました。

エンジニアになって 4 年目、勉強会で人前に出て発表するようになってようやく 1 年が経ちました。
(そういえば社外でまともに発表したのは去年の PHP カンファレンスが初めてでした)
振り返ってみると、便利なツールであったりフレームワークであったりの話ばかりで、より泥臭い実践的なノウハウについての話がほとんどできていません。
今の自分に足りないもの、そして仕事の中で求められているものはそこにある気がしているので、来年こそはそういう発表をしてみたいと思いました。
(それにはそれなりの成果が先立っている必要があるわけですが)

最後に、PHP カンファレンス 2012 のスタッフの皆様、素晴らしいイベントをありがとうございました。