브라우저 캐시Cache 작동원리와 이슈해결&방지 (feat. 디스크 캐시/메모리 캐시)

 

 

 

브라우저 캐시Cache 작동원리와 이슈해결&방지 가이드 (feat. 디스크 캐시/메모리 캐시)

 

 

최신 웹 배포에서 클라우드 캐싱을 효과적으로 관리하는 방법에 대해 알아봅니다.

"브라우저가 제공하는 모든 HTTP 요청은 먼저 브라우저 캐시로 라우팅되어 요청을 수행하는 데 사용할 수 있는 유효한 캐시 응답이 있는지 확인합니다. 일치하는 항목이 있으면 캐시에서 응답을 읽어 네트워크 대기 시간과 전송으로 인해 발생하는 데이터비용을 모두 제거합니다."

 

시작하며..

  현대 웹 애플리케이션의 퍼포먼스와 사용자 경험을 최적화하기 위해 클라우드 캐싱은 필수적인 요소로 자리 잡았습니다. 클라우드 캐싱은 네트워크 대기 시간과 데이터 전송 비용을 줄여 빠르고 효율적인 서비스를 제공할 수 있게 합니다.

  그러나 캐싱 메커니즘의 복잡성과 잘못된 설정으로 인해 예상치 못한 문제가 발생할 수 있습니다. 이 글에서는 클라우드 캐싱의 기본 로직과 검사 방법, 그리고 발생할 수 있는 이슈들을 분석하여 효과적인 캐싱 전략을 수립하는 데 도움이 되는 정보를 제공하고자 합니다.

 

기본 로직

최초 요청 시, 신규 또는 최신 파일에 대한 캐싱 이력이 없을 경우 다음과 같은 단계가 진행됩니다:

1. 최초 접속자가 Origin 서버로부터 파일을 요청하면, CloudFront(CF)에 파일이 캐싱됩니다.
2. 이후 접속자는 CF에 캐싱된 파일을 사용하여 캐싱하게 됩니다.

  파일이나 이미지를 수정해도 이름이 같다면, 그리고 TTL(Time to Live) 기간이 만료되지 않았다면 CF는 캐싱된 정보를 제공하게 됩니다. 따라서 Origin 서버의 최신화 작업이 확인되지 않습니다.

  TTL 만료 후 CF가 변경 내용을 확인한 후 Origin 서버의 최신 버전으로 갱신하지만, 즉시 반영시키려면 Invalidation(무효화) 처리를 통해 CF 캐시를 비워야 Origin 서버의 최신 파일을 로드할 수 있습니다.

 

TTL (Time to Live)

• TTL(Time to Live): 캐시의 만료 기간
• Cache-Control: max-age=86400(초 단위) 기본 86400초(24시간)으로 설정되며, Network 패널에서 확인 가능합니다. 이 값이 유효한 경우 서버를 거치지 않고 캐시에서 데이터를 제공합니다. (캐시를 사용하지 않도록 설정하는 Cache-Control: no-cache 속성도 있습니다)
• 1차 무효화 처리 후에도 일부 개체가 사용자의 메모리 캐시나 디스크 캐시에 남아있으면 반영이 되지 않을 수 있습니다. 이 경우 사용자가 강력 새로고침을 하거나 요청에 대해 강제로 최신 버전을 내려받도록 할 수 있습니다.

 

TTL 만료 후 프로세스

1. CloudFront는 최신 버전이 있는지 확인합니다.
2. 캐시에 이미 최신 버전이 있는 경우 Origin 서버는 status 304 코드(Not Modified)를 반환합니다.
3. CloudFront 캐시에 최신 버전이 없으면 Origin 서버에서 status 200 코드(OK)와 개체의 최신 버전을 반환합니다.

  정적 자원(html/css/js/img)의 경우 TTL 주기를 길게 설정하며, 강제 무효화는 연 1000회 무료로 제공되고 이후에는 소액의 과금이 발생합니다. 활발한 개발 단계에서는 TTL 주기를 짧게 설정하는 것이 좋습니다.

 

