jovid18/stocking_backend

📈 서비스 소개

10만건의 동시 주문도 처리 가능한 모의 주식 투자 서비스

10만건의 부하 테스트 결과: 평균 응답 시간 100ms, TPS 894.2/s



10만건의 동시 주문시에도 체결이 진행되는 모습

🎯 서비스의 목표

• 처음 해보는 유저들도 쉽게 참여가 가능한 모의 주식 투자 서비스
• 대용량 트래픽에서도 안전하게 체결이 진행되는 서버
• 주문의 순서가 보장되는 메시지 체결(동시성 제어)
• 실시간 모니터링으로 서버의 상태 확인 및 서버 이상 시 슬랙으로 알람

🖇️ 프로젝트 링크

구분	링크
	STOCKING
	FE Github
	BE Github
	브로슈어
	발표 영상
	소개 영상

📚기술 스택 정리

🪶 주요 기능

📌로그인 & 회원가입

• 로컬 회원가입 가능 및 카카오, 네이버, 구글의 소셜 로그인 가능
• redis를 활용해 세션 저장
• 중복로그인시 웹 소켓을 사용해 로그아웃 됩니다 라는 메세지 전송 후 세션 삭제

📌게임 시스템

• 12분 마다 게임 시작 게임의 시작은 채팅에서 알려주며 각종 이벤트의 정보를 보여줌
• 이벤트가 호재인지 악재인지에 따라 더미의 주문이 달라짐 → 보다 실감나는 모의 주식이 가능
• 시장가/지정가, 매수/매도 주문의 생성 및 주문 정정, 삭제 가능
• 종목별/ 매수/매도, 최신순/ 오래된순과 같이 원하는 조건으로 주문 조회 가능
• 차트와 호가창을 이용해 시각적으로 주식의 흐름 파악가능
• 게임이 진행되는 동안 가장 많은 수익률을 낸 사람이 우승

📌랭크 시스템

• 게임에서의 수익률에 따라 순위가 공지
• 수익률에 따라 MMR 점수가 올라가고 MMR에 따라 티어가 변동

📌채팅 시스템

• 메인페이지, 회사 페이지, 주문페이지에 채팅창 존재
• 각 사용자들의 채팅 뿐만이 아니라 게임의 시작과 종료, 각종 이벤트들이 수신됨
• 체결 성공 및 실패 여부를 채팅으로 전달

🙋🏻 팀원 소개

역할	이름	담당	Email	GitHub
팀장	정소이	BE/FE	writer__soi@naver.com	soijeongg
팀원	조성현	BE/FE	cshcho99@gmail.com	jovid18
팀원	최준혁	BE/FE	jhmhmami@naver.com	norwegianwood97
팀원	윤형식	BE/FE	fly010905@gmail.com	nyeongsik13

📜개발 기획 및 진행

✍🏻기획

사전 회의

USER FLOW

ERD

WIRE FRAME

SEQUENCE DIAGRAM

서버 버전 관리

📓 진행

TO-DO LIST

프론트 페이지 정리

백엔드 API 정리

스케쥴링 함수 정리

.env 정리

메시지 큐 정리

부하테스트&모니터링

🧭 서비스 아키텍쳐

✔️ 기술적 의사 결정

