AI 학습 봇의 침공, 그리고 위키독스의 생존기

Hello everyone. I'm running Wikidocs. I'd like to share my experience dealing with AI bots while operating the Wikidocs server and my thoughts on adopting Cloudflare. Wikidocs isn't huge, but it handles quite a bit of traffic. However, about three months ago, our traffic started skyrocketing abnormally. While that would normally be great news for regular visitors, unfortunately, most of it was AI learning bots trying to scrape Wikidocs' data. 1. The Merciless Onslaught of AI Bots These bots request things relentlessly. It's pretty much a DDoS attack. Connections from the US are over 10 times more frequent than from Korea. Having 10 times more US visitors on a Korean site is definitely not normal. While some bots are conscientious, others bombard us with over 100 requests simultaneously. We've had all sorts of battles with these bots recently. Initially, we tried mixing Nginx settings and Fail2ban, but we were helpless against bots that constantly changed IPs using VPNs. It seemed like we were losing. Rumor has it Wikidocs is a prime spot for data learning, as AI learning bots have proliferated in the past week, causing continuous traffic that the server struggled to handle. 2. Cloudflare: A Love-Hate Rekindling In the end, we brought in Cloudflare to put an end to this fight. Wikidocs had already used Cloudflare three years ago, but we disabled it due to speed issues and Google indexing problems. With Cloudflare, regardless of whether you use Free, Pro, or Business plans, you're connected to overseas servers, not Korean ones, which made speeds really slow. The Enterprise plan connects to Korean servers for fast access, but it's unbelievably expensive – only suitable for large corporations. Plus, about three years ago, although the exact cause was unclear, Google's search bots had issues, and all our indexed Wikidocs pages vanished. This cut off Google search traffic, causing our main income source, AdSense revenue, to plummet. Despite these past anxieties, we had no choice but to use Cloudflare again. It was an unavoidable decision to prevent the server from crashing due to AI bot attacks.

1. 무자비한 AI 봇들의 공습

We applied the 'Pro' version of Cloudflare. We didn't need the Business features; we just needed to set up DDoS protection and security rules to block the massive US traffic. After applying Cloudflare, the server hasn't gone down since. Cloudflare blocks some threats on its own, and for connections outside Korea, we used the 'Challenge' feature to make it difficult for bots to connect. We were careful not to include search bots, remembering the nightmare of losing our indexed Google pages back then. 3. Security Solved, But Speed is the Problem We solved a major issue, but another big one popped up: 'Speed.' Although Cloudflare has Korean regions, they refuse to connect non-Enterprise plans to them, citing high Korean bandwidth costs. So, to access Wikidocs via browser, you'd connect to servers in the US or other places with cheaper bandwidth instead of the conveniently located Korean servers, forcing us to endure agonizingly slow speeds. 4. The Savior: Argo Smart Routing, and the Cost Dilemma That's when we found a glimmer of hope: Cloudflare's Argo Smart Routing feature. Enabling this connects users to the closest Cloudflare region to their location. In other words, it connects Koreans to Korean servers.

2. 애증의 클라우드플레어 재도입

This solved the speed issue, but a bigger concern emerged: traffic costs. Argo Smart Routing has a base fee of $5 per month, plus $0.1 per GB. On busy days, Wikidocs can generate around 100GB of traffic daily. Simple calculation: $10 per day, which is $300 (about 450,000 KRW) per month. Moreover, with bots running rampant in the AI era, more traffic will be generated, making Argo Smart Routing an overwhelming feature for a small site like Wikidocs. Plus, if Argo speeds things up, AI bots worldwide might access it even faster, turning it into a 'true hotspot.' 5. Domain Separation Strategy: wikidocs-cdn.net Amidst this irony, we devised a plan: move static and image files, which constitute the majority of Wikidocs' traffic, to Cloudflare's R2 for service and distribute the traffic. Initially, we tried connecting `static.wikidocs.net` to R2, but since 'Argo' charges by domain, it was considered the same traffic, leading to a cost explosion. So, we bought a new domain, `wikidocs-cdn.net`, and connected it to R2. By completely separating the domain, 'Argo' wouldn't charge for `wikidocs-cdn.net` traffic. However, another problem arose. It wasn't a huge issue, but it was quite annoying. When we served static files and images via R2 using `wikidocs-cdn.net`, the old Cloudflare speed issue resurfaced. While you can apply caching to static files, it wasn't a perfect solution. We became dissatisfied with the speed for various reasons. 6. Final Solution: Building a Hybrid CDN So, we stopped using R2 services and reconnected `wikidocs-cdn.net` to the Wikidocs server, creating our own CDN-like system using Nginx to serve only static files and images. Finally, we have a site with satisfactory speed and effective AI bot handling. However, this incurred costs for Cloudflare Pro, Argo Smart Routing, and the additional domain purchase. We reduced Argo charges by separating static files and images, but we'll need to keep an eye on this. The AI era has brought a world where content sites must bear the cost of bot traffic. T_T For now, the immediate crisis is averted, so we need to nurture the service well to justify the security costs. Thanks for reading this long post.

AI Translated Image

