12월 크롤링: CDN 및 크롤링

2024년 12월 24일 화요일

콘텐츠 전송 네트워크(CDN)는 웹사이트의 지연 시간을 줄이고 일반적으로 웹 트래픽 관련 문제를 해결하는 데 특히 적합합니다. CDN의 기본 목적은 사이트에 많은 트래픽이 발생하더라도 콘텐츠를 빠르게 전송하는 것입니다. CDN의 'D'는 전 세계에 콘텐츠를 전송하거나 배포하기 위한 것이므로 사용자에게 전송하는 시간도 한 곳의 데이터 센터에 호스팅할 때보다 단축됩니다. 이 게시물에서는 사이트의 크롤링 및 사용자 환경을 개선하는 방식으로 CDN을 사용하는 방법을 살펴보고 CDN 지원 사이트 크롤링의 몇 가지 자세한 정보도 살펴봅니다.

요약: CDN이란 무엇인가요?

CDN은 기본적으로 원본 서버(웹사이트가 있는 위치)와 최종 사용자 간의 중개자 역할을 하며 일부 파일을 제공합니다. 이전에는 CDN의 가장 큰 관심사가 캐싱이었습니다. 즉, 사용자가 사이트에서 URL을 요청하면 CDN은 해당 URL의 콘텐츠를 캐시에 잠시 저장하여 서버가 한동안 해당 파일을 다시 제공하지 않아도 되었습니다.

CDN은 사용자와 가까운 위치에서 사용자에게 콘텐츠를 제공하여 사이트 속도를 크게 높일 수 있습니다. 예를 들어 오스트레일리아의 사용자가 독일에 호스팅된 사이트에 액세스하는 경우 CDN은 오스트레일리아의 캐시에서 사용자에게 콘텐츠를 제공하여 전 세계를 왕복하는 시간을 줄입니다. 빛의 속도이든 아니든 무시할 수 없는 거리입니다.

마지막으로 CDN은 사이트를 과부하 및 일부 보안 위협으로부터 보호하는 데 유용한 도구입니다. CDN은 관리하는 전 세계 트래픽 양을 바탕으로 신뢰할 수 있는 트래픽 모델을 구성하여 트래픽 이상치를 감지하고 과도하거나 악의적인 것으로 보이는 액세스를 차단할 수 있습니다. 예를 들어 2024년 10월 21일에 Cloudflare 시스템이 약 1분 동안 지속된 4.2Tbps((편집자: 엄청난 양입니다)) DDoS 공격을 자동으로 감지하고 완화했습니다.

CDN이 사이트에 도움이 되는 방법

가장 빠른 서버와 최고의 업링크 금액을 보유하고 있고 속도를 높이는 데는 아무런 필요가 없다고 생각할 수도 있지만, 특히 사이트가 큰 경우 CDN을 사용하면 장기적으로 비용을 절약할 수 있습니다.

  • CDN의 캐싱: 미디어, JavaScript, CSS와 같은 리소스 또는 HTML이 CDN의 캐시에서 제공되는 경우 서버는 이러한 리소스를 제공하는 데 컴퓨팅 및 대역폭을 소비하지 않아도 되므로 프로세스 중에 서버 부하가 줄어듭니다. 일반적으로 페이지가 사용자의 브라우저에서 더 빠르게 로드되며 이는 전환수 증가와 관련이 있습니다.
  • 트래픽 폭증 보호: CDN은 과도하거나 악의적인 트래픽을 식별하고 차단하는 데 특히 효과적이므로 악의적인 봇이나 행위자가 서버에 과부하를 줄 때도 사용자가 사이트를 방문할 수 있습니다.
    폭주 방지 외에도 악성 트래픽을 차단하는 데 사용되는 것과 동일한 제어 기능을 특정 크롤러, 특정 패턴에 맞는 클라이언트, 동일한 IP 주소를 계속 사용하는 트롤 등 원치 않는 트래픽을 차단하는 데도 사용할 수 있습니다. 서버나 방화벽에서도 이 작업을 할 수 있지만 일반적으로 CDN의 사용자 인터페이스를 사용하는 것이 훨씬 쉽습니다.
  • 안정성: 일부 CDN은 사이트가 다운되더라도 사용자에게 사이트를 제공할 수 있습니다. 물론 이는 정적 콘텐츠에만 적용될 수 있지만, 이 정도만 되면 다른 곳으로 비즈니스를 옮기지 않아도 되기에 충분할 수 있습니다.

요약하자면 CDN은 유용한 도구입니다. 사이트가 크거나 대량의 트래픽이 예상되거나 이미 발생하고 있다면 가격, 성능, 안정성, 보안, 고객 지원, 확장성, 향후 확장 등의 요소를 고려하여 필요에 맞는 CDN을 찾아보세요. 호스팅 또는 CMS 제공업체에 문의하여 사용 가능한 옵션과 이미 사용 중인 옵션이 있는지 확인하세요.

