Fastly X-Cache 읽는 법: HIT·MISS만으로 오리진 요청을 판단하면 안 되는 이유

Fastly를 운영하다 응답 헤더에서 MISS를 발견하면 캐시가 제대로 동작하지 않는다고 생각하기 쉽습니다. 하지만 실드가 있는 경로에서는 어느 위치의 MISS인지부터 구분해야 하죠. 같은 두 단어라도 순서가 바뀌면 이번 요청이 처리된 위치와 기록의 시점이 달라지죠.

이 글은 Fastly 공식 문서의 대표적인 실드·엣지 캐시 사례를 기준으로 헤더를 읽는 방법을 정리합니다. 헤더만 보고 설정을 바꾸기보다, 어떤 근거가 더 필요한지 찾는 데 사용하는 안내예요.

Fastly의 X-Cache는 어떤 정보를 보여주나요?

X-Cache는 Fastly의 처리 상태를 HIT 또는 MISS로 단순화해 보여주는 응답 헤더입니다.

Fastly X-Cache 공식 문서는 이 값을 fastly_info.state에서 파생한 간단한 표시로 설명합니다. 상태가 HIT이거나 HIT-로 시작하면 HIT, 그 밖에는 MISS로 표시하죠.

따라서 MISS를 캐시를 조회했지만 객체가 없었다는 뜻으로만 읽으면 놓치는 조건이 있죠. 캐시를 우회하는 PASS도 MISS로 보고됩니다. 반대로 엣지에서 생성한 합성 응답도 HIT로 표시되므로, HIT가 항상 저장된 오리진 객체를 전달했다는 증거는 아니죠.

stale 응답 제공이나 백그라운드 재검증에 따른 적중도 HIT로 표시합니다. HIT라는 단어만으로 최신 콘텐츠인지, 재검증이 필요 없는지까지 판단하기는 어려워요. 응답 상태와 콘텐츠의 신선도는 별도로 확인할 항목입니다.

Fastly 캐시 수명과 재검증 공식 문서는 stale-while-revalidate에서 사용자에게 stale 응답을 제공하면서 별도 백그라운드 요청으로 오리진의 콘텐츠를 재검증하는 동작을 설명합니다. 따라서 사용자 응답의 HIT와 별도 오리진 재검증 요청은 함께 발생할 수 있습니다. 사용자 응답을 어디에서 얻었는지와 같은 시점에 별도 백그라운드 요청이 있었는지를 구분해야 합니다.

HIT, MISS는 어느 POP에서 적중했다는 뜻인가요?

일반적인 실드·엣지 두 POP 사례에서 HIT, MISS는 실드 적중과 엣지 미적중을 나타냅니다.

POP는 Fastly가 요청을 처리하는 거점입니다. 아래 표는 Fastly Shielding 공식 문서의 대표적인 캐시 경로를 정리한 것으로, 왼쪽이 실드이고 오른쪽이 사용자와 연결된 엣지입니다. 사용자 요청이 이동하는 방향이 아니라 응답이 처리되는 순서로 읽는 것이 핵심이죠.

이 표의 HIT, MISS는 실드에서 응답을 얻었으므로 오리진 요청이 필요하지 않은 사례입니다. MISS가 하나 포함됐다는 이유로 캐시 전체가 실패했다고 판단하면 안 되죠. 공식 문서는 이때 적중률 계산에는 적중과 미적중이 각각 반영된다고 설명합니다.

표는 모든 Fastly 응답을 포괄하는 판정 규칙이 아닙니다. Next-gen WAF at Edge나 사용자 정의 VCL의 restart로도 여러 서버 기록이 생길 수 있어요. 실제 서비스의 경로와 헤더 변경 설정을 확인한 뒤 이 사례에 해당하는지 판단해야 해요.

MISS, HIT의 MISS는 이번 요청에서 발생했나요?

대표적인 두 POP 캐시 사례에서 MISS, HIT의 첫 MISS는 과거 캐시 저장 당시의 기록입니다.

처음 요청에서 엣지와 실드 모두 캐시에 객체가 없었다면 MISS, MISS가 나타날 수 있습니다. 이후 엣지가 해당 객체를 캐시에서 제공하면 MISS, HIT가 보일 수 있죠. 이때 첫 MISS는 앞서 실드에서 객체를 가져오던 시점의 정보예요.

