2016 02-25-crawler-study-01
TRANSCRIPT
2016年2月25日第1回クローラー開発勉強会
ファッション系ECサイトクローラー開発の苦労話
自己紹介•過去~現在のキャリア • 派遣で6年程エンジニア&PM
• 正社員で8年ほどWeb系な人を対象にしたキャリアコンサルタントを経験
• 2014年7月~フリーランスでなぜかWeb系のエンジニアをやってます。(Rails4+AngularJS)
•クローラー開発について • 趣味ベース
• クラフトビールの情報収集のためのクローラーをNode.js+いくつかのnpmモジュールでの開発
• 仕事で
• ファッションECサイトの収集のためのクローラー開発をRuby/Rilsベースでの開発
Agenda
1. ファッションECサイトの特徴
2. ファッションECサイトをどう攻めるか?
3. これまでの経験を踏まえてクローラーで出来たこと・実現出来てないこと
1. ファッションECサイトの特徴
Photo By Bruno Cordioli https://www.flickr.com/photos/br1dotcom/4693813432/
•リッチなUI
•推測しやすいURL
•画像が多い
リッチなUI例:WILD THINGS
推測しやすいURLサイト名 カテゴリ:ジーンズ
gu /jp/store/feature/gu/men/jeans/
ZOZOTOWN /category/pants/denim-pants/
女性の場合のURLは?
ボトムス・パンツカテゴリの
一覧は?
サイト名 商品詳細ページ
NewBalance /products/newbalancejmjl6240sib.html
GO OUT /item/15RZ0068.html
商品IDっぽい
商品IDっぽい
画像が多い
2. ファッションECサイトをどう攻めるか?
• ボルダリングのようなもの
• 腕力に頼り過ぎない
• クローリングも腕力=技術に頼り過ぎないようにする
• 頭を使うと意外と簡単なルートが見つかる(かも??)
リッチなUIのサイトの攻め方• リッチなUIを実現するためにJavaScriptを多用
• 攻め方
• PCサイトが無理ならスマフォサイトを探す
• JavaScriptを多用してるならWebAPIで情報取得してるケースのはずなのでAPIのエンドポイントを探す
• あるサイトでは/xxx/ApiGetProductInfo.do?&product=[:product_id] という感じでJSON取得できるのを発見
• これ↑気になる人は後でお声がけください。個別に教えます
サイトの攻め方• URLが推測しやすい→サイト全体の構造が把握しやすい
• 攻め方
• ZOZOTOWNの場合にはカテゴリ一覧の名前をどこかで取得できれば良さそう
• /category/[メインカテゴリ]/[サブカテゴリ]
Photo by Sebastien Wiertz via Flickrhttps://www.flickr.com/photos/wiertz/4604140980/
これまでの経験を踏まえてクローラーで出来たこと・実現出来てないこと
出来たこと:在庫情報のスクレイピング処理
tableタグ thタグ
tdタグ
在庫情報
id/classセレクタ無い。。。。サイズ・色・在庫のスクレイピングがとても面倒
1. 先頭のtrのchildrenのテキストを取得し文字列が空白でない箇所をサイズとして配列に格納
2. trを順番にループtdタグが含まれてる場合に詳細の処理を行う
3. ループカウンター付きでtdを1つづつ処理 4. 上記3.のループカウンターの値を参照して現在処理中のセルを特定した上でサイズ、色、在庫の有無を格納
①
②③
④
出来たこと:画像取得含めたクローラーのアーキテクチャが考えられるようになった
SiteACrawler
SiteBCrawler
Redis
MySQL
ScrapingWorker
相手サーバー負荷
取得アイテム数
情報鮮度
出来てないこと:クローリングする上での最適なバランス
新 低
高
少
古
取得アイテム数
情報鮮度
新 低
高
少
古
相手サーバー負荷
相手のサーバー負荷を考慮しながら商品情報をたくさん取得→ クローラーの実行頻度少ない状態なので取得された情報が古くなりがち
商品情報をたくさん取得し、かつ、短い周期でクローラーを実行→ 相手のサーバーへのアクセス増えるため負荷高くなる
多 多感覚的なものですがこの三角形の面積は一定になる気がする3要素のうちの1つを犠牲にする
方針が必要なのかも
出来てないこと: 画像管理の最適な方法
Scraping Worker
?
?
VPSベース
懸念:画像転送量に応じたお金
懸念:1. 運用コストが高くつきそう 2. 将来的にS3とかに移行したくなった場合のデータ移行
ご清聴ありがとうございました