Global Store - Spring Boot 연결 이슈

테스트를 진행하며 알게된 내용 중 나름 유용했던 설정이 있다.

logging.level.io.lettuce.core.protocol.ConnectionWatchdog=DEBUG

해당 객체는 lettuce 에서 제공하는 객체이며 커넥션 연결에 대해 확인할 수 있도록 로깅을 제공해준다.

해당 객체가 확인해주는 로깅을 보면 다음과 같다.

36mi.l.core.protocol.ConnectionWatchdog    [channel=0x50d0bb6c, /10.0.42.59:55816 -> photowidget-redis-slave-v3.yl2nl5.clustercfg.apn2.cache.amazonaws.com/10.0.37.146:6379, last known addr=photowidget-redis-slave-v3.yl2nl5.clustercfg.apn2.cache.amazonaws.com/10.0.37.146:6379] channelActive()
36mi.l.core.protocol.ConnectionWatchdog    [channel=0xd23e595d, /10.0.42.59:39986 -> photowidget-redis-master-v3.sevvte.clustercfg.use2.cache.amazonaws.com/20.0.168.191:6379, last known addr=photowidget-redis-master-v3.sevvte.clustercfg.use2.cache.amazonaws.com/20.0.168.191:6379] channelActive()
36mi.l.core.protocol.ConnectionWatchdog    [channel=0x67c26040, /10.0.42.59:52558 -> /10.0.132.115:6379, last known addr=/10.0.132.115:6379] channelActive()
36mi.l.core.protocol.ConnectionWatchdog    [channel=0x9093a911, /10.0.42.59:48900 -> /10.0.30.39:6379, last known addr=/10.0.30.39:6379] channelActive()
36mi.l.core.protocol.ConnectionWatchdog    [channel=0xbfe929c2, /10.0.42.59:55822 -> /10.0.37.146:6379, last known addr=/10.0.37.146:6379] channelActive()
36mi.l.core.protocol.ConnectionWatchdog    [channel=0x38d2f875, /10.0.42.59:39990 -> /20.0.168.191:6379, last known addr=/20.0.168.191:6379] channelActive()
36mi.l.core.protocol.ConnectionWatchdog    [channel=0xb572c207, /10.0.42.59:55792 -> /20.0.157.174:6379, last known addr=/20.0.157.174:6379] channelActive()
36mi.l.core.protocol.ConnectionWatchdog    [channel=0xbee72739, /10.0.42.59:36300 -> /20.0.7.184:6379, last known addr=/20.0.7.184:6379] channelActive()
36mi.l.core.protocol.ConnectionWatchdog    [channel=0xd23e595d, /10.0.42.59:39986 -> photowidget-redis-master-v3.sevvte.clustercfg.use2.cache.amazonaws.com/20.0.168.191:6379, last known addr=photowidget-redis-master-v3.sevvte.clustercfg.use2.cache.amazonaws.com/20.0.168.191:6379] channelInactive()
36mi.l.core.protocol.ConnectionWatchdog    [channel=0xd23e595d, /10.0.42.59:39986 -> photowidget-redis-master-v3.sevvte.clustercfg.use2.cache.amazonaws.com/20.0.168.191:6379, last known addr=photowidget-redis-master-v3.sevvte.clustercfg.use2.cache.amazonaws.com/20.0.168.191:6379] Reconnect scheduling disabled
36mi.l.core.protocol.ConnectionWatchdog    [channel=0x50d0bb6c, /10.0.42.59:55816 -> photowidget-redis-slave-v3.yl2nl5.clustercfg.apn2.cache.amazonaws.com/10.0.37.146:6379, last known addr=photowidget-redis-slave-v3.yl2nl5.clustercfg.apn2.cache.amazonaws.com/10.0.37.146:6379] channelInactive()
36mi.l.core.protocol.ConnectionWatchdog    [channel=0x50d0bb6c, /10.0.42.59:55816 -> photowidget-redis-slave-v3.yl2nl5.clustercfg.apn2.cache.amazonaws.com/10.0.37.146:6379, last known addr=photowidget-redis-slave-v3.yl2nl5.clustercfg.apn2.cache.amazonaws.com/10.0.37.146:6379] Reconnect scheduling disabled
36mi.l.core.protocol.ConnectionWatchdog    [channel=0x67c26040, /10.0.42.59:52558 -> /10.0.132.115:6379, last known addr=/10.0.132.115:6379] channelInactive()
36mi.l.core.protocol.ConnectionWatchdog    [channel=0x67c26040, /10.0.42.59:52558 -> /10.0.132.115:6379, last known addr=/10.0.132.115:6379] Reconnect scheduling disabled
36mi.l.core.protocol.ConnectionWatchdog    [channel=0x9093a911, /10.0.42.59:48900 -> /10.0.30.39:6379, last known addr=/10.0.30.39:6379] channelInactive()
36mi.l.core.protocol.ConnectionWatchdog    [channel=0x9093a911, /10.0.42.59:48900 -> /10.0.30.39:6379, last known addr=/10.0.30.39:6379] Reconnect scheduling disabled
36mi.l.core.protocol.ConnectionWatchdog    [channel=0xbfe929c2, /10.0.42.59:55822 -> /10.0.37.146:6379, last known addr=/10.0.37.146:6379] channelInactive()
36mi.l.core.protocol.ConnectionWatchdog    [channel=0xbfe929c2, /10.0.42.59:55822 -> /10.0.37.146:6379, last known addr=/10.0.37.146:6379] Reconnect scheduling disabled
36mi.l.core.protocol.ConnectionWatchdog    [channel=0xb572c207, /10.0.42.59:55792 -> /20.0.157.174:6379, last known addr=/20.0.157.174:6379] channelInactive()
36mi.l.core.protocol.ConnectionWatchdog    [channel=0xb572c207, /10.0.42.59:55792 -> /20.0.157.174:6379, last known addr=/20.0.157.174:6379] Reconnect scheduling disabled
36mi.l.core.protocol.ConnectionWatchdog    [channel=0xbee72739, /10.0.42.59:36300 -> /20.0.7.184:6379, last known addr=/20.0.7.184:6379] channelInactive()
36mi.l.core.protocol.ConnectionWatchdog    [channel=0xbee72739, /10.0.42.59:36300 -> /20.0.7.184:6379, last known addr=/20.0.7.184:6379] Reconnect scheduling disabled
36mi.l.core.protocol.ConnectionWatchdog    [channel=0x38d2f875, /10.0.42.59:39990 -> /20.0.168.191:6379, last known addr=/20.0.168.191:6379] channelInactive()
36mi.l.core.protocol.ConnectionWatchdog    [channel=0x38d2f875, /10.0.42.59:39990 -> /20.0.168.191:6379, last known addr=/20.0.168.191:6379] Reconnect scheduling disabled
36mi.l.core.protocol.ConnectionWatchdog    [channel=0xd51bf7a8, /10.0.42.59:52560 -> /10.0.132.115:6379, last known addr=/10.0.132.115:6379] channelActive()
36mi.l.core.protocol.ConnectionWatchdog    [channel=0x3b697368, /10.0.42.59:52572 -> /10.0.132.115:6379, last known addr=/10.0.132.115:6379] channelActive()
36mi.l.core.protocol.ConnectionWatchdog    [channel=0xace1fbde, /10.0.42.59:48904 -> /10.0.30.39:6379, last known addr=/10.0.30.39:6379] channelActive()
36mi.l.core.protocol.ConnectionWatchdog    [channel=0x5a5c10c1, /10.0.42.59:55834 -> /10.0.37.146:6379, last known addr=/10.0.37.146:6379] channelActive()
36mi.l.core.protocol.ConnectionWatchdog    [channel=0x5a5c10c1, /10.0.42.59:55834 -> /10.0.37.146:6379, last known addr=/10.0.37.146:6379] channelInactive()
36mi.l.core.protocol.ConnectionWatchdog    [channel=0x5a5c10c1, /10.0.42.59:55834 -> /10.0.37.146:6379, last known addr=/10.0.37.146:6379] scheduleReconnect()
36mi.l.core.protocol.ConnectionWatchdog    [channel=0x5a5c10c1, /10.0.42.59:55834 -> /10.0.37.146:6379, last known addr=/10.0.37.146:6379] Reconnect attempt 1, delay 1ms
36mi.l.core.protocol.ConnectionWatchdog    Reconnecting, last destination was /10.0.37.146:6379
36mi.l.core.protocol.ConnectionWatchdog    [channel=0x154d48fb, /10.0.42.59:55838 -> /10.0.37.146:6379, last known addr=/10.0.37.146:6379] channelActive()
36mi.l.core.protocol.ReconnectionHandler   Reconnected to 10.0.37.146/<unresolved>:6379

