가짜 크롤러를 차단하는 서버 미들웨어

웹 애플리케이션의 요청 파이프라인은 우아한 구조입니다. 요청이 웹 서버에 도착하고, 미들웨어 스택을 통과하며, 컨트롤러에 도달한 후 응답을 반환합니다. 스택의 각 미들웨어는 요청을 검사하고, 수정하고, 통과시키거나 완전히 거부할 수 있는 기회를 가집니다. 이 아키텍처는 검증이 요청이 애플리케이션 로직에 닿기 전에 일어나기 때문에 봇 감지를 구현하기에 완벽합니다. Google 봇이라고 주장하는 가짜 크롤러는 미들웨어 계층에서 식별되고 차단되며, 컨트롤러는 요청이 존재했다는 것을 알지도 못합니다. 페이지를 렌더링하는 데 CPU 사이클이 낭비되지 않습니다. 데이터베이스 쿼리가 실행되지 않습니다. 캐시 항목이 채워지지 않습니다. 가짜 봇이 문 앞에서 차단되고, 소비했을 서버 리소스는 합법적인 방문자를 위해 보존됩니다.

이 미들웨어를 구축하려는 동기는 구체적이고 비용이 많이 드는 문제에서 나왔습니다. 대규모 애플리케이션이 실제 사용자 기반과 상관없는 속도로 대역폭과 서버 리소스를 소비하고 있었습니다. 접근 로그는 Google 봇, Bing 봇 및 기타 합법적인 크롤러라고 주장하는 요청의 막대한 양을 드러냈습니다. 조사 결과 대부분이 가짜였으며, 클라우드 호스팅 공급자에서 발생했습니다. 각 가짜 요청은 실제 요청과 동일한 서버 리소스를 소비했습니다: 동일한 PHP 실행 시간, 동일한 데이터베이스 쿼리, 동일한 메모리 할당, 응답을 위한 동일한 대역폭. 시간당 수천 개의 가짜 요청으로 곱하면, 비용이 상당했습니다. 미들웨어 솔루션은 가짜 크롤러가 애플리케이션 리소스를 소비하기 전에 이를 차단하여 이러한 낭비를 제거하기 위해 설계되었습니다.

구현은 모든 백엔드 개발자가 적응할 수 있는 간단한 패턴을 따릅니다. 미들웨어는 모든 들어오는 요청을 가로채고, 사용자 에이전트 문자열이 알려진 검색 엔진 크롤러 패턴과 일치하는지 확인하며, 그렇다면 봇 감지 API를 사용하여 크롤러의 알려진 인프라에 대해 요청의 IP 주소를 검증합니다. 크롤러임을 주장하지만 검증에 실패한 요청은 403 응답으로 차단됩니다. 검증을 통과하거나 크롤러임을 주장하지 않는 요청은 정상적으로 미들웨어 스택을 통해 계속됩니다. 검증 결과가 IP 주소별로 캐시되므로 전체 검사는 최소한의 지연을 추가합니다. 즉, 각 고유 IP는 한 번만 검증됩니다.

미들웨어 계층에서 차단하는 것 뒤의 의사 결정 로직

웹 서버 수준(Nginx 또는 Apache)이나 애플리케이션 수준(컨트롤러 내)이 아닌 미들웨어 계층에서 차단하도록 선택하는 것은 특정 트레이드오프가 있는 의도적인 아키텍처 결정입니다. 웹 서버 수준에서 차단하는 것은 요청이 PHP에 도달하지 않으므로 리소스 소비 측면에서 가장 효율적인 옵션입니다. 그러나 봇 감지를 위한 웹 서버 구성은 일반적으로 정적 IP 블랙리스트 또는 단순한 사용자 에이전트 일치를 포함하며, 둘 다 실제 크롤러와 가짜를 정확하게 구별하는 데 필요한 동적, API 기반 검증을 제공하지 않습니다. 수백만 개의 IP 주소의 정적 블랙리스트를 유지하는 것은 비현실적이며, 사용자 에이전트 일치만으로는 사용자 에이전트가 사소하게 스푸핑할 수 있으므로 신원을 검증할 수 없습니다.

