CDN TTL, 원본 헤더와 설정의 우선순위

원본 헤더와 배포 설정이 함께 작동합니다

전송 서비스의 보관 시간은 두 곳에서 정해집니다. 원본 서버가 보낸 헤더와 배포 쪽 설정입니다. 둘이 충돌할 때 무엇이 이기는지 모르면 설정을 바꿔도 결과가 예상과 다릅니다. 기본 구조는 이렇습니다. 원본이 보관 시간을 지정하면 그 값을 쓰되, 배포 설정의 최소값과 최대값 범위 안으로 조정됩니다. 원본이 아무것도 지정하지 않으면 배포 설정의 기본값을 씁니다. 그래서 최소값을 크게 설정하면 원본이 짧게 지정해도 그 최소값까지 늘어납니다. 이 동작이 '분명히 짧게 설정했는데 오래 남는다'의 원인입니다.

원본 헤더를 기준으로 삼는 쪽이 관리가 쉽습니다

두 곳에서 설정할 수 있다는 것은 혼란의 원인이기도 합니다. 그래서 한쪽을 기준으로 정합니다. 권장은 원본 헤더를 기준으로 삼고 배포 설정의 최소값을 0으로, 최대값을 아주 크게 두는 것입니다. 그러면 원본이 보낸 값이 그대로 적용되어 자원별로 세밀하게 조절할 수 있고, 설정이 코드와 함께 관리됩니다. 반대로 배포 설정을 기준으로 삼으면 자원별 구분이 어려워집니다. 예외는 원본 헤더를 바꿀 수 없는 경우입니다. 외부 저장소나 수정할 수 없는 서비스를 원본으로 쓸 때는 배포 설정으로 조절할 수밖에 없습니다.

적용되는 값을 계산해 확인합니다

학습용 가정으로 계산합니다. 가정값은 원본이 보관 시간을 3,600초로 지정하고 배포 설정의 최소값이 7,200초라고 두겠습니다. 원본이 지정한 3,600초는 60으로 나누면 60분입니다. 그런데 최소값이 7,200초이므로 실제 적용은 7,200초, 즉 3,600으로 나누면 2시간이 됩니다. 두 값의 차이는 3,600초입니다. 이것이 중간 계산값이자 혼란의 실체입니다. 최종 확인은 응답 헤더를 받아 적중 상태와 남은 수명을 보는 것입니다. 계산으로 예상한 값과 실제 응답이 다르면 배포 설정의 최소값과 기본값을 다시 봅니다.

오류 응답에도 보관 시간이 적용됩니다

결론을 뒤집는 조건은 오류 응답입니다. 원본이 일시적으로 오류를 돌려줄 때 그 오류 응답도 캐시될 수 있고, 보관 시간이 길면 원본이 정상으로 돌아온 뒤에도 사용자에게 계속 오류가 보입니다. 그래서 오류 응답의 보관 시간을 짧게 따로 설정합니다. 두 번째 조건은 요청 조건입니다. 같은 경로라도 특정 헤더나 매개변수에 따라 응답이 달라지면 캐시 키에 그 값을 포함시켜야 하고, 포함하지 않으면 한 사용자의 응답이 다른 사용자에게 전달됩니다. 그래서 설정 점검표에 오류 보관 시간과 캐시 키 구성 두 항목을 넣습니다.

성능 최적화 실행 전 점검표

• 원본 헤더와 배포 설정의 우선순위를 확인했다
• 원본 헤더를 기준으로 삼고 최소값을 0으로 두었다
• 응답 헤더로 적중 상태와 남은 수명을 확인했다
• 오류 응답의 보관 시간을 짧게 따로 설정했다