패스틀리(Fastly), Stale Content 제공하기

 

Stale Content 제공하기

 

웹 서비스 운영 시, 오리진 서버의 장애나 지연, 혹은 네트워크 문제가 발생하면 정상적인 콘텐츠 제공이 어려워질 수 있습니다. Fastly는 이러한 상황에서도 사용자 경험을 보호하기 위해 stale(오래된) 콘텐츠를 임시로 제공하는 기능을 제공합니다. 이 글에서는 Fastly 공식 문서에 따라 stale 콘텐츠 제공 방식과 설정 요소를 정리해 보겠습니다.

---

1. Stale Content란 무엇인가?

Stale 콘텐츠는 TTL(Time-To-Live)이 만료되었지만 Fastly 캐시에 남아 있는 객체를 의미합니다.

일반적으로 TTL이 만료되면 Fastly는 오리진에서 새로운 콘텐츠를 받아 오려고 하지만, 특정 상황에서 오리진이 응답하지 못할 수 있습니다. 이때 Fastly는 사용자에게 오류가 아닌 캐시된 오래된 콘텐츠를 제공하여 서비스 연속성을 유지할 수 있습니다.

---

2. Stale 콘텐츠가 제공되는 주요 상황

Fastly는 아래와 같은 경우 stale 콘텐츠를 제공할 수 있습니다.

 

① 오리진 서버가 오류를 반환하는 경우

• 500, 502, 503 등 오류 발생 시 Fastly는 stale 객체를 반환할 수 있습니다.

② 오리진 서버의 타임아웃이 발생한 경우

• 오리진에 연결하거나 응답을 받는 과정에서 시간이 초과될 경우 stale 콘텐츠 제공이 가능.

③ 재검증(revalidation) 실패 시

오브젝트가 만료되어 오리진과 재검증을 시도하지만

• 오리진이 응답하지 않거나
• 304 Not Modified로 재검증되지 못한 경우

Fastly는 stale 콘텐츠 제공을 선택할 수 있습니다.

---

 

3. Stale 콘텐츠 제공을 제어하는 방법

Fastly는 stale 제공 동작을 여러 방식으로 제어할 수 있습니다.

---

(1) Cache-Control 헤더를 통한 제어

 

오리진이 응답 헤더에 다음과 같은 값을 지정하면 Fastly가 stale 콘텐츠를 제공할 수 있는 조건을 설정할 수 있습니다.

 

 

• stale-if-error

오리진이 오류를 반환하면, 해당 시간 동안 stale 콘텐츠 제공을 허용합니다.

 

예시:

Cache-Control: max-age=600, stale-if-error=86400

→ TTL 만료 후 24시간 동안 오류가 발생하면 stale 콘텐츠를 제공.

---

• stale-while-revalidate

Fastly가 오리진에 재검증 요청을 보내는 동안 사용자에게 stale 객체를 제공하도록 허용합니다.

 

예시:

Cache-Control: max-age=600, stale-while-revalidate=60

→ 만료된 후 재검증이 60초 안에 완료되지 않더라도 stale 콘텐츠를 반환해 사용자 체감 속도를 높임.

---

(2) VCL을 통한 stale 제어

 

더 정교한 제어가 필요할 경우, VCL에서 stale 제공 정책을 설정할 수 있습니다.

 

문서가 설명하는 주요 포인트는 다음과 같습니다.

 

• 오브젝트가 stale이 되었을 때 Fastly가 이를 반환할지 여부는 VCL에서 결정 가능
• 오리진 오류·타임아웃 발생 시 stale 객체 반환 정책을 조정할 수 있음
• 특정 조건(예: 특정 경로, 특정 헤더)에 따라 stale 제공을 선택적으로 허용 가능

 

이 방식은 정교한 커스터마이징이 필요한 서비스에서 유용합니다.

---

4. Stale Content 제공의 장점

 

문서에서는 Fastly 기능적인 측면에서 아래와 같은 장점을 제시합니다.

 

✔ 서비스 가용성 향상

오리진 장애가 발생해도 사용자에게 콘텐츠 제공 가능.

 

