커널 개발자의 고백: AI 크롤러가 우리 CPU의 20%를 잡아먹는다

지난 며칠 동안 제 웹사이트 중 하나에 함정을 추가하는 데 시간을 보냈습니다. 물론 아이러니하게도 LLM을 사용해서 말이죠. 그리고 꽤 재미있게 하고 있습니다.

Anubis의 작업 증명 시스템 대신 iocaine 방식을 선택했지만, 제 애플리케이션 자체에 구현했습니다. Elixir로 만들어져서 스크레이퍼에게 문제를 일으키는 것이 거의 서버 리소스를 사용하지 않아서 정말 재미있습니다.

현재 나쁜 스크레이퍼를 맛있는 데이터를 약속하는 가짜 무한 블랙홀 경로로 속인 다음, 헤더를 빠르게 보낸 후 15분에 걸쳐 이미지를 한 바이트씩 제공하고, 응답을 부풀려 토큰을 낭비하게 하며, 무작위로 AI 생성 섹시한 토스터 이미지를 반환합니다. 어떤 봇이 가장 많이 당했는지에 대한 리더보드가 있는 관리자 대시보드도 있습니다. 이 습하고 어두운 가을 저녁에 제 마음을 따뜻하게 해줍니다.

저는 2024년에 Anthropic의 3차 면접까지 갔고, 그들은 프로그래밍 테스트로 웹 크롤러를 만들라고 했습니다. 도중에 robots.txt를 존중하도록 만들기 시작했는데, 그 순간 그들이 더 이상 저에게 관심이 없다는 것을 바로 알 수 있었습니다.

저도 공개 cgit 인스턴스를 운영하며 매일 100만 건 이상의 히트를 받습니다. 제 개인 프로젝트는 커널의 규모나 영향력에 한참 못 미치지만요. diff, blame, 스냅샷, 과거 커밋과 같은 cgit 엔드포인트를 (nginx conf로) 차단해야 했습니다. 다른 방법은 전혀 효과가 없기 때문입니다. 이제 그들은 402(결제 필요)를 반환합니다. 저는 이것이 제 완전한 패배라고 생각하며, 마음이 아프지만 어쩔 수 없습니다.

Tavis Ormandy가 거의 정확히 1년 전에 Anubis에 대해 이렇게 예측했습니다:

https://news.ycombinator.com/item?id=44962529

그것은 결코 해결책으로 자리 잡지 못했습니다. 고성능 스크레이퍼는 일반 사용자보다 작업 증명 챌린지를 처리하는 데 더 적합합니다. 작업 증명은 비밀번호 해시에 적합합니다. 비밀번호 추측 하나는 제로 한계 효용을 제공하기 때문입니다. 그러나 스크레이퍼의 모든 요청은 스크레이퍼에게 생산적입니다.

> 왜 git.kernel.org가 크롤러에게 "흥미로운"가?

이 글은 이러한 봇에 얼마나 적은 생각과 노력이 들어가는지 과소평가하는 것 같습니다. 저도 훨씬 덜 흥미로운 프로젝트가 있는 cgit 인스턴스를 운영하지만, HTTP 요청의 홍수에서 자유롭지 않습니다.

제가 생각해낸 설명은 그들이 모든 링크를 크롤링하려고 시도한다는 것입니다. 그것이 얼마나 말이 되는지 또는 얼마나 많은 부하를 일으키는지와는 상관없이요. cgit이 cgit이기 때문에, 이는 모든 매개변수와 해시 조합에 대한 수십억 개의 링크를 의미합니다. 또는 의도적인 DDoS 공격일 수도 있습니다.

이 글의 문체가 정말 마음에 듭니다.

그리고 봇의 진화 과정("user agent 변경"에서 "IP 주소 변경", 제공업체가 전체 서브넷, 전체 ASN을 차단해야 하고 "프록시 SDK 수익화"가 실제라는 것을 깨닫는 것)은 LLM 이전 시대의 위협 행위자의 진화 과정을 그대로 반영합니다.

저는 한때 인기 있었던 게임 웹사이트를 운영하고 있습니다. 예전에는 초당 수백 건의 합법적인 요청이 있었습니다. 인기 이벤트 시간에는 부하가 특히 높았습니다. 그래서 항상 전용 서버에서 실행해 왔습니다.

또한 "온라인 사용자" 카운터가 있는데, 세션을 유지하는 인증되지 않은 사용자의 실제 사용자 세션을 세려고 했습니다. 그들은 댓글을 달거나 특정 필터 및 표시 옵션을 수정할 수 있었습니다. Google 봇은 절대 세지 않았습니다.

지난 몇 년 동안 이 카운터는 온라인 사용자 100-200명에서 수천 명으로 증가했습니다. 저는 수년 동안 거의 손을 대지 않고 사소한 업그레이드와 백업만 했습니다. 그러나 사이트도 상당히 느려졌고, 이러한 세션이 분명히 영향을 미치고 있었습니다. 그래서 마침내 이 크롤러들을 조사해 보니, 예, 완전히 인위적인 엄청난 트래픽이었습니다. 사이트에는 소수의 실제 사용자만 있고, 모든 버튼을 클릭하는 등 할 수 있는 모든 것을 시도하는 수천 개의 크롤링 세션이 있었습니다. 정렬과 검색이 GET 링크로 구현되어 있어서 더 나빴습니다.

크롤러를 제외하도록 카운터를 수정했지만, 약간의 딜레마가 있습니다. 봇이 모든 콘텐츠를 기반으로 지식을 업데이트하는 것을 막고 싶지 않습니다.

제가 찾은 최선의 해결책은 새로운 CloudFlare 기능으로, 크롤러에게 요청당 비용을 청구하거나 차단할 수 있는 기능입니다. 이것은 인터넷 전체에 훌륭한 아이디어라고 생각합니다. 베타 액세스에 신청했지만 아직 연락을 받지 못했습니다.

> 그것은 즉시 매우 효과적이었습니다 — 봇들은 그냥 포기했습니다. 몇 달 동안은 행복했습니다: 봇은 경계에서 차단되어 포기하고 더 쉬운 목표로 이동했습니다; 사용자들은 약간 짜증났지만 참았고, Anubis 스택은 어디에나 배포하기 쉬웠습니다.

기술자와 함께 일하는 기술자로서 저는 이런 종류의 편향에 매우 민감해졌습니다. 이 해결책이 실제로 더 나은가요? CPU 비용이 모든 사람을 약간 짜증나게 하는 것보다 실제로 더 나쁜가요, 아니면 "감각을 거스른다"는 이유로 해결되는 문제인가요?

저는 이 특정 사례에 대해 찬성이나 반대를 주장하는 것은 아닙니다. 그러나 측정 없이 결론에 도달하는 사람들을 자주 봅니다. 20%의 비용은 얼마이며, 그 비용이 "모두를 약간 짜증나게 하는" 것보다 가치가 있나요?

참고: 얕은 클론이 왜 나쁜가요? 저는 항상 더 저렴하다고 생각했는데, 아마도 제 디스크 공간에만 그런 것 같습니다. (서버가 "모든 것" 대신 어떤 blob을 보내줄지 계산해야 하기 때문에?)