캐시 경로 패턴

• 현재 별도의 설정 없이 동일한 값으로 설정되어 있습니다.
• .min 파일의 버저닝(ver. 뒤에 붙는 숫자)을 통해 캐시된 파일이 새로 요청되도록 할 수 있습니다.
• 업로드된 이미지의 경우 prefix를 사용합니다.

CF에도 메모리 한계가 있어 모든 파일을 캐시 처리하는 것이 능사는 아니며, 상황에 따른 효율적 설정이 필요합니다.

 

검사 방법

개발자 도구의 Network 패널을 사용하여 요청된 데이터 리스트와 데이터 캐싱 여부 등을 확인합니다.

• Header > x-cache:
  • "Hit from cloudfront": 캐시된 데이터 제공
  • "Miss from cloudfront": 캐시되지 않은 데이터 제공
  •  

Network 패널 항목별 설명

1. Status 호출 상태 코드:
   • 2XX: 성공. 클라이언트가 요청한 동작을 수신하여 이해했고 승낙했으며 성공적으로 처리. 200 기존의 파일을 삭제하고 새로운 파일로 대체 또는 캐시
   • 3XX: 리다이렉션 완료. 클라이언트는 요청을 마치기 위해 추가 동작이 필요함. 내가 다 처리못해서 다른 애한테 위임하는 성격. (응답 코드가 304인 경우 "Not modified" 즉, 수정할 내용이 없다. 캐시에서 페이지를 로드하고 200이라면 새로 다운받은 후 Last-Modified 값을 갱신)
   • 4XX: 요청 오류. 클라이언트에 오류가 있음
   • 5XX: 서버 오류. 서버가 유효한 요청을 명백하게 수행하지 못했음
2. Initiator: 시작 지점
3. Size: 데이터 용량
   • disk cache: 강력 새로고침 시 삭제됨
   • memory cache: 브라우저 창을 닫으면 삭제됨
4. Time: 요청 시작부터 응답 종료까지 걸리는 시간
5. Waterfall: 요청한 항목의 동작 수행 타임라인

 

용어 구분

• '무효화': CF 캐시 리셋
• '버저닝': css/js의 넘버링을 통한 네이밍 갱신
• '브라우저 캐시 비우기 및 강력 새로고침': Origin/CF 서버 데이터 요청 후 사용자의 메모리/디스크 캐시 삭제

 

이슈 분석

1. 정기 배포는 주기가 일주일 정도로, 캐시 만료 기본값이 24시간이라 신규 코드가 적용된 화면을 볼 수 있었습니다.
   그러나 활발한 배포가 이루어질 경우 기존 캐시가 만료되기 전에 캐시가 새로 저장될 수 있습니다.
2. 정적 자원(html/css/js/img) 중 css/js는 버저닝을 통해 최신화되지만, 나머지 자원은 캐시된 개체가 제공됩니다.
   이전 요청이 없다면 Origin 서버에 요청하여 최신화된 개체를 제공하지만, 배포 중 요청이 들어온다면 구 버전과 신 버전이 혼합되어 정상적으로 출력되지 않을 수 있습니다.
3. 캐시된 두 개의 리소스를 동시에 갱신해도 한 리소스의 오래된 버전이 다른 리소스의 새로운 버전과 혼합되어 사용될 수 있습니다. 이 경우 마크업, css, js 간의 의존성이 큰 경우 캐싱 이슈 발생 확률이 높습니다.

결론

  클라우드 캐싱은 웹 애플리케이션의 성능과 사용자 경험을 극대화할 수 있는 강력한 도구입니다. 하지만 캐싱 메커니즘과 설정을 정확히 이해하고 관리하지 않으면 다양한 문제를 초래할 수 있습니다.
  정기적인 배포와 적극적인 캐시 관리, 그리고 개발자 도구를 활용한 검사 방법을 통해 이러한 문제를 사전에 예방하고 해결 할 수 있습니다.

최적의 캐싱 전략을 통해 사용자에게 빠르고 안정적인 서비스를 제공하는 것이 중요합니다.