[신투 프디아] 실시간성과 안정성의 균형 맞추기 (Redis, MySQL)

 

이 글은 알파코에서 진행되는 [신한투자증권] 프로디지털아카데미 과정 중, 김송아 강사님과 함께하는 '파이널 프로젝트'를 기반으로 작성되었습니다

 

 

 

그동안의 프로젝트엔 모든 데이터를 MySQL에 넣고 조회하는 구조였다.

그런데 조건 탐지 로직이 매분 단위로 20개 종목 * 42개 조건을 검증해야 하는 상황이었기 때문에 DB 쿼리가 감당이 안됐다. 

조회 속도가 밀리면 실시간 알림의 의미가 없어지기 때문이다.

 

 

그래서 Redis를 도입했다.

자주 바뀌는 데이터는 Redis, 하루에 한 번 바뀌는 데이터는 MySQL

이라는 원칙을 만들었다.

 

 

Redis를 도입한 이유

Redis는 사실 속도 때문만이 아니라 역할 분리를 위해 도입했다.

• 1분마다 바뀌는 데이터는 캐시로서 빠르게 갱신
• 1일 단위 데이터는 하루 한 번만 MySQL에 영속화

-> 실시간 분석 전용 스테이지 역할을 하도록 설계했다.

 

 

키 컨벤션 설계

Redis의 핵심은 키 컨벤션이었다.

데이터를 어떻게 구분하느냐에 따라 캐시 구조가 달라지기 때문이다.

• 분봉 데이터 (1분마다 갱신)
• 일봉 데이터 (하루 1회 갱신)

 

 

 

MySQL과 동기화 설계

처음엔 Redis에만 데이터를 넣었다.

Redis는 빠르고 가볍지만, 영구 저장소로 쓰기엔 불안정하다.

메모리 기반이라 서버가 재시작되면 데이터가 사라질 수 있고, 덮어쓰기나 TTL 만료로 데이터가 언제 없어질지 모른다.

그래서 하루에 한 번, 장 마감 시점에 Redis 데이터를 MySQL로 옮기는 구조를 추가했다.

• 1분 데이터 -> Redis에만 저장, 1시간 보관
• 1일 데이터 -> Redis 저장 후 하루 1회 MySQL에 동기화
• MySQL은 영구 보관 및 분석용

이렇게 나누니까 실시간성과 안정성의 균형이 잡혔다.

 

 

느낀 점

Redis를 쓰면 속도는 빨라지지만 그만큼 데이터 정합성을 스스로 책임져야 한다.