가시성은 좀 별로인데 


나도 다른 사람들 플젝 하는거 올리니까 자극되서 계획하던거 올려봄.





자프링 입문한지 2개월 된거라 아직 잘 모르는데 피드백 주면 써도 달게 받음.





로드맵은 총 6단계로 우선은 계획중이고

mvp후 나머지 5단계는 점진적 개선을 위한 단계로 알면됨.

이대로 그대로 할건 아니고 진행 하기전 계획을 어느정도 잡은거라고 보면 됨.


일단 ERD/ DDL/ 정책 / 트랜잭션 플로우 까지 끝내서 시퀸스만 정립하고 바로 들어갈듯.







0. 인프라 및 환경 구성


목표 : 최소한의 비용으로 환경 구축하기


테스트 환경 : windows 11 + WSL2 (Ubuntu 22.04)


개발은 Macbook (맥에서 테스트하고 모니터링 하고 다같이 하기에는 부하 측정의 결과가 믿을만 하지 못했어서)


리소스 제어 : Docker compose 로 실행하되, 리소스 제한으로 저사양 인스턴드 환경 구현


구성은

메인 - Java 17, Spring Boot

봇 - Java(쓰레드 공부할겸) or Python

기타 - MySQL , Redis, RabbitMQ or Kafka

모니터링 - Prometheus + Grafana



실제 AWS 배포 테스트는 5단계 WebFlux 도입 후 로 예상




---------------------------------------------------------




1. MVP + 미러링 봇


목표 : 거래소 코어 기능 구현 및 업비트 시세 추종


아키텍쳐 : Spring MVC + MySQL



초기 제약조건을 PK/FK/Unique 정도만 해서 빠르게 MVP 마무리 (2주 예상)

하나의 트랜잭션으로 동기적으로 모든 로직 처리



미러링 봇

1. 업비트 websocket으로 실시간 호가 받아오기

2. 현재가 기준으로 지정가 주문 생성

3. 주기적으로 시장가 주문 강제 체결로 시세 형성

4. 가격 급등시 cancel하고 재주문하기


로 구성.



검증지표는 JUnit으로 테스트 코드 통과





-----------------------------------------------------



2. 정합성 강화


목표 : 금융 시스템 수준의 데이터 무결성 확보



예상되는 문제는

1. 동시 주문으로 경합 문제가 생겨 잔고가 마이너스가 되거나 꼬이는 문제.

2. 주문 체결이 딜레이 되면서 무한 로딩에 걸리는 문제.



메인:

1. Strict DDL 적용 (DB레벨의 검증이나 인덱스 등)

2. Update 가 아닌 모든 자산변경 이력을 원장에 Insert 하고 합산 검증

3. 비지니스 예외 처리

4. 트랜잭션 격리 수준 검토




검증 지표는 동시성 테스트 시나리오




--------------------------------------------------



3. 캐싱 전략과 성능 최적화 


목표 : p95 응답 속도를 100ms 이하로.



예상되는 문제는

1. 메인 접속 시 현재가(Ticker) 및 호가 (Order Book) 조회 쿼리로 DB CPU 폭주 예상.



메인:

Redis 도입 

- 호가는 Sorted Set 활용

- 현재가는 체결 발생 시 Hash 자료주고 업데이트


Write-Through 방식으로 체결엔진이 DB 저장과 Redis 갱신을 동시에 처리하게끔.


Slow Query Log 분석으로 인덱스 최적화



검증 지표는 K6 부하 테스트 (유저 90% + 봇 10% 트래픽)


이떄 기준치는 실제 업비트 mau 리서치 해서 역산할 예정.





--------------------------------------------------------------------



4. 매칭 엔진 고도화 및 동시성 제어


목표 : DeadLock 0건 + TPS 극대화



예상되는 문제점

1. 주문량 폭증 시 DB Row Lock 경합으로 인한 체결 지연 및 데드락 발생.


메인 : 

충돌이 적은 경우에는 Optimistic Lock 도입

핫한 자산의 잔고 차감 시에는 Redisson 도입


DB 쿼리 매칭을 In-Memory (Java Priority Query) 기반 매칭으로 

@Async 를 통해서 주문 접수와 체결의 스레드를 분리



검증 지표는 봇의 트래픽을 올려서 데드락 발생 여부와 TPS를 측정 비교





-------------------------------------------------------------------



5. 논 블로킹 아키텍쳐로 전환


목표 : 동일 인스턴스에서 동시 수용량 N배 증가 및 AWS 배포



예상되는 문제점

Tomcat 스레드 풀 고갈 및 Context Switching 오버헤드


메인:

Spring MVC 를 Spring WebFlux 로 전환.

DB 드라이버를 비동기로 전환해서 I/O 블로킹 제거

SSE / WebSocket으로 체결 내역과 호가창 실시간 업데이트


로컬에서 AWS 배포로




검증 지표는 로컬 환경에서 MVC 대비 접속자 수 비교 와 로컬 환경 과 AWS 배포 환경의 동시 접속자수 비교


++ 가능하다면 이떄 코틀린으로 변경? (아마 안할듯?)



---------------------------------------------------------------------------




6. MSA + 내결함성


목표 : Single Point of Failure 제거 및 장애 전파 차단




예상되는 문제점

매칭 엔진이 멈추면 모든 시스템이 멈추는 단일 실패 지점이 발생하여 장애전파 발생.



메인:

인증 서버 <> API 서버 <> 매칭 엔진 서버 <> 소켓 서버를 분리.


RabbitMQ 나 Kafka를 도입해서 이벤트 기반 아키텍쳐로 전환.

> 주문 -> 메시지 큐 -> 매칭 엔진 -> 메시지 큐 -> 정산 및 알림



검증 지표는 의도적인 매칭 엔진의 다운에도 조회 및 주문 접수 가능한지 테스트





--------------------------------------------------------------------------------




기존의 프로젝트에서 좀 못해봤던거랑 gpt 사용해서 계획을 좀 세웠음.




아마 모니터링 쏙에서 좀더 가서 예거나 쓰레드 덤프 분석 까지도 좀 해볼가 싶은데


아직 모니터링도 제대로 파악하지 못해서 이거는 하면서 딥다이브 해볼예정.






중간에 뭔가 이거는 왜필요하나 같거나 빠진 부분이나 개선할거 있으면 


뭐든 피드백으로 받겠음미다.