한 번 열어본 페이지를 다시 열면 빠르다. 당시 기록에서는 그런 화면 뒤에 숨어 있던 비용을 확인하려고 캐시가 없는 검색어와 주소를 따로 재현했다.

후속 관찰에서는 상세 화면 96ms, PDF 경로 13ms, 깊은 검색 11ms가 다시 발견됐다. 각 경로를 고친 뒤 기록에는 8ms, 4ms, 3ms가 남았다. 이미 캐시가 잘 맞는 조건만 확인했다면 이 문제를 다음 독자에게 설명할 수 없었을 것이다.

처음 들어오는 고객부터 생각한다

나는 내가 이미 여러 번 열어본 화면만 보고 사이트가 빠르다고 말하지 않는다. 처음 접속한 고객은 아직 준비되지 않은 화면을 만날 수 있다. 그 방문에서도 기다림과 실패를 줄이는 방법을 먼저 찾는다.

캐시 미적중은 오류와 같은 말이 아니다

R2에서 아직 저장되지 않은 화면을 찾는 404 뒤에 정상적인 가벼운 응답이 이어지는 구조도 있었다. 따라서 저장소의 404 횟수와 사용자 요청 실패 횟수를 같은 지표로 합치지 않았다.

대신 전체 흐름을 본다. 캐시 조회, 원본 조회, 변환, 응답, 다음 요청의 캐시 적중을 각각 기록한다. 캐시가 없을 때도 방문자는 의도한 내용과 상태를 받아야 한다.

내가 다시 확인하는 테스트 표

  1. 기존에 열어본 주소와 처음 보는 입력을 구별한다.
  2. 실제로 쓰는 캐시 키가 무엇인지 확인한다. 임의 쿼리 문자열을 붙였다고 우회됐다고 단정하지 않는다.
  3. 각 요청의 입력, 적중 여부, CPU, 벽시계 시간, 응답 상태와 내용 버전을 함께 적는다.
  4. 캐시가 없는 목록·상세·검색·HEAD 경로를 따로 확인한다.
  5. 필요한 경우 테스트 전용 키 공간으로만 캐시를 비우고 운영 전체를 초기화하지 않는다.

처음 방문한 사람이 받을 내용을 설계한다

공식 Cache API는 데이터센터별 캐시 동작을 설명한다. 어느 위치에서 한 번 채웠다는 사실을 전세계 모든 위치의 적중으로 생각하지 않는다. Worker CPU와 네트워크 대기 시간도 별도로 본다.

버전과 언어까지 확인한다

캐시된 영문 페이지에 한글 본문이 섞이거나 이전 배포의 콘텐츠가 남지 않는지 확인한다. URL만 적는 캐시 기록보다 언어·콘텐츠 버전·실제 키를 함께 남기는 기록이 낫다.

내가 얻은 운영 원칙은 단순하다. 빠른 두 번째 방문에 만족하기 전에, 느린 첫 방문도 설명할 수 있게 만든다.