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

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

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

intro프로젝트를 진행하며 발생한 문제 상황과 해결 과정들을 상세히 기록하고 추후에 같은 문제가 발생 했을때 빠르게 문제 해결하기 위해 트러블 슈팅을 정리할려고 한다.기록하는 습관을 기르기 위해 프로젝트 기간동안 꾸준히 작성할 것 이다.처음에는 @DistributedLock과 @Transactional을 함께 사용하면 락과 트랜잭션이 동시에 작동해 정합성이 보장될 줄 알았다. 하지만 실제 테스트 과정에서 다음과 같은 문제가 발생했다.⚠️ 문제 상황 발생@Around("@annotation(distributedLock)")public Object lock(ProceedingJoinPoint joinPoint, DistributedLock distributedLock) throws Throwable { ..