AnyEventとEC2を使ったクローリングツールのご紹介

AnyEventとEC2を使った
クローラーのご紹介
Songhee Han
Kazuya Shono

自己紹介
• 韓松熙（@purewish）
• 荘野和也（@miniturbo）

10/14/2010 Copyright Since 1999 © GaiaX Co. Ltd. All rights reserved. 2

本セッションの内容
• 本セッションでは、
• EC2を用いたクローリングサーバのスケールアウト
• AnyEventを用いたインスタンス管理や前後処理の制御
についてご紹介します
• クローリングの対象や目的によって実装方法が異な
るため、特定のクローリング処理というよりも、ク
ローリングをするための構成や設計を中心にお話
したいと思います

Copyright Since 1999 © GaiaX Co. Ltd. All rights reserved.

クローラー
• 先日、業務でPerlを使ったHoneybeeというク
ローラーを作成しました
• Honeybeeでは、クローリングに特化した
Honeybee::Beeと、クローリングの前後に行
う一連の処理フローを管理・実行する
Honeybee::Hiveの2パッケージで構成されて
います


AnyEventとは
• AnyEventのかんたんな説明
• イベント駆動プログラミングをまとめるためのインターフェイス
• I/O, Timer, HTTPなどのイベントが発生したタイミングで、非同期に
処理を実行することができる
• 今回使ったモジュール
• AE::timer
• AnyEvent::Socket
• AnyEvent::Handle


全体的なイメージ
Hive

事前処理

クロールクロールクロール Bee

事後処理


Honeybee::Beeについて


シンプルなアプリケーション
• 今回のクローラーでは、クローリング部分を楽にス
ケールアウトできるように設計しました
• さまざまなホスティングサービスに設置できるように
するため、クローリング処理だけを切り出し、環境に
依存しないシンプルなアプリケーションになっていま
す
• そのクローリング部分こそがHoneybee::Beeです


Honeybee:: Beeの実装
• Bee自体は、受け取ったURLを対象にスクレ
イピングを行い結果をJSON形式で返します
• そのため、BeeはWeb Application
Frameworkを使用せず、単純なPSGIのアプ
リケーションとして実装されています


スケールアウト

• シンプルな構成のアプリなので環境に依存せ
ず、設置することができます
• 今回は、Amazon Web ServicesのEC2を利
用し、複数のインスタンスに設置することでス
ケールアウトをはかりました


連携のイメージ図
Hive パラメータを送信 Bee

EC2インスタンス

Crawler
Daemon

他のレンタルサーバ

JSONで返す


EC2のイメージ管理
• EC2で楽にインスタンスを起動するために、
あらかじめBeeを組み込んだOSイメージを
AMIとしてS3に保存しています


Honeybee::Hiveについて


Hiveの機能
• Honeybee::Hiveでは、
• クローリング対象のURLを生成し、データベースに格納
• クローリング処理（Bee側とHTTP通信）
• クローリング結果の重複対応
といった機能が実装されています
• この機能を実行するために、Hive側では2つのデー
モンが用意されています


2つのデーモン
• Crawler Daemon
• インスタンスの管理
• クローリング処理の実行
• Flow Management Daemon
• 全体の処理を順次実行するための、メッセージの
受信と機能の実行を行う


Crawler Daemon
Hive Bee

事前処理
クロール処理
Flow
Management Crawler
Daemon Daemon EC2インスタンス

事後処理他のレンタルサーバ


クローリング処理の管理
• 実際のクローリング処理はBeeで行います
• Hive側では、Beeが設置されているインスタンスを
管理し、効率的にBee側に作業を行うようにリクエス
トをする必要があります


インスタンスの管理
• 今回は、インスタンスの情報をデータベースに格納していま
す
• AnyEventのtimerで、定期的にインスタンスの状態をチェック
し、idleなインスタンスが存在すれば、そのインスタンスを
activeにし、リクエストを送るようにしています
• レスポンスが返ってきたら、使用したインスタンスをidleの状
態に戻します


Bee側へのリクエスト
• 取得したidle状態のインスタンスにリクエストを送り
ます
• インスタンスが複数存在する場合も考慮し、インスタ
ンスの数だけ子プロセスを立ち上げ、並列でリクエ
ストを送るようにしています
• 子プロセスは、レスポンスを処理し、インスタンスを
idle状態に戻して終了します


Bee側の処理フロー図
Hive Bee

Crawler Daemon
子プロセス (idle)

子プロセス (idle)

(active)


インスタンスの管理
use AnyEvent;
use Parallel::ForkManager;

my $cv = AE::cv;
my $timer = AE::timer 0, 1, sub {
# idle状態のインスタンスをデータベースから取得
my $instances =
$api->logic('Instance')->get_idle_instances(1);
my $pm = Parallel::ForkManager->new(scalar @$instances);
foreach my $instance (@$instances) {
$pm->start and next;
・・・ # 次のページで詳細を記述
# インスタンスをidle状態に戻す
$api->logic('Instance')->idle_instance(
$instance->{instance_seq});
$pm->finish;
}
$pm->wait_all_children;
};
$cv->recv;


