Julien Nioche氏が語るStorm Crawler - Apache Stormをベースとするオープンソースのクローラパイプライン

DigitalPebbleのディレクタで，Apache NutchWebクローラプロジェクトのPMCメンバ兼コミッタであるJulien Nioche氏が，StormCrawlerについての講演を行なった。StormCrawlerはストリーミングフレームワークであるApache Stormをベースとした，分散Webクローラ開発のための再利用可能なコンポーネントのコレクションだ。

InfoQはプロジェクトの中心的コントリビュータであるNioche氏にインタビューして，StormCrawlerに関する詳細と，同じ領域に属する他のテクノロジとの比較について聞くことにした。

InfoQ: StormCrawlerのメリットを活用できるのは，クローリング/スクラッピングパイプラインのどのステージなのでしょう？

Nioche: StormCrawlerはスケジューリングやフェッチ，構文解析，インデックス付けといったパイプラインのクローリングに関して，すべての主要ステージを実装するためのコードとリソースを提供します。Apache SolrやElasticsearch，MySQL，Apache Tikaといった，一般的に使用されているプロジェクト用のモジュールに加えて，XPathやsitemaps，URLフィルタリング，言語識別などでデータ抽出を行なう，さまざまな拡張機能を提供しています。

InfoQ: Apache NutchやPythonのScrapyのような，他のクローリングテクニックと比べた場合はどうですか？

Nioche: StormCrawlerは元々，私がApache Nutchを使用した経験の結果から生まれたものですので，コンセプト(FetcherBoltの設計，URL，Parseフィルタなど)やや初期の実装には多くの共通点があります。Nutchの機能を実装していますし，Nutch 2.xのように，さまざまなストレージバックエンド(HBase，Cassandraなど)を使用することができます。

StormCrawlerとNutchの最も大きな違いは，後者がApache Hadoopをベースとしている(そこから生まれたものでもある)ため，バッチ駆動である点です。URLフェッチングやコンテント解析やインデックス付けが，それぞれ別のステップで実行されます。このため，フェッチ時にはネットワーク使用率は高いがCPUやディスクの使用率が比較的低く，構文解析やインデックス付けではその逆になるのです。

一方のStormCrawlerは，ストリーム処理フレームワークであるApache Stormをベースとしているので，すべてのオペレーションを同時に実行することができます – URLは絶えずフェッチ，構文解析，インデックス付けされるため，クロールプロセスがより効率的であるとともに，バッチ指向では一般的な長時間のワークロードもありません。Nutchとは違い，コンテンツをディスクへ永続化する必要もありません(ただし必要であれば可能)。StormCrawlerは，低レイテンシが必要であったり，あるいはストリーム結果(ページビジットのようなユーザ生成イベント)としてURLが渡される場合など，広い範囲のユースケースの実装を容易なものにします。

Scrapyとの比較では，StormCrawlerがスケーラブルな分散環境で動作するのに対して，ScrapyにはFronteraのような分散クローリングを行なうプロジェクトもあるものの，シングルプロセスです。

StormCrawlerの分散処理と信頼性(他にUIやメトリクスフレームワークやログなども)を担っているのはApache Stormです。

ユーザフレンドリを目指している点，データスクレイピングの優れたソリューションである点については，ScrapyとStormCrawlerは同じです。

要するに，NutchのスケーラビリティとScrapyの使いやすさを組み合わせたものがStormCrawlerである，と言えるでしょう。

InfoQ: クロールのワークロードはI/O集中型になりがちですが，Apache SparkやApache Flickと比較して，Apache Stormをストリーミングフレームワークに使用することのメリットは何でしょう？

Nioche: Apache Stormの設計とコンセプトはシンプルかつ効率的です。それに当時は，Sparkが存在していませんでした。Spark Streamingはデータをマイクロバッチで処理しますし，宣言的なスタイルは私のニーズに最適とは言えなかったのです。

クローリングの主な課題のひとつにポライトネス(politeness)があります。これは，クローラがWebサーバにヒットする頻度によって定義されるものです。一般的なストリーミングアプリケーションとは違い，目的は可能な限り早くメッセージを転送することではなく，スループットを最適に保ちながら丁寧に処理することです。それには精細なコントロールが必要であり，Apach Stormのメカニズムがその目的を果たしているのです。

InfoQ: 今後のリリースに関するロードマップは，どのようになっていますか？

Nioche: StormCrawlerの開発主体はコミュニティです。最新の安定版リリースは1.2で，Stormの1.xバージョンをベースとしています。次回のリリースには言語識別モジュールが含まれる他，最新のElasticsearch 5に対応する予定もあります。大きな機能としては，AJAXベースのサイトで使用されるようなSeleniumベースのプロトコル実装を，どこかの時点で用意したいと思っています。