Embed Size (px)
Citation preview
AWS Lambda Meetup #0
Lambdaで作る クローラー／スクレイピング
２０１4年12月22日 NRIネットコム 佐々木拓郎
✦ プロフィール
‣ NRIネットコム株式会社
‣ Twitter: @dkfj
‣ Facebook: takuro.sasaki
‣ blog: http://blog.takuros.net/
‣ 好きなAWSサービス： S3,SQS
自己紹介： 佐々木拓郎
主にJAWSUG大阪で活動していました （東京、初進出）
宣伝！！
本業と全く関係ないですが、 Rubyのクローラー本を書きました。
http://amzn.to/1lsJ5id
Rubyによるクローラー開発技法 巡回・解析機能の実装と21の運用例
NRIネットコム
✦NRIグループで主にWebビジネスを専門としている会社
‣ Webシステムの企画・設計・開発・運用 ‣ デザインも重視していて、ディレクター・デザイナーも一杯 ‣ スマホ／タブレットも得意 ‣ もちろんAWSをはじめとするクラウドにも力を入れている
AWS Lambda
サーバ不要で、イベントドリブンな プログラム実行基盤
イベントキック Lambdaで実行
インフラの在り方を根底から変える！！(かもしれない）
今、注目の アーキテクチャ
S3 Event Notifications
S3のオブジェクトに対してのイベントを検知し、 後続の処理を行う
イベントPut,Post, etc
通知
SQSキュー
SNSトピック
Lambda Function
（）
Lambdaで クローラー/スクレイピング
クローラー／スクレイピング、 ご存知ですか？
クローラー
• Webを巡回するプログラムの総称 • ボット、スパイダー、ロボットなど様々な呼ばれ方がある • 巡回戦略を練るのが一番の仕事 • スクレイピングやストレージの機能を持つことが多い
スクレイピング
• 取得したHTMLなどから、データを抜き出すこと • 例えば、HTML中のAタグのリンク先を全て取得する • 正規表現派と構文解析派が存在する
巡回＆ダウンロード
スクレイピング
Lambdaクローラー全体像
1. キック
2. http リクエスト ＆ ダウンロード 3. html保存 4. S3 Event Call
5. S3 getObject6. Scrape
LambdaCrawler parseHtml
インターネット
S3
クローリング部分とスクレイピング部分を実装
クローラーの実装
1. キック
3. html保存
LambdaCrawler
Node.jsの httpクラスを利用
AWSの s3 putObjectを利用
URL付与
2. http リクエスト ＆ ダウンロード
スクレイピングの実装
4. S3 Event Call
5. S3 getObject6. Scrape
parseHtml
S3 Eventで Lambdaファンクション
の呼び出し
引数から、 該当のファイルを取得
cheerioという スクレイピング用の ライブラリを利用
ソース
https://github.com/takuros/lambda-crawler
解説は、こちら http://blog.takuros.net/entry/2014/12/14/053606
実装のポイント• データダウンロード部とスクレイピング部の分離 ‣ Lambdaはタイムアウトがあり、一般のバッチと違う
⇒細かいエラー処理・例外処理をやってられない
‣ 単一処理に限定すると、エラー処理がし易い（はず） ⇒成功／失敗のどちらかに倒す
• 処理間の連携方法が重要 ‣ S3 + Event Notificationだと比較的シンプルで良い ‣ Lambda ⇒ Lambda連携だと、失敗時の追跡が大変（そう）
いろいろ試してみた
実行元のサーバ
実行の度に、違うサーバが呼ばれるのか？
実験①
Httpリクエストを行う処理を複数作成し、
手動で複数回実行
HttpTest
HttpTest2
1. キック
54.172.104.205 - - [21/Dec/2014:13:24:12 +0000] "GET /hoge.html HTTP/1.1" 200 5 "-" "-" 54.172.104.205 - - [21/Dec/2014:13:24:20 +0000] "GET /hoge.html HTTP/1.1" 200 5 "-" "-" 54.172.104.205 - - [21/Dec/2014:13:24:23 +0000] "GET /hoge.html HTTP/1.1" 200 5 "-" "-" 54.172.104.205 - - [21/Dec/2014:13:24:28 +0000] "GET /hoge.html HTTP/1.1" 200 5 "-" "-" 54.172.104.205 - - [21/Dec/2014:13:25:24 +0000] "GET /hoge.html HTTP/1.1" 200 5 "-" "-"
基本的には、同一のサーバで実行される模様
2. キック
実験②並行処理で、実験①のLambdaファンクションを呼び出し
10並列×10ループ ⇒ 100リクエスト
ParallelCall
1. キックHttpTest
HttpTest54.173.132.200 - - [21/Dec/2014:15:57:32 +0000] "GET /hoge.html HTTP/1.1" 200 5 "-" "-" 54.173.132.200 - - [21/Dec/2014:15:57:32 +0000] "GET /hoge.html HTTP/1.1" 200 5 "-" "-" 54.173.132.200 - - [21/Dec/2014:15:57:32 +0000] "GET /hoge.html HTTP/1.1" 200 5 "-" "-" 54.173.132.200 - - [21/Dec/2014:15:57:32 +0000] "GET /hoge.html HTTP/1.1" 200 5 "-" "-" 54.173.132.200 - - [21/Dec/2014:15:57:32 +0000] "GET /hoge.html HTTP/1.1" 200 5 "-" "-"
やはり同一IP（≒同一サーバ）
実験③さらに並行処理で、実験②のLambdaファンクションを呼び出し
（10並列×10ループ）×（10並列×10ループ）⇒ 10,000リクエスト
1. キック
ParallelCall
HttpTest
HttpTest
ParallelCall
HttpTest
HttpTest
ParallelChainCall
結果
結果として、高性能なDDosツールが出来ました
※悪用激禁！！
IPアドレスの分散（≒複数のサーバで実行）
54.172.104.205 - - [21/Dec/2014:16:08:31 +0000] "GET /hoge.html HTTP/1.1" 200 5 "-" "-" 54.173.73.201 - - [21/Dec/2014:16:08:31 +0000] "GET /hoge.html HTTP/1.1" 200 5 "-" "-" 54.173.132.200 - - [21/Dec/2014:16:08:31 +0000] "GET /hoge.html HTTP/1.1" 200 5 "-" "-" 54.173.132.200 - - [21/Dec/2014:16:08:31 +0000] "GET /hoge.html HTTP/1.1" 200 5 "-" "-" 54.173.73.201 - - [21/Dec/2014:16:08:31 +0000] "GET /hoge.html HTTP/1.1" 200 5 "-" "-" 54.173.132.200 - - [21/Dec/2014:16:08:31 +0000] "GET /hoge.html HTTP/1.1" 200 5 "-" "-"
分散
考察
• Lambdaは、自動的にスケールアウトする • スケールアウトの時間は、数秒程度（？） • タスクの分割と追跡性を工夫すれば、Hadoop的な使い方もお手軽に出来るのでは？
• Phantomjsと併用で、負荷計測装置も作れそう
感想Lambdaを導入するにも、
• スケジュール/ジョブ制御システムが必要な場合が多い • その部分は、現状自前で構築する必要がある • AWSによるサービス化希望 • サードパーティのサービスが重要になるかも Ex）
サーバワークス Cloud Automator
NRI mPLAT
おまけ
実験③の結果を、Google Analyticsで計測
Googleに怒られそう
一気に数千に跳ね上がり
北米からの攻撃
おまけ
実験③のLambda側は？
AWSに怒られました。
Rate Exceeded
教訓
• Lambdaは、簡単に暗黒面に陥る • 強力過ぎる仕組みなので、使い方にはご注意を • バグって無限循環したら、どうやって止めるなど？ ⇒Lambdaファンクションを消せば良いとのこと
免責
こちらは個人の意見で、 所属する企業や団体は関係ありません。
ご清聴ありがとうございました 後日の質問は、@dkfjまで
