Cache-Control 설정을 통한 파일 캐싱 최적화 완료

[limehee]

Summary

#431

이 PR은 Cache-Control 설정을 추가하여 서버에서 제공하는 파일의 캐싱을 최적화하는 작업을 포함합니다. 이를 통해 파일 접근 시 성능을 향상시키고, 불필요한 서버 요청을 줄여 서버 부하를 감소시킵니다.

Tasks

• WebConfig 클래스에 Cache-Control 설정 추가
• 응답 헤더에 Cache-Control 설정이 적용되었는지 확인
• 캐시가 설정된 파일에 접근하여 성능 최적화 확인

Screenshot

Log

2024-07-27 16:59:14.151 [http-nio-8080-exec-1] INFO  p.c.a.g.h.ApiLoggingInterceptor - [0:0:0:0:0:0:0:1:anonymousUser] /resources/files/profiles/202310000/1255299469048375_896b6bd5-8fb7-4e76-ac93-2a42aac385b4.jpg GET 200 7ms
2024-07-27 16:59:14.266 [http-nio-8080-exec-4] INFO  p.c.a.g.h.ApiLoggingInterceptor - [0:0:0:0:0:0:0:1:anonymousUser] /resources/files/profiles/202310000/1255299469048375_896b6bd5-8fb7-4e76-ac93-2a42aac385b4.jpg GET 200 4ms
2024-07-27 16:59:19.600 [http-nio-8080-exec-5] INFO  p.c.a.g.h.ApiLoggingInterceptor - [0:0:0:0:0:0:0:1:anonymousUser] /resources/files/profiles/202310000/1255299469048375_896b6bd5-8fb7-4e76-ac93-2a42aac385b4.jpg GET 304 0ms
2024-07-27 16:59:21.561 [http-nio-8080-exec-7] INFO  p.c.a.g.h.ApiLoggingInterceptor - [0:0:0:0:0:0:0:1:anonymousUser] /resources/files/profiles/202310000/1255299469048375_896b6bd5-8fb7-4e76-ac93-2a42aac385b4.jpg GET 304 1ms

[mingmingmon]

파일 캐싱 작업 잘 살펴보았습니다!

1. 캐시 보관을 하루로 두어 max-age가 잘 설정됨을 확인했습니다. max-age를 넘지 않았다면 서버에 요청없이 저장된 캐시에서 파일을 바로 사용하니 시간이 많이 단축되는군요.
2. max-age를 넘어버린 경우에는 last-modified를 확인해 파일정보가 수정이 되지 않았다면 캐시에 저장된 파일을 지속적으로 사용하고 304를 반환함을 확인했습니다.

한 가지 질문이 있습니다. 캐싱 방법에 대해 찾아보니, last modified말고도 e-tag 방식이 있던데 last modified를 선택하신 이유가 있으신가요?

제가 이해한 내용은 다음과 같습니다. e-tag 방식은 데이터 내용에 고유하게 태그를 달아 이를 기준으로 변경여부를 판단하여 정밀도가 높다고 합니다. 특히 last modified 방식의 한계인 초 단위보다 더 짧은 시간 안에 변경이 일어나면 캐시를 유지한다는 점과 시간동기화 문제를 e-tag로 극복할 수 있습니다. 다만 e-tag를 계산하고 비교하는데 걸리는 시간이 last-modified 방식에 비해 오래 걸린다는 단점이 있습니다.

제 개인적인 생각으로는 e-tag도 충분히 좋은 선택지인 것 같은데(정밀도, 정확도 측면에서 더 우수하다는 점), last-modified를 선택하신 이유가 궁금합니다.

[limehee]

좋은 지적을 해주셔서 감사합니다. 말씀하신 것처럼 e-tag 방식은 높은 정밀도와 정확도를 제공하는 훌륭한 캐싱 방법입니다. 그러나 저희 플랫폼에서 last-modified를 선택한 이유는 다음과 같습니다.

1. 변경 가능성이 적은 파일: 우리 플랫폼에 업로드되는 파일은 대부분 변경 가능성이 적습니다. 파일이 업로드될 때 이미 랜덤한 파일명을 가지기 때문에, 동일한 파일에 대해 캐싱되어도 실제로 변경된 파일이 다시 업로드될 확률이 낮습니다.

2. e-tag의 필요성 감소: e-tag는 변경 여부를 매우 정확하게 판단할 수 있지만, 파일명이 랜덤하게 생성되고 사용자들이 이러한 파일에만 접근하는 구조이기 때문에, 파일이 변경되었을 때 캐싱으로 인해 이전 버전의 파일에 접근할 가능성이 거의 없습니다. 따라서, e-tag를 사용하는 것보다 last-modified를 사용하는 것이 우리 시스템 구조에 더 적합합니다.

3. 성능 고려: e-tag는 계산하고 비교하는 데 시간이 더 걸릴 수 있습니다. 저희 시스템에서는 대부분의 파일이 변경되지 않는다는 점에서 성능을 최적화하기 위해 last-modified 방식을 사용하는 것이 더 효율적입니다.

이러한 이유들로 인해 last-modified 방식을 선택하게 되었습니다.

[SongJaeHoonn]

응답 헤더들을 여러 번 봐왔지만, 많은 헤더들을 각각 어떻게 사용해야 하고, 어떤 방식으로 사용해야 하는지 모르고 있었어서 부끄럽지만 개발 시에는 여러가지 헤더들을 무시한 채로 진행했었는데,

이번에 올려주신 Cache-Control 설정을 보고, 모르는 내용이다 보니 계속 알아보다가,
서버 설정으로 웹 캐싱을 통해 자원을 효율적으로 가져올 수 있다는 점을 알게되었네요.

Cache-Control 설정을 yml파일에서도 할 수 있고, 그게 좀 더 간단하지 않나? 라는 의문을 가졌으나,
업로드된 파일이 있는 경로에만 적용해야 하기 때문에 resourceHandler에 설정하신 것이라고 생각했습니다.
제가 생각한 내용이 맞을까요?

[limehee]

Cache-Control 설정을 yml파일에서도 할 수 있고, 그게 좀 더 간단하지 않나? 라는 의문을 가졌으나, 업로드된 파일이 있는 경로에만 적용해야 하기 때문에 resourceHandler에 설정하신 것이라고 생각했습니다. 제가 생각한 내용이 맞을까요?

네, 맞습니다. Cache-Control 설정을 yml 파일에서 전역적으로 적용하는 방법도 있지만, 특정 경로의 파일들에 대해서만 캐싱 정책을 적용하기 위해 resourceHandler에 설정했습니다.