사용 기술	기술 설명
Node.JS	JavaScript를 이용하는 가장 대중적인 프레임워크인 Node.JS를 사용하기로 결정했습니다.
MySQL	MySQL은 사용자가 데이터베이스 솔루션을 무료로 개발하고 배포할 수 있으며 ACID 규약을 준수해 높은 신뢰성과 안정성을 보장하고, 또한 웹 애플리케이션에서 빠른 읽기와 쓰기 속도 등 많은 장점을 가져서 사용하였습니다.
Redis	Redis는 인메모리 데이터베이스를 사용하여 데이터 처리 속도가 디스크 기반 데이터베이스보다 훨씬 빠르기 때문에 리소스 소모와 DB 서버의 부하를 줄이기 위해 사용했습니다. 이를 통해 주문 처리 속도를 대폭 개선하고 전반적인 시스템 성능을 향상시킬 수 있었습니다.
Session vs JWT	세션의 경우에는 모든 인증 정보를 세션에서 관리하기 때문에 보안 측면에서 유리하고, 만약 세션이 탈취가 되어도 서버에서 해당 세션을 무효화하면 되지만 토큰에는 정보가 다 들어있어서 해당 토큰을 무효화하더라도 정보 유출을 막을 수 없습니다. 이에 따라 보안성이 더 뛰어난 세션을 쓰기로 결정했습니다.
PRISMA	프리즈마는 간단한 구문을 사용해 데이터베이스와 상호작용하는 ORM이며 다양한 데이터베이스 드라이버를 지원하여 사용하였습니다.
ioredis vs redis	ioredis 패키지는 redis 패키지에 비해 대규모 및 복잡한 환경에서 더 많은 기능과 유연성을 제공하여 채택하였습니다.
passport	Passport는 다양한 인증 전략을 지원하여 로컬 로그인 외에도 Google, Kakao 등 다양한 플랫폼의 인증을 활용할 수 있습니다. 또한 복잡한 인증 로직을 간단하게 구현할 수 있어 개발 편의성과 소셜 로그인 구현을 위해 사용하기로 결정했습니다.
Argon2 vs bcrypt	Argon2는 bcrypt 보다 최근에 개발되었고, 현재까지 개발된 암호화 함수 중 가장 강력한 보안성을 제공하여 Argon2를 채택하였습니다.
WebSocket vs socket.io	Socket.io에 비해 상대적으로 경량화되어있는 WebSocket을 선택하여 메모리와 CPU의 사용을 줄였습니다.
Jest	Jest는 설정이 간편하고, 실행 속도가 빠르며 스냅샷 테스팅을 통해 변경사항을 쉽게 확인할 수 있습니다. 또한 단위 테스트와 통합 테스트에 적합한 다양한 도구를 제공하기 때문에 사용이 편리하여 테스트 패키지로 jest를 채택하였습니다.
Vercel	React 애플리케이션을 손쉽게 배포할 수 있는 최적화된 환경을 제공하며 GitHub와 같이 소스 코드 저장소와 통합을 통해 코드 커밋이 이러어질 때마다 자동으로 빌드와 배포가 실행되기에 배포 프로세스에 대한 관리 부담을 줄이고, 코드 변경 사항을 신속하게 적용할 수 있어 사용했습니다.
Github Actions	GitHub Actions는 사용이 쉽고 복잡한 절차 없이 GitHub과 원활하게 통합될 수 있는 장점이 있습니다. 또한, 배포 과정에 도움이 되는 다양한 템플릿을 제공하여 효율적인 워크플로우를 구축할 수 있어 배포에 Github Actions를 사용하였습니다.
prettier/eslint	각자 작성한 코드의 스타일을 일치시키기 위해 prettier를 사용하여 세미콜론, 줄 바꿈과 관련하여 자동으로 조정하고자 하였고, ESLint를 이용해 prettier의 스타일에 맞게 코드 스타일을 일치시켰습니다.
ALB	ALB를 사용함으로써 여러 서버에 걸쳐 트래픽을 효과적으로 분산시킬 수 있었습니다. 이는 각 서버의 과부하를 방지하고 서버간 트래픽이 고르게 분산되면서 각 서버의 부하가 경감됩니다. 결과적으로, 이는 각 서버에서 더 빠르고 효율적인 처리를 가능하게 하여 최종 사용자 경험을 크게 향상시킬 수 있어 사용하였습니다.
Docker	Docker는 컨테이너화 기술을 사용하여 애플리케이션의 실행 환경을 격리하므로, Amazon EC2 인스턴스 내에서 직접 서버를 배포하는 것과 비교해 더 높은 환경의 일관성과 이식성을 제공합니다. 또한 Docker를 사용하면 CD 과정에서 이미지를 빌드하고,이를 배포하는 과정이 일관되게 이루어지므로, 더 빠르고 효율적인 배포 프로세스를 구축할 수 있었습니다.
ECR vs Docker Hub	CD를 통해 배포 프로세스를 자동화하는 과정에서 깃 액션을 통해 이미지를 기존에는 도커 허브에 올렸으나 보안이 우려되어 이미지 저장소를 AWS의 ECR로 변경하였습니다.
ECS	ECS는 손쉽게 ECR의 이미지를 이용하여 ECS 인스턴스를 생성해주는 컨테이너 오케스트레이션 서비스로 러닝커브가 낮고, 오토스케일링 및 무중단 배포가 지원되기 때문에 ECS를 채택하였습니다.
Kafka vs Redis-Streams	사용자의 주문에 대해 순서를 지키며 처리하기 위해 메시지큐 통신을 선택하였습니다. 이에 따라 Kafka와 Redis-Streams의 사용을 고민하고 Kafka가 확장성이 높고 대규모 트래픽을 처리하는데 최적화 되어 있어 Kafka를 채택하여 사용했습니다.
Jmeter	Jmeter는 오픈소스이며, csv와 다양한 테스트 스크립트를 사용해 테스트 작업을 간소화 할 수 있는 장점을 가지고 있었습니다. 또한 많은 레퍼런스가 존재해 손쉽게 적용할 수 있었기 때문에 Jmeter를 체택해 부하 테스트에 사용했습니다.
node-exporter	node-exporter는 서버 수준에서 시스템의 상태를 수집합니다 node-exporter를 사용하면 직접 매트릭을 수집하는 코드를 쓰지 않고도 간편하게 시스템의 매트릭을 수집 할 수 있기 때문에 node-exporter를 사용했습니다.
Prometheus	프로메테우스는 오픈소스 모니터링 및 경고 도구로, 시스템과 서비스의 상태를 실시간으로 모니터링하는 데 사용했습니다. 프로메테우스는 시스템의 성능 지표를 실시간으로 수집하고 비침투적인 모니터링통해 서비스가 모니터링 과정에서 발생할 수 있는 성능 저하나 중단 없이 지속적으로 데이터 수집이 가능합니다. 이러한 장점 때문에 Prometheus을 선택하여 시스템과 서비스의 상태를 실시간으로 모니터링 하였습니다.
Grafana	Grafana는 오픈소스 데이터시각화 툴로써 다양한 그래프, 지오맵등을 사용하여 데이터를 시각화 하여 데이터를 더 직관적으로 이해 할 수 있다는 점과 슬랙이나 메일을 통해 사용자에게 알림을 보낼 수 있다는 점때문에 체택해 사용했습니다.