크롤링이 CDN이 있는 사이트에 미치는 영향

크롤링 측면에서 CDN도 유용할 수 있지만 드물지만 크롤링 문제를 일으킬 수 있습니다. 계속 확인해 주세요.

CDN이 크롤링 속도에 미치는 영향

Google의 크롤링 인프라는 CDN을 기반으로 하는 사이트에서 더 높은 크롤링 속도를 허용하도록 설계되었습니다. CDN은 크롤러가 액세스하는 URL을 제공하는 서비스의 IP 주소에서 추론됩니다. 대부분의 경우 이 방법이 효과적입니다.

오늘 스톡 사진 사이트를 시작했는데 스톡에 1,000,007개의 사진이 있다고 가정해 보겠습니다. 모든 제품에 대한 방문 페이지, 카테고리 페이지, 세부정보 페이지를 포함하여 웹사이트를 출시하면 페이지가 많아집니다. 크롤링 용량 한도에 관한 문서에서는 Google 검색에서 이러한 페이지를 최대한 빨리 크롤링하려고 하지만 크롤링으로 인해 서버가 과부하되어서는 안 된다고 설명합니다. 크롤링 요청 수가 증가하여 서버가 느리게 응답하기 시작하면 서버가 과부하되지 않도록 Google 측에서 제한이 적용됩니다. Google의 크롤링 인프라가 사이트에서 CDN을 기반으로 한다는 것을 감지하고 서버가 이를 처리할 가능성이 높으므로 동시 요청을 더 많이 보내도 괜찮다고 가정하여 웹 스토어를 더 빠르게 크롤링하는 경우 이 제한의 기준점이 훨씬 높습니다.

그러나 URL에 처음 액세스할 때는 CDN의 캐시가 '콜드' 상태입니다. 즉, 아직 아무도 해당 URL을 요청하지 않았으므로 콘텐츠가 아직 CDN에 캐시되지 않았습니다. 따라서 원본 서버는 CDN의 캐시를 '워밍업'하기 위해 해당 URL을 한 번 이상 제공해야 합니다. 이는 HTTP 캐싱이 작동하는 방식과도 매우 유사합니다.

즉, 웹 스토어가 CDN을 지원하더라도 서버는 이러한 1,000,007개의 URL을 한 번 이상 제공해야 합니다. 최초 제공 후에만 CDN에서 캐시를 지원할 수 있습니다. 이는 '크롤링 예산'에 상당한 부담이 되며 며칠 동안 크롤링 속도가 빨라질 수 있습니다. 한 번에 여러 URL을 출시할 계획이라면 이 점을 유의하세요.

CDN이 렌더링에 미치는 영향

첫 번째 리소스 크롤링에 관한 12월 크롤링 블로그 게시물에서 설명한 대로 리소스를 자체 호스트 이름 또는 CDN 호스트 이름(cdn.example.com)으로 분할하면 웹 렌더링 서비스(WRS)가 페이지를 더 효율적으로 렌더링할 수 있습니다. 단, 이 방법은 다른 호스트 이름에 연결하는 오버헤드로 인해 페이지 성능에 부정적인 영향을 미칠 수 있으므로 렌더링 성능과 함께 페이지 경험을 신중하게 고려해야 합니다.

CDN으로 기본 호스트를 지원하면 이 문제가 방지됩니다. 쿼리할 호스트 이름이 하나이고 중요한 렌더링 리소스는 CDN의 캐시에서 제공될 가능성이 높으므로 서버에서 리소스를 제공할 필요가 없으며 페이지 경험에 영향을 미치지 않습니다.

마지막으로 비즈니스에 가장 적합한 솔루션을 선택합니다. 정적 리소스에 별도의 호스트 이름(cdn.example.com)을 사용하거나, 기본 호스트 이름을 CDN으로 지원하거나, 둘 다를 실행합니다. Google의 크롤링 인프라는 두 옵션을 모두 문제없이 지원합니다.

CDN이 과보호하는 경우

CDN의 폭증 보호 및 크롤러의 크롤링 방식으로 인해 사이트에 필요한 봇이 CDN의 차단 목록(일반적으로 웹 애플리케이션 방화벽(WAF))에 포함되는 경우가 있습니다. 이렇게 하면 크롤러가 사이트에 액세스할 수 없게 되며, 결국 사이트가 검색 결과에 표시되지 않을 수 있습니다. 차단은 다양한 방식으로 발생할 수 있으며, 그중 일부는 다른 차단보다 사이트의 Google 검색 결과 노출에 더 부정적인 영향을 줄 수 있습니다. 또한 차단은 CDN 측에서 이루어지므로 관리하기가 쉽지 않거나 불가능할 수 있습니다. 이 블로그 게시물에서는 이를 하드 차단과 소프트 차단이라는 두 가지 버킷으로 분류했습니다.

