【ITニュース解説】Humanely dealing with humungus crawlers

Webサイトを運営していると、多くのユーザーが訪れるのは喜ばしいことだが、人間ではない「クローラー」と呼ばれるプログラムによるアクセスが問題になる場合がある。クローラーとは、インターネット上の情報を自動的に収集するために作られたプログラムのことだ。例えば、Googleの検索エンジンがWebサイトの内容を調べてデータベースに登録するために使うボットもクローラーの一種だ。しかし、中には特定の情報を集める目的で設計された「Webスクレイパー」や、悪意のある目的で利用されるボットなど、さまざまな種類のクローラーが存在する。

これらのクローラーが「巨大な」数で、あるいは非常に高い頻度でアクセスしてくると、Webサイトのサーバーに大きな負担をかける。これは、限られたサーバーのリソース（処理能力や通信帯域）が、過剰なリクエストによって消費され、本来のサービス提供に支障をきたす状況だ。サーバーは、一つ一つのリクエストに応答するためにコンピューターのリソース（CPU、メモリ、ネットワーク帯域幅など）を消費する。その結果、本来のユーザーへのサービス提供が遅れたり、最悪の場合、サーバーがダウンしてWebサイトが見られなくなったりする可能性もある。

また、サーバーが稼働し続けるためには電気代やネットワーク利用料がかかるため、不必要なクローラーのアクセスは運営コストの増加にもつながる。特に厄介なのは、悪意がない、あるいは正当な目的を持つクローラーであっても、設定ミスや効率の悪い設計によって、過剰なアクセスをしてしまう場合があることだ。このようなクローラーに対しても、Webサイト運営者は何らかの対策を講じる必要がある。

これまで、過剰なクローラーに対処するためのいくつかの方法が使われてきた。一つは「robots.txt」というファイルで、これはクローラーに対して「このページにはアクセスしないでほしい」とか「この部分はクロールしないでほしい」といった指示を出すものだ。しかし、これはあくまで「お願い」であり、悪質なクローラーや指示を無視する設計のクローラーには全く効果がない。

次に「レート制限」という方法がある。これは、特定のIPアドレス（インターネット上のコンピューターを識別する番号）から短時間に送られてくるリクエストの数を制限するものだ。例えば、「1秒間に10回以上のリクエストがあったらそれ以上は受け付けない」といった設定だ。この方法は一定の効果があるが、複数のIPアドレスを使い分けてくるクローラーや、ゆっくりと時間をかけて大量にアクセスしてくるクローラーには対処しにくい。また、急にアクセスを遮断すると、正当なクローラーであってもサイト運営者との信頼関係を損ねる可能性もある。

さらに、「IPブロック」という手法もある。これは特定のIPアドレスからのアクセスを完全に遮断するものだ。しかし、クローラーはIPアドレスを頻繁に変えることができたり、広範囲のIPアドレスを使ってきたりするため、いたちごっこになりがちだ。また、共有のIPアドレスを使っている場合など、無関係な正規ユーザーのアクセスまでブロックしてしまう危険性もある。「CAPTCHA」のように、人間であることの証明を求める方法もあるが、これはユーザー体験を損ねるため、多用することは難しい。

そこで、記事ではこれらの従来の対処法とは異なる、「人道的（humanely）」なアプローチを提案している。このアプローチの考え方は、クローラーを即座にブロックしたり排除したりするのではなく、その活動を「非効率」にすることで、自発的にアクセスを減らしたり、設定を修正させたりするように促す、というものだ。

まず、この対処法の出発点は、Webサイトの「アクセスログ」を詳しく分析することにある。ログには、どのIPアドレスから、どのユーザーエージェント（クローラーの種類を識別するための情報）を使って、どのくらいの頻度でアクセスがあったかといった情報が記録されている。この情報を監視することで、通常のユーザーとは異なる、異常なアクセスパターンを持つクローラーを特定する。例えば、同じIPアドレスから何百もの同時接続を試みたり、数分間に何万ものページをリクエストしたりするような挙動がそれに当たる。

特定された問題のあるクローラーに対しては、「低速化（Throttling）」という手法を用いる。これは、サーバーがクローラーからのリクエストに対する応答を、意図的に遅らせるというものだ。具体的には、通信の基盤となるTCP/IPレベルで工夫する。例えば、サーバーが送るデータの量を一度に少なく通知したり（TCPウィンドウサイズを小さくする）、通信の終了を知らせる応答（FIN-ACK）を遅らせたりすることで、クローラーが情報を得るのに非常に時間がかかるように仕向ける。また、HTTPレベルでも、レスポンスの本体（Webページのデータそのもの）の送信をゆっくりと行うことで、同様の効果を狙うことができる。

この低速化がなぜ「人道的」で効果的なのかというと、クローラーの運営者側にとって、サイトから情報を収集する効率が極端に悪くなるからだ。クローラーは通常、可能な限り早く大量の情報を収集しようとする。もし一つのサイトから情報を受け取るのに時間がかかりすぎると、そのクローラーは他のサイトを回る機会を失い、コンピューティングリソースも無駄に消費することになる。結果として、クローラーの運営者はこのサイトからのクロールを停止したり、設定を見直してアクセス頻度を大幅に下げたりするインセンティブが働くことになる。

さらに、HTTPステータスコードを適切に利用することも有効だ。「429 Too Many Requests」というコードは、「一時的にアクセスが多すぎるので、少し待ってからまた来てほしい」というメッセージを伝える。また、「503 Service Unavailable」というコードは、「サーバーが一時的に過負荷状態にあるため、現在はサービスを提供できない」ということを示す。この503コードと合わせて「Retry-After」という情報も送ることで、「〇〇秒後にまたアクセスしてください」と具体的な再試行のタイミングをクローラーに伝えることができる。これにより、クローラーは無駄な再試行を避け、サーバー側も一時的な負荷を回避する時間を得られる。

これらの対策は、Webサーバーの機能や、Webサイトの前に置かれる「リバースプロキシ」と呼ばれる機器の設定によって実現することが可能だ。例えば、特定のユーザーエージェントやIPアドレスからのリクエストに対して、応答速度を遅らせるようなルールを設定できる。重要なのは、このような設定を行う際に、本当に問題のあるクローラーだけを対象とし、正規のユーザーや検索エンジンのボットのような正当なクローラーには影響を与えないように慎重にバランスを取ることだ。

この「人道的」なアプローチは、Webサイトのサーバーリソースを保護し、過剰なクローラーによる悪影響を最小限に抑えつつ、インターネット上の他のシステムとの協調的な関係を維持しようとする、より洗練された方法と言える。システムエンジニアを目指す上では、このようにサーバーとネットワーク、そしてそこにアクセスするプログラムとの相互作用を理解し、効率的かつ持続可能なシステムを設計・運用する視点が非常に重要となるだろう。