TIL(Today I Learned)/Apache JMeter Test

[부하 테스트 및 확장성 테스트 - 배포환경] 단일 서버 vs 이중 서버 성능 차이

jiyoon0000 2025. 2. 17. 18:59
테스트 개요

1. 목표

:부하 테스트 및 서버 확장성 테스트 (Load Test & Scalability Test)

  • Redis 기반 캐싱을 적용한 상태에서 단일 서버 vs 이중 서버 성능 차이 측정
  • 부하 테스트(Load Test) 수행 후 트랜잭션 처리 속도(TPS) 분석
  • 서버 확장성 Scaling에 따른 성능 변화 분석
  • 정확한 서버의 성능 분석을 위해 극한의 상황으로 테스트

2. 테스트 환경

  • 부하 테스트 도구: JMeter
  • 성능 측정 방식: TPS(Transactions Per Second) 분석
  • 테스트 조건:
    • Number of Threads (users) : 200명
    • Ramp-up period (seconds) : 20초
    • Loop Count: 3000
  • 비교환경
    • 단일 서버 환경 (EC2 인스턴스 1개)
    • 이중 서버 환경 (EC2 인스턴스 2개)
테스트 결과

1. 단일 서버 환경

  • 평균 TPS: 약 280 TPS
  • 지속적인 부하가 증가하면서 일정 TPS를 유지했으나, 일정 시간이 지나면서 급격한 성능 저하 발생
  • 시간이 지남에 따라 서버의 CPU 및 메모리 사용량이 포화 상태에 도달
  • 부하가 일정 수준을 넘어서면 응답 시간이 증가하고, 일부 요청 실패(HTTP Request Failure) 또는 타임아웃 발생
  • 단일 서버에서 한계점 도달 후 응답률 저하
  • 결론
    • 단일 서버로는 지속적인 대량 요청을 처리하는 데 한계가 있음 → 서버 이중화 필요!

2. 이중 서버 환경

  • 평균 TPS: 약 280 ~ 320 TPS
  • 트랜잭션 성공률이 높고, 성능 저하 없이 일정 TPS 유지
  • Scaling(서버 확장)을 통해 요청 처리량이 증가하는 것을 확인
  • CPU 및 메모리 사용량이 분산되어 단일 서버 대비 안정적인 성능 유지
  • 로드 밸런서가 트래픽을 분산하면서 한 서버에 부하가 집중되지 않음
  • 결론
    • 서버를 수평 확장(Scaling Out)하면서 TPS 자체는 큰 변화가 없었지만 요청 처리량이 증가하며 단일 서버보다 많은 트래픽을 처리할 수 있음

3. 테스트 결과 비교 (+ 그래프)

  • 결과 (Scaling Up → Scaling Out)
    • 서버 부하가 2개의 서버로 분산되면서 CPU 및 메모리 사용량이 안정적으로 유지됨
    • 처리량이 일정하게 유지되었고, 서버가 1개일 때 보다 지속적인 요청 처리 가능
    • 서버 한 대 대비 성능이 2배 가까이 증가, 트래픽이 몰려도 안정적인 서비스 운영 가능
테스트
환경		 평균 TPS 서버 정상 운영시간 CPU 사용률 부하 지속
가능 여부		 실패율
단일 서버 280 TPS
-> 급감		 약 11분 후 서버 다운 90% 이상 (포화 상태) 일정 시간 후 성능저하 약 48%
이중 서버 280 ~ 320 TPS
-> 안정적		 약 21분 정상 작동 분산으로 CPU 안정적 (평균) 일정 TPS 유지 약 20%

 

<왼쪽 : 단일 서버 / 오른쪽 : 이중 서버>

 

 

결론

*서버 이중화 적용으로 서버 부하 분산 성공

  • 서버 2개로 확장 후, 요청 실패율 48% → 20%로 감소
  • CPU 사용량 분산으로 안정적인 서비스 운영 가능
  • TPS 유지되며 트래픽 급증에도 서버 정상 작동
  • 비용 절감 효과 확인 → 서버 운영 최적화 완료
  •  최적의 방식: 서버 이중화 (Scaling Out) 적용