✔ 사용자 경험 안정성 확보

오리진 응답 지연 또는 불안정 상황에서도 빠르고 정상적인 화면 제공.

 

✔ 트래픽 폭주 상황에서 오리진 보호

TTL 만료 후에도 즉시 오리진으로 재요청되지 않도록 하여 부하 증가 방지.

 

---

5. Stale Content의 동작 요약

상황Fastly 동작

TTL 유효	Fresh 콘텐츠 제공
TTL 만료 → 재검증 성공	최신 콘텐츠 제공
TTL 만료 → 재검증 실패	Stale 콘텐츠 제공 가능
오리진 오류 or 타임아웃	Stale 콘텐츠 반환 가능 (stale-if-error)
재검증 중	Stale 제공 가능 (stale-while-revalidate)

 

---

6. 주의해야 할 점

Fastly는 오리진 오류나 재검증 지연 시 stale 콘텐츠를 제공할 수 있지만, 특정 조건이 충족되지 않으면 stale 기능이 기대대로 작동하지 않을 수 있습니다. 아래는 문서에서 설명하는 주요 원인과 고려사항입니다.

 

1) 캐시 관련 조건 (Cache)

 

Stale 콘텐츠는 캐싱 가능한(cacheable) 객체에 대해서만 존재합니다.

캐시가 불가능한 응답이나 캐시에 저장되지 않은 객체는 stale로 제공될 수 없습니다.

 

2) VCL 설정 영향 (VCL)

 

다음 두 VCL 변수는 stale 기능을 무효화합니다:

 req.hash_always_miss = true

• 항상 캐시 미스로 처리하므로 stale 객체가 있어도 사용하지 않음.

req.hash_ignore_busy = true

• 바쁜 상태(busy object) 처리 무시 → stale-while-revalidate 효과 상실.

 

이 두 값을 사용하면 stale-while-revalidate가 동작하지 않음.

 

3) Shielding 사용 여부 (Shielding)

 

Shielding이 없을 경우:

 

• 각 POP은 그 POP에서 해당 객체가 요청된 적이 있어야 stale 콘텐츠를 제공할 수 있음.
• 요청 이력이 없는 POP에는 stale가 존재하지 않을 수 있음.

Fastly의 권장사항

• Shielding을 활성화하면 stale 객체가 존재할 가능성이 크게 증가.
• 특히 purge all 이후 캐시를 빠르게 다시 채우는 데도 효과적.

 

4) 요청량(Requests)의 영향

 

트래픽이 증가할수록 stale 객체가 여러 POP에 저장될 가능성이 높아짐.

• 인기 있는 컨텐츠는 자연스럽게 여러 POP에 캐시됨.
• Shielding이 없어도 트래픽이 많은 사이트는 stale 제공 확률이 높아짐.

 

5) Fastly의 LRU(Least Recently Used) 정책

 

Fastly는 LRU 정책으로 캐시 공간을 관리하기 때문에:

• 객체가 TTL 전체 기간 동안 캐시에 유지된다고 보장할 수 없음.
• 객체가 캐시에서 **일찍 제거(eviction)**될 수 있음.

특징

• 요청 빈도, TTL, POP의 상황 등 다양한 요소가 eviction에 영향을 줌.
• TTL이 3700초 이상인 객체는 디스크에도 저장됨.
• TTL이 짧으면 메모리에서만 유지(transient), 그리고 더 빨리 evict될 가능성 있음.

Fastly의 권장사항

• 가능하다면 TTL을 3700초 이상으로 설정.

 

---

정리

 

Fastly의 stale content 제공 기능은 오리진의 장애나 지연 상황에서도 서비스를 안정적으로 유지하는 데 중요한 역할을 합니다.

오리진이 단순히 느린 경우는 물론, 오류나 타임아웃 발생 시에도 Fastly는 stale 객체를 제공해 서비스 중단 없이 사용자 경험을 보호합니다. 오리진에서 Cache-Control 헤더를 적절히 설정하거나 VCL을 통해 상세한 정책을 구성하여, 서비스 요구에 맞는 최적의 stale 제공 전략을 만들 수 있습니다.