기존 및 개선 후 부하 테스트

기존 시스템 REST API - 30분 동안 5000명의 동시 가상 사용자(VUs)를 목표로 부하 테스트를 진행

상품 서비스 파드 2개, 주문 서비스 2개 (각 0.5vCPU, 1GB 메모리)

 

결과 :

 

 

부하 테스트 결과, 약 175 req/s에서 HTTP 요청의 99퍼센타일 응답 시간(http_req_duration_q0.99)이 1400ms까지 상승했습니다.

이 시점부터 서버 병목이 두드러졌으며, Product 서비스 Pod(CPU 할당 0.5코어) 2개는 실제로 0.411코어, 0.423코어(약 82% 이상 사용)를 보였는데, 이는 Order 서비스 Pod와 유사한 자원 사용 패턴이었습니다.

이를 통해, 주문(Order)으로 인한 상품(Product) 서비스 부하가 상당하다는 사실을 확인할 수 있었습니다.

또한 Product 서비스가 이미 높은 부하로 응답이 지연되거나 타임아웃이 발생하면, Order 서비스 역시 해당 응답을 기다리면서 지연이 누적되어 양쪽 서비스 모두 병목이 일어나는 악순환이 발생한다는 점도 파악되었습니다.

 

 

개선된 시스템 - 30분 동안 5000명의 동시 가상 사용자(VUs)를 목표로 부하 테스트를 진행

상품 서비스 파드 1개, 주문 서비스 3개 (각 0.5vCPU, 1GB 메모리) -> 상품 서비스에서 많은 성능 향상으로 2개의 파드가 필요하지 않았음 (종합적으로는 같은 개수의 파드로 테스팅)

 

개선 과정 포스팅

- https://haepalea.tistory.com/33

REST-API에서 Kafka 기반 EDA로

 

- https://haepalea.tistory.com/35

이벤트 배치 처리로 전환해 성능 최적화

 

결과 :

 

 

 

부하 테스트 결과, 종합적으로 같은 파드 개수 상황에서 약 531 req/s에서 HTTP 요청의 99퍼센타일 응답 시간(http_req_duration_q0.99)이 185ms로 측정되어, 요청 규모가 3배 이상 증가(175→531 req/s)했음에도 불구하고 응답 시간은 약 1400ms → 185ms(약 87% 단축)로 크게 개선되었습니다.

이 시점에서 Product 서비스 Pod(CPU 할당 0.5코어)1개는 실제로 0.134코어(기존 대비 약 16% 사용)만을 소비해, 과거 2개의 파드가 전부 82% 이상을 사용했던 것 대비 여유가 기하급수적으로 늘어났습니다.

이는 기존 시스템 달리, 주문(Order) 처리 시 상품(Product) 서비스에 발생하던 부하를 이벤트 기반 배치처리로 상당 부분 해소했음을 보여줍니다.

또한, Product 서비스가 일시적으로 지연 또는 타임아웃 상태가 되더라도, Order 서비스는 동기 대기 없이 주문 이벤트만 발행합니다.

그 결과, 이전처럼 양쪽 서비스가 서로 대기하며 병목이 악순환으로 이어지는 상황 없이, 안정적인 처리를 유지할 수 있게 되었습니다.