각 클러스터 엔드포인트 에 대해 설정했을 때의 로깅이다.

기존에 캐시를 사용하는 엔드포인트를 호출하는 방식은 기존 캐시매니저에 관리되는 TTL 이 만료되기 전에는 삭제하는 별도 처리가 필요했다. 그리고 기존 운영되는 캐시를 삭제하는 부분은 혹시 모를 장애를 불러올 지 모르는 부분이기에 별도의 단순 확인용도의 health check 엔드포인트를 추가하였다.

@Cacheable(value = ["health"])
@CircuitBreaker(name="health", fallbackMethod = "getHealthCheck")
fun healthCheck(key: String=""): String {
    return this.getHealthCheck()
}

fun getHealthCheck(t: Throwable?=null): String {
    return if(t != null) "failed" else "success"
}

프로젝트 내부적으로 별도의 circuitBreaker 를 사용하도록 되어있는데, cacheManager 를 통해 데이터를 조회해보고 없다면, fallbackMethod 를 통해 가져온 값을 cacheManager 의 캐시에 집어넣게 되어있다.

여기서 실제 DB 등을 조회하는게 아닌, 단순한 문자열을 집어넣게 해두고, 만약 여기에 문제가 발생하면 failed 문자열을 밷도록 만들었다.

처음엔 현재 적용된 마스터 노드 엔드포인트 + MasterReplica + ReadFrom.REPLICA_PREFERED