앞선 표의 일반적인 캐시 적중 사례에서는 사용자 응답을 엣지에서 제공하며, 실드 응답을 다시 받아오지 않습니다. 별도 백그라운드 재검증이 발생하는지는 이 헤더만으로 판단하지 않습니다. 따라서 이 응답으로 지금도 실드에 객체가 없다고 결론 내릴 수는 없어요. HIT, HIT도 첫 HIT는 과거 기록이라는 점이 같습니다.

예를 들어 연속 응답에서 첫 번째 값이 계속 MISS라 해도 그 값만 보고 실드 설정 오류로 판단하지 않습니다. 이번 요청에서 새로 발생한 결과와 캐시 객체에 남아 전달된 정보를 나누어야 하죠. 이 차이를 놓치면 정상적인 엣지 적중을 문제로 오해할 수 있죠.

실드의 구조와 도입 효과는 기존 글 오리진을 지키는 캐시 한 겹 더: 오리진 실드와 계층형 캐시의 원리에서 확인할 수 있습니다. 여기서는 구조를 다시 설계하기보다 지금 보고 있는 헤더가 어느 시점을 나타내는지에 집중합니다.

헤더 순서와 각 숫자는 무엇과 함께 읽나요?

X-Served-By로 각 항목의 서버를 대조하고, X-Cache-Hits는 서버별 횟수로 읽습니다.

X-Served-By 공식 문서는 응답을 전달한 노드의 식별 정보를 설명합니다. 실드·엣지 두 POP 예시에서는 X-Cache의 왼쪽 값과 왼쪽 서버, 오른쪽 값과 오른쪽 서버를 대응시키는 방식이죠. 다만 두 값 중 오른쪽이 HIT라면 세 디버깅 헤더의 왼쪽 항목은 과거 실드 응답의 정보라는 조건을 함께 적용합니다.

X-Cache-Hits 공식 문서는 적중 횟수가 개별 캐시 서버 단위임을 명시합니다. 같은 POP 안에서도 객체를 보관한 서버가 여럿일 수 있어 숫자가 다르게 보일 수 있죠. 이 값을 서비스 전체 요청 수나 전체 캐시 적중률로 계산하지 않는 것이 좋아요.

노드 식별자는 재사용될 수 있고 노드 구성도 달라질 수 있습니다. 서로 다른 시점의 식별자를 영구적인 서버 신원처럼 사용하는 것은 피해야 하죠. 비교할 때는 응답을 받은 시각과 경로 조건을 같이 남겨 두세요.

X-Cache 값이 하나라는 사실만으로 실드가 꺼졌다고 판단하지도 않습니다. 실드를 설정했어도 사용자가 지정된 실드 POP에 직접 도착하는 사례가 있어요. 실드가 없는 구성도 값이 하나일 수 있으므로 실제 설정과 함께 확인해야 합니다.

Fastly 설정을 점검하기 전 어떤 기록을 모으나요?

대상 URL과 요청 조건, 응답 헤더와 시각을 함께 기록한 뒤 설정·오리진 로그와 대조합니다.

아래 항목은 이 글에서 제안하는 상담 준비 자료입니다. Fastly가 자동으로 하나의 진단 보고서를 만들어 준다는 기능 설명은 아니죠.

쿠키, 인증 토큰, 비밀 쿼리 값은 공유 자료에서 가려야 합니다. 조건 차이를 판단할 정보는 필요한 범위로 정리하되, 원본 자격 증명을 그대로 전달하지 마세요. 비교 기록은 문제를 재현한 조건을 설명하는 자료예요.

헤더가 없을 때도 캐시가 동작하지 않는다고 바로 판단하지 않죠. Fastly 문서는 VCL로 디버깅 헤더를 제거하거나 Fastly-Debug 조건에서만 제공하는 방식을 안내하죠. 우선 헤더 노출 정책을 확인하는 편이 좋아요.

스피디는 Fastly Korea Authorized Reseller로 Fastly 도입 상담을 제공합니다. 서비스와 국내 운영 소개는 Fastly 엣지 클라우드를 한국에서 도입하기: 글로벌 인프라와 스피디의 국내 운영에서 확인할 수 있어요. 문의할 때는 현재 헤더와 확인하려는 오리진 요청 조건을 함께 정리해 보세요.

이것만 기억하세요

자주 묻는 질문 (FAQ)