트리맵 갱신 최적화

주식 테마 트리맵 서비스 성능 개선 과정

이 글은 주식 테마 트리맵 서비스를 구현하면서 겪은 문제와 해결 과정을 다룹니다. 특히 트리맵 생성의 성능 이슈, 실시간 시세 갱신 구조, 네트워크 호출 최적화 및 캐싱 전략을 통해 아키텍처를 개선한 과정을 공유합니다.

1. 트리맵(TreeMap)과 실시간 시세 갱신

트리맵이 필요한 이유

주식 서비스에서 시장 정보를 한눈에 파악할 수 있는 트리맵 기능은 필수적이며, 빠른 데이터 갱신이 중요합니다.

초기 시세 갱신 방식의 문제점

처음에는 개별 종목의 시세를 서버에서 하나씩 요청하고 DB에 저장하여, 과도한 네트워크 통신과 DB 트랜잭션으로 인해 성능 저하가 발생했습니다.

개선된 요청 방식과 비동기 처리

개별 요청을 시장(코스피, 코스닥) 단위의 일괄 요청으로 변경했으나, 서버 스케일 아웃 시 중복된 시세 업데이트가 발생했습니다. 비동기 스레드를 사용하여 메인 서버의 부하는 줄였지만, 서버 수가 증가하면 동일 작업이 중복 수행되어 스케일 아웃이 어렵게 되었습니다.

2. 아키텍처 변경: Kafka 활용

서버 역할 분리 및 Kafka 도입

서버를 시세 갱신(Collector)과 데이터 저장(Search)으로 분리하고, Kafka를 통해 비동기 메시지 통신을 하여 스케일 아웃 시 발생하는 중복 갱신 문제를 해결했습니다.

Collector 서버 스케일 아웃 필요성 검토

Collector 서버는 정기적인 데이터 수집 업무만 수행하므로 대규모 트래픽 발생 가능성이 적어 스케일 아웃이 필요하지 않다고 결론지었습니다.

참고: 해당 아키텍처는 토스 증권의 실시간 시세 갱신 구조를 참고하였습니다.

3. 트리맵 생성 성능 개선

초기 문제: 긴 트리맵 생성 시간

트리맵 생성 주기를 5분으로 설정했지만, 실제 생성에 7분이 소요되어 실시간성이 떨어졌습니다.

문제 원인 분석

HashMap 키 비교에서 엔터티의 equals 메서드가 필요 이상으로 많은 필드를 비교하여 추가 쿼리가 발생해 속도가 저하됐습니다.

해결 방법: equals 최적화

비즈니스 로직 상 꼭 필요한 필드(code)만을 이용하여 equals 메서드를 재정의했고, 트리맵 생성 시간이 7분에서 5분으로 개선됐습니다.

4. 네트워크 호출 최적화

문제점: 개별 호출로 인한 병목

각 주식 데이터를 개별적으로 요청하여 병목이 발생했습니다.

개선 방법: SQL IN 절 활용

필요한 데이터를 SQL의 IN 절을 이용하여 한 번에 조회하고, 최소 기간(최근 3일)의 데이터만 조회하여 부하를 줄였습니다. 결과적으로 5분이었던 수행 시간이 1분으로 단축됐습니다.

5. 데이터 캐싱 및 요청 처리 구조 개선

Redis를 이용한 데이터 캐싱

생성된 트리맵 데이터를 Redis에 저장하여 사용자 요청 시 즉시 제공함으로써 실시간 생성 부담을 제거했습니다.

구조 변경 후 TPS 확장이 가능해졌습니다.

6. 결론 및 배운 점

• 비즈니스 로직에 적합한 equals()와 hashCode() 정의가 중요합니다.
• 네트워크 호출은 배치 처리로 최적화하여 성능을 높입니다.
• Redis 캐싱은 시스템 부하 감소와 실시간 응답 속도 향상에 효과적입니다.

이러한 최적화로 트리맵의 빠른 갱신과 높은 요청 처리를 모두 달성했습니다.

최종 결과 확인

최적화된 트리맵을 다음 사이트에서 실시간으로 확인할 수 있습니다:

👉 next-stock.com

---

참고자료

• 토스 증권 아키텍처 PDF