自社アプリの所持ユーザーから得たデータとアプリストアのランキング情報を元に、Google PlayおよびApp Store上にある100万オーダーのアプリ情報を24h/365dクロールするシステムを開発しました。
ポイント
- 属人性の低減を強力に行った
- 極力自らの手でマネージする必要のないAWSのリソースを組み合わせてシステムが構成されるようにした
- オートメーションと可視化を進め、全社で認知できるようにした → 実際に認知され、やる気向上につながっていると評価された
- インタラクティブなSlack Botを実装し、実環境ログインなしでクローリングシステムを制御できるようにした
- ドキュメントを「全体を見渡す視点」と「実装を具体的に見ていく視点」両面からちゃんと書いた
背景
かつて在籍していた企業では、自社アプリのユーザーから任意で得た情報を元に、統計的に得られたアプリのユーザー数といったデータを販売するB2Bサービスを展開していました。そのサービスでは過去のストアランキングの参照や、ストアで閲覧できる情報の日時差分なども提供しており、毎日アプリストアから情報をクロールする必要がありました。
元々あったクローラーはPython 2.7 + Scrapyで記述されていたのですが、
など、問題点が表面化していました。当時のDockerや関連技術の隆盛もあり、その波に乗って新たなクローラーシステムへ置き換えようという話になり、その計画・立案・実装・保守をほぼ1人で担当しました。
要件
実現しなければならない要件は主に以下のとおりでした。
- 24時間に一度、既知の全アプリをクロール・スクレイプ・保存・出力する
- 必要に応じて、任意の国と言語を組み合わせてクロールをスケジュールできる
- それらを24時間以内にクロールするために必要なリソース量へオートスケールする処理も必要
- データアナリストと営業チームのためにデータを外部出力する
- 顧客の要望に応じてデータ出しをするチームは主にBigQueryで業務を遂行していました
- できるかぎり属人性を減らす
- 全世界のユーザーからどの程度データが得られているか・どれくらいクロールしたかを可視化する
使用技術・手法
ほとんどGo・一部のユーティリティでPythonを使いました。いわゆるSDKやフレームワークといったものは使わず、できるだけ言語の標準ライブラリもしくは薄いパッケージのみ使用しました。
クラウドは（ベンダーロックインの危険性も言われる今日この頃ですが）AWS一本で行きました。
Golang
Python
- ごく一部のユーティリティ・業務効率化スクリプト
AWS
クロール規模に応じてシステムをスケールするため、ランキングのクローラー・アプリのクローラー・ランキング及びユーザー所持情報をまとめてクローリングキューに差し込むスケジューラーなど、すべてマイクロサービス的に分散していました。AWS ECSはまだ公開された当初であり、現在では公式に実装されている処理を当時手で書いたりもしました。
Slack Bot
Slack Bot と絵文字リアクションで対話できるBotライブラリを開発し、それを用いて、クロール状況の表示や次回のスケジューリングがBot上で完結するような仕組みを導入しました。
属人性低減
属人性の低減のために以下のような工夫をしました。
- コンテナのBuild・Test・PushはCircle CIで実行し、コードで具体化する
- AWSのインフラを100％ AWS CloudFormationで立ちあげる
- EC2/ECSインスタンス上のコンテナ更新をSlack Botでやる
ドキュメント
システムの理解には全体観の共有が必要不可欠なので、俯瞰的にクラウドリソースを図示したり、コードの全体観や動作のフローをREADMEや別なドキュメント（Qiita Team）にしたためたりしました。また、具体的な説明はどちらかというとコード自体で説明されるように読みやすさを心がけ、必要ならコメントを書くというふうな運用で進めました。
可視化
クロールにまつわるログはすべてJSONでCloudWatchに流し込み、専用のクエリとCloudWatch Dashboardを組み合わせることでオーバーヘッドゼロの可視化およびモニタリング環境を構築しました。
さらに、それらのデータをGoogle Data Studioに流し込み、Raspberry Piで構築したキオスクで表示して他の社員からも見えるようにしました。社員の士気高揚に貢献しているとしてこの開発で社内賞を頂きました。
