マネーフォワードさん、空さん、LAPRASのクローラーのアーキテクチャを発表しました

こんにちは、CTOの伊藤です。

12/3に Crawler Night 2020 Winter という、クローラーの開発&運用に関する知見の共有イベントを実施したので、そのイベントレポートとなります。

前回の scouty Crawler Night 2019 に続き今回は第二回目のCrawler Nightとなりました。クローラーに関するイベント/勉強会は探してもほとんどありませんが、趣味や仕事でクローラーを書いている方はたくさんいるように思っています。気をつけないと法律を違反しやすい分野でもあるのでなかなか情報をアウトプットしづらいのだと思いますが、そのような特性を持つ分野だからこそ、私達はこうやってホワイトにやっているよ！という発信が大事だと思っています。

今回の発表ではクローラーのアーキテクチャに関する話が大半でしたが、次回は法律周りの話などもしてみたいです。

それでは、タイムテーブルに沿ってレポートを書いていきます。

発表の前に懇親会を行いました。最近弊社が開催しているイベントではこのようにすることが多いのですが、発表前に交流しておくことで場が温まるのと、会場にいる方のバックグラウンドをなんとなく把握した上で登壇できるので、より参加者の属性を意識した発表ができるというメリットがあります。

イベント終了後にアンケートを取ったのですが、そこにも最初に懇親会をしたのが良かったという声がありました。

LAPRAS クローラーの技術課題とアーキテクチャの変遷 - LAPRAS株式会社 DJ☆エンジニア 両角 和軌

LAPRASのクローラーエンジニアによる発表で、弊社のクローラーの変遷に関する発表です。今までScrapyをメインで使っていましたが、以下の点で辛かったという話でした。

1. Scrapyはコールバック地獄で複数ページを一度に辿っていくクロールする処理を書くのがつらい。
2. テストの書き方がつらい。独自でテストフレームワークを作成したが、イマイチ。
3. 拡張が難しい。

最近は新しいアーキテクチャを試しており、蔵(データ提供のAPI) + scraping モジュールの2つに分離し、クロールのハンドリングは蔵が行い、scrapingはステートレスでただクロールするだけ、というように責務を分けました。新しいアーキテクチャにしたことで2つのメリットを享受できました。

1. テストがしやすくなった
2. 設計に集中できるようになった

スクレイピングのフレームワークにも使い方によって向き不向きがあり、Scrapyが得意なのは並列リクエストで、検索エンジンに対するクロールやウェブのアーカイブ目的。うちでの使い方には向いていなかったようです。

AWS Lambda（SAM）でつくるクローラー - 株式会社空 田仲 紘典

ホテル業界には料金設定の無駄やムラが多いという課題があり、空さんは競合ホテルの料金を解析して、料金の最適化を行うことでその課題を解決しようしていらっしゃる会社です。

クローリングの種類には大きく、定期的に情報を収集するバッチ型、取得タイミングが不定で速さが求められるリアルタイム型の2種類があり、空さんの場合にはサービスの特性上リアルタイムなクローリングをする必要があります。

負荷のタイミングが不定である点や、インフラはベストプラクティスに乗るという設計方針からLambda(SAM) + S3という構成にしているそうです。

また、技術選定の際には

1. (管理観点で)ローコストで本番稼働ができること
2. ローカル環境で単体テストができる + 周辺の統合テストまで実行できること

を大切にしており、Lambda(SAM)はその前提にも合致していたようです。

発表の後半はLambda+SAMの開発Tipsを紹介をされていたので、詳細に興味があるかたはスライド資料をご覧ください。

とこしえに毎日改修し続けるスクレイピングアーキテクチャの一つのあり方 - 株式会社マネーフォワード 内波 生一

マネーフォワードさんに入社してから5年間ずっと毎日クローラーの修正をしてきた内波さんによる発表です。インフラのアーキテクチャよりはアプリケーション設計で気をつけていることを中心にお話頂きました。

マネーフォワードさんのクローリングにおける三大義務として

1. 「正しい」情報を取らなければいけない
2. 個人情報を守らなければならない
3. 変わり続けなければならない

というものがあるようです。それぞれより詳細に説明すると。

1.「正しい」情報を取らなければいけない

以前は個人向けのサービスのみを提供していたので、(誤解を恐れずに表現すると)多少の不具合は許されうる状況であったが、近年は事業者向けのサービスも提供しているため、誤った情報を取ることは許されない状況になっているようです。

そのため いかに誤った情報を保存しないか を重要視されており、少しでも想定していないデータを見つけたときにはすべてエラーにして落ちる様な設計をされているようです。そのためのクローリングフレームワークも自作しており、専任でそれを保守している方もいらっしゃるようです。

2. 個人情報を守らなければならない

顧客から銀行口座等のユーザ名・パスワード情報を受け取り、本人に代わり情報を取得しているため、それにより得た情報は何があっても外に漏れないようにする必要があります。そのためデバッグ時にもエンジニアが生のパスワードを手にしてイレギュラー対応をすることは許されず、すべでのケースをコード上で管理しているようです。(例外対応も含めて手作業で修正することは許されないようです)

3. 変わり続けなければならない

継続的に事業を続けていくためには変化を続けていかなければなりません。クローリングのアーキテクチャも今の延長線上で妥協するのではなく、常に今のシステムよりも良いものを作れるように挑戦を続けているようです。

最近ではマイクロサービス化を進めており、スクレイピングモジュールとそこで得た情報を提供する部分の分離をした話をしていただきました。(1つめの発表の蔵+scrapingと同じ構成)

また、攻め続けるための守りとして、エラーが起きたことを正しく検知できるように、エラー発生時の通知や、自動でのチケット発行、エラー監視のためのダッシュボードの整備にも力を入れているようでした。

LT x 4

発表資料: https://go-talks.appspot.com/github.com/guregu/slides/goquery/goquery.slide#1

LTは先の3つの発表とは別で、イベントの参加申込と一緒に参加者を募集しました。LAPRAS社内から3名、社外から1名の発表となり、社内色が強く感じになってしまいましたが、トークの内容は多岐に渡ったのでみなさん楽しんで頂けたのではないでしょうか。Elixir布教の発表もありました。

アンケート結果

LT終了後、(2次)懇親会開始前に参加者にアンケートを取りました。参加者30人のうち20名から回答を頂きました。90%の方がプラスに評価していただいて満足度も高く、期待した内容が聞けていたようで、運営としては大変嬉しい限りです。

一方で懇親会で個別に話を聞いていると、業務でクローラーを開発している人向けのアドバンストな内容が多く、これからクローラーを書いてみようとしている方へのビギナー向けの情報が少なかったという声もあり、こちらは次回のCrawler Nightのトーク構成のバランス調整時に気をつけようと思いました。

次回に向けて

今回はクローラーの設計や実務経験上のTips的な話が多かったですが、次回はクローリングに関連する法律面の話やクロール先サイトに迷惑をかけないために気をつけるべきことなど、クロールを始めようとしている人たちが心理的障壁を感じている部分の話ができると良いなと思っています。

濃いトークのCrawler Nightに対して、ビギナー向けの Crawler Light (明るい, 軽め) をやったらいいんじゃない？という声も社内から出てきたりしているので、次回はネーミングも含めて再検討してみたいと思っています！

次回は2020年夏頃を予定していますので、ぜひ奮ってご参加ください。