컨트롤러 또는 서비스 클래스 내의 애플리케이션 수준에서 차단하는 것은 가장 유연한 옵션이지만 가장 효율적이지 않습니다. 요청이 컨트롤러에 도달할 때까지, 미들웨어 스택이 이미 실행되었고, 경로가 해결되었으며, 세션 초기화 및 인증과 같은 잠재적으로 비싼 작업이 이미 발생했습니다. 이 시점에서 차단하면 컨트롤러 실행 시간은 절약되지만 그 전에 일어난 모든 것이 낭비됩니다. 가짜 봇 요청이 시간당 수천 개인 고트래픽 애플리케이션의 경우, 이 낭비된 전처리가 누적됩니다.

미들웨어 계층은 파이프라인에서 최적의 지점에 있습니다. 세션 처리 전에, 인증 전에, 경로별 미들웨어 전에, 확실히 어떤 컨트롤러 로직 전에 실행됩니다. 하지만 헤더, IP 주소 및 쿼리 매개변수를 포함한 전체 요청 객체에 접근할 수 있으므로, 단순 패턴 매칭보다 정교한 검증 로직을 수행할 수 있습니다. 미들웨어는 외부 API를 호출하고, 결과를 캐시하고, 주장된 신원을 기반으로 조건부 로직을 적용하고, 분석을 위해 검증 결과를 기록할 수 있습니다. 이 효율성과 유연성의 조합은 미들웨어를 웹 애플리케이션에서 봇 감지의 자연스러운 홈으로 만듭니다.

캐시 전략은 성능에 특히 중요합니다. 캐싱 없이, 주장된 크롤러로부터의 모든 요청은 IP 주소를 검증하기 위해 API 호출을 필요로 합니다. 빠른 API도 모든 요청에 지연을 추가합니다. 해결책은 IP 주소를 키로 하는 검증 결과를 캐시하는 것입니다. 수 시간 또는 하루 종일의 time-to-live를 가진. 검색 엔진 크롤러는 드물게 변하는 안정적인 IP 범위에서 작동하므로, 캐시된 검증 결과는 장기간 유효합니다. Google 봇이라고 주장하는 요청이 도착하면, 미들웨어는 먼저 캐시를 확인합니다. IP가 캐시 기간 내에 합법적인 것으로 검증된 경우, 요청은 즉시 허용됩니다. IP가 가짜로 검증된 경우, 즉시 차단됩니다. 첫 번째 IP 주소만 실제 API 호출을 필요로 하며, 그 후 결과는 무시할 수 있는 지연 비용으로 캐시에서 제공됩니다.

차단되는 요청에 어떤 일이 일어나는가

가짜 크롤러를 차단하는 것은 단순히 403 응답을 반환하고 계속하는 문제가 아닙니다. 차단 결정과 그 컨텍스트는 분석을 위해 기록되어야 합니다. 차단된 모든 요청은 사이트에 접근하려는 사람, 자신을 무엇이라고 주장하는지, 어디서 오는지에 대한 데이터 포인트를 나타냅니다. 시간이 지남에 따라, 이 로그는 더 광범위한 보안 결정을 알리는 패턴을 드러냅니다. 특정 ASN이 불균형한 양의 가짜 크롤러를 담당할 수도 있습니다. 가짜 Google 봇 요청이 하루의 특정 시간에 급증할 수도 있습니다. 특정 URL 경로가 다른 경로보다 더 많은 가짜 크롤러를 끌어들일 수도 있으며, 이는 봇이 특정 콘텐츠를 대상으로 하고 있음을 시사합니다.

