신규 서비스의 기능을 설계하면서 빠른 데이터 접근이 필요하고, 별도로 관리할 필요는 있지만 굳이 MongdoDB 나 RDB를 사용할 필요가 없어서 Redis를 붙인 부분이 있었다.
QA에서 성능테스트를 진행하지 않아 미처 예측을 하지 못해, 실제 배포후 XXXX만개 가량의 데이터를 처리하면서 레디스의 I/O 성능이 기대치보다 낮아 오히려 서비스 제공에 문제가 발생했었다. 따라서 레디스는 활성화된 유저들에 한해 캐시 서버처럼 사용하도록 변경되었다.
이때 결국 남은 데이터를 밀었어야 하는데, 해당 작업을 진행하면서 불안감에 레디스 클러스터 모니터링을 하고 있었다. 이때 눈에 띄게 올라가는 수치가 있었는데 'Fragmentation ratio'였다.
여기서 Fragmentation ratio란?
레디스에서의 fragmetation ratio(단편화 비율)은 'Used Memory RSS / Used Memory' 로 계산하고, 따라서 1%이면 1배, 2%이면 2배이다. 즉, OS가 레디스에 할당하기 위해 사용한 물리 메모리 양이, 실제 매모리 사용량의 몇배인지를 계산하여 단편화 비율을 추론하는데, 보통은 1.5 이하로 유지하는 것이 바람직하다.
다만 RSS가 peak를 기준으로 산정되어 단편화 비율 값을 신뢰 할 수는 없지만 대강 비슷한 수치이겠거니하고 참고 지표로 활용하면 될 듯 싶다.
그렇다면 지금 내가 삭제하고 있는 레디스의 단편화 비율은 1.5 아래여야하잖아?
불안해서 OOO만건의 데이터를 선 삭제했었는데, 이때 0.1 정도가 올라가는 것을 확인했다. 만약 이 상태로 XXXX만건을 삭제한다면 ratio가 1.5를 넘길 것이 분명했다.
그럼 키가 만료될 때까지 기다리면 되지 않냐고 되물을 수 있다. 그렇게 된다면 XXXX만 건이 1시간 사이에 모두 추가된 데이터들이었기에 만료도 해당 시간 안에 동시에 이루어질 것이고, 결국은 예상하지 못한 시간에 단편화 수치가 피크를 찍어 서비스에 영향을 끼칠 가능성이 존재했다.
어떻게 해결해야 할까?
여러번 재시작 요청을 하는 것이 무리일 것이라고 생각하고 다른 팀들은 해당 이슈를 어떻게 해결했나 확인해보니 단순하게 1.5 수치를 넘기면 그때 레디스 담당자에게 레디스 재시작을 여러번 요청했고, 아니면 특정 키값에 대한 키 클랜징 요청을 한 기록이 있었다.
결국 안정성을 위해 플랫폼 팀에 키클랜징 협업 요청을 드렸고, 우리 팀이 사용하는 레디스 클러스터 버전부터 키클랜징을 지원하지 않는다는 답변을 받았다. 하....
그럼 내가 우려한 일이 벌어질까?
대량의 작은 객체를 다루고 있었기에 단편화 비율이 높아지는 상황이었는데, 전체 메모리 사용량이 적다면 큰 이슈가 발생하지 않는다. 그리고 플랫폼 팀에서도 용량이 넉넉하여 우려한 문제가 발생하지 않을 가능성이 높으니 모니터링 후 요청해도 된다는 답변을 받았다.
그렇다 현재 할당 받은 용량이 총 1TB, 그리고 현재 사용량이 10GB였기 때문에 동시 만료 시기에만 모니터링하고 이후 restart 요청을 하는 것이 오히려 합리적인 선택이 되었다.
근데 신기한게 해당 문제에 대해서 내가 처음으로 논의한 사람이 되었다. 지금까지 문제가 발생했으면 플랫폼 팀에서 먼저 연락이 왔는데, 우리팀에서 사용하고 있는 다른 레디스 ratio가 2.0이 넘어도 문제가 발생하지 않아, 아무도 신경쓰지 않았다고 했다.
내가 너무 예민했나 싶기도 했지만, 팀에서 한번더 생각해 볼 이슈가 생겨서 좋은 계기가 된 사건이었다.