마이크로캐시 & 봇 부하 흡수
검색봇·AI 크롤러는 일상적인 부하원입니다. 특히 조합형 URL 표면이 큰 사이트(예: 본문/항목이 수만 개로 갈라지는 콘텐츠 사이트)는 크롤러가 서로 다른 URL 을 빠르 게 훑기 때문에, 각 요청이 애플리케이션(PHP)을 끝까지 실행하게 되어 워커가 봇으로 가득 차고 사람의 요청이 밀리는 현상이 생깁니다.
multi-saas-kit 의 리버스 프록시(nginx) 기본 설정은 이 부하를 마이크로캐시 + 캐시 경화로 흡수합니다.
증상
- 평소엔 빠른데 가끔 홈/페이지가 수 초~십수 초씩 느려진다.
- 특히 로그인(관리자) 상태에서 더 느리게 느껴진다 — 로그인 요청은 캐시를 우회해 항상 애플리케이션을 실행하므로, 워커가 봇으로 차 있으면 그만큼 대기한다.
- 접속 로그를 보면 트래픽의 상당 비율이 크롤러(User-Agent 에
bot/crawler/AI 크롤러 이름)다.
동작 원리 (계층)
| 트래픽 | 처리 |
|---|---|
| 알려진 스크레이퍼 | 즉시 차단(403) — 애플리케이션 미실행 |
| 검색봇·AI 크롤러 (GET/HEAD) | 마이크로캐시에 단기 저장 → 같은 URL 재크롤은 캐시로 응답(애플리케이션 미실행) |
| 사람 | 캐시 우회(항상 최신) — 세션/CSRF 영향 없음 |
여기에 캐시 경화가 더해집니다:
- 동시 미스 묶음: 같은 URL 을 동시에 여러 봇이 처음 요청 해도 애플리케이션은 1번만 실행하고 나머지는 그 결과를 공유합니다.
- 백그라운드 갱신 + stale 제공: 캐시가 만료돼도 사용자를 기다리게 하지 않고 직전 캐시를 즉시 응답한 뒤 뒤에서 갱신합니다.
결과적으로 봇의 재크롤이 애플리케이션 워커를 점유하지 않으므로, 사람(로그인 관리자 포함)의 요청이 항상 워커를 확보합니다.
튜닝 원칙 (운영자)
구조는 표준, 수치는 사이트별. 기본 설정의 구조는 그대로 두고, 봇 부하가 큰 사이트만 수치를 조입니다.
| 노브 | 의미 | 조정 방향 |
|---|---|---|
| 봇 요청 속도 제한(rate) | AI·기타봇의 초당 허용 | 봇 폭주 사이트는 더 낮게 |
| 봇 동시 연결 수 | 봇이 동시에 점유 가능한 연결 | 애플리케이션 워커 수보다 작게(사람 몫 확보) |
| 캐시 보관 시간(TTL) | 봇 응답 캐시 유효시간 | 콘텐츠가 정적이면 길게(재크롤 흡수↑) |
주의:
- 검색봇은 제한/차단하지 않습니다 — 검색 노출(SEO)을 위해 무제한 허용 + 캐시만 적용합니다.
- 봇 동시 연결 수는 애플리케이션 워커 수보다 작게 두어, 봇이 몰려도 사람이 쓸 워커가 항상 남게 합니다.
- 이미 봇이 폭주 중인 사이트의 제한을 함부 로 완화하지 마세요 — 완화 시 재폭주합니다. 대규모 트래픽은 엣지(예: Cloudflare)에서 먼저 줄인 뒤 조정합니다.
가장 큰 레버는 엣지
origin(서버)의 캐시·제한은 봇이 소비하는 자원을 줄이는 백스톱입니다. 트래픽 자체를 서버에 도달하기 전에 줄이려면 엣지(Cloudflare)에서 AI 크롤러 차단/챌린지가 가장 효과적입니다(서버 코드 변경 0). 서버 방어 개요와 봇 정책 문서를 함께 참고하세요.
점검
배포 후 다음을 확인합니다(도메인은 운영 도메인으로 대체):
- 사람으로 홈 접속 → 정상(200).
- 알려진 스크레이퍼 User-Agent → 차단(403).
- 같은 콘텐츠 URL 을 크롤러 User-Agent 로 두 번 요청 → 2번째가 눈에 띄게 빠름(캐시 적중).
설정 반영은 무중단 reload 로 적용되며, 설정 오류가 있으면 자동으로 거부되어 운영 중인 사이트에 영향을 주지 않습니다.