차단된 요청에 대한 응답은 포괄적인 403보다 더 미묘할 수 있습니다. 일부 구현은 429(요청 너무 많음)을 반환하여 봇이 식별되었다는 사실을 숨기며, 봇 운영자가 자신의 접근 방식을 조정하기가 더 어렵게 만듭니다. 다른 구현은 빈 본문으로 200을 반환하며, 이는 최소한의 대역폭을 낭비하면서 봇이 감지되었음을 알지 못하도록 합니다. 더 공격적인 접근은 크롤러 검증이 실패했음을 나타내는 메시지와 함께 403을 반환하며, 이는 투명하지만 봇 운영자에게 감지 메커니즘에 대한 정보를 제공합니다. 선택은 사이트 운영자의 투명성과 운영 보안에 대한 철학에 따라 다릅니다.

크롤러임을 주장하지만 실제로는 Google이 페이지를 보는 방식을 시뮬레이션하기 위해 크롤러 같은 사용자 에이전트를 잘못 사용하는 합법적인 서비스인 봇의 경우, 차단은 의도한 것보다 더 방해가 될 수 있습니다. 일부 SEO 모니터링 도구는 Google인 검증에 실패합니다. 비록 그들의 목적은 사이트 운영자의 관점에서 합법적이지만. 미들웨어는 크롤러 같은 사용자 에이전트를 잘못 사용하는 알려진 합법적인 서비스의 IP 범위 화이트리스트를 유지하거나, 일부 사용자 에이전트 패턴에만 검증을 적용하면서 다른 패턴은 무시하여 이를 수용할 수 있습니다. 미들웨어 접근 방식의 유연성은 웹 서버 구성이나 애플리케이션 코드의 변경 없이 이러한 종류의 미묘한 정책을 허용합니다.

동기식 대 비동기식 검증

봇을 동기식으로 검증할지 비동기식으로 검증할지에 대한 질문은 차단의 효과와 애플리케이션에 미치는 성능 영향을 모두 영향을 줍니다. 동기식 검증은 미들웨어가 요청을 일시 중지하고, 검증 API를 호출하며, 응답을 기다린 후, 결과를 기반으로 요청을 허용하거나 차단하는 것을 의미합니다. 이 접근 방식은 즉시 차단을 제공하지만 각 IP 주소로부터의 첫 번째 요청에 지연을 추가합니다. 캐싱으로 인해 지연은 첫 번째 요청에만 영향을 주지만, 고트래픽 애플리케이션의 경우 가끔 지연도 허용되지 않을 수 있습니다.

비동기식 검증은 다른 접근 방식을 취합니다. 새 IP로부터의 첫 번째 요청은 검증 작업이 백그라운드에서 큐에 들어가는 동안 허용됩니다. 검증 결과가 돌아오면, 이것은 캐시되고, 그 IP로부터의 모든 후속 요청은 결과에 따라 처리됩니다. 이 접근 방식은 요청 파이프라인에 0 지연을 추가하지만, 검증이 완료되기 전에 가짜 봇으로부터 적은 수의 초기 요청이 통과하도록 합니다. 대부분의 애플리케이션에서, 이 트레이드오프는 허용됩니다. 검증되지 않은 세 개의 요청을 보낸 후 차단되는 가짜 봇은 검증되지 않은 채로 수천 개의 요청을 보낸 것보다 훨씬 적은 리소스를 소비했습니다.

큐 시스템은 비동기식 접근 방식을 간단하게 만듭니다. 미들웨어는 봇 감지 API를 호출하고, 캐시에 결과를 저장하며, 선택적으로 애플리케이션의 다른 부분이 수신할 수 있는 이벤트를 발생시키는 검증 작업을 디스패치합니다. 작업은 몇 초 내에 실행되므로, 검증되지 않은 봇 트래픽이 통과할 수 있는 시간 창은 매우 좁습니다. 빠른 인메모리 캐시를 사용하는 애플리케이션의 경우, 캐시된 결과는 모든 애플리케이션 인스턴스에서 즉시 사용 가능하므로, 로드 밸런싱 환경에서도 검증은 IP 주소별로 한 번만 일어나야 합니다.

