[Spring Boot] 캐시 무효화(캐시 제어) - http응답의 캐시 제어

개인적으로 제작 중인 프로젝트에 적용시키면서 실전경험 쌓기 (2024.04.03)

https://github.com/GyuminGomin/people-driver

GitHub - GyuminGomin/people-driver: busan IT Academy Final Project

동기 : 캐시 설정을 통해 오래된 데이터를 자동 처리하고 로그아웃을 하였을 시 뒤로가기 할 때 남아있는 캐시기록을 방지하기 위해 캐시를 제어할 필요가 있다고 생각이 들었다. 그리고 개발을 진행하며 캐시가 계속 남아 있어 f5를 눌렀을 때 css가 변하지 않아 ctrl+f5를 눌러줬어야 하는데, 이 경우도 번거롭다 느껴져 캐시 무효화 작업을 진행하였다

1. 캐시 무효화(캐시 제어) 란?

웹 애플리케이션에서 클라이언트 브라우저나 프록시 서버에 저장된 데이터를 무효화하거나 어느정도 유지시켜주는 작업을 의미한다.

- 목적

1. 최신 데이터 제공 : 캐시를 무효화하여 클라이언트에게 항상 최신 데이터를 제공할 수 있음. 이는 웹 애플리케이션에서 사용자가 항상 최신 정보를 보게 하고 업데이트 된 내용을 즉시 반영할 수 있도록 도움을 줌

 

2. 보안 강화 : 중요한 데이터나 보안 관련 정보가 캐시에 남아있으면 보안 위험을 초래할 수 있다. 따라서 보안 취약점을 최소화하기 위해 캐시를 주기적으로 무효화하여 중요한 정보가 오래 남지 않도록 하는 것

 

3. 성능 향상 : 네트워크 대역폭과 서버 부하를 줄이기 위해 캐시를 사용. 하지만 캐시가 너무 오래 남아있으면 업데이트된 데이터를 클라이언트가 가져오지 못하고 오래된 데이터를 계속 사용하게 됨. 이는 성능 저하로 이어짐

 

4. 사용자 경험 향상 : 캐시를 효과적으로 관리하면 사용자 경험 향상 가능. 최신 데이터를 제공하고 응답 시간을 최소화하여 사용자가 웹 애플리케이션을 보다 빠르고 신뢰할 수 있게 만들어 줌

- 캐시가 존재하는 곳

• CPU의 L1, L2, L3 캐시
• 운영체제의 page / disk cache
• DB를 위한 MemCached, Redis와 같은 캐시
• API 캐시
• 7계층 (Application 계층) HTTP 캐시 (CDN)
• DNS 캐싱
• 브라우저 안에 들어 있는 캐시
• 복잡하고 시간 집약적인 작업을 위해 존재하는 마이크로서비스 내부 캐시

- 나의 목적

• Session을 사용하면 로그인 정보가 서버의 Redis에 저장되어 있다. 로그아웃 처리를 했는데 뒤로가기를 눌렀을 시 여전히 캐시 정보가 Redis에 남아있어 로그인 되어 있는 상태라면 문제가 발생할 수 있으므로 처리가 필요
• 개발을 하며 브라우저 캐시 정보에 지속적으로 캐시 정보가 남아 있어 CSS 파일을 수정할 때 즉각 반응이 안되고 있는 상태가 있었다. 이 상태를 방지하기 위해 설정
• 캐시는 무조건 필요 없는 것이 아니다. 방대한 양의 데이터를 캐시가 남아 있음으로써 컴퓨터 자원을 아낄 수 있는 장점이 있는데 이것을 생각하면 이미지, 영상 같은 큰 이미지의 데이터는 캐시 정보가 오래 남아 있을 필요가 있으므로 유저에게 더 빠른 응답을 할 수 있도록 할 예정이다.

2. 실전 적용

springboot.web 의존성에는 WebMvcConfigurer라는 설정 인터페이스가 존재하는데, 여기서 addInterceptor라는 메서드가 존재한다. 이 메서드를 통해 구현하면 되는데

 

대부분의 프로젝트 구조는 resources 폴더는 정적 자원들을 할당해 둔다.

따라서 나의 프로젝트는 이미지 파일이나 영상 파일 같이 데이터가 큰 파일들은 따로 resources/img 폴더로 지정해두었다.

 

즉 간단하게 캐시 상태를 관리하고자 할 때는

@Configuration
public class WebMvcConfig implements WebMvcConfigurer {

	@Override
	public void addInterceptors(InterceptorRegistry registry) {
		WebContentInterceptor interceptor = new WebContentInterceptor();
		interceptor.setCacheSeconds(0);
		
		// "/resources/img/**" 패턴에 대해서만 캐시 저장 시간을 60x60x24으로 설정
        interceptor.addCacheMapping(CacheControl.maxAge(86400, TimeUnit.SECONDS), "/resources/img/**");

        registry.addInterceptor(interceptor).addPathPatterns("/**");
	}
}

다음과 같이 구현해주면 된다.

 

축구를 좋아하는 사람들은 자주 들어봤을 용어일 텐데,

여기서 interceptor란? 웹 애플리케이션 내에서 특정한 URI 호출을 말 그대로 '가로채는' 역할 이라고 생각하면 된다.

기존 컨트롤러에서 로직을 작성할 때 가장 필수적인 비즈니스 로직이 아닐 경우, 사전이나 사후에 제어할 수 있도록 처리하는 것을 의미한다.

 

예를 들면, 위에 /resources/img/**라는 요청이 들어오면, CacheControl이라는 HTTP 캐시 관련 헤더의 정보를 수정하여 유효시간을 1일로 처리하는 것을 의미한다. 이 요청 처리는 꼭 필요한 비즈니스 로직이 아니므로 인터셉터로 처리할 수 있다.

Interceptor가 전처리 후처리를 하는 공간 (출처는 학원에서 배웠던 ppt에서 가져온 이미지 입니담)

위 그림을 보면, Dispatcher Servlet이 요청 경로를 매핑하고 컨트롤러에 보내주기 전,

Controller에서 처리를 하고 난 후,

마지막으로 ViewResolver를 통해 반환을 하고 난 뒤 처리가 되는 형태를 보여주고 있다.

기본적으로 인터셉터는 이 세가지를 처리하지만, addInterceptor라는 메서드는 전처리를 담당한다. 만약 다른 경우가 있어 후 처리를 하고 싶다면 HandlerInterceptor를 인터페이스를 구현하여 postHandle을 처리하고
registry.addInterceptor(new PostHandler()).addPathPatterns("/**"); 처럼 구현하면 된다.

 

 

만약 캐시 무효화(캐시 제어)를 하면서 다르게 사용할 예시가 더 있다면 알려주시면 감사하겠습니다. (적극적으로 조언을 구하고 싶습니다!)

읽어주셔서 감사합니다!

 

 

Reference

https://velog.io/@zenon8485/%EC%BA%90%EC%8B%B1%EA%B3%BC-%EC%BA%90%EC%8B%9C-%EB%AC%B4%ED%9A%A8%ED%99%94%EC%97%90-%EB%8C%80%ED%95%9C-%EA%B0%84%EB%8B%A8%ED%95%9C-%EA%B8%80

캐싱과 캐시 무효화에 대한 간단한 글