🔎 성능 개선 결과

📕 서버 버전별 요약

📗 부하 테스트 및 모니터링 결과

유저수는 동일하게 100명으로 테스트하고, 본 서비스의 핵심인 주문 요청에 대한 부하를 검증
Jmeter를 이용하여 가상의 유저가 1번의 회원가입→ 1번의 로그인→ n번의 주문 → 1번의 로그아웃을 요청하는 스파이크 테스트를 진행

100명의 유저가 100번의 주문 요청

100명의 유저가 200번의 주문 요청

100명의 유저가 500번의 주문 요청

1️⃣ TPS 및 평균 응답 시간 개선

🆙 성능 개선 결과

• TPS: 77.6/s→590.3/s (660.7% 증가), 평균응답시간: 1211.3ms→177ms (85.39% 감소)

2️⃣ 주문 처리 속도 개선

• STOCKING의 체결 로직: 주문 유효성 검증 ⇒ 주문 생성 및 삭제 ⇒ 주문 매칭 ⇒ 주문 체결
• Ver 3.0은 체결서버( MySQL, 주문 유효성 검증 ⇒ 주문 생성 및 삭제 ⇒ 주문 매칭 ⇒ 주문 체결)
• Ver 4.0은 매칭서버( Redis, 주문 유효성 검증 ⇒ 주문 생성 및 삭제 ⇒ 주문 매칭) , 체결 서버 (MySQL, 주문 체결)
• 즉, ver 3.0의 체결 서버로부터 체결 과정의 일부를 Redis를 이용하는 매칭 서버를 분리하여 주문 처리 속도 개선

🆙 성능 개선 결과

• 단일 주문 처리 시간: 87.16ms→77.28ms (11.34% 감소), 1만건의 동시 주문 총 처리시간: 796s→601s (24.5% 감소)

✅ 단일 주문 처리 시간 비교

✅ 동시 주문 10000건의 총 처리 시간 비교

❗트러블 슈팅(성능 개선/대규모 트래픽 처리)

사용자에게 주문의 체결 결과를 응답으로 전달하여 대기시간이 너무 길어지는 문제 (ver 0.0)

• 문제 상황
• 기존 코드의 경우 주문 처리를 다한 뒤 그 결과를 사용자에게 응답하는 방식

postOrder = async (req, res) => {
    const { userId } = res.locals.user;
    const orderData = req.body;
    if (orderData.price) {
        orderData.price = 10000 * Math.floor(+orderData.price / 10000);
    }
    try {
        const result = await this.orderService.createOrder(userId, orderData);
        return res.json({ message: result });
    } catch (error) {
        console.log(error.message);
        const { message } = error.message ? error : { message: '주문 생성 도중 문제가 발생했습니다.' };
        if (error.message) return res.status(400).json({ message });
    }
};
                    

• 이로 인해 응답으로 인한 시간이 너무 걸림


• 해결 방법
• 주문 처리를 대기하지 않고, 사용자에게는 주문 접수에 대한 성공/실패 여부를 바로 전달
• 이후 주문 처리의 결과는 소켓 채팅창으로 공지

사용자가 불가능한 주문을 허용하여 불필요한 리소스 낭비 (ver 0.0 ⇒ ver 1.0)