Scale Up -> Scale Out
수직확장 -> 수평확장

 

*실행한 부하테스트와 확장성 테스트에서 수직확장(Scale Up)과 수평확장(Scale Out)의 개념이 같이 나온 이유

 

1. Scale Up(Scaling Up) : 수직 확장

  • 기존 서버의 성능(스펙)을 높이는 방식으로 확장
  • ex> 단일 서버에서 CPU와 메모리를 업그레이드하여 처리 성능을 증가시키는 경우
  • 확장방법
    • CPU 코어 수 증가
    • 메모리(RAM) 추가
    • 스토리지(SSD) 업그레이드
    • 쿼리 최적화, Redis 캐싱 적용 -> 기존 서버가 처리할 수 있는 용량을 증가 시킨 경우도 포함
  • 특징
    • 서버의 개수는 그대로 유지
    • 성능이 높아지므로 처리량이 증가할 가능성이 높음
    • 물리적 한계에 도달하면 더 이상 확장 불가능

2. Scale Out(Scaling Out) : 수평 확장

  • 서버의 개수를 늘려 부하를 분산하는 방식
  • ex> 단일 서버에서 2개의 서버로 늘려 로드 밸런서를 통해 부하를 분산하는 경우
  • 확장 방법
    • 여러 개의 서버를 추가하고 로드 밸런서를 사용하여 트래픽 분산
    • MSA(마이크로서비스 아키텍쳐) 적용
    • 클러스터링을 통해 여러 대의 서버가 같은 역할을 수행
  • 특징
    • 이론적으로는 무한 확장 가능
    • 시스템의 고가용성(HA : High Availability) 보장 가능
    • 분산 환경에서 데이터 일관성을 유지하는 것이 중요

3. 이번 테스트의 경우 Scaling Up -> Scaling Out = 혼합 확장(Hybrid Scaling)

  • Scale Up
    • 쿼리 최적화 및 Redis 캐싱 적용
      • 기존 단일 서버의 성능을 개선하여 더 많은 요청을 처리할 수 있도록 함
  • Scale Out
    • 단일 서버에서 이중 서버로 확장, 로드 밸런서를 통해 트래픽 분산
      • 요청 처리량 증가
      • TPS 변화는 적지만 총 요청 수용량 증가
  • 결론
    • 서버 개수만 늘린다고해서 성능이 무조건 좋아지는 것은 아니다.
    • 이 테스트를 통해 이런 상황에서는 TPS 증가보다는 요청 처리량 증대가 목표가 되었다는 것을 확인할 수 있었다.
최종 분석

1. 요약

  • 단일 서버에서는 지속적인 트래픽을 감당하기 어렵고 일정 시간이 지나면 성능 저하가 발생
  • 서버를 하나 추가하여 부하를 분산했을 때 TPS 자체는 큰 변화가 없었으나, 요청 처리량이 증가
  • 이번 테스트는 단순한 Scale Out이 아니라 Scale Up과 결합된 Hybrid Scaling 개념으로 진행됨
  • 로드밸런싱, DB 최적화, 오토스케일링 도입을 고려

2. 최종 개선 방향

  • TPS 성능 향상
    • 서버 확장만으로 TPS 성능을 향상하는데 한계가 있기 때문에 DB 쿼리 최적화, Redis 캐싱 구조 개선, 비동기 처리 도입 등의 성능 개선 고려
  • 오토 스케일링 적용 고려
    • 특정 TPS 이상으로 부하가 급증할 경우 오토스케일링을 적용하여 자동으로 서버를 확장하고 줄이는 방식을 고려
  • Scaling 전략 추가 고려
    • Scale Up을 더 활용하여 데이터베이스 서버를 수직 확장하거나 캐싱으로 서버를 최적화하는 방법 고려