- Crawl Budget Management For Large Sites | Google Search Central | Documentation | Google for Developers
- Learn what crawl budget is and how you can optimize Google's crawling of large and frequently updated websites.
AI가 번역한 다른 언어 보기
durumis AI가 요약한 글
- 구글 검색 크롤링 예산 효율적 활용을 위해 웹페이지 전송 속도 개선 및 Cloud Run 기반 Redirect 서비스 도입을 진행했습니다.
- robots.txt, favicon.ico 등 정적 파일 및 리다이렉션 로직을 Cloud Run으로 이전하여 기존 GKE Autopilot 대비 응답 속도를 200ms에서 20ms로 개선했습니다.
- 전 세계 다양한 리전에 Cloud Run 배포를 통해 사용자 위치에 가까운 서버에서 서비스를 제공하여 속도 향상 및 비용 절감 효과를 얻었습니다.
모든 컨텐츠를 메인으로 하는 서비스들은 구글의 검색에 많이 노출되기를 원합니다.
그런데, 구글의 검색에 노출되기 위해서는 크롤러가 자주 들어와서 최신 데이터를 크롤링해가고, 그걸 잘 반영해 줘야 합니다.
이때, 크롤러가 웹 사이트에 더 자주 들어오기 위해서는 "크롤링 예산"이라는것을 이용해서 예산이 더 높으면 더 자주 들어올 수 있고, 그러기 위해서는 사이트의 트래픽이 어느정도 나와줘야 합니다.
그렇다면 이 제한된 "크롤링 예산"을 어떻게 효율적으로 활용해야 같은 예산에서 더 자주 들어올까요?
그것은 사이트의 웹페이지 전송 속도가 빨라야 합니다. 예를들면 페이지 다운로드 시간이 200ms 인 사이트 보다 20ms 인 사이트는 더 자주 페이지를 크롤링해가는것이죠.
저희 두루미스는 기본적으로 "글로벌 서비스"를 지향하기 때문에, 전세계 8개 리전에서 기본적인 트래픽을 서비스 하고 있습니다.
GCP 서버 리전
현재 기본적으로 저희 서비스는 구글의 40개의 리전중에서 아시아의 서울, 싱가포르, 뭄바이, 유럽의 벨기에, 미국의 로스엔젤레스, 사우스 캐롤라이나에 있는 리전을 활용하고 있습니다. 전세계 어디에서 접속하더라도 웬만해서는 느리지 않게 접속이 가능한것이죠.
그런데, 앞에서 이야기한 이유로 좀 더 극한의 속도를 위해서 조금 더 튜닝하기로 했습니다.
현재 저희 서비스는 초기 런칭때 URL 방식에서 새로운 서브도메인 방식으로 변경하는 과정을 거치고 있어서, Redirect가 일부 있으며, 이 부분에 많은 구글의 크롤러 방문이 있습니다. 기존의 URL을 새로운 URL로 구글에 빠르게 인지 시켜줘야 할 이유가 있는것이죠.
따라서 주어진 크롤러 예산을 최대한 활용하기 위해서, Redirect 용 트래릭은 최대한 빠른 속도를 유지할 필요가 있는것입니다.
기존에는 위에서 언급한 8개 리전에 GKE 가 배치되어 있으며, 각각의 GKE 는 구글의 GKE Autopilot 을 활용하여 DB와 연동되지 않는 데이터를 이용하여 Redirect를 하고 있습니다.
따라서, 이번에 GKE에 있는 그리고 기존에 다른 Cloud Run에 있던 일부 로직을 새로운 Cloud Run 으로 이전하기로 했습니다. 이전하려는 리스트는 다음과 같습니다.
- robots.txt : 정적인 파일이긴 하지만, 여러 서브 도메인에서 일정 로직으로 된 내용들을 서빙하고 있다.
- favicon.ico : 순수 정적 파일
- durumis.com/[lang]/@userId/postID : 새로운 URL로 리다이렉트 -> userId.durumis.com/[lang]/postID
기존에는 GKE Autopilot 에 있는 약간은 무거운 프레임워크를 통해서 서빙을 했을때는 약 200ms 의 응답시간을 보였습니다.
새로운 방법은 Cloud Run 을 이용해서 돌리고, 워낙 간단한 로직이어서 프레임워크를 사용하지 않고, node:http 를 이용 라이브러리 없이 기본코드를 활용하였습니다.
const http = require("http"); const fs = require("fs"); const path = require("path"); let cachedFavicon = null; function loadFavicon() { const faviconPath = path.join(__dirname, "favicon.ico"); try { cachedFavicon = fs.readFileSync(faviconPath); console.log("Favicon loaded into memory"); } catch (err) { console.error("Error loading favicon:", err); } } --- 생략 --- const server = http.createServer((req, res) => { if (req.url === "/favicon.ico") { res.writeHead(200, { "Content-Type": "image/x-icon", "Cache-Control": "public,max-age=2419200" } res.end(cachedFavicon); }); server.listen(port, () => { console.log(Server running at http://localhost:${port}/); });
( 위의 코드를 그대로 넣으면 동작하지 않습니다. 대충 개념만 이해 하셔야 합니다. )
favicon.ico의 경우에는 이미지 파일이기때문에 file에서 불러와서 메모리에 상주시키고, 그것을 이용하여 전송하는 방식을 선택하였습니다.
쉘 스크립트를 활용하여 gcloud 를 이용하여 여러개의 리전에 동시에 배포를 시킵니다.
짜잔..
그렇게 해서 배포한 결과는 다음과 같습니다.
Cloud Run 화면
미국의 "모든 리전" 에 배포를 하고, 각 대륙별로 유럽에 2개, 아시아에 2개 , 아프리카에 1개, 남미에 2개의 리전에 배포를 하였습니다. 사실 Serverless 의 장점인데, 저렇게 한다 하더라도 전혀 비용이 증가하지 않습니다. ( 오히려 멀지 않은 곳의 트래픽을 서빙하게 되면 비용이 감소할 수도 있습니다. )
자. 이렇게 해서 속도는 얼마나 빨라 졌을까요.
기존의 서버측 응답속도는 다음과 같습니다.
GKE Autopilot
개선된 속도는 다음과 같습니다.
Cloud Run 을 활용한 Static File
당연히 Cloud Run 은 Serverless 니까 콜드 스타트 시간이 있지 않나..라고 생각하실수 있는데, 일정 주기로 꾸준히 크롤링이 들어오는 상황에서는 사실 크게 문제 되지 않습니다. GCP의 Serverless 의 특징중 하나인데, Standby 와 Idle 을 왔다갔다 하면서 대기하고 있기 때문이죠. ( 비용이 늘어나는것도 아니구요 )
다음 포스트에서는 위와 같은 작은 정적파일 혹은 301 Redirect 가 아닌, 이미지 파일이나 기타 다른 파일들에 대한 부분들을 설명하도록 하겠습니다.