• 문제 상황
• 가령 사용자가 현재 잔액이 1000만원이 있는 상황에서 현재가보다 낮은 가격으로 지정가 매수 100만원 주문을 20번 신청하더라도 이를 방지할 수 없었음
• 이로 인해, 체결과정에서 현재 사용자가 체결 당시 현금 또는 주식이 있는지 체크를 했어야 했고 이로 인해 불필요한 리소스가 낭비


• 해결 방법
• 사용자가 가용 금액, 가용 주식을 도입하여 아직 체결되지 않은 주문이라도 가용 금액/가용 주식이 감소하여 사용자의 현재 상황으로는 불가능한 주문을 방지
• ERD에 tradableQuantity, tradableQuantity를 도입하고 그에 맞게 체결 함수를 ver 0.0에서 ver 1.0으로 변경


체결함수 ver 0.0

체결함수 ver 1.0

메인 서버에서 API 통신과 소켓 통신 둘 다 담당하는 문제 (ver 1.0 ⇒ver 2.0)

• 문제 상황
• 메인 서버와 소켓 서버가 같은 역할을 겸함, 이는 여러 사용자가 접속해 있을 때 메인 서버의 부하를 키우게 됨


• 해결 방법
• 메인 서버로부터 소켓 서버를 분리하였고, ALB를 이용해 메인 서버로 가는 요청(/api*)과 소켓 서버로 가는 요청을 (/ws*) 경로 기반 라우팅 처리


서버 버전 1.0

서버 버전 2.0

ALB 적용

메인 서버에서 API 통신과 체결을 동시에 담당하는 문제 (ver 2.0 ⇒ ver 3.0)

• 문제 상황
• ver 2.0에서 소켓 서버를 분리하였으나, 많은 체결이 몰렸을 때 CPU에서 API 요청과 메인 처리를 둘 다 담당해야 하는 문제가 발생


ver 0.0에서 100명의 유저가 500번의 요청을 처리할 때 실제로 504,Gateway Time-out 에러가 발생하여 사용자의 요청을 제대로 처리하지 못함

ver 0.0~ver 2.0 모두 전체적으로 응답 시간과 TPS가 낮게 나옴

부하 테스트 이후 그라파나를 이용한 모니터링 결과 CPU에 가해지는 부하가 무척 큰 것을 확인



• 해결 방법
• 카프카 메시지 큐를 사용하여 메인 서버에서 체결을 진행하지 않고 주문의 내용을 직렬화 하여 메시지로 전달
• 체결 서버에서는 해당 메시지를 역직렬화 하여 체결을 진행


서버 버전 2.0

서버 버전 3.0

버전 3.0 부하 테스트 결과 TPS와 평균 응답 시간이 크게 개선된 것을 확인

버전 3.0 모니터링 결과 CPU의 부하가 크게 감소하는 것을 확인

주문 체결 처리에 많은 시간을 소모하는 문제 (ver 3.0 ⇒ ver4.0)

• 문제 상황
주문 유효성 검증, 주문 생성 및 삭제, 주문 매칭, 주문 체결 처리를 체결 서버에서 전부 담당
체결 함수 ver 1.0 아래의 과정이 모두 하나의 체결 서버에서 MySQL 트랜잭션으로 처리


• 해결 방법
• 매칭 서버에서 Redis를 이용하여 주문 유효성 검증 및 매칭 작업을 진행하고 , 그 결과를 메시지큐로 체결서버에 전달 체결 서버에서 받아 MySQL을 이용하여 주문을 체결
• 예상 효과
  • 단일 주문 처리 속도 향상
  
  
  일을 분할하면서 전체 처리 시간 향상
  


Redis의 string, hashset, sortedset의 자료구조를 이용하여 매칭 서버에서도 체결 서버의 MySQL DB와 같이 정보를 저장

체결 서버의 처리 내용이 다시 매칭 서버에 영향을 끼치지 않도록 로직을 구성하여 정합성 유지

서버 버전 3.0

서버 버전 4.0

개선 결과
단일 주문 처리 시간 비교
"
동시 주문 10000건의 총 처리 시간 비교
"

한개의 메인 서버에서 부하를 감당하는 문제 (ver 4.0 ⇒ ver 5.0)

• 문제 상황
• 많은 사용자의 API 요청이 하나의 EC2 인스턴스에서 처리
이로 인해 부하 테스트에서 특정 시간에 CPU에 과부하가 걸리는 것을 확인 (ver 4.0, 동시 주문 2만건 부하테스트)



