바쁜사람들을 위한 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를 통해 데이터를 조회
3.
기존의 조회 데이터가 변경되는 경우 redis 에 해당 값을 업데이트 하도록 수정
테스트 환경
LOCUST
•
user : 300 (TPS 100)
•
time : 1시간
RDB
•
Aurora mysql 5.7
•
db.r5.large
ElastiCache
•
Redis 5.0.6
•
t2.micro
Spring Service
•
t3.medium
•
tomcat 8
•
Spring 1.5.4v
결과
Reids 반영 전 Locust 결과
Redis 반영 Locust 결과 (오후 4시부터 58분부터 10분간 Redis 정지)
Redis 수정 전 | Redis 반영 및 Redis on | Redis 반영 및 Redis off | |
Spring Service CPU | 70% | 70% | 70% |
RDB CPU | 20- 22% | 20 - 22% | 20 - 22% |
REDIS CPU | X | 0.1% | X |
RESPONSE TIME (ms) | 300ms 내외 | 450ms 내외 | 4800ms 내외 |
Connection count | 80 | 70 | 80 |
뭐야 왜 차이가 없어?
실제 결과는 Redis를 적용해서 RDS의 부하에 차이가 거의 없었고 그나마 DB Connection 개수가 약간 줄어들었다.
하지만 오히려 Redis 가 종료되는 경우 Redis 접근 대기를 위한 3초의 대기시간을 설정했던 바람에 reponse time 이 증가해버리는 문제점이 발생해버렸다.
어째서 이런 결과가?
사실 RDS 에 가해주는 주요 부하의 원인은 Read 가 아닌 Write 에 있었다.
해당 서버에 가해지는 TPS 의 95% 이상이 DB에 Write, Read를 동시에 하는 요청이였고,
하나의 요청에 많으면 4개의 table에 write 를 하는 상황이 나왔기 때문에
이로 인해 해당 부하가 발생하는 것 이였다.
조회 데이터 또한 많지만, 조회 데이터 범위가 row 1만개 이하이기 때문에 큰 부하가 발생하지 않았기도 했다.
이후 선임님이 불필요한 index 제거와, 기존 오래된 데이터들의 삭제작업 이후 DB CPU 사용량이 30 % 이상 감소했다
결론
RDB의 조회기능은 상당히 강력하며, 조회 시 CPU부하도 그렇게 높지 않다.
RDB의 조회 기능을 Cache를 사용하여 부하를 줄이고자 한다면, 차라리 RDS 읽기전용 레플리카 기능사용을 고려하는 것이 현명할 것 같다.
