1️⃣ 체결 구조 개선 (Scheduler → RabbitMQ)✅ 문제 정의 기존 모의투자 서비스의 핵심 기능인 "주문 체결"은 스케줄러 기반의 주기적 처리 방식으로 구현@Scheduled(fixedRate = 1000)으로 1초마다 전체 주문을 스캔 주요 문제점주가 변동이 없어도 반복적으로 전체 주문 탐색실시간 반응 불가 (주기 기반 처리)종목 수 증가 시 병목 및 리소스 낭비 발생 @Scheduled(fixedRate = 1000) // 1초마다 실행 public void settleOrders() { List completeOrders = orderRepository.findAllReadyOrdersWithFetchJoin(OrderStatus.COMPLETED); for (Order order..

이번 프로젝트에서 모의 투자 서비스의 성능을 크게 좌우하는 핵심 기능은 "주문 체결"이다. 기존에는 스케줄러 기반의 주기적 체결 방식으로 구현되어 있었지만, 실시간 가격 변화에 즉시 반응하지 못해 성능과 트래픽 측면에서 한계가 있었다. 그래서 이전에 작성한 블로그를 참고하여 기술을 적용할려고 한다. ✅ 1. 기존 구조의 문제점모든 종목의 주문을 일정 주기로 전체 스캔(Schedule) → 리소스 낭비조건에 맞지 않는 주문도 매번 평가 → 불필요한 쿼리/계산 발생실시간 체결이 어려움 → 사용자 반응성 저하가격 급등락 시 스케줄러 병목 → 성능 저하 📌기존 코드스케줄러를 이용해 1초마다 주문완료된 주문건과 해당 종목의 가격을 redis 에서 불러와 비교함불필요한 쿼리문 발생@Scheduled(fixedR..

이번 프로젝트에서 모의 투자 서비스의 성능을 크게 좌우하는 핵심 기능은 "주문 체결"이다. 기존에는 스케줄러 기반의 주기적 체결 방식으로 구현되어 있었지만, 실시간 가격 변화에 즉시 반응하지 못해 성능과 트래픽 측면에서 한계가 있었다.이를 개선하기 위해, 실시간 체결 시스템에 적합한 메시지 브로커를 도입하고자 하였고, 그 선택의 타당성을 확인하기 위해 먼저 메시지 브로커 개념을 이해하고, Kafka와 RabbitMQ를 비교 분석하였다.💡 "메시지 브로커(Message Broker)는 분산 시스템 간 데이터를 안정적으로 주고받기 위한 미들웨어로, 발신자(Producer)와 수신자(Consumer) 사이에서 메시지를 큐에 저장하고 비동기로 전달하는 역할을 한다. ✅ 메시지 브로커 이해메시지 큐(MQ)는 ..

이번 프로젝트에서 모의 투자 서비스의 핵심 기능인 "주문 체결"에 대해 맡았다. 실시간 시세를 기반으로 여러 사용자가 동시에 시장가 매수를 시도할 경우, 잔고 차감 및 보유 종목 업데이트가 정확히 반영되지 않으면 데이터 정합성 문제가 발생한다. 이 문제를 해결하기 위해, Redisson 기반의 분산락을 커스텀 어노테이션 방식으로 도입하였다. ✅ TradeService에 Redisson 락 적용하기📌 문제 상황다수의 유저가 동시에 동일한 계좌로 매수 주문을 보낼 경우, 잔고 차감 및 보유 종목 수량 증가가 동시성 문제가 발생하면서 데이터가 꼬여버렸다. 동시성 제어에 대해 이론적으로 다룬 글이 있어 해당 글을 참고하였다.https://computerreport.tistory.com/154 [Spring..