클라우드 환경에서의 Redis 라이센스 정책에 의해서 최근 io.valkey 에 대한 마이그레이션을 준비하고 있습니다. Valkey 는 Redis 7.4 미만 버전의 fork 서비스로 현재는 valkey 8.0 까지 release 되었지만, 저희는 아직 Valkey 7.2.x 로 테스트를 하고 있어요.

fork 버전이기 때문에 사용성에 있어서는 Redis 와 큰 차이가 없고, 가장 많이 사용되는 lettuce 에서의 호환 (하지만, 일부 기능은 사용할 수 없음) 으로 인하여 큰 무리 없이 하나씩 마이그레이션을 하고 있습니다.

하지만, Valkey 의 버전이 올라가면 올라갈수록 lettuce 를 사용이 안될 수도 있다는 점을 가정하여, io.valkey.glide 의 라이브러리를 테스트하고, 저희에 맞게 wrapping 을 하고 있는데요. valkey 서버와 다르게 Glide 라이브러리에 대한 지양점의 차이로 조금은 혼란스러운 상태가 있어서, 기록을 남겨둘까 해요.

• MasterReplica 구조에서 Replica 노드 직접 연결

  • lettuce 와 다르게 Valkey 는 Replica Role 을 가지는 Node 에 직접 연결을 할 수 없어요.

  • Replica Role 은 항상 Master 와 함께 붙어 다니면서 읽기 전략을 수행해야 하는 관점때문에 그런거 같아요.

• MasterReplica 에서의 pipeline 은 Primary 노드에 집중되요.

  • Pipeline 에 쓰기 명령을 할 수 있기에, 이와 같은 현상이 생겼을 것이라 생각해요.

  • 하지만, 이에 대한 설정을 사용자에게 맡긴다면 좀 더 좋은 환경을 제공할 것이라 생각하여, Github 에 이슈를 발행하였어요.

• Cluster Topology 업데이트는 자동 수행이 되어요.

  • Cluster 노드 변경을 위해서 lettuce 는 Topology 업데이트 전략을 추가 해줘야 했다면 Glide 라이브러리는 이를 알아서 해결해요.

• Transaction, Pipeline 명령을 위한 Connection 관리가 없어도 되요.

  • lettuce 는 Connection 에 직접 명령을 보내는 구조로, pipeline 을 위하여 autoFlush 를 끄고, 명령어를 모아 놓은 다음 flushCommands 를 해야 했거나.

  • transaction 의 multi 가 수행되면 connection 에 담기는 명령이 모두 multi 아래에서 수행되어야 하기에 Connection 을 별도로 만들거나 Pool 정책이 필요 했는데요.

  • 명령어 전달 방식이 channel 에 모이고 이를 Connection 에 flush 하는 방식으로 지원이 되면서 Pool 에 대한 신경을 쓰지 않아도 되요.

• Cluster 환경에서 mget, hmget 과 같이 같은 Slot 에서만 동작해야 하는 명령들이. Glide 모듈 내에서는 좀더 쉽게 접근이 가능하게 되요.

  • 각 Key 의 HashSlot 을 모듈내에서 구하고, Key 가 저장되어 있는 node 를 찾아서 그룹핑하여 한번에 전달하는 구조에요.

  • 하지만, 이 경우 최악의 상황에서는 모든 Node 에 한번씩 연결을 해야 하기 때문에 좋지 못한 결과를 얻을 수는 있고, Valey Cluster 서버내에서는 해당 명령을 지원하지 않기 때문에 모듈에서 되는 것 가지고 Valkey 이는 이것이 수행되는 구나 등의 오해가 있을 수 있어요.

Spring Data Redis 를 사용하지 않고 Lettuce 을 직접사용하면서 모듈 마이그레이션 과정에서 작은 (?) 차이점들을 알게 되었는데요.

Server 가 아닌 모듈이 지향하는 Remote Cache Server 와의 차이를 이해 한다면 조금은 위와 같은 사항이 이해되긴 합니다.

• lettuce : Server 와 1:1 로 맞추어서 기능을 만들고 서버에서 제공하지 않는 기능을 억지로 만들지 않아요.

• io.valkey.glide: 사용자의 편의성을 우선시 하고, performane 에 우선을 두고 있어요. 즉, valkey 서버에서는 지원하지 않는 기능이지만 편의성으로 확장을 하고 있는거 같더라구요.

모듈을 Wrapping 을 하게 되면, 우리의 케이스에 맞춰서 다양한 생각을 하게 되는 경험을 하게 되는데요. 이때 단순이 소스 모듈이 지원을 하기 때문에 서버도 이런 기능을 제공하겠지? 라는 생각 보다는 서버의 상황과 맞추어서 생각을 좀 더 깊게 해야 하는 케이스가 항상 발생하는것 같아요.

단순히 되네? 라기 보다는 이 모듈은 이게 왜 되는것이지? 하는 생각이 좀더 필요하지 않을까 싶어요.