Update Technology Post "AWS EC2 기반 부하 테스트를 진행하며 시스템 아키텍처 및 성능 개선하기"

Author: devFancy

_posts/2025-12-30-spring-boot-coupon-system-performance-improvement.md

@@ -598,21 +598,44 @@ MySQL의 CPU 사용량이 347.16%(CPU 점유율: 86.79%)를 기록했습니다.
 
 ## 성과 및 결론
 
-Kafka 프로듀서 및 컨슈머의 Config 튜닝을 통해 대량 유입 상황에서도 Consumer Lag을 실시간으로 해소하는 구조를 완성했습니다.
+이번 프로젝트를 통해 단일 서버에서 시작하여 고가용성을 갖춘 분산 아키텍처로 진화하며 트래픽을 안정적으로 처리하는 구조를 완성했습니다.
+단순히 TPS 수치를 높이는 것에 그치지 않고, 시스템의 병목 지점을 모니터링을 통해 수치를 확인하고 해결해 나가는 과정에서 다음과 같은 성과를 얻었습니다.
 
-브로커 이중화 및 복제 설정을 통해 성능(2,700 TPS -> 1,500 TPS)을 일부 희생하는 대신, 운영 환경 수준의 데이터 안정성과 고가용성을 확보했습니다.
+먼저, Kafka 프로듀서 및 컨슈머의 Config 튜닝을 통해 대량 유입 상황에서도 Consumer Lag을 실시간으로 해소하는 구조를 완성했습니다.
+또한, 브로커 이중화 및 복제 설정을 통해 성능(2,700 TPS -> 1,500 TPS)을 일부 희생하는 대신, 운영 환경 수준의 데이터 안정성과 고가용성을 확보했습니다.
 
 현재 시스템의 최대 한계는 API 서버의 CPU 자원 고갈임이 확인되었으나, 컨슈머와 DB 서버는 여전히 여유 자원을 보유하고 있어 API 서버 확장 시 선형적인 성능 향상이 가능할 것으로 판단됩니다.
 
+지금까지 진행한 점진적 개선 과정을 표로 요약하면 다음과 같습니다.
+
+> 아키텍처 개선 단계별 요약
+
+| 테스트 단계   | 주요 아키텍처 변경 사항                 | VU (가상 사용자) | Rate Limiter | API 서버 (최대 TPS) | Consumer 서버 (최대 TPS) | 주요 결과 및 병목 지점              |
+|----------|-------------------------------|-------------|--------------|-----------------|----------------------|----------------------------|
+| Step 1-1 | 초기 아키텍처 (단일 인스턴스)             | 500         | 100          | 400             | 120                  | 저부하 상황 정상 동작 확인            |
+| Step 1-2 | 초기 아키텍처 (부하 증가)               | 5,000       | 100          | 900             | 95                   | Consumer Lag 누적, 레이턴시 급증   |
+| Step 2-1 | 서버 인스턴스 분리                    | 7,000       | 1,000        | 1,450           | 810                  | 성능 개선되었으나 API 서버 CPU 포화    |
+| Step 2-2 | DB 전용 인스턴스 분리 및 API 서버 스레드 튜닝 | 7,000       | 1,300        | 2,500           | 1,250                | p95 응답 시간 개선, DB CPU 한계 도달 |
+| Step 2-3 | DB Scale-up, 컨슈머 Scale-out    | 10,000      | 2,700        | 2,500           | 2,500                | 유입/처리 속도 균형 확보 (Lag 해소)    |
+| Step 3-1 | Kafka Broker 이중화              | 7,000       | 2,700        | 1,830           | 1,820                | 안정성 확보 및 현재까지 완성된 아키텍처     |
+
 ## 향후 개선 방안
 
-현재 CPU 점유율 100%에 도달한 API 서버를 증설하여 부하를 분산하고, p95 응답 시간을 목표치인 3초 이내로 단축할 계획입니다.
+현재 CPU 점유율 100%에 도달한 API 서버를 증설하여 부하를 분산한다면, p95 응답 시간을 목표치인 3초 이내로 단축할 수 있을 것으로 판단됩니다.
 
-API 서버의 TPS 유입량에 맞춰 컨슈머 서버의 Rate Limiter 값을 유동적으로 조정함으로써, 시스템 전반의 처리 효율을 극대화할 계획입니다.
+또한, API 서버의 TPS 유입량에 맞춰 컨슈머 서버의 Rate Limiter 값을 유동적으로 조정함으로써 시스템 전체의 처리 효율을 극대화하는 방향도 고려해 볼 수 있습니다.
 