설정에 대해 실패했다고 생각하여, 반드시 클러스터 엔드포인트 로 구성해야 할거라 생각하였고, 단순하게 생각한다면 설정에 의존하지 않고, 직접 각 읽기/쓰기 에 대해 각각 커넥션 연결을 구성하여 사용하는 방법이 최선이라 생각하여 고려하게 된 부분이었다. 하지만 이 방법에 대해서는 조금만 고민해보면 굉장히 고려해야 할 부분이 많아진다.

위 Redis 설정에 대한 그림에서 LettuceConnectionFactory 를 분리하여 생성하게 된다면, 당연히 그 하위에 ConnectionFactory 객체를 주입받아야 하는 CacheManager, RedisTemplate 두 객체도 그에 맞게 별도의 구성을 해주어야 한다.

아마 그림으로 보면 위와 같이 구성되게 될텐데, 애초에 RedisTemplate 에 대해서는 수동조작하는 방식으로 객체를 가져다 코드에서 조작하도록 사용하였으니, 해당 객체를 사용하는 부분에 들어가 읽기와 쓰기에 대해 사용하는 부분을 수정하면 되는 부분이긴 하다. 어쨌든 이 객체를 사용하는 부분들 모두 찾아가 수정해주어야 하는 부분이 해당 처리방법에 첫번째 우려되는 부분이다. 변경점에 모두 수작업으로 변경해주고, 각 처리되는 부분에 대해 모두 테스트를 재진행해주어야 한다.

