프로젝트 기획 문서 🗂 → 링크
- 상점 주인과 고객을 위한 상품 주문 및 거래 완료(가상 결제) 기능 제공
- 상점 주인을 위한 상품 판매 통계 및 거래 정산을 위한 배치 프로그램 및 확장성을 고려한 설계 적용
👨💻1인 프로젝트
프로젝트 수행 기간 : 2024.12.18 ~ 2025.01.18
Backend
DevOps & Testing
이미지 클릭 시, 확대하여 자세히 보실 수 있습니다.
| Micro Service Architecture | ERD |
|---|---|
 |
 |
- User Domain
- 상점 주인 소셜(카카오) 회원가입 및 로그인 / 로그아웃
- Store Domain
- 상점 주인에 의한 판매 상품 관리(CRUD)
- 상품 판매 통계 및 정산 데이터 조회
- Trade Domain
- 주문용 태블릿 기기에 의한 상품 주문
- 현재 진행중인 거래의 주문 내역 조회
- 상점 주인에 의한 현재 진행중인 거래의 주문 내역에 대한 일괄 (현금/카드) 결제
- Batch Server
- 1일, 1주(월요일 ~ 일요일), 1달 단위의 상품 판매 통계 데이터 생성
- 1일, 1달(상점별 정산일)의 정산 데이터 생성
- MSA 기반으로 각 서비스의 확장성 제공 및 독립적인 운영 지원
- Eureka 서비스 디스커버리와 API Gateway 를 활용한 동적 서비스 등록 및 라우팅 구현
- JWT 인증 필터를 API Gateway 에 적용하여 통합 인증 기능 구현
- OpenFeign 을 통한 내・외부 모듈 통신 구현
- Choreography Saga 패턴 적용을 통한 분산 환경에서의 트랜잭션 제어 (With Kafka)
- Prometheus With Pushgateway & Grafana 를 통한 애플리케이션 및 배치 프로그램 모니터링 구성
- Docker Compose 로 컨테이너 기반의 통합 개발/배포 환경 구성
- JUnit을 활용한 통합 및 단위 테스트 코드 작성 - 비즈니스 코드 98% Line Coverage 달성
Spring Batch 를 활용한 배치 프로그램 및 서비스 확장을 고려한 설계 적용
→ 🔗 자세히 보기
- 대용량 데이터 처리에 적합한 Chunk 기반 설계 적용
- JdbcPagingItemReader 와 JdbcBatchItemWriter 를 활용한 배치 프로그램 구성
프로젝트 테스트 실행 환경
- 서버 자원 - AWS EC2 → t2.micro 인스턴스 (Free-Tier), 가상 CPU 1 core, 메모리 1GiB
- 데이터베이스 자원 - AWS RDS → db.t4g.micro 인스턴스 (Free-Tier), 가상 CPU 2 core, 메모리 1GiB
보통 vCPU(가상 CPU) 는 물리 CPU 사양의 절반 정도의 성능을 가진다.
예를 들어 50만개의 상품에 대한 판매 데이터 1,000만개가 있다고 하자. 이때 집계 결과로 50만개의 상품 판매 통계 데이터가 생성되게 된다.
- 테스트 수행 결과 (3회 평균 시간)
Job Input data 개수 Output data 개수 소요 시간 상품 판매 통계 데이터 생성
(1달 기준)2,791,000 건 1,000 건 33.761초 정산 데이터 생성
(월정산)930,100 건 100 건 4.907초
- 데이터를 가져오는 시점부터 집계가 완료되어 처리 및 저장이 간단하다는 장점이 있음
- 하지만 집계 연산이 쿼리에 의존적이기 때문에 쿼리의 실행 계획이 복잡해지고, 이는 데이터베이스의 성능 저하로 이어질 수 있음
- 특히, 데이터베이스로부터 집계 데이터를 조회해오는 ItemReader는 배치 작업 전체 성능의 90% 이상을 좌우함
- 또한 서비스의 도메인(데이터베이스 스키마) 증가 및 데이터 누적으로 인해 서비스의 규모가 커지면,
집계 쿼리 작성 및 유지보수에 더 많은 리소스가 필요함
Ver 2. 서비스 규모 증가 및 확장성을 고려한 배치 프로그램 설계 적용 → 🔗 자세히 보기
- Database에서 GROUP BY + SUM 쿼리를 통해서 수행하던 집계 역할을, Redis 가 대신 수행하는 설계
- 쿼리 작성 및 유지보수에 대한 리소스 절약과 쿼리 실행 계획의 단순화를 통해 대규모 데이터 처리 시, 성능 향상 기대
- Redis 의 O(1) 의 시간복잡도를 보장하는 hash 함수와 다수의 연산을 묶어서 Redis 에게 요청하는 Redis Pipeline 을 통한 성능 저하 방지
- 테스트 수행 결과 (3회 평균 시간)
Job Input data 개수 Output data 개수 소요 시간 상품 판매 통계 데이터 생성
(1달 기준)2,791,000 건 1,000 건 4분 17.106초 정산 데이터 생성
(월정산)930,100 건 100 건 43.984초 - 정산 데이터 생성 (월정산) 작업의 경우 기존 18분 4.17초에 수행되었지만, 내장 함수 제거와 인덱스 추가등의 쿼리 튜닝을 통해 43.984초로 단축 → (95.94% 성능 개선)
Ver 1 : GROUP BY + SUM 쿼리를 활용한 집계 수행, Ver 2 : Redis 를 활용한 집계 수행
- 데이터가 작고 쿼리가 단순한 서비스의 초기 단계일 경우에는, Ver 1이 더 적합함
- 하지만 Ver 1 의 GROUP BY + SUM과 같은 쿼리는 연산이 데이터베이스에 의존적이며 성능 저하 및 난해한 쿼리 튜닝의 원인이 될 수 있음
- 하지만 Ver 1 의 GROUP BY + SUM과 같은 쿼리는 연산이 데이터베이스에 의존적이며 성능 저하 및 난해한 쿼리 튜닝의 원인이 될 수 있음
- 서비스의 도메인(데이터베이스 스키마) 증가 및 데이터 누적으로 인해 서비스의 규모가 커지면, Ver 2가 더 적합한 방법
- 데이터량이 증가하고 쿼리가 복잡해질수록 Ver 2가 시간 및 리소스 절약 측면에서 유리함
- 또한, 쿼리가 단순해져서 코드 작성 및 유지보수도 더욱 간결해질 수 있음
- 결론적으로, 집계 연산을 어디에서 수행할지는 유지보수성과 성능의 균형이 중요한 요소
성능 기준점을 충족하는 범위 내에서, 서비스 특성과 확장성을 고려하여 유지보수에 적합한 설계를 선택하는 것이 최선의 선택
프로젝트 문서화 진행 🗒️ → 링크
- 프로젝트 진행 시, 내용 정리 및 진행사항 트래킹을 위해 문서화 작업 수행
- 항해99 취업 리부트 코스 6기 - 우수 프로젝트 기록 선정
- 기능 명세서 📋 → 링크
- 서비스의 비즈니스 기능에 대한 상세 내용을 정리한 문서
- API 명세서 🛰️️ → 링크
- 서비스의 비즈니스 기능에 대한 API 명세를 정리한 문서
- Error Code 🚫 → 링크
- API 호출 시, 발생할 수 있는 예외 코드를 정리한 문서
- 기술적 의사 결정️ ⚒️ → 링크
- 프로젝트 진행 시, 요구 사항을 구현하기 위한 기술 선택의 이유 및 근거를 정리한 문서
- Github Repository Clone
- Kakao 개발자 센터 App 등록 및 설정 For OAuth Login
- .env 파일 수정 - 환경 변수 설정
- docker compose file 실행
docker compose -f docker-compose.infrastructure.yml -p pos up -d docker compose -f docker-compose.application.yml -p pos up -d docker compose -f docker-compose.monitoring.yml -p pos up -d
- database 접속 및 schema.sql 의 DDL 실행
- service-db (:3307)
- meta-db (:3308)
프로젝트 참고