1年前、ニューヨークタイムズとProPublicaは、Knight News Challenge 2009のコンテストにおいて助成金の申し出を受けた。DocumentCloudは、71万9500ドルの賞金を受け取り、ドキュメントを統合して調べることを容易にするドキュメントベースのアプリケーションを構築する使命を負った。これは同時に実現するには非常に高価な処理タスクであるため、DocumentCloudは100% RubyでCloudCrowdというクラウドのソリューションを実装することを決めた。
DocumentCloud はもともとPDF処理にCloudCrowdを使用しているが、CloudCrowdは以下のような他の高価なタスクにも利用できる。
- 画像の生成やリサイズ
- PDF上でテキストの抽出やOCRを実行
- ビデオの暗号化
- 大規模ファイルやデータベースの移行
- ウェブスクレイピング
CloudCrowdアーキテクチャのドキュメントでは、以下のように述べられている。
CloudCrowdは、小さな仕事をたくさん行うためのものではありません。巨大で高価な仕事を適度に行うものです。
CloudCrowdは、MapReduce フレームワークの影響を受けている。そのアーキテクチャは、実際の処理を行う作業デーモンによって動くセントラルサーバに基づく。そして、REST-JSON API と何が起きているのかモニタリングするウェブコンソールとともに公開されている。CloudCrowdは、ファイルストレージとしてAmazon S3を使うが、別のストレージも要望があれば追加できる。
InfoQは、作成者のJeremy Ashkenas氏と情報交換する機会があった。Jeremy氏は、DocumentCloudで働き始めたばかりで、Ruby-Processingの作成者でもある。
InfoQ: RightScale Gems や Naniteと比べてCloudCrowdはどうか? なぜ自分のソリューションを作り出したのか?
Jeremy Ashkenas氏: 実は、CloudCrowdはRightScale AWS gemを使います。そして、すべての結果(中間時と終了時の両方)に対して、分散データストアとしてS3を使います。話が脱線しますが、RightScale gemを通してEC2インスタンスをさらに構築することで、CloudCrowdのクラスタの自動スケーリングをサポートすることは、興味深い将来の方向性であり、素晴らしい貢献になるでしょう。セントラルサーバは、自動スケーリングの決定に必要なすべての情報を持ちます。このサーバは、作業数、場所、状態、作業待ちの列の長さを知っています。後は、インスタンスの構築のためのアルゴリズムを決定し、新しいインスタンスに必要な依存関係がすべてインストールされていることを確認するだけです。
Naniteと比べて、CloudCrowdは簡単で分かりやすいツールであろうとしています。そのため、Rubyマニアたちは、簡単に理解してカスタマイズできるでしょう。CloudCrowdは、ActiveRecordと標準のActiveRecordデータベース、伝達やスケーリングのためのHTTP や S3のように、たいていのRuby開発者が慣れ親しんでいる技術を使います。これらすべては、ひと際優れてデバックしやすく、作成が容易です。最小のCloudCrowdアクションは、たった1つのRubyのクラスで、1つの「プロセス」メソッドを定義しています。このメソッドは、並行して計算する部分を実行し、それをS3に保存します。これは、HadoopやNaniteのような産業に強いシステムの1つの選択肢として考えられるべきです。ErlangやAMQP、RabbitMQは必要ありません。非常にサイズが大きくなることを約束するものではありませんが、たいていの使用には十分持ちこたえられるにちがいありません。多くの部分は、どのように効率的に問題に対応できるかによるでしょう。
InfoQ: なぜRubyを使ったのか? Erlangなどの他の選択肢について考えたか?
Jeremy Ashkenas氏: 私がRubyを使ったのは、DocumentCloudの残りの部分を一緒にまとめるために使う計画を立てていたからです。例に挙げられたアクションの多くの中で実際の力仕事はRuby自身の中で実行されているのではなく、適当なツールから取り出されていることに注目してください。Rubyは物を結びつける言語として優れていて、実際の画像処理やPDF変換、ビデオの暗号化は、GraphicsMagickやTesseract、FFmpegなど適当なところへ渡されるでしょう。