전편에 이어서..
머 어느정도 완료는 되었습니다.
더 이상 고도화 할 필요는 없어서 여기서 멈추지만 주문 체결 선물 포지션 청산 까지 구현은 했고
TPS 도 잘 나오네요. 더 고도화 하다간 제 컴터가 먼저 하늘나라 갈꺼 같아서...
시스템 아키텍처
[사용자 브라우저] → [CloudFront/S3] → [ALB] → [API Gateway :8080]
│
┌──────────────────────────────────┼──────────────────────────┐
│ │ │
[UCenter :6001] [Exchange API :6004] [Market :6003]
(회원/인증/KYC) (현물거래 API) (시세/WebSocket)
│ │ │
[OTC API :6002] [Exchange Engine :6005] [Futures API :6009]
(P2P 거래) (주문 매칭 엔진) (선물거래 API)
│ │ │
[Wallet :6006] [Futures Engine :6008] [Chat :6007]
(입출금) (선물 매칭 엔진) (메시징)
│ │ │
[Admin :6010] [Robot :20000] [Redis 7]
(관리자 API) (시장조성 봇 - 바이낸스 추종) (캐시/세션)
│ │ │
└──────────────[MySQL 8.0]─────────┼────[MongoDB 7.0]─────────┘
│
[Kafka 3.6]
(이벤트 스트리밍)핵심 기능
거래 기능은 현물 거래(실시간 오더북 + 캔들차트), 선물 거래(레버리지 지원), OTC P2P 법정화폐 거래(에스크로), 그리고 바이낸스/OKX/HTX 시세를 추종하는 자동 시장조성 봇까지 포함합니다.
사용자 기능으로는 이메일/SMS 인증 회원가입, KYC 본인인증(신분증 업로드), 2FA, 다중 화폐 지갑(입출금), 추천인 시스템(커미션 추적)이 있습니다.
관리자 기능은 회원 관리, KYC 승인 워크플로우, 거래쌍/코인 설정, 주문 모니터링, 재무 리포트, 봇 제어까지 60개 이상의 관리 페이지로 구성됩니다.
이걸 aws 테라폼으로 배포한다고 할때..
성능 분석: 사양별 수용 가능 유저 수
이 시스템의 성능 병목 지점을 분석하고, 서버 사양별로 수용 가능한 유저 수를 추정했습니다.
병목 지점 분석
| 구간 | 병목 요소 | 영향 |
|---|---|---|
| 매칭 엔진 | 심볼당 단일 스레드 synchronized 처리 | 단일 거래쌍 최대 처리량 제한 |
| Gateway | Redis Rate Limiter + Connection Pool | 동시 접속 수 제한 |
| Kafka | 브로커 수 × 파티션 수 | 메시지 처리 처리량 제한 |
| MySQL | 커넥션 풀(HikariCP max 50) + I/O | 주문/체결 영속화 병목 |
| WebSocket | Market 서비스 메모리 + 네트워크 대역폭 | 실시간 시세 구독자 수 제한 |
사양별 성능 추정표
Tier 1: 스테이징/개발 환경 (~$410/월)
| 구성 요소 | 사양 |
|---|---|
| ECS Fargate | 서비스당 0.5 vCPU / 1GB RAM (12개 서비스) |
| MySQL | db.t3.micro (2 vCPU, 1GB) |
| Redis | cache.t3.micro |
| Kafka | kafka.t3.small × 2 브로커 |
| MongoDB | t3.micro EC2 |
| 지표 | 수치 |
|---|---|
| 동시 접속 유저 | 300 ~ 500명 |
| 주문 처리량 | ~200 건/초 (단일 거래쌍) |
| WebSocket 구독자 | ~1,000명 |
| 오더북 깊이 | 100 호가 |
| API 응답 시간 | 50~200ms (p95) |
| 일일 활성 유저 | ~2,000명 |
Tier 2: 소규모 프로덕션 (~$1,200/월)
| 구성 요소 | 사양 |
|---|---|
| ECS Fargate | 서비스당 1 vCPU / 2GB RAM |
| MySQL | db.t3.medium (2 vCPU, 4GB) |
| Redis | cache.t3.small |
| Kafka | kafka.m5.large × 2 브로커 |
| MongoDB | t3.small EC2 |
| 지표 | 수치 |
|---|---|
| 동시 접속 유저 | 1,000 ~ 3,000명 |
| 주문 처리량 | ~800 건/초 (단일 거래쌍) |
| WebSocket 구독자 | ~5,000명 |
| 오더북 깊이 | 100 호가 |
| API 응답 시간 | 20~100ms (p95) |
| 일일 활성 유저 | ~10,000명 |
Tier 3: 중규모 프로덕션 (~$3,500/월)
| 구성 요소 | 사양 |
|---|---|
| ECS Fargate | 엔진 2 vCPU / 4GB, API 서비스 1 vCPU / 2GB (Multi-AZ) |
| MySQL | db.r6g.large (2 vCPU, 16GB) + Read Replica 1대 |
| Redis | cache.r6g.large (클러스터 모드) |
| Kafka | kafka.m5.large × 3 브로커 |
| MongoDB | r6g.large EC2 |
| 지표 | 수치 |
|---|---|
| 동시 접속 유저 | 5,000 ~ 15,000명 |
| 주문 처리량 | ~3,000 건/초 (단일 거래쌍) |
| WebSocket 구독자 | ~20,000명 |
| 오더북 깊이 | 100 호가 |
| API 응답 시간 | 10~50ms (p95) |
| 일일 활성 유저 | ~50,000명 |
Tier 4: 대규모 프로덕션 (~$8,000+/월)
| 구성 요소 | 사양 |
|---|---|
| ECS Fargate | 엔진 4 vCPU / 8GB, API 2 vCPU / 4GB (3-AZ) |
| MySQL | db.r6g.xlarge (4 vCPU, 32GB) + Read Replica 2대 |
| Redis | cache.r6g.xlarge (클러스터 모드, 3 샤드) |
| Kafka | kafka.m5.2xlarge × 3 브로커 |
| MongoDB | r6g.xlarge EC2 (레플리카셋) |
| 지표 | 수치 |
|---|---|
| 동시 접속 유저 | 20,000 ~ 50,000명 |
| 주문 처리량 | ~8,000 건/초 (단일 거래쌍) |
| WebSocket 구독자 | ~80,000명 |
| 오더북 깊이 | 100 호가 |
| API 응답 시간 | 5~30ms (p95) |
| 일일 활성 유저 | ~200,000명 |
요약 비교표
| 항목 | Tier 1 (스테이징) | Tier 2 (소규모) | Tier 3 (중규모) | Tier 4 (대규모) |
|---|---|---|---|---|
| 월 비용 | ~$410 | ~$1,200 | ~$3,500 | ~$8,000+ |
| 동시접속 | 300~500 | 1K~3K | 5K~15K | 20K~50K |
| 주문/초 | ~200 | ~800 | ~3,000 | ~8,000 |
| DAU | ~2K | ~10K | ~50K | ~200K |
| 적합 용도 | 개발/테스트 | 소규모 런칭 | 중견 거래소 | 대형 거래소 |
참고: 위 수치는 코드 구조, 자료구조 특성, 인프라 사양을 기반으로 한 이론적 추정치입니다. 실제 성능은 거래쌍 수, 주문 패턴, 네트워크 환경에 따라 달라질 수 있으며, 프로덕션 배포 전 반드시 부하 테스트를 수행해야 합니다. 프로젝트에는 1,000명 동시 사용자를 시뮬레이션하는 부하 테스트 프레임워크(
loadtest/)가 포함되어 있습니다.
답이 없습니다 ㅋㅋ
다들 즐거운 AI 생활 되세용
'AI' 카테고리의 다른 글
| AI와 함께 개발하면 공수가 얼마나 줄어들까? — ERP 실전 사례 (0) | 2026.02.20 |
|---|---|
| 주말에 심심해서 만든 부동산 분석앱 (1) | 2026.02.13 |
| AI로 기존 레거시 코드 리펙토링 (0) | 2026.02.11 |
| Claude Code 로 거래소 만들기(1) (0) | 2026.02.11 |
| 앱+서버 만들때 Claude code 효율 비교 (2) | 2026.01.19 |