Bee側とのやりとり
$pm->start and next;

my $crawl = $api->logic('Crawl')->get_crawl;
my $res = $ua->post($instance->{instance_url}, {
seq => $crawl->{crawl_seq},
url => $crawl->{crawl_search_url},
domain => $crawl->{crawl_search_tool_domain}
});

my $content = JSON::decode_json( $res->content );
if ( $content->{success} ) {
$api->logic('Crawl')
->succeed($crawl->{crawl_seq}, $content->{urls});
}
else {
$api->logic('Crawl')
->fail($crawl->{crawl_seq}, $content->{error});
}

$pm->finish;


Flow Management Daemon
Hive Bee

事前処理
クロール処理
Flow
Management Crawler
Daemon Daemon EC2インスタンス



順次実行される仕組み
• Beeではスケールアウトが重要だったように、Hiveでは処理
フローが順に実行される点を重視しました
• 順次実行される仕組みとして、
• cronなどで定期的に処理のステータス（どこまで実行したか）を確認
することは避けたい
• 処理が実行された後、自動的に次の処理を実行するよう、メッセージ
やシグナルで通知を行う
• 通知を受け取ったとき、次の処理を実行する
という観点で設計を行いました


メッセージを送る側
• 今回は、AnyEvent::Socketを使用し、tcp_serverでメッセー
ジを受け取り、決められた処理を順に実行しています
• メッセージは各処理の最後で送信します
• 送る際に、
• 次に実行するコールバック名
• そのコールバックに渡す引数
をシリアライズし、ソケット通信で送信します


メッセージを受け取る側
• 送られたメッセージをtcp_serverで受け取ります
• 受け取ったメッセージをアンシリアライズします
• 最後に、指定されたコールバックを、復元された引
数を渡して実行します


Hiveのイメージ図
Hive

メッセージを送信
事前処理

Flow
Management
クロール処理 Daemon

事後処理
次の処理を実行


イベントの処理
package Honeybee::Hive::Event;
use Storable qw/freeze/;
use IO::Socket::UNIX;

sub trigger {
my ( $self, $data ) = @_;
my $serialized = freeze($data);

my $sock = IO::Socket::UNIX->new(
Peer => $conf->{hive}->{socket}
);
$sock->send($serialized);
$sock->close;
}

sub execute {
my ( $self, $event, $args ) = @_;
eval { $self->$event($args); };
carp $@ if $@;
}


メッセージの送信
#!/usr/bin/env perl
use strict;
use warnings;
use utf8;
use Honeybee::Hive::Event;

my $event = Honeybee::Hive::Event->new;
$event->trigger({
event => 'prepare_crawl',
args => {
process_seq => 1,
}
});


メッセージの受信と実行
use Storable qw/thaw/;
use AnyEvent::Socket;
use AnyEvent::Handle;
use Honeybee::Hive::Event;

my $event = Honeybee::Hive::Event->new;
tcp_server '', $conf->{socket}, sub {
my ($fh) = @_;
my $handle;
$handle = AnyEvent::Handle->new(
fh => $fh,
on_read => sub {
my $buffer = $handle->rbuf;
my $data = thaw($buffer);
$event->execute($data->{event}, $data->{args});
}
);
};
AE::cv->recv;


イベントの処理
package Honeybee::Hive::Event;
use Storable qw/freeze/;
use IO::Socket::UNIX;

sub trigger {
...
}

sub execute {
my ( $self, $event, $args ) = @_;
eval { $self->$event($args); };
carp $@ if $@;
}

sub prepare_crawl {
...
$self->trigger({ event => 'crawl' })
}


全体の流れ
Hive Bee

事前処理
クロール処理
Flow
Management Crawler
Daemon Daemon



考察


今までは...

• 一つのロジックに一連の処理の流れが書い
てあったため、処理の一部分だけをスケール
アウトすることが難しかった
• ロジックを分割したとき、状態遷移を管理する
ためには、定期的にチェックするしかなかった
• 例えば...状態を表すフラグをDBに設けそのフラ
グを定期的にチェックしたり...


今回の設計で...

• 複雑なロジックを出来る限りシンプルに分割
することで、特定の処理をスケールアウトしや
すい設計にした
• crontabなどで定期的にチェックする構成をや
め、各処理の最後で自動的に次の処理を実
行させるようにした
• 今回は、ソケット通信にて実装した


Amazon EC2を使用すると...

• 新しいインスタンスを立ち上げるだけで、捌け
る数を増やすことができる
• クローリング部分はシンプルな処理なので、
スペックを必要とせず、1インスタンスに掛か
るコストが低い


まとめ

• 今回の実装コンセプトはほんの一例にすぎま
せんが、こういったアプローチもよいのではな
いかと思います
• ご意見ありましたら是非お聞かせ下さい


ご静聴ありがとうございました


AnyEventとEC2を使ったクローリングツールのご紹介

More Related Content

AnyEventとEC2を使ったクローリングツールのご紹介