クラウドソーシングでスクレイピングの高速化案件を受注しました。
案件の内容としては、商品の在庫が補充されたら、他のどのアカウントよりも早く検知して欲しいというものでした。
スクレイピングの高速化には自信があったので、その旨と他のアカウントよりも遅い原因の仮説と対応策を提案文に書いて送りました。
予めクライアントには、ネット環境やタイミングによって、物理的にどのアカウントよりも早く検知し続けることは不可能ですよと伝えておきました。
契約の締結が完了してからすぐに取り掛かり、検知までの速度を3分の1に改善してソースコードを共有しました。
クライアントもかなり驚いてくれたのですが、でも他のアカウントの中で2つだけ、自分達よりも常に早く検知するアカウントがあると言ってきました。
1日一緒にそのアカウントと自分達のシステムを監視したのですが、確かにその2つのアカウントは数秒早く検知していました。
だとしても、自分が実装した高速化はブラウザ上では最速になる部類なので、おそらくもっと別のところに原因があると伝えました。
といっても、自分も原因がわからなかったので色々調べました。
するとサーバーキャッシュという、まさにこれだと思う仕組みが見つかり、そこから仮説を立てました。
原因
- サーバーキャッシュが影響している
- 1度アクセスすると、そのページのキャッシュが保持される
- 1度目以降のアクセスはキャッシュを取りに行ってしまうので、キャッシュ自体が更新されるまで古い情報が返される
解決方法
- IPローテーションで、リロードごとに新規の接続としてアクセスする
- リロードごとに1度目のアクセスとして判断されるので、キャッシュではなく常に最新のデータを取ってくることができるはず
それから、IPローテーションはコストがかなり高いこと、サーバーに余計な負荷をかけることになるので、マナーとして高頻度なアクセスは自重する必要があるということも伝えました。
この仮説をクライアントも自分も試してみたいとは思ったのですが、コストがクライアントの予算を超えてしまうので保留になりました。
最後に高速化を行なったソースコードの仕組みを知りたいとお願いされたので、原理から細かく教えてあげました。
今回の改修案件で、蓋を開けてみないとわからない、かなり大きなイレギュラーもあるということを学びました。
中途半端な終わり方だった気もするけど、高い評価を頂けたので安心しました :)