하드 차단

하드 차단은 CDN이 크롤링 요청에 어떤 형태로든 오류가 포함된 응답을 전송하는 경우를 말합니다. 여기에는 다음이 포함됩니다.

  • HTTP 503/429 상태 코드: 일시적인 차단을 알리는 권장되는 방법은 이러한 상태 코드를 전송하는 것입니다. 이렇게 하면 CDN의 의도하지 않은 차단에 대응할 수 있는 시간이 확보됩니다.
  • 네트워크 시간 초과: CDN의 네트워크 시간 초과로 인해 영향을 받는 URL이 Google 검색 색인에서 삭제됩니다. 네트워크 오류는 심각한 '하드' 오류로 간주되기 때문입니다. 또한 사이트에 과부하가 발생했다고 크롤링 인프라에 신호를 보내므로 사이트의 크롤링 속도에 상당한 영향을 미칠 수 있습니다.
  • HTTP 200 상태 코드가 포함된 임의의 오류 메시지: 소프트 오류라고도 하며 특히 심각합니다. Google 측에서 오류 메시지를 '하드' 오류(예: HTTP 500)로 간주하면 Google에서 검색에서 URL을 삭제합니다. Google에서 오류 메시지를 '하드' 오류로 감지하지 못한 경우 동일한 오류 메시지가 있는 모든 페이지가 Google 검색 색인에서 중복으로 삭제될 수 있습니다. Google 색인 생성에는 중복 URL의 재크롤링을 요청할 유인이 거의 없으므로 이 문제를 해결하는 데 시간이 더 걸릴 수 있습니다.

소프트 차단

CDN에서 '인간입니까' 전면 광고를 표시할 때도 유사한 문제가 발생할 수 있습니다.

인간이라고 불리는 것에 혼란스러워하는 크롤리

Google 크롤러는 자신이 인간이 아니며 인간인 척하지 않는다고 확신합니다. 크롤링만 하고 싶어 합니다. 하지만 전면 광고가 표시되면 멋진 사이트가 아닌 전면 광고만 보게 됩니다. 이러한 봇 인증 전면 광고의 경우 크롤러와 같은 자동화된 클라이언트에 콘텐츠를 일시적으로 사용할 수 없다는 명확한 신호를 503 HTTP 상태 코드 형식으로 보내는 것이 좋습니다. 이렇게 하면 콘텐츠가 Google 색인에서 자동으로 삭제되지 않습니다.

차단 디버깅

하드 차단과 소프트 차단이 모두 발생한 경우 제대로 작동하는지 확인하는 가장 쉬운 방법은 Search Console의 URL 검사 도구를 사용하고 렌더링된 이미지를 확인하는 것입니다. 페이지가 표시되면 문제가 없는 것입니다. 빈 페이지, 오류 또는 봇 문제 페이지가 표시되면 CDN에 문의하는 것이 좋습니다.

또한 이러한 의도치 않은 차단을 방지하기 위해 Google, 다른 검색엔진, 기타 크롤러 운영자는 Google의 IP 주소를 게시하여 Google 크롤러를 식별하고 적절하다고 판단되면 WAF 규칙에서 차단된 IP를 삭제하거나 허용 목록에 추가할 수 있도록 지원합니다. 이 작업을 수행할 수 있는 위치는 사용 중인 CDN에 따라 다릅니다. 다행히 대부분의 CDN 및 독립형 WAF과 관련된 훌륭한 문서가 있습니다. 다음은 약간의 검색으로 찾은 내용입니다(이 게시물 게시 시점 기준).

사이트가 검색엔진에 표시되어야 하는 경우 중요한 크롤러가 사이트에 액세스할 수 있는지 확인하는 것이 좋습니다. IP가 알지 못하는 사이에 자동으로 차단 목록에 추가될 수 있으므로 가끔 차단 목록을 확인하는 것이 사이트의 검색 및 기타 실적을 높이는 데 도움이 됩니다. 차단 목록이 매우 긴 경우(이 블로그 게시물과 마찬가지로) IP 범위의 처음 몇 개 세그먼트만 찾으세요. 예를 들어 192.168.0.101을 찾는 대신 192.168만 찾으면 됩니다.

크롤링 12월 블로그 게시물 시리즈의 마지막 게시물입니다. 작성하는 동안 즐거웠던 만큼 여러분께도 도움이 되었기를 바랍니다. 하실 말씀이 있다면 어떻게 해야 하는지 아실 겁니다.

게시자: 마틴 스플리트, 게리 일리즈

크롤링에 대해 자세히 알아보시겠어요? 12월 크롤링 시리즈 전체를 확인해보세요.