하이브리드 접근 방식은 둘 다의 최고를 결합합니다. 높은 신뢰도의 패턴과 일치하는 알려진 봇 사용자 에이전트는 캐시된 결과로 동기식 검증을 트리거하며, 최소한의 지연을 추가합니다. 낮은 신뢰도의 패턴은 비동기식 검증을 트리거하며, 검증이 백그라운드에서 실행되는 동안 첫 번째 요청을 허용합니다. 이 계층화된 접근 방식은 일반적인 경우를 최적화하면서 엣지 케이스를 우아하게 처리합니다. 미들웨어의 요청 파이프라인 위치는 이 로직을 구현하기에 이상적인 장소입니다. 라우팅 결정을 내리는 데 필요한 모든 정보에 접근할 수 있고 비싼 애플리케이션 로직 전에 실행되기 때문입니다.

문 앞에서 차단하는 것의 측정 가능한 영향

봇 감지 미들웨어를 구현한 결과는 서버 메트릭에서 거의 즉시 눈에 띕니다. 가장 극적인 변화는 대역폭 소비입니다. 가짜 크롤러는 응답에서 참조되는 모든 자산을 포함하여 완전한 HTML 페이지를 요청합니다. 차단된 각 요청은 전체 응답을 전송하는 데 사용되었을 대역폭을 절약하며, 콘텐츠가 풍부한 페이지의 경우 요청당 수십 또는 수백 킬로바이트가 될 수 있습니다. 시간당 수천 개의 차단된 요청에 걸쳐, 대역폭 절약이 누적되어 의미 있는 비용 절감을 초래합니다. 특히 전송당 기가바이트 요금을 청구하는 공급자에 호스팅된 애플리케이션의 경우.

CPU 사용률은 서버가 더 이상 요청에 대해 PHP 코드를 실행하고, 데이터베이스 쿼리를 실행하고, 템플릿을 렌더링하지 않으므로 떨어집니다. 감소는 인간 트래픽이 적지만 봇 트래픽이 상수인 비피크 시간 동안 가장 눈에 띕니다. 미들웨어를 구현하기 전에, 봇은 자지 않으므로 서버는 새벽 3시에도 기준 CPU 사용률을 유지했습니다. 구현 후, 비피크 사용률은 거의 0에 가까워지며, 서버에 피크 시간 동안 합법적인 트래픽을 위한 여유를 제공합니다.

합법적인 방문자에 대한 응답 시간은 감소된 서버 부하의 직접적인 결과로 개선됩니다. 초당 500개의 요청을 처리하는 웹 서버, 그 중 300개는 가짜 봇이며, 초당 200개의 요청만 처리하는 서버, 모두 합법적인 것보다 200명의 실제 방문자를 위해 사용 가능한 용량이 더 적습니다. 미들웨어는 차단된 요청에 대한 리소스를 절약할 뿐입니다. 통과되는 모든 요청의 품질을 향상시킵니다. 서버가 실제 작업을 위해 더 많은 용량을 사용할 수 있기 때문입니다.

데이터베이스 부하는 비례적으로 감소합니다. 애플리케이션이 모든 페이지 요청을 위해 데이터베이스를 쿼리하는 경우, 300개의 가짜 요청을 초당 차단하면 300개의 불필요한 데이터베이스 쿼리를 초당 제거합니다. 복잡한 쿼리 또는 제한된 데이터베이스 연결이 있는 애플리케이션의 경우, 이 감소가 안정적인 작동과 주기적인 과부하의 차이가 될 수 있습니다. 미들웨어는 웹 서버에서 애플리케이션 계층을 통해 데이터베이스까지 전체 스택을 보호합니다. 그것은 원치 않는 트래픽이 그들 중 어느 것에도 도달하기 전에 이를 중단함으로써.