위키독스는 '프로(Pro)' 버전을 적용했습니다. 굳이 비즈니스 기능까지는 필요하지 않았고, DDoS 방어와 보안 관련 규칙들을 설정하여 방대한 미국 쪽 트래픽만 막아주면 되기 때문입니다. 클라우드플레어를 적용한 후로 서버가 죽는 일은 없어졌습니다. 클라우드플레어가 자체적으로 막아주는 게 있고, 또 한국 이외에서 접속할 경우에는 '챌린지(Challenge)' 기능을 사용하여 봇들의 접속을 어렵게 했습니다. 구글 인덱싱 페이지가 없어졌던 과거의 악몽이 있기 때문에 서치 봇들은 여기에 해당되지 않게 꼼꼼하게 작업했습니다.

3. 보안은 해결했지만, 속도가 문제

큰 문제가 해결되었지만 또 다른 큰 문제가 생겼습니다. 바로 '속도' 문제입니다. 클라우드플레어 한국 리전이 있지만 한국의 망 사용료가 비싸다는 이유로 엔터프라이즈 급이 아닌 이상 절대로 한국 리전으로 붙여주지 않더군요. 그래서 브라우저로 위키독스에 접속하려면 멀쩡하게 가까이 있는 한국 리전 대신 미국이나 망 이용료가 싼 곳으로 왔다 갔다 하게 만들어, 처참한 속도를 감수해야만 했습니다.

4. 구원투수 Argo Smart Routing, 그리고 비용의 딜레마

그때 한 줄기 희망을 발견했습니다. 바로 클라우드플레어의 Argo Smart Routing 기능입니다. 이 기능을 켜면 접속자가 위치한 가장 가까운 클라우드플레어 리전으로 연결해 줍니다. 즉, 한국 사람은 한국 리전으로 연결해 주는 것입니다.

이걸로 속도 문제는 해결되었지만, 더 큰 고민이 찾아왔습니다. 그것은 바로 트래픽 비용입니다. "Argo Smart Routing"은 월 5달러 기본에, 1GB당 0.1달러씩 과금이 됩니다. 위키독스가 바쁜 날에는 하루에 100GB 정도 트래픽이 발생하기도 합니다. 단순 계산으로 하루에 10달러, 한 달이면 300달러(약 45만 원)가 나옵니다. 더구나 AI 시대에 봇들이 활개 치면 더 많은 트래픽이 발생하게 될 것이고, "Argo Smart Routing"은 위키독스 같은 작은 규모의 사이트가 감내하기에는 정말 벅찬 기능인 것입니다. 게다가 Argo 덕분에 속도가 빨라지면 전 세계에 분포한 AI 봇들이 더욱 빠른 속도로 접속하게 되어 '진정한 맛집'이 될 수도 있고요.

5. 도메인 분리 작전: wikidocs-cdn.net

이러한 아이러니 속에서 고민하던 중, 위키독스의 주요 트래픽인 정적 파일과 이미지 파일들을 클라우드플레어의 R2로 옮겨 서비스하여 트래픽을 분담하는 작전을 세우게 되었습니다. 처음에 `static.wikidocs.net`을 사용하여 R2와 연결시키려고 했는데, "Argo"는 도메인 단위의 과금이어서 이 또한 동일 트래픽으로 간주되어 요금 폭탄을 맞게 됩니다. 그래서 `wikidocs-cdn.net`이라는 도메인을 새로 구입하여 R2와 연결했습니다. 이렇게 아예 도메인을 분리해 버리면 "Argo"는 `wikidocs-cdn.net` 트래픽에 대해서는 과금하지 않게 되니까요.

하지만 또 문제가 생겼습니다. 이번에는 아주 큰 문제는 아니지만 꽤 신경 쓰일만한 문제였습니다. 정적 파일과 이미지들을 R2에 연결하여 `wikidocs-cdn.net`으로 서비스했더니, 클라우드플레어의 고질 문제인 속도 문제가 또 발생한 것입니다. 물론 정적 파일들에 캐시를 적용할 수는 있지만, 완벽한 해결책이 아니었습니다. 여러 가지 이유로 속도 문제에 만족하지 못하게 된 상황이 된 것이죠.

6. 최종 해결: 하이브리드 방식의 CDN 구축

그래서 R2 서비스를 쓰지 않고, `wikidocs-cdn.net`을 다시 위키독스 서버에 물려 Nginx로 정적 파일과 이미지만 서비스하는 자체 CDN 비슷하게 만들었습니다. 드디어, 속도도 만족스럽고 AI 봇들도 적절히 처리할 수 있는 사이트가 되었습니다. 다만 클라우드플레어 프로, "Argo Smart Routing", 추가 도메인 구입 등의 비용이 발생하게 되었습니다. 정적 파일과 이미지들을 분리하여 Argo 과금을 줄였지만, 이 부분은 지속적으로 관찰해야 할 것 같습니다. AI 시대가 되면서 콘텐츠 제공하는 사이트들은 봇 트래픽 비용까지 감당해야 하는 세상이 왔네요. ㅜㅜ 일단 급한 불은 껐으니, 보안 비용 아깝지 않게 서비스를 잘 가꾸어 나가야겠습니다. 긴 글 읽어주셔서 감사합니다.