🎫 티켓팅 서비스

🐮🐶 소개

• 공연 티켓팅 서비스
• nGrinder를 이용한 부하 테스트

📆 기간

• 2023.11.22 ~ 2024.01.23

🧑‍💻 역할

• 1인 개인 프로젝트

📝 개발 스택 및 사용 툴

• 👾 Back

  

• ☁ Cloud

  

• 💾 DB / Cache

  

• 🕋 CI / CD

  

• 🖥️ Monitoring / Test

  

• ⚒️ Tool

  

🌐 URL

Git : https://github.com/itavita08/Ticketing-Service

⚙️ 아키텍쳐

🔩 ERD

✏️ 기술적 의사 결정

1. Redis
   • In-Memory 데이터 저장 방식을 사용하므로 디스크 기반 저장에 비해 훨씬 빠른 응답 속도를 제공합니다.
   • Redis의 단일 스레드 구조는 모든 명령을 순차적으로 처리하며, 단일 연산에 대해서는 원자성이 보장됩니다. 이로 인해 티켓팅 서비스에서 중요한 데이터 일관성 및 무결성을 유지하는 데 도움이 되며, 시스템 안정성을 향상할 수 있습니다.
   • 동일한 데이터를 데이터베이스를 통해 반복적으로 조회하는 경우 데이터베이스에 부하가 발생하여 속도가 더 느려집니다. 따라서 Redis 캐시를 사용하여 데이터베이스 부하를 줄이고 응답시간을 개선하기 위해 선택했습니다.
2. JPQL
   • JPQL은 JPA의 쿼리 언어로 널리 사용되며, 객체지향적 접근은 데이터베이스와 객체 간의 매핑을 효과적으로 수행합니다.
   • JPA와의 통합은 데이터베이스 작업을 효율적으로 수행할 수 있도록 도와주며, 타입 안정성은 컴파일 시점에서 오류를 찾아내어 안정적인 쿼리 작성을 보장합니다.
   • JPQL의 간결하고 가독성 있는 문법은 복잡한 검색 요구 사항에도 쉽게 대응할 수 있도록 도와줍니다.
   • 이러한 이유로 JPQL을 사용하여 프로젝트의 쿼리작성 효율성과 유지보수성을 높이기 위해 선택했습니다.
3. GitHub Action
   • GitHub와 통합되어 있어서 별도의 CI/CD 도구를 사용할 필요 없이 프로젝트에 쉽게 적용할 수 있어서 선택했습니다.
4. Docker
   • GitHub Actions를 활용한 CI/CD 구현으로 애플리케이션 배포 및 확장 과정이 빠르고 효율적으로 진행이 가능합니다.
   • Load Balancer을 사용하면서 지속적인 EC2에 배포를 하고 교체가 발생하면서 배포 환경 간의 차이가 생겨 심각한 서비스 장애를 초래할 수 있습니다. Docker을 사용하여 애플리케이션과 모든 의존성을 컨테이너로 패키징 함으로써 개발, 운영환경이 일관된 상태를 유지하기 위해 선택했습니다.
5. Pinpoint
   • nGrinder에서도 TPS, Mean Time Test 등 모니터링을 할 수 있지만 Pinpoint에서 병목지점을 확인할 수 있어 Pinpoint를 선택했습니다.

📖 시나리오

👉 티켓팅 사이트인 인터파크 티켓 사이트를 참고
- 인터파크 티켓 2023년 6월 기준 월간 이용자 수 1713만명
티켓팅 사이트는 사람들이 많이 몰렸을 경우 서버가 터지는 경우가 많으므로 최고 트래픽 상황을 가정

• 1일 총 유저 수
  • DAU(하루 중 중복 없는 순수 사용자 수) x 1명당 1일 평균 요청 수
  • 하루 이용자 수 20만명(예측) x 요청 수 최소 5번 이상(예측)
  • 100만
• 1일 평균 rps
  • 1일 총 요청 수 / 하루 12시간을 초로 환산
  • 100만 / 43200
  • 23 rps
• 최대 트래픽
  • 1일 최대 rps
  • 1일 평균 rps x 피크 시간 집중률
  • 피크 시간대에 집중률이 평균 보다 10배많다고 예측
  • 23 rps x 10
  • 230 rps
• Vuser
  • 목표 rps x (한번의 시나리오를 완료하는데 걸리는 시간 / 시나리오 당 요청 수)
  • 한번의 시나리오당 목표 시간 = 1500ms, 시나리오당 요청 수(회원가입, 로그인, 예매) 3번
  • 230 x (1.5 / 3)
  • 115

🐞 부하 테스트

1. 로컬(맥북 에어 M2)환경

   • Redis X, fetch join 미사용

     

     • Pinpoint를 통해 getConnection()에서 병목 지점 확인

       • Hikari maximum pool size 여러번 변경으로 최적의 값 120
       • DB max connection 변경

     • 쿼리문에서 병목 지점 확인

       

   • Redis X, fetch join 사용

     

     • 6797ms → 2996ms 단축

   • Redis O, fetch join 사용

     • Redis 사용 후 테스트 결과 별차이가 없어서 Pinpoint 확인
     • 부하 툴 및 애플리케이션, 모니터링을 로컬에서 한번에 진행하다보니 CPU 사용률이 100프로라 Redis를 사용해도 별 차이가 없다라고 생각했습니다.

2. AWS 환경

   • EC2(Arm) t4g.small(2 vCPU, 2 GiB 메모리) 1대

     

     

     • 11883 ms
     • CPU 사용률 100%

   • EC2(Arm) t4g.small(2 vCPU, 2 GiB 메모리) 4대, AWS Load Balancer 사용

     

     • 11883 ms → 3078 ms
     • TPS 증가 및 처리시간은 줄였지만 여전히 CPU 사용률 100퍼

   • EC2(Arm) t4g.medium(2 vCPU, 4 GiB 메모리) 4대, AWS Load Balancer 사용

     • 스케일 업을 하였지만 CPU가 아닌 메모리만 늘어난 스케일 업으로 처리시간에 큰 영향을 주지 못했다.
     • CPU 사용률 100퍼

   • EC2(Arm) t4g.xlarge(4 vCPU, 16 GiB 메모리) 4대, AWS Load Balancer 사용

     • CPU 스케일 업되는 t4g.xlarge 선택

       

       • 3078 ms → 1487 ms
       • 목표로 했던 1.5s 달성