• 해결 방법
• Main 서버에서 게임을 관리하는 파트를 분리하여 게임 서버를 만들고 Main 서버의 EC2 인스턴스를 3대로 늘림
• ALB를 통해 대상 그룹에 메인 서버 인스턴스를 3개 추가하여 로드밸런싱을 진행


서버 버전 4.0

서버 버전 5.0

ALB를 통해 main 인스턴스3개에 로드 밸런싱(라운드 로빈)

부하테스트 TPS와 평균 응답 시간이 크게 개선되는 것을 확인

부하테스트 결과 CPU의 리소스의 사용률이 감소하는 것을 확인(ver 5.0, 동시 주문 2만건 부하테스트)

능동적인 인스턴스 관리 부재와 블루-그린 배포로 인한 비용 문제 (ver 5.0 ⇒ ver final)

• 문제 상황
• 사용자의 요청에 관계 없이 고정된 EC2 인스턴스의 수가 변하지 않아 요청이 적을 때에는 리소스가 낭비되고, 요청이 많을 때에는 서버에 과도한 부하가 집중됨


무중단 배포를 NIGNX를 이용한 블루-그린 배포를 진행하였는데, 이 과정에 하나의 메인 서버를 위해 3개의 EC2 인스턴스가 필요하여 비용 문제가 발생



• 해결 방법
• 기존의 CD 과정에서 ECR에 이미지를 업로드 하였는데, 이를 이용하여 AWS에서 제공하는 컨테이너 오케스트레이션 서비스인 ECS를 이용하여 메인 서버의 증설 및 로드 밸런싱, 오토스케일링, 무중단 배포(롤링 배포)를 적용


ECS로 생성된 EC2에 로드 밸런싱이 적용

CPU의 부하율에 따라 오토 스케일링 적용
테스트를 위해 CPU를 1%만 사용해도 확장하도록 변경 ECS 태스크 확인 결과 태스크가 5개로 추가 된 것을 확인 로드밸런서에도 제대로 반영이 되는 것을 확인
기존 그린-블루 배포에서 롤링 배포로 전환


실제 롤링 배포가 적용되는 모습
코드 업데이트 이후 새로운 배포가 활성화 기존의 EC2 인스턴스를 하나씩 대체하는 것을 확인 모든 배포가 완료되고 기존 버전이 Draining 되는 모습

🔧장애 대응

카프카에서 문제가 발생 시

• 만일 하나의 브로커에 장애가 생겨 역할을 못하게 된다면 서버 자체를 사용할 수 없게 됨
• 그렇기 때문에 카프카의 브로커를 3대로 구축하여 하나의 브로커에 장애가 생겼을때 다른 브로커들이 해당 브로커의 역할을 대신해 처리
• 시스템 전체가 중단되는 것을 방지하고 장애가 발생한 브로커 격리 가능

AWS RDS에서 문제가 발생 시

• RDS의 muiti-AZ 배포 옵션을 사용해 RDS의 에러에 대비 가능
• multil-AZ 배포 옵션 사용시 RDS는 마스터 데이터베이스와 동기적으로 복제된 데이터베이스의 복제본을 다른 가용 영역에 생성
• 마스터 데이터베이스에 장애 발생시 RDS가 자동으로 복제본을 마스터 데이터베이스로 승격해 마스터 데이터베이스에 문제가 발생하더라도 서비스를 계속 제공함

카프카 중복 메시지 방지

• 카프카에 중복 메시지가 들어가게 되면 중복된 메시지로 인해 동일한 데이터를 여러번 처리하거나 이벤트 순서를 무시하게 됨
• 동일한 작업을 여러번 수행해도 결과가 동일하게 유지되는 특성인 멱등성을 이용해 중복 메시지를 방지

❓기타 트러블 슈팅(각종 버그들)

전체 목록

Transaction API error

로컬 메시지 큐에서 데이터가 순차적으로 처리되지 않는 에러

테스트 중 RDS 연결이 끊기는 오류

jmeter 로컬 테스트 중 발생한 오류

새로고침을 할때마다 연결되는 클라이언트가 늘어나는 에러

로컬에서 elastic cache 접속시 timeout

메인/소켓 서버 분리 이후 소켓 연결이 안되는 에러

EC2 인스턴스에서 public IP를 탄력적 IP로 재할당 한 이후에 접속이 안되는 오류

EC2에서 배포된 메인서버가 소켓서버와 자동으로 연결이 종료되는 오류

EC2에서 Jmeter로 테스트 시 WARNING이 뜨는 오류

배포 이후 로컬에서 카프카 컨슈머가 동작하지 않는 오류

채팅창 관련 이슈

Kafka 관련 이슈

웹소켓 연결 실패