오늘은 레디스 모니터링 중에 바보된 사연을 소개합니다.
resque 나 sidekiq 같은 Redis를 Queue 로 사용하면서 겪은 삽질입니다.(개인적으로 둘 중에 하나를 추천하라면, sidekiq을 강력하게 추천합니다. 일단 sentinel과 연동된 failover 기능도 있고, resque가 lpop을 쓰는데 비해 sidekiq은 blpop을 써서 네트웍이나 redis 의 resource를 훨씬 적게 사용합니다.)
보통 위와 같이 redis를 queue로 사용할 때 redis network 의 input size 가 output size 보다 크거나 비슷해야 합니다. 왜냐하면 queue 이기 때문에 input == output 입니다. request 는 rpush queue_name data 인데, response 는 lpop queue_name + data 이니, 그런데… output 이 훨씬 많은 경우가 발생했습니다.
특정 기능이 동작하는지 보기 위해서 redis monitor 명령을 사용했습니다.
이유가 뭘까 고민을 하면서 다음과 같은 가정을 몇가지 해봤습니다.
1. 에러가 나서 리턴 스트링이 더 많다?
예를 들어 rdb 장애로 쓰기 금지 상태이면 ping 만 보내도 “MISCONF 어쩌고” 하는 에러 메시지가 전달됩니다.
그런데 이건 아니더군요.
그런데 의외로 간단하고 멍청한 이슈였습니다.
위의 기능을 확인하기 위한 redis monitor를 걸었더니… 그것도 외부에서 redis monitor | grep “1234” 식으로 했더니… 해당 서버에서 모니터링 메시지가 급증했던 것입니다. 실제로 모든 데이터가 넘어오니…
또한 해당 서버로 들어가서 redis monitor만 해도 실제로 ssh를 통해서 모니터링 메시지를 모두 보기 때문에, network outbound 가 늘어납니다. redis monitor | grep “1234” 이렇게 해당 장비 내부에서 하면 거의 늘어나지 않겠죠?
바보 같은 삽질기이지만… 웬지 다음에 또 실수할까 봐서 올립니다.
