概要
- AIクローラー による負荷が深刻な問題
- サーバーリソースの 20% がスクレイパー対応に消費
- Anubis チャレンジ導入も効果は一時的
- 正規ユーザーは全体の 2%未満
- 今後は 機能制限 やアクセス制御の強化予定
AIクローラーによる負荷の現状
- git.kernel.org のサーバーがAIクローラーによるアクセスで 常時高負荷
- 5つの地理分散ノードで 14コア以上 が常にHTMLレンダリングに専念
- スクレイパーによるリクエストは全体の 98%、正規アクセスはわずか 2%
- Linux開発 の全履歴がクローラーにとって貴重な学習データ源
- git clone で簡単に全データ取得可能にも関わらず、非効率なHTMLパースが主流
クローラーの進化と対策
- 初期は IPブロック や fail2ban で対応可能だったが、すぐに回避される状況
- クローラーは ユーザーエージェント偽装 や サブネット分散 で検知回避
- 最近は 家庭用機器やモバイルIP 経由での攻撃が急増
- Proxy SDK の普及で一般家庭のTVやIoT機器も攻撃元に変化
Anubisチャレンジの導入と限界
- Anubis による計算課題で一時的にボット排除に成功
- 難易度を上げても、ボットはすぐに対応し突破
- 正規ユーザーにも負担増加、特にモバイル端末では体感遅延や発熱
サーバーリソースへの影響
- 5ノード合計 90コア のうち、 14-16コア がスクレイパー処理に専念
- リクエスト数は1日 600万、そのうち 66% は即時ブロック
- スクレイパーの波状攻撃でリソース消費がスパイク状に変動
今後の対応方針
- クロール可能なURL数の削減 や 高負荷アクションの制限
- 匿名アクセス時の 機能制限 や 追加認証 の導入を検討
- 全データのダウンロード提供は継続、ただし手続きは煩雑化
- AIバブルの収束 やクローラーの効率化に期待
- 根本的な解決策は未だ不明、今後も状況に応じて対策強化
まとめ
- AIスクレイパー問題 はサーバー運用にとって深刻な課題
- 利便性とセキュリティの バランス調整 が今後の鍵
- 利用者への影響も避けられない現状
- データ公開の理念 は維持しつつ、現実的な制限を実施