20230306_캐싱이슈

캐싱을 추가하는 과정에서 objectmapper을 기본으로 제공해주는 부분이 아니라 추가해서 넣어주고 싶었다 이유는 이러했음 캐싱을 적용해둔 이후에 막 Redis에 객체가 캐싱될것이다 그런데 만약에 캐싱되고 있는 객체의 정보가 변경되면 객체가 다르기 떄문에 수 많은 캐싱되어있는 객체들을 받으면서 에러를 막 뱉을 것이다 그래서 요런 것을 해결하기 위한 방법으로 ObjectMapper에 deserializationFeature의 DeserializationFeature.FAIL_ON_IGNORED_PROPERTIES 요걸 세팅해주는 방법이다 뭐 추가로 더 필요한건 추가로 넣어주면됨 이렇게 redis에 대한 설정을 해주기 위해서는 기존에 아무런 세팅이 없었던 상황인데 각각의 추가 세팅이 필요했었다

위의 발생할 수 있는 에러 사항을 재현하기 위한 테스트는 이러하다 캐싱할 때 ttl을 좀 길게 잡아두고 테스트하고자 하는 객체를 캐싱한다 그리고 캐싱한 객체를 내 서버에서 변경하고 다시 그 객체를 redis 서버로부터 받게되면 에러가 발생!

정리해보면 캐싱을 캐시 서버에 저장해둔 상황에서 내서버에서 캐싱하기로 해둔 객체에 변화가 생겼을 때 캐싱된 데이터를 읽어올때 직렬화, 역직렬화에서 에러가 발생했다

직렬화, 역직렬화란 객체를 네트워크나 파일단위로 변환해서 해당 객체를 네트워크나 파일로 변환하는 것을 의미한다 이때 객체는 바이트 스트림 단위로 쪼개지고 이것을 직렬화라고 하며 다시 객체로 불러오는 과정을 역직렬화라고 한다

자 그럼 이제 objectmapper 을 입혀줘야 하는데 어디에다가 입혀야할까? 그 방법을 확인해보니까 Redis에서 왔다갔다 할때 사용되는 RedisTemplate에서 Serialize 시 커스텀한 ObjectMapper을 사용하는 방법이다

적용이 가능한 RedisSerializer에는 몇 가지 종류가 있다 JdkSerializationRedisSerializer

• 요게 기본값으로써 기본 자바 직렬화 방식을 사용

GenericJackson2JsonRedisSerializer

• 요놈의 장점은 별도의 클래스 타입을 지정해주지 않는다는 것이다

• 알아서 직렬화 될 때 해당 클래스 타입과 해당 클래스의 패키지에 대한 정보가 함께 들어감

• 그래서 문제는 직렬화는 괜찮지만 역직렬화하는 과정에서 보낸서버가 아닌 다른 서버에서 해당 값을 받는다고 가정했을 때

• 역직렬화로부터 데이터를 받는 곳에서도 해당 클래스를 구현해두어야만 하고 해당 클래스의 패키지명도 반드시 같아야함

• 즉, 하나의 서버를 가지는 구조에서만 유용하게 사용할 수 있다는 점이다

Jackson2JsonRedisSerializer

• 요놈은 위의 GenericJackson2JsonRedisSerializer와 반대로 따로 클래스명을 지정하지 않는 대신 각각의 클래스별로 별도의 RedisTemplate을 지정해주어야 한다

• 내가 오늘(3.6)에 삽질한 내용도 이러한 내용이다 이걸로 사용하다보니 단 하나의 객체를 캐싱하는 경우가 아닌 여러 객체를 캐싱하게 되면 그 각자의 객체에 대한 각각의 RedisTemplate을 지정해주어야 한다

StringRedisSerializer

• 요놈은 String 값을 그대로 저장하는 방식이다

• 그래서 문제는 Json 형태로 변환해서 저장하기 위해서는 직접 encoding, decoding을 해주어야 한다는점이 문제이다

결론은 이러함 GenericJackson2JsonRedisSerializer을 사용해서 처리했을때는 여러가지 객체로 각각의 RedisTemplate을 선언해야하는데... 일일이 선언하는건 벌써부터 거부감이 든다 그래서 Jackson2JsonRedisSerializer을 사용해서 처리하고 위에서 했던 시나리오(캐싱된놈!=변경된놈) 을 테스트해보니 local class incompatible: stream classdesc serialVersionUID Different error 이러한 에러가 발생해버렸다..! 해당 에러는 클래스 serialize id가 다르다는 에러 발생 요걸 해결하기위해 static final long serialVersionUID=1L 이렇게 강제로 해당 클래스에 대한 SID을 고정으로 넣어주었고 기존에 만들어놨던 테스트 코드에서 해당 에러가 사라진 것을 확인할 수 있었다 그리고 위에서 진행했던 테스트를 통해서 매핑도 정상적으로 진행되는거 눈으로 확인도 완료했다

그런데 이것도 방법이긴 하지만 완벽한 방법은 아니라고 사수님이 말씀하셨다 캐싱하는 과정에서 객체 변화로 인한 에러를 잡는 방법은 위처럼 클래스에 SID을 고정하고 에러를 나지 않고 자연스럽게 받을 수 있는 것만 받는 방법 그리고 추가로 redis에 키로 등록하는 과정에서 키에다가 회사 컴포넌트의 jar 버전을 넣어서 아이디를 구체화 시켜서 애초에 받지 않게 해버리는 방법 이렇게 2가지가 있다고 말씀하셨다

그래서 앞으로 해야할 일은 추가로 해당 캐시설정을 애노테이션으로 만들어서 사내에서 사용하는 라이브러리에 집어넣는 작업 그리고 jar 버전을 가져와서 키에다가 넣어서 컴포넌트의 버전이 달라지면 걱정없이 처리하는 방법으로 고도화

아이디를 버전을 통해서 관리하는 방법 먼저 진행했다 사내 라이브러리에 저걸 가져오는것이 있는데 문제는 그거다 >> 어떻게 @Cacheable, @CacheEvict, @CachePut, @Caching 요런 애노테이션 내부에서 id = “#변수명” 이렇게 저기 변수명에 내가 넣길 원하는 놈을 잘 파싱해서 넣어주어야 하는데 어떻게 넣을 것이냐

과거에도 애노테이션에 어떻게 변수를 넣을 것인가에 대한 삽질을 겁나게 했었는데 이 기회에 보자

변수를 넣는 방법으로는 (메소드에 선언할 수 있는놈들 기준으로) 해당 메소드의 파라미터에 넣고 싶은 변수를 넣어주는 방법이다

그래서 이번에 해본게 @Cacheable, @CacheEvict, @CachePut 을 달아둔 메소드에다가 추가로 jar 버전을 받도록 파라미터를 하나 더 추가했다

그렇게 추가하고 #뒤에 변수를 넣었더니 잘만 가져와 지더라!