제일 문제되는 부분이 CacheManager 이다. Cache 사용에 있어 CacheManager 를 사용하여 얻는 이점은 당연히 Spring 에서 지원해주는 Aspect 기능의 어노테이션으로 지원되는 부분이다. CacheManager 를 사용하므로 기본적으로 코드는 @Cacheable @CacheEvict 등의 선언식의 코드를 작성하도록 되어있다. 이때 @CacheEvict 에 대해서는 사실 쓰기 담당하는 CacheManager 를 사용하면 그만이지만 @Cacheable 에 대해서는 사실 읽기/쓰기가 같이 있다고 봐야 한다. Redis 에 데이터가 있다면 읽어서 리턴하고, 없다면 코드를 수행하여 결과값을 캐시에 넣고 리턴하기 때문에 읽기/쓰기 두개의 동작을 해야한다. 하디만 @Cacheable 어노테이션 설정에 cacheManager 는 하나만 설정할 수 있다.

이 문제를 해결하기 위해 기존 CacheManager 를 뜯어보고, 내부 사용 객체에 cacheWriter 라는 객체를 사용하는걸 확인하여, 혹시 해당 CacheManager(RedisCacheManager) 를 상속받아 cacheReader 라는 별도의 ConnectionFactory 를 주입받아 Routing 처리가 가능한지 확인해보는 방법도 고려해보았다.

이 경우 Redis 설정에 넣은 각 클러스터 엔드포인트에 대해 어떤게 마스터인지 모르겠다고 얘기하며 Exception 이 떨어진다.

Unsupported block type: quote

위와 같은 exception 을 뱉어낸다. 그래도 위 내용으로 하나 알게된 내용은, Redis 연결에 대해 우리가 설정에 넣은 순서에 따라 역할이 부여되거나 하는 내용이 아니라는 점이다. 분명하게 에러 내용을 보면 내가 설정한 클러스터 엔드포인트에 대해 role 을 REPLICA 로 가져갔다.

이 테스트로 알게 된 내용이다.

이 경우 Redis 설정을 Cluster 로 올렸기 때문에 설정한 클러스터 엔드포인트에 대해 별도의 Master/Replica 의 역할을 구분하여 인식하지 않는다.

그렇기 때문에 ReadFrom 설정을 하더라도 별다른 역할 구분이 없기 때문에 둘 중 어느쪽이든 커넥션 맺는대로 사용하게 된다. 대부분의 경우 테스트에서 마스터만 사용하게 되었다.

처음으로 정상동작했던 설정이다. 해당 설정을 사용하면 커넥션에 대해 Role(역할) 체크까지 정상적으로 마치고 사용 시에도 문제 없이 동작했다.

즉, 중요한건 실제 연결되는 Redis 에 대해 역할이 정확하게 확인되어야 한다는 것이다. 클러스터 엔드포인트도 다른 레플리카 되는 노드의 엔드포인트도 Redis 자체에 룰이 정확하게 마스터로 되어있지 않았고, 어플리케이션 서버에서 직접 커넥션을 맺어보고 확인했을 때 해당 Redis 가 본인의 역할(룰)을 알려주는걸 사용하는 것이기 때문에 우리가 임의로 다른 엔드포인트를 마스터라고 설정할 수는 없는 것이었다.

위 테스트로 알게 된 내용으로 마스터 역할을 하는 Redis만 식별되면 되는 것을 알게되었다. 그렇기 때문에 마스터 클러스터에 있는 노드들에 대해서는 실제 마스터 Redis 식별을 위해 다 넣어주어야 한다. 하지만 레플리카 되는 클러스터의 경우, 클러스터 엔드포인트의 역할이나 각 레플리카 노드들의 역할이 다르지 않을 것으로 보여 레플리카의 경우 클러스터 엔드포인트를 지정해주었다.