CloudFront 캐시 설정: 적중률보다 먼저 확인할 로그인·쿠키·쿼리 문자열
AI Editter
CloudFront의 캐시 적중률이 낮다고 모든 쿠키와 쿼리 문자열을 제거하면 위험할 수 있습니다. 같은 URL이라도 로그인 사용자나 언어, 상품 옵션에 따라 응답이 달라질 수 있기 때문입니다.
캐시 키를 줄이는 작업은 어떤 요청끼리 같은 응답을 공유해도 되는지 정의하는 과정입니다. 적중률 숫자보다 응답의 정확성과 사용자 분리가 먼저입니다.
같은 URL이라고 같은 응답은 아니다
로그인한 사용자마다 다른 주문 내역을 반환하는 URL과, 누구에게나 같은 로고 파일을 반환하는 URL은 캐시 정책이 달라야 합니다. CloudFront를 처음 붙일 때 먼저 경로를 정적 파일·공개 페이지·개인화 API로 나누고 원본 응답 헤더를 확인합니다. 캐시 적중률 수치만 높이는 것보다 서로 다른 계정으로 같은 경로를 열었을 때 자료가 섞이지 않는지 확인하는 것이 먼저입니다.
응답을 세 종류로 나눈다
| 응답 | 예 | 기본 검토 방향 |
|---|---|---|
| 모든 사용자에게 동일 | 버전이 붙은 CSS·이미지 | 적극적인 캐시 |
| 제한된 조건에 따라 다름 | 언어·공개 검색 결과 | 필요한 조건을 키에 포함 |
| 사용자별 비공개 | 내 정보·주문·관리 화면 | 캐시 비활성 등 명확한 분리 |
경로별 behavior를 나눌 때 우선순위와 패턴도 확인합니다. 넓은 패턴이 비공개 경로를 먼저 잡으면 의도한 정책이 적용되지 않을 수 있습니다. 응답을 만드는 원본의 규칙과 CDN 설정을 함께 검토합니다.
캐시 키와 원본 요청 정책을 구분
캐시 정책은 응답을 구분하는 키와 TTL 등을 제어합니다. 원본 요청 정책은 원본에 추가로 전달할 값들을 제어할 수 있습니다. 어떤 값을 원본에 보낸다는 사실이 그 값별로 캐시가 나뉜다는 뜻은 아닙니다.
원본이 lang에 따라 다른 HTML을 만들지만 lang이 캐시 키에 없다면, 서로 다른 언어 요청이 같은 캐시 객체를 공유할 수 있습니다. 반대로 결과에 영향을 주지 않는 추적용 값이 모두 키에 들어가면 같은 콘텐츠가 여러 객체로 나뉩니다.
동작 차이는 AWS의 캐시 정책 문서와 원본 요청 정책 문서를 기준으로 확인합니다.
쿼리 문자열은 이름별로 분류
| 매개변수 예 | 응답 영향 | 처리 후보 |
|---|---|---|
| lang | 언어 변경 | 키 포함 또는 경로로 분리 |
| page | 목록 내용 변경 | 키 포함 |
| utm_source | 추적만 사용 | 원본 사용 방식 확인 후 키 제외 검토 |
| session·token | 인증·개인화 | 공개 캐시와 분리 |
추적 매개변수라도 원본에서 실제 응답을 바꾸는지 확인한 뒤 제외합니다. 서명·인증에 쓰는 값은 정렬·삭제·정규화를 임의로 적용하지 않습니다. URL에 비밀값을 넣는 구조라면 로그 노출 문제도 함께 검토합니다.
쿠키도 동일하게 분류합니다. 분석 쿠키가 응답을 바꾸지 않는지, 장바구니·로그인 쿠키가 있는 요청은 어디로 가는지 실제 사용자 흐름으로 확인합니다.
minimum TTL을 놓치지 않는다
AWS 문서는 최소 TTL이 0보다 크면 원본에 Cache-Control: no-cache, no-store, private가 있어도 최소 TTL 동안 캐시될 수 있다고 경고합니다. 따라서 비공개 응답을 원본 헤더 하나로만 보호한다고 생각해서는 안 됩니다.
개인화 경로에는 캐시가 꺼진 정책 등 명확한 설정을 적용하고, 필요한 인증 정보를 원본에 전달하는 방식도 확인합니다. 최소 TTL 0만 설정했다고 모든 개인화 처리가 자동으로 안전해지는 것은 아닙니다. 다른 TTL과 원본 응답, behavior의 실제 적용 결과를 봐야 합니다.
두 사용자와 비로그인으로 시험
개인정보가 없는 시험 계정 A·B를 만들고 각 계정에 구별되는 테스트 값을 넣습니다. 같은 URL을 A, B, 비로그인 순서와 반대 순서로 요청합니다.
| 시험 | 통과 기준 |
|---|---|
| A 로그인 후 B 요청 | B의 데이터만 |
| 로그인 후 비로그인 요청 | 로그인 데이터 노출 없음 |
| lang=ko 후 lang=en | 각 언어가 정확 |
| page=1 후 page=2 | 목록 내용이 정확 |
| 공개 정적 파일 반복 | 정책에 맞는 캐시 사용 |
| 로그아웃·권한 변경 | 비공개 응답과 접근이 정상 |
응답 본문과 상태 코드, Cache-Control, Age, X-Cache 등 관련 헤더를 함께 기록합니다. X-Cache 한 값만으로 모든 엣지와 모든 사용자 경로를 검증했다고 보지 않습니다.
적중률은 같은 경로와 기간으로 비교
전체 적중률이 낮아도 비공개 API가 많은 서비스라면 의도한 결과일 수 있습니다. 캐시 가능한 정적 경로와 동적 경로를 분리해서 봅니다. 요청 수가 적거나 배포 직후 캐시가 비어 있는 기간도 구분합니다.
변경 전후에 원본 요청 수, 원본 지연, 오류율, CDN 처리 비용을 같은 기간과 유사한 트래픽에서 비교합니다. 적중률만 올라가고 오래된 상품 정보나 개인화 오류가 생기면 성공이 아닙니다.
전환과 되돌리기
현재 behavior와 정책 ID, TTL, 원본 헤더를 기록한 뒤 제한된 경로에서 변경합니다. 정책 변경의 배포 상태를 확인하고, 필요한 경우 적절한 캐시 무효화 또는 버전 URL 전략을 사용합니다.
문제가 생기면 이전 정책으로 되돌리는 것과 이미 저장된 객체를 처리하는 것을 함께 고려합니다. 잘못 캐시된 비공개 응답이 의심되면 해당 경로의 캐시를 중지하고 무효화하며 접근 영향을 확인합니다. 최종 운영 문서에는 새 경로를 추가할 때 공개·조건부·비공개 중 무엇인지 먼저 분류하도록 남깁니다.