바쁜사람들을 위한 3줄 요약

1. RDB 의 조회 기능은 우리가 생각하는 것보다 훨씬 강력하고 효율적이다.
2. RDB 의 부하를 높히는 것은 조회기능보다 데이터 삽입, 수정이 압도적으로 높다
3. DB connection 개수를 약간이나마 줄이는 목적이 아니라면 그냥 RDB 조회를 사용해라

문제상황

이 글을 쓰고 있는 저는 이제 백앤드 개발 2년차에 들어가는 신입 백앤드 개발자입니다.

이번 8월초에 받은 업무중 하나로 특정 단말에 들어오는 데이터를 여러 고객사에 전달할 수 있는 기능 개발에 대한 일이였습니다. 다만 당시 얼마전에 해당 서비스에 붙어있는 RDB의 CPU 상황이 피크시간때에 뻗어버렸던 일이 발생했고, 인덱스 개선 작업이 이루어져도 여전히 높은 리소스 사용량을 보이며, 앞으로 해당 서비스에 연결할 단말이 늘어날 계획이었기 때문에 이에 대한 개선작업 또한 이루어져야했습니다.

저는 이 상황에서 조회하는 데이터가 잘 변하지 않는 데이터임을 확인하였고, 이를 Redis Cache에 저장하고 우선적으로 조회하도록 설계해 작업을 진행했습니다.

왜 해당 기술을 선택했는가?

Redis

1. 해당 서비스는 단일 서비스가 아닌 4개 이상의 이중화가 되어있는 서비스 이었기에, ehcache로 구현시 추가 동기화 작업이 필요함
2. 다른 서비스 기능으로 인해 Redis 가 이미 구축되어 사용하고 있기에 추가 작업이 필요 없음

환경

1. 1 서비스당 최소 10, 최대 60 TPS 부하
2. db.r5 이상의 AWS RDB
3. DB Connection pool 개수를 최소 20개 최대 100개로 설정

작업 진행

1. 기존의 조회에 사용한 pk 를 redis-key 로 사용하고, redis를 우선적으로 조회하도록 설정
2. Redis connection 이 끊어졌다고 판단되면 RDS를 통해 데이터를 조회