iQONを支える、400サイトのクローラーの裏側

f:id:vasilyjp:20180927090637j:plain


こんにちはVASILYエンジニアの塩崎です。 iQONでは提携先ECサイトからアイテム情報をクロールしています。 クローラーの仕組みを大幅に変更することによって、1ヶ月間で400サイト分のクローラーを製作することができるようになりました。

今までの仕組みですと、2年間で80サイト分ですので、製作速度は100倍になりました。 今回はその仕組みをざっと紹介したいと思います。

ユーザーさんの欲しいアイテムがない!

そもそも、なんでこんなにアリエナイスピードでクローラーを作る必要があったんでしょうか? iQONにはブランドLIKEという機能があり、ユーザーさんが特定のブランドをお気に入り登録することができます。

しかし、ユーザーさんに人気のブランドにも関わらずアイテム点数がほとんどないブランドが多かったです。 中にはTOP10に入っていながらもアイテム点数が数十点しかないブランドもありました。

ユーザーさんにもっとiQONを使って貰うためには、この部分の改善が必要です。 そのため、ブランドLIKEの上位1000ブランドの全アイテムをクロールするためのタスクフォースが組まれました。

1000ブランドのアイテムを集めるために

課題1 400サイトのクローラーを作成し、運用しないといけない

このタスクフォースにはエンジニアが5人いたため、各人が1日あたり2サイト分のクローラーを製作すれば期限に間に合います。

しかし、そんなことをしてしまうと、膨大な数になったクローラーのメンテナンスが非常に大変になってしまいます。 仮に1つのサイトが1年間に1回リニューアルをするとしても、1日に1.5サイト分のクローラーの修正をする必要が出てしまいます。 (ちなみにこれは楽観的な想定)今まで通りの仕組みでクローラーを作成した場合は、クローラーの修正コストが馬鹿になりません。

課題2 アイテム情報の自動判定

また、当時はクロールしたアイテム情報の画像判定(iQONのコーディネート作成用の画面に出す or 出さない)やアイテムのカテゴリ判定(トップス or ボトムス or etc.)を人力で行っていました。

なので、たとえ大量のアイテムをクロールしたとしても、その判定の速度がボトルネックとなることが目に見えていました。 人力判定では1日あたり最大で3000点しか判定できませんでしたが、この程度のスピードですとアイテム情報判定の部分で新規アイテムの追加の滞留が起きてしまいます。

解決策

そのため、プロジェクト期間の前半1ヶ月で判定の自動化と、クローラーを簡単に製作するためのツール作りをすることになりました。 その後の1ヶ月を使いチーム全体でクローラーの作成をすることとなりました。

チームの約半数はビジネス職でしたので、エンジニアじゃなくてもクローラーを製作できるようなツールが必要です。

このクローラー作成ツールと自動判定機を使うことによって、今までとは比べものにならないスピードでクローリングを行い、常に最新のアイテムの情報をユーザーさんに届けられるようになりました。

クローラーの構成

まずは、今のiQONのクローラー全体の構成の紹介をしたいと思います。

クローラー作成ツールによるサイト固有パーサーの生成

ECサイト上のアイテム情報は、まず各「サイト固有パーサー」によって解析が行われます。 商品名や価格などの商品名が書かれているHTML要素はECサイト毎に異なります。 このサイト毎の差異を吸収しクローラー共通基盤に対して統一させたフォーマットでデータを提供するのがこのサイト固有パーサーの役割です。

従来の方法では、この「サイト固有パーサー」はエンジニアがrubyコードで書いていました。 しかし、その方法ではエンジニア以外の人がサイト固有パーサーを書くことができません。 さらに、ECサイトにわずかな変更があった場合でもrubyのソースコードを変更する必要があり、エンジニアが行う必要のあるメンテナンスのコストが非常に大きいです。

そのため、エンジニア以外の人でもサイト固有パーサーを簡単に製作できるようなツール、クローラー作成ツールを作りました。 このクローラー作成ツールの画面でXPATHや正規表現を入力するとその結果がDSLとしてDBに書き込まれます。 サイト固有パーサーはこのDSLをDBから読み込み、それに応じてECサイトの情報をパースします。

また、どうしてもツールでは対応できないような複雑なパースを行う必要のある商品情報(非同期なAPI通信を含むもの、詳細ページによって要素のxpathが変わるものなど)を含むECサイトもあります。 そのような要素については「エンジニアに依頼」にチェックを入れると、エンジニアがその要素のパーサーだけrubyコードで実装することができます。その後、エンジニアが書いたrubyコードとツールが生成したDSLをマージしサイト固有パーサーを生成することができます。

このツールを使用することで、エンジニア以外の人でもクローラーを高速に作ることができるようになりました。また、ECサイトのHTMLの構造が変わった場合でもエンジニア以外の人が対応することができるようにもなり、メンテナンスのコストを大幅に減らすことができました。

中には1つのサイトのクローラーをわずか3分で作ってしまうような猛者も登場してしまいました。 いままではエンジニアが1日に1つくらいのペースで作っていたため、エンジニアの間で戦慄が走るようなことにも繋がってしまいました。

アイテム情報判定の完全自動化

未判定アイテム情報テーブルに格納された情報は、自動判定機によって判定済みアイテム情報テーブルに移動されます。 自動判定機は、アイテムの画像判定とアイテムカテゴリーの判定を行います。

アイテムの画像判定

iQONというサービスの大きな特徴の一つに、ユーザーがファッションアイテムを組み合わせてコーディネートを作り、それを投稿できるという機能があります。

そのため、クロールした画像の中から、ユーザーさんがコーディネートを作りやすい画像を判定する必要があります。アイテムが単体で写っている画像がコーディネートに使われやすい傾向にあるため、その判定を行っています。

この処理は従来ではクラウドワーカーさんによる人力判定が行われていましたが、現在ではプログラムによる自動判定が行われています。

この処理の詳細は以下の記事に詳しくまとまっています。

iQONでクロールしたアイテム画像がコーディネートに使われるまで

アイテム情報のカテゴリー判定

商品名や商品の説明文などのテキスト情報からアイテムのカテゴリー(Tシャツ、ブラウス、ワンピース、etc)を判定します。

この判定機内部はMeCabで形態素解析を行った結果から、アイテムのカテゴリーを最も判定している可能性の高い単語をピックアップします。 その単語をアイテムカテゴリー辞書と照会することによってアイテムのカテゴリーを自動判定します。

この処理も、クラウドワーカーさんによる人力判定から、プログラムによる自動判定に移行しました。

これら2つの自動判定によってアイテムの判定速度が大きく向上しました。 いままでは最大でも1日に3000アイテムの判定しか行えなかったのが、1日に10万点ものアイテムを判定できるようになりました。

まとめ

今回の記事では、まだクローラーの全体構成を説明するだけに留まってしまいました。 ソースコードなどもなく、図も概念的なものに限っているため、まだまだこれで本当に100倍になるのかという部分に疑問をお持ちの方も多いでしょう。

次回以降の記事で製作速度を100倍にするためにしたことをより具体的に説明していきたいと思いますので、 好ご期待ください。

クローラーそのものは直接ユーザーさんの目に触れることはありませんが、iQONというサービスの根幹を支えていると自負しています。 今回、数多くのクローラーを製作したことにより、「自分の好きなブランドのアイテムが増えた!」という意見をユーザーさんから頂くこともできました。

VASILYでは一緒に働くことができる優秀なエンジニアを募集しています。 100倍なんて生温いという方がいらっしゃいましたら是非ご応募ください。

カテゴリー