_(2).png&blockId=6543ad75-dbe2-4c20-b355-adc717dd4659)
프로젝트 : Gream
주제 : 기프티콘 입찰 거래 사이트
컨셉 : 단일 장애 지점 제로
아키텍쳐
.png&blockId=c783a42a-0036-4456-8362-131661899b94)
.png&blockId=cfc3e970-1452-45e0-be22-ac46bcacabf1)
사용 기술
Front-End
•
Vite 5.0
•
React 18.2.0
•
MUI 5.15.4
•
Zustand 4.4.7
•
Axios 1.6.5
•
React query 5.17.9
•
React router dom 6.21.2
Back-End
•
Java 17
•
Spring boot 3.1.7
•
Spring security 6.1.6
•
Spring data JPA 3.1.7
•
Spring data Redis 3.1.7
•
Spring Batch 5.0.4
•
QueryDSL 5.0.0
•
MapStruct 1.5.5
•
Swagger 2.3.0
•
JWT 0.11.5
•
Lombok
Infrastructure
•
S3
•
ECR
•
LoadBalancer
•
Route53
•
Codedeploy
•
EC2
•
RDS
•
ElastiCache for redis
Database
•
MySQL 8.0.35
•
H2 DB 2.1.214
•
Redis 7.2
Monitoring & Test
•
Prometheus
•
Grafana
•
Jmeter
주요 기술
SPOF(단일 장애 지점) 제거
DB Replication
•
Mysql Replication
•
Redis Replication
개발 효율 개선
•
부하테스트
◦
Jmeter
•
테스트 코드
◦
jacoco
부하 분산 처리
•
Load Balancer
◦
Auto Scailing
CI / CD
•
Bule/Green Deploy
•
ECR
•
Code Deploy
•
Github Actions
비즈니스 서비스
•
알림 서비스
◦
Redis Stream
•
결제 모듈
◦
Toss Payments
•
스케줄링
◦
scheduling
◦
lamda
•
모니터링
◦
prometheous
◦
grafana
기술적 의사결정
DB Replication
문제 상황
•
단일 DB를 사용 시, 장애 복구가 불가능함
해결 방안
•
AWS RDS(MySQL) 와 AWS ElastiCache for Redis 에 대한 Standby DB을 생성
개선 사항
•
장애 발생 시, 유연한 Failover 대처를 할 수 있었음
Scale - Out / Load-Balancing
문제 상황
•
하나의 EC2 서버가 모든 서비스와 트래픽을 담당 및 처리
•
해당 EC2에 장애 발생 혹은 부하로 인해 종료되는 경우, 서비스가 중단되는 이슈 발생
해결 방안
•
AWS Elastic Load Balancing 을 사용하여 오토스케일링 및 로드밸런싱을 처리
◦
기존 서비스 처리 중인 EC2 서버의 평균 CPU 량에 따른 EC2 복제 (Dynamic Scailing Policy 사용)
◦
전체 트래픽을 여러 EC2 서버에 분산처리하여 서버의 부담을 낮춤
개선 사항
•
만 건의 트래픽 처리 시, t3 micro 기준 2개의 EC2 복제 및 트래픽 분산처리
•
각각의 EC2의 CPU 처리량을 80% → 30%로 낮출 수 있었음
Command / Query 분리
문제 상황
•
하나의 DB가 서비스의 모든 기능처리를 도맡아 하고 있음
•
명령요청보다 빈도수가 높은 조회처리를 한 곳에서 하다보니 성능이 저하되는 이슈가 발생
해결 방안
•
Primary DB에서 Command 를 담당하고, Secondary DB에서 Query 담당
◦
Multi-AZ 사용
▪
Primary 와 Secondary 간 Synchronous 동기화를 통해 실시간 데이터를 위한 데이터 정합성을 지킬 수 있음
▪
여러 가용영역의 Standby DB를 활용
◦
Read Replica 사용
▪
Command DML 처리를 불가능하게 하여 Query에 대한 데이터 정합성 유지
▪
동일한 데이터 복제를 통해 유연한 Failover 지원 가능
개선 사항
•
코드 레벨
◦
단일책임 원칙을 지킬 수 있음
◦
리팩토링 허들을 낮출 수 있음
•
아키텍처 레벨
◦
조회 요청과 명령 요청의 트래픽이 분산처리 되므로 더 많은 트래픽을 처리할 수 있음
부하 테스트
문제 상황
•
선택할 수 있는 방안이 nGrinder와 Jmeter가 있었음
해결 방안
•
Jmeter를 사용하기로 결정
◦
Jmeter는 로컬에서 사용하기 편함(nGrinder는 docker를 사용해야함)
◦
Jmeter의 GUI가 사용하기 편했음
◦
Jmeter의 리스너를 설정하여 여러 결과를 볼 수 있었음
결제 모듈
문제 상황
•
비즈니스 컨텍스트 상 포인트 제도에 대해서 결제 및 환급 처리를 해주어야 함
•
외부 분산 서비스 사용 시, 에러 발생에 대한 대비 정책이 필요함
◦
분산 서비스 처리에 대한 에러 대비가 없다면 사용자로 하여금 처리가 되었다고 오해를 할 수 있음
해결 방안
•
토스 페이먼츠 모듈을 사용하여 결제 처리
•
분산 서비스 에러 발생 대비정책 수립
◦
Resilience4
◦
@TransactionalEventListener
개선 사항
•
토스 API 사용과 분산 API 에러대비책을 활용하여 안정적인 결제 모듈을 지원할 수 있음
제한 사항
•
환급 처리를 위해 뱅킹 API 사용을 하려면 사업자등록증과 심사 과정이 필요함
Scheduling
문제 상황
•
비즈니스 컨텍스트 상, 마감기한이 지난 입찰 데이터에 대해 삭제 처리를 해주어야 함
해결 방안
•
간단한 스케줄링이므로 AWS Lambda 를 사용
◦
서비싱을 담당하는 EC2로부터 스케줄링 작업을 분리함
◦
관심사 분리를 할 수 있었음
•
스케줄링 처리 여부에 대한 검증 작업을 처리
◦
Cloud Watch 사용한 스케줄링 처리 여부 모니터링
◦
삭제처리가 되지 않은 데이터가 있을 경우를 대비하여 마감기한이 지난 데이터를 제외하고 조회할 수 있게 처리
개선 사항
•
비즈니스 컨텍스트에 따라 데이터 조회 시 마감기한이 지난 입찰데이터를 제외할 수 있었음
트러블슈팅
jdbc-url vs url ( feat. Hikari )
이미지 URL 저장을 위한 TEXT 로 변경에 대한 이슈
ElastiCache와 다른 VPC의 EC2와의 연결
팀원
Table
Search
