원본이 503이어도 화면은 200: 오래된 캐시를 구분하는 법

목록 페이지에 저장본이 있어도 원본 서버가 잠깐 실패하면 사용자에게 오류를 보여줘야 할까. 갱신 전 데이터를 잠시 보여줘도 되는 화면이라면 다른 선택이 가능하다. 다만 사용자 응답이 정상이라고 원본도 정상이라고 판단해서는 안 된다.

정상 응답 하나를 저장한 뒤 원본만 실패시켰다

실험용 Python 서버는 처음에 snapshot-v1이라는 고정 문자열을 200으로 반환했다. Nginx가 이 응답을 캐시하도록 설정하고 같은 주소를 두 번 요청했다. 이후 실험용 서버를 503 응답으로 바꾸고 캐시 유효기간이 지난 뒤 다시 요청했다. 실제 외부 API나 유료 서비스는 호출하지 않았다.

proxy_cache_valid 200 1s;
proxy_cache_use_stale error timeout http_503;
add_header X-Lab-Cache $upstream_cache_status always;

1초는 변화를 짧은 실험에서 확인하기 위한 값이다. 실제 서비스에 그대로 적용할 권장 갱신 주기가 아니다. 완전한 실험 설정과 실행 스크립트는 글 아래 원자료에 포함했다.

정상 화면과 정상 원본은 서로 다른 신호다

마지막 요청에서 이용자가 받은 것은 200이지만 원본 서버는 503이었다. 본문은 첫 성공 응답과 같았고 캐시 상태에는 STALE이 표시됐다. 이 구성이 화면의 연속성을 지켜준 동시에, 상태 코드만 보는 모니터링에서는 원본 장애가 가려질 수 있다는 점도 확인했다.

관찰 항목을 세 줄로 나누는 것이 좋다. 사용자에게 보낸 상태, 원본에서 받은 상태, 마지막 성공 데이터의 시각이다. 오래된 데이터를 보여주는 동안에도 원본 오류를 기록하고 데이터 나이를 확인할 수 있어야 한다. 실험의 X-Lab-Cache 헤더는 그중 캐시 상태를 보기 위한 보조 장치다.

저장본을 써도 되는 화면인지 먼저 판단하기

이 실험은 누구에게나 같은 짧은 텍스트를 대상으로 했다. 사용자별 쿠키, 인증, 변경 요청을 섞지 않았다. 성공 저장본이 없는 첫 방문에도 같은 동작을 기대할 수는 없다. 빈 캐시와 이미 저장된 캐시의 실패 시나리오를 구분해서 설계해야 한다.

1. 저장본이 있는가

   없으면 stale로 제공할 이전 응답도 없다.

2. 원본 요청은 성공했는가

   사용자 200과 원본 성공을 서로 다른 값으로 본다.

3. 본문 버전이 바뀌었는가

   복구 후 새 내용과 다음 HIT가 같은 버전인지 확인한다.

본문의 세 줄 설정은 proxy_cache·proxy_pass가 있는 location 내부의 일부다. 캐시 저장 영역과 키, upstream 주소를 생략한 예제이므로 독립 설정으로 붙여 넣지 않는다. 전체 로컬 설정은 최초 원자료 JSON의 configuration에서 볼 수 있다. X-Lab-Cache는 실험용 헤더이며 다른 CDN의 상태 표시와 같은 이름이나 의미를 가정하지 않는다.

운영에 옮기기 전 남길 기록

오래된 데이터의 허용 시간, 원본 실패 알림 조건, 정상으로 돌아왔을 때 갱신되는 경로를 정한다. 화면이 계속 보인다는 사실만으로 장애 대응을 끝내지 않는다. 이 글의 설정은 원리를 보여주는 작은 실험이며 인증·개인화·전체 캐시 정책을 대신하지 않는다.

추가 확인: 저장본이 없는 주소는 503이 남았다

후속 실험에서는 같은 캐시 설정 아래 두 주소를 사용했다. /cached/warm은 정상 응답을 미리 저장하고 /cached/empty는 원본을 503으로 바꾼 뒤 처음 요청했다. 1초 유효기간 이후 warm의 저장본을 요청하는 순서도 유지했다. 이 차이를 통해 “오래된 응답을 쓰는 정책”과 “아무 응답도 저장한 적 없는 상태”를 나눴다.

표의 stale은 유효기간이 지난 warm 주소에 대한 요청이다. 저장된 snapshot-v1을 200으로 돌려줬다. 반면 empty는 MISS와 503을 반환했다. use_stale 설정이 응답을 새로 만들어 주는 것은 아니며, 내보낼 저장본이 없는 경우에는 원본 실패가 사용자에게 드러났다는 결과다.

원본 복구 후에는 본문까지 바뀌는지 확인한다

다음에는 합성 원본을 200으로 되돌리고 본문을 snapshot-v2로 바꿨다. warm 주소의 첫 복구 요청은 EXPIRED였으며 본문이 v2로 갱신됐다. 바로 뒤의 요청은 HIT와 v2였다. 상태 코드가 계속 200이더라도 v1에서 v2로 실제 내용이 교체됐는지 확인해야 복구 후 갱신을 구분할 수 있다.

여기서 EXPIRED는 오류 이름이 아니라 만료된 캐시를 가진 요청에서 관찰한 캐시 상태다. STALE을 봤다고 원본이 반드시 장애라는 일반 규칙으로 확대하는 것도 피해야 한다. 이 실험에서는 우리가 원본을 503으로 고정해 원인을 알고 있었지만, 실제 설정의 다른 stale 사용 조건은 별도로 확인해야 한다.

빈 캐시의 첫 화면 정책을 별도로 정하기

이 실험의 세 응답을 진단 메모로 옮기면 ‘warm: 200/STALE/snapshot-v1’, ‘empty: 503/MISS’, ‘복구 첫 요청: 200/EXPIRED/snapshot-v2’가 됩니다. 200 두 개도 마지막 성공 본문과 갱신 결과가 다릅니다. MISS와 503을 본 주소에는 내보낼 성공 저장본이 없었고, 복구 확인에는 상태 200뿐 아니라 v2가 필요했습니다. 실제 서비스에서는 이 표의 합성 문자열 대신 확인 가능한 자료 버전·마지막 성공 시각을 사용하며, 다른 stale 조건의 원인은 자신의 설정에서 따로 확인합니다.

python3 run-lab.py --output observations.json

python3 lab-nginx-boundaries.py --output new-observations.json