채팅방(ChatRoom) 조회 성능 개선(Cache Aside Pattern 적용) - bondyuu/dodam GitHub Wiki
- 클라이언트가 주로 이용하는 기능은 정해져 있고, 해당 기능의 성능을 높이는 것이 마치 전체 프로그램 성능을 높여준느 효과를 만들어냅니다.
- 사용자 경험을 향상시키고 고객 유출 요소를 제거하기 위해 채팅방 성능을 개선해야 합니다.
- MySQL보다 Redis가 비싸면서도 저장용량(최대 512MB로 한정)은 작습니다.
- 성능 향상과 비용 최적화를 고려한 DB 전략이 필요합니다.
- 쌓여가는 채팅 메세지를 고려할 때 MySQL과 함께 Redis Caching 전략이 필요합니다.
- 대용량 트래픽을 고려해 Scale Up보다 Scale Out으로 기능 구현해야 합니다.
- 비용과 대용량 데이터 저장을 고려해 MySQL로 CRUD를 설계하고, 성능과 사용자 경험 향상, Redis의 작은 저장 용량을 고려해 캐싱을 적용했습니다.
- Redis의 한계 용량(512MB)을 고려할 때 Redis CRUD가 아니라 Redis Caching(Cache Aside Pattern)이 적합하다고 판단했습니다.
- Postman과 Insomnia를 활용해 성능 테스트를 진행했습니다.
- Redis Caching으로 채팅기록을 불러와 MySQL보다 빠른 로딩을 구현했습니다.
[채팅방 전체 목록 조회 속도를 97ms → 12ms로 약 800% 개선했습니다.]
[채팅방 상세 정보 조회 속도를 42ms → 13ms로 약 350% 개선했습니다.]
- Jmeter를 활용해 성능 테스트를 진행했지만 실패했습니다.
- JWT Token을 API에 입력하지 못해 실패했습니다.
- Jmeter의 기본적인 기능을 정확히 이해해야 구현 가능하다고 생각합니다.
- Spring Data Redis 대신에 Redis Client Redisson을 사용해 채팅 기능을 구현하려고 했습니다.
- 숫자 1 ~ 50,000을 DB에 입력하는 동작을 3번 반복한 결과, Redisson이 Spring Data Redis보다 약 30% 정도 성능이 좋았습니다.
- 하지만 Redisson의 경우 커뮤니티가 상대적으로 적고 처음 사용하기 어려웠습니다. 10일 동안 채팅 기능 구현에 애썼지만 결과적으로 포기하고 Spring Data Redis를 활용해 구현했습니다.
- Spring Data Redis 숙달 후 Redis Client Lettuce, Redisson을 사용하는 것이 옳다고 생각합니다.
