애플리케이션 구조
현재 개발중인 서버는 캐시 서버가 따로 존재하지 않는다.
따라서 캐시관리를 위해 코어 서버에서 직접 캐시를 관리해야 하고 그 과정에서 싱글톤 패턴을 이용해 각 모듈에 맞는 캐시를 따로 관리하고 있다.
각각의 모듈을 위와 같이 서로다른 형태의 캐시를 가지고 있고 각 모듈은 각각의 캐시 상태를 통해 복잡한 로직을 수행하고 있다.
최근에 모듈A 에서 모듈B의 캐시를 참조해야 하는 상황이 발생했는데 이 부분을 어떻게 해결해야 할 것인지를 고민했다.
개발을 하다보면 하나의 책임만을 수행할 수 있도록하는 단일 책임 원칙을 고수하는것이 원칙인데 이 부분을 지키자니 작은 곳에서 사용하는데 너무 큰 자원을 낭비해야 하는 상황이 발생했고 결국엔 그 부분만 예외적으로 참고할 수 있도록 해당 원칙을 무시하기로 했다.
이 부분은 사수께도 말씀을 드렸지만 구조를 변경하게 된다면 잃을 것이 더 많은 상황이라는 것에 동의, 어쩔 수 없는 조치였다. 한편으로는 애초에 캐시 관리에 대한 아키텍처 설계를 좀 다르게 진행했다면 어땠을까 라는 생각을 갖는 계기가 되었다.
이슈 발생
얼마 지나지 않아서 새로운 이슈가 발생했다.
각각의 모듈은 각자 다른 캐시를 참고 하고 있고 각 캐시에서 관리하는 자료구조는 모두 상이하다.
캐시는 대부분 ConcurrentHashMap 구현체를 사용해 key, value 쌍으로 데이터를 관리하고 있고 그 데이터의 수는 어마어마하다.
문제는 실제로 애플리케이션 런타임 환경에서 key 가 변경될 수 있는 일이 발생했고 key 변경이 이슈가 다른 캐시에 전파 된다는 것이었다.
속성 변경이 발생하게 되면 각각의 캐시에서는 데이터 구현체의 key 값을 변경 해야 하고 이 과정이 모든 캐시에서 동시다발적으로 발생해야 했다.
또한 각 캐시는 하나의 속성에 같은 key 값을 갖는 것이 아니고 속성안의 여러 정보들 중 하나의 값으로 key 값을 갖고 있는 상황이었다.
하나의 큰 속성안에 속성A 와 속성B 가 존재하고 각 속성의 변경여부가 캐시에 영향을 줄 수 있는 이 상황을 어떤 방식으로 해결해야 할 것인지에 대한 생각을 하기로 했다.
해결 방법
필요에 따라서 각 캐시는 새로운 자료구조를 추가해야 하는 경우가 빈번하게 발생했고 그에 따라서 업데이트 로직을 매번 구현한다는것이 너무나 번거롭고 개발자의 실수를 유발 할 수 있다는 생각이 들었다.
따라서 자동적으로 변경에 대한 감지를 할 수 있는 방법이 없을까를 고민하다 가장 먼저 떠오른 방법은 AOP를 이용하여 변경을 전파하는 방법 이었다.
AspectJ 를 이용하여 특정 맵을 타겟팅하도록 구현하여 각 클래스의 특정 맵에 대해 업데이트를 수행하도록 하고, 필요한 경우 추가적인 조건을 통해서 타겟팅할 수 있지 않을까 라는 생각을 했다.
하지만 문제는 AOP를 이용하는것이 옳은 설계 방법인가에 대한 생각을 하게 됬다.
각 모듈의 캐시 업데이트를 동일한 관점으로 볼 수 있는가에 대한 근거가 부족하다고 생각했다.
글 쓰기 순서
1. 현재 캐시 상태
2. 이전에 발생한 문제 다른 모듈에서 다른캐시 참조 -> 아쉬웠던 부분 서술
3. 새롭게 발생한 문제
4. 업데이트 방향성에 대한 고찰
5. 해결 방법
6. aop 적용 방안
7. 아쉬운 부분
애플리케이션 구조
현재 개발중인 서버는 캐시 서버가 따로 존재하지 않는다.
따라서 캐시관리를 위해 코어 서버에서 직접 캐시를 관리해야 하고 그 과정에서 싱글톤 패턴을 이용해 각 모듈에 맞는 캐시를 따로 관리하고 있다.
각각의 모듈을 위와 같이 서로다른 형태의 캐시를 가지고 있고 각 모듈은 각각의 캐시 상태를 통해 복잡한 로직을 수행하고 있다.
최근에 모듈A 에서 모듈B의 캐시를 참조해야 하는 상황이 발생했는데 이 부분을 어떻게 해결해야 할 것인지를 고민했다.
개발을 하다보면 하나의 책임만을 수행할 수 있도록하는 단일 책임 원칙을 고수하는것이 원칙인데 이 부분을 지키자니 작은 곳에서 사용하는데 너무 큰 자원을 낭비해야 하는 상황이 발생했고 결국엔 그 부분만 예외적으로 참고할 수 있도록 해당 원칙을 무시하기로 했다.
이 부분은 사수께도 말씀을 드렸지만 구조를 변경하게 된다면 잃을 것이 더 많은 상황이라는 것에 동의, 어쩔 수 없는 조치였다. 한편으로는 애초에 캐시 관리에 대한 아키텍처 설계를 좀 다르게 진행했다면 어땠을까 라는 생각을 갖는 계기가 되었다.
이슈 발생
얼마 지나지 않아서 새로운 이슈가 발생했다.
각각의 모듈은 각자 다른 캐시를 참고 하고 있고 각 캐시에서 관리하는 자료구조는 모두 상이하다.
캐시는 대부분 ConcurrentHashMap 구현체를 사용해 key, value 쌍으로 데이터를 관리하고 있고 그 데이터의 수는 어마어마하다.
문제는 실제로 애플리케이션 런타임 환경에서 key 가 변경될 수 있는 일이 발생했고 key 변경이 이슈가 다른 캐시에 전파 된다는 것이었다.
속성 변경이 발생하게 되면 각각의 캐시에서는 데이터 구현체의 key 값을 변경 해야 하고 이 과정이 모든 캐시에서 동시다발적으로 발생해야 했다.
또한 각 캐시는 하나의 속성에 같은 key 값을 갖는 것이 아니고 속성안의 여러 정보들 중 하나의 값으로 key 값을 갖고 있는 상황이었다.
하나의 큰 속성안에 속성A 와 속성B 가 존재하고 각 속성의 변경여부가 캐시에 영향을 줄 수 있는 이 상황을 어떤 방식으로 해결해야 할 것인지에 대한 생각을 하기로 했다.
해결 방법
필요에 따라서 각 캐시는 새로운 자료구조를 추가해야 하는 경우가 빈번하게 발생했고 그에 따라서 업데이트 로직을 매번 구현한다는것이 너무나 번거롭고 개발자의 실수를 유발 할 수 있다는 생각이 들었다.
따라서 자동적으로 변경에 대한 감지를 할 수 있는 방법이 없을까를 고민하다 가장 먼저 떠오른 방법은 AOP를 이용하여 변경을 전파하는 방법 이었다.
AspectJ 를 이용하여 특정 맵을 타겟팅하도록 구현하여 각 클래스의 특정 맵에 대해 업데이트를 수행하도록 하고, 필요한 경우 추가적인 조건을 통해서 타겟팅할 수 있지 않을까 라는 생각을 했다.
하지만 문제는 AOP를 이용하는것이 옳은 설계 방법인가에 대한 생각을 하게 됬다.
각 모듈의 캐시 업데이트를 동일한 관점으로 볼 수 있는가에 대한 근거가 부족하다고 생각했다.
글 쓰기 순서
1. 현재 캐시 상태
2. 이전에 발생한 문제 다른 모듈에서 다른캐시 참조 -> 아쉬웠던 부분 서술
3. 새롭게 발생한 문제
4. 업데이트 방향성에 대한 고찰
5. 해결 방법
6. aop 적용 방안
7. 아쉬운 부분
