[최종 프로젝트 - 현재 시세를 반영한 모의 투자 서비스] 5분 브리핑(2차)
·
카테고리 없음
1️⃣ 체결 구조 개선 (Scheduler → RabbitMQ)✅ 문제 정의 기존 모의투자 서비스의 핵심 기능인 "주문 체결"은 스케줄러 기반의 주기적 처리 방식으로 구현@Scheduled(fixedRate = 1000)으로 1초마다 전체 주문을 스캔 주요 문제점주가 변동이 없어도 반복적으로 전체 주문 탐색실시간 반응 불가 (주기 기반 처리)종목 수 증가 시 병목 및 리소스 낭비 발생 @Scheduled(fixedRate = 1000) // 1초마다 실행 public void settleOrders() { List completeOrders = orderRepository.findAllReadyOrdersWithFetchJoin(OrderStatus.COMPLETED); for (Order order..
[최종 프로젝트 - 모의 투자 서비스] RabbitMQ 를 이용한 실시간 지정가 체결
·
프로젝트/프로젝트 회고
이번 프로젝트에서 모의 투자 서비스의 성능을 크게 좌우하는 핵심 기능은 "주문 체결"이다. 기존에는 스케줄러 기반의 주기적 체결 방식으로 구현되어 있었지만, 실시간 가격 변화에 즉시 반응하지 못해 성능과 트래픽 측면에서 한계가 있었다. 그래서 이전에 작성한 블로그를 참고하여 기술을 적용할려고 한다. ✅ 1. 기존 구조의 문제점모든 종목의 주문을 일정 주기로 전체 스캔(Schedule) → 리소스 낭비조건에 맞지 않는 주문도 매번 평가 → 불필요한 쿼리/계산 발생실시간 체결이 어려움 → 사용자 반응성 저하가격 급등락 시 스케줄러 병목 → 성능 저하 📌기존 코드스케줄러를 이용해 1초마다 주문완료된 주문건과 해당 종목의 가격을 redis 에서 불러와 비교함불필요한 쿼리문 발생@Scheduled(fixedR..
[Spring]비동기 메시지 큐 (Kafka & RabbitMQ)
·
Spring
이번 프로젝트에서 모의 투자 서비스의 성능을 크게 좌우하는 핵심 기능은 "주문 체결"이다. 기존에는 스케줄러 기반의 주기적 체결 방식으로 구현되어 있었지만, 실시간 가격 변화에 즉시 반응하지 못해 성능과 트래픽 측면에서 한계가 있었다.이를 개선하기 위해, 실시간 체결 시스템에 적합한 메시지 브로커를 도입하고자 하였고, 그 선택의 타당성을 확인하기 위해 먼저 메시지 브로커 개념을 이해하고, Kafka와 RabbitMQ를 비교 분석하였다.💡 "메시지 브로커(Message Broker)는 분산 시스템 간 데이터를 안정적으로 주고받기 위한 미들웨어로, 발신자(Producer)와 수신자(Consumer) 사이에서 메시지를 큐에 저장하고 비동기로 전달하는 역할을 한다. ✅ 메시지 브로커 이해메시지 큐(MQ)는 ..
[최종 프로젝트 - 현재 시세를 반영한 모의 투자 서비스] 주문 도메인 성능 개선(Redisson 분산락 적용)
·
프로젝트/프로젝트 회고
이번 프로젝트에서 모의 투자 서비스의 핵심 기능인 "주문 체결"에 대해 맡았다. 실시간 시세를 기반으로 여러 사용자가 동시에 시장가 매수를 시도할 경우, 잔고 차감 및 보유 종목 업데이트가 정확히 반영되지 않으면 데이터 정합성 문제가 발생한다. 이 문제를 해결하기 위해, Redisson 기반의 분산락을 커스텀 어노테이션 방식으로 도입하였다. ✅ TradeService에 Redisson 락 적용하기📌 문제 상황다수의 유저가 동시에 동일한 계좌로 매수 주문을 보낼 경우, 잔고 차감 및 보유 종목 수량 증가가 동시성 문제가 발생하면서 데이터가 꼬여버렸다. 동시성 제어에 대해 이론적으로 다룬 글이 있어 해당 글을 참고하였다.https://computerreport.tistory.com/154 [Spring..
[트러블슈팅] Redisson 분산락과 트랜잭션 적용 시점 충돌(AOP 를 활용한 해결)
·
프로젝트/트러블슈팅
intro프로젝트를 진행하며 발생한 문제 상황과 해결 과정들을 상세히 기록하고 추후에 같은 문제가 발생 했을때 빠르게 문제 해결하기 위해 트러블 슈팅을 정리할려고 한다.기록하는 습관을 기르기 위해 프로젝트 기간동안 꾸준히 작성할 것 이다.처음에는 @DistributedLock과 @Transactional을 함께 사용하면 락과 트랜잭션이 동시에 작동해 정합성이 보장될 줄 알았다. 하지만 실제 테스트 과정에서 다음과 같은 문제가 발생했다.⚠️ 문제 상황 발생@Around("@annotation(distributedLock)")public Object lock(ProceedingJoinPoint joinPoint, DistributedLock distributedLock) throws Throwable { ..
[Spring]동시성 제어(Redisson)
·
Spring
5분 브리핑을 진행하면서 다수의 멀티 스레드로 동시 주문을 실행하면 데이터 정합성 문제가 발생하는 것을 다루었고 본격적으로 성능 개선을 위해 분산 락을 적용해볼려고한다.✅분산 환경에서 동시성 제어는 왜 필요한가?여러 요청이 공유 자원을 동시에 접근할 때, 분산된 DB나 서버 간 동기화 속도 차이로 인해 데이터 정합성 문제가 발생할 수 있다.예를 들어, 모의투자 시스템에서 동일한 계좌가 여러 주문을 동시에 처리하는 경우, 잔고 감소 또는 보유 주식 수량 차감이 정확하게 이루어지지 않아 잘못된 체결이나 정합성 오류가 발생할 수 있다. ✅분산락 없이 발생하는 문제점📌 하나의 계좌가 동시에 두 개의 매도 주문 처리 시도 기대 결과: 보유 주식 1개씩 두 번 매도되어 총 2개 차감실제 결과: 보유 주식이 1개..