Crawler Night 2020 Winter 登壇してきました
こんにちは！株式会社空、取締役CTOの田仲です。
Crawler Night 2020 Winter 登壇してきました。
登壇のきっかけは、CTO of the year 2018 で共にファイナリストとして登壇した Shogo Ito@LAPRAS のツイートからです。
直近の案件で、リアルタイムクローリングを１〜２ヶ月ぐらいかけて、開発していた知見を少しでも共有したく応募しました。
そもそもクローリングには思い出がある
株式会社空として、クローリングから事業をゼロから構築し、「ホテル番付（※）」で TechCrunch Tokyo 2017 にて最優秀賞を獲得したことがあります。思い出だけでなく、事業も少しずつ軌道に乗り始め、少なくとも２年クローリングの知見を貯めることができました。
（※）現在は「MagicPrice ライトプラン」とサービス名を統合いたしました。
↓ TechCrunch Tokyo 2017 ピッチプレゼン ↓
知見の一つ「AWS Lambda（SAM）でつくるクローラー」
クローリングには、
・バッチ
・リアルタイム
の２種類が存在しており、登壇した内容は冒頭でも述べたように
リアルタイムについて、共有してきました。
登壇ではリアルタイムのみに触れていたので、バッチによるクローリングも触れておきます。
バッチによるクローリングはどう行っていた？
全国のホテル・旅館情報を取得するために、１日１回データ取得を行ってい、ホテル・旅館情報の１つずつをSQSにキューを保存、受け取ったキューを元に、EC2（サーバ）からクローリングしていました。
Batch → SQS → EC2（AutoScaling）
EC2はSQSのキューの滞留数によって、AutoScalingする仕組みを使っていました。
キューの受信には、Ruby のライブラリ「shoryuken」を利用して、非同期的に呼び出せる環境づくりをしていました。
バッチによるクローリングパターンだと、サービス側で決められるため、いつ実行することがわかっている。EC2 のリソースを適切に使い切る設定もできます。また、費用についても、無駄に発生することが少なく済みます。
リアルタイムによるクローリングをバッチの時と同じように実行すると、リソースは使い切れるのか？費用は？
答えは、リソースも使いきれないし、無駄な費用が発生する。
リアルタイムは、取得の速さやタイミングの不定期により、
EC2 だと（最低一台）常時起動させる必要がある。
もし13〜14時の間だけクローリングイベントが発生するパターンだと、残り23時間は無駄な費用を発生させてしまいます。
そこで Lambda を利用することで、無駄な費用を発生させず、不定期なタイミングにも瞬時にクローリングできるようにしました。
詳細は登壇資料にてご確認ください。
・・・
今回は私、田仲が登壇する機会となりましたが、弊社のメンバーも登壇する機会を増やしていき、プロダクトづくりに関わる方達へ知見を共有していきます。
ニュースレターに登録しませんか？
プライシング市場/ダイナミックエコノミー関連ニュースや空からのお知らせをまとめてお届けするニュースレターを配信しています。こちらからご登録ください。
この記事が気に入ったらサポートをしてみませんか？