-아직 컨슈머 서버는 약 20~30%, DB 서버는 약 13%의 CPU 가용 리소스를 보유하고 있음을 확인했습니다.
+부하 테스트 결과, 아직 컨슈머 서버는 약 20~30%, DB 서버는 약 13%의 CPU 가용 리소스를 보유하고 있음을 확인했기에, 
+API 서버 확장 시 전체 시스템의 TPS가 임계치까지 선형적으로 향상될 수 있는 구조적 여력이 충분하다고 보입니다.
 
-따라서 API 서버 확장 시 전체 시스템의 TPS가 임계치까지 선형적으로 향상될 수 있는 구조적 여력이 충분하다고 판단됩니다.
+추가적으로, 동시 접속자가 10만 명에서 1,000만 명 단위까지 급증하는 대규모 트래픽 상황을 대비하여 대기열 시스템 도입을 검토해 볼 수 있습니다
+
+단순히 서버를 증설하는 것만으로는 순간적인 트래픽 폭주를 감당하는 데 비용 효율과 기술적 한계가 존재하기 때문입니다. 
+이를 위해 Redis의 ZSet을 활용하여 사용자의 진입 순서를 보장하고, 시스템이 처리 가능한 속도에 맞춰 입장 토큰을 발급하는 구조로 개선하는 것이 효과적일 것으로 생각됩니다.
+
+특히 대기열 시스템을 시스템의 부하 상태에 따라 유연하게 동작하도록 설계하는 방식을 고민해 볼 수 있습니다.
+평소에는 바로 진입할 수 있도록 허용하되, 모니터링 중인 API 서버의 응답 지연 시간이나 Consumer 서버의 Lag이 임계치를 초과하는 상황이 감지될 때만
+대기열이 활성화되는 유량 제어 방식을 적용한다면, 사용자 경험과 시스템 안정성을 동시에 확보할 수 있을 것으로 보입니다.
 
 ## 마무리하며
 
@@ -623,8 +646,7 @@ API 서버의 TPS 유입량에 맞춰 컨슈머 서버의 Rate Limiter 값을 
 - 트래픽 **제어**와 **분산**의 중요성: Redis Rate Limiter를 통해 DB가 처리할 수 있을 만큼만 트래픽을 조절하고,
   리소스 지표를 확인하며 서버를 늘리거나 사양을 높이는 과정이 유기적으로 이루어져야 함을 경험했습니다.
 
-- 운영 관점의 **가용성** 확보: 카프카 브로커 이중화와 복제 설정을 진행하며, 단순히 빠른 시스템보다
-  "장애 상황에서도 안전하게 돌아가는 시스템"을 만드는 법을 고민할 수 있었습니다.
+- 운영 관점의 **가용성** 확보: 카프카 브로커 이중화와 복제 설정을 진행하며, 단순히 빠른 시스템보다 "장애 상황에서도 안전하게 돌아가는 시스템"을 만드는 법을 고민할 수 있었습니다.
 
 초기 목표였던 3,300 TPS를 수치상으로 완전히 달성하지는 못했지만, 모니터링 지표를 통해 API 서버의 CPU 병목 지점을 확인했습니다.
 이는 API 서버를 한 대 더 증설한다면 목표치를 충분히 달성할 수 있다는 데이터 기반의 확신을 얻은 값진 성과였습니다.
@@ -646,4 +668,6 @@ API 서버의 TPS 유입량에 맞춰 컨슈머 서버의 Rate Limiter 값을 
 
 - [[책] 가상 면접 사례로 배우는 대규모 시스템 설계 기초 2](https://product.kyobobook.co.kr/detail/S000211656186)
 
-- [[토스메이커스 컨퍼런스 TMC25] Engineering - '주식모으기' 서비스로 살펴보는, 대용량 트래픽 처리 노하우](https://www.youtube.com/watch?v=I_PEfXDRDX4)
+- [[토스메이커스 컨퍼런스 TMC25] Engineering - '주식모으기' 서비스로 살펴보는, 대용량 트래픽 처리 노하우](https://www.youtube.com/watch?v=I_PEfXDRDX4)
+
+- [[토스 SLASH 22] 토스뱅크의 완전히 새로운 대출 시스템](https://www.youtube.com/watch?v=SLamxuykpnw)