부하테스트 (1/2)

컴클로딩·2022년 9월 5일
부하테스트
0

📍 Intro

  • 실전 프로젝트도 이제 추석을 제외하면 7일 가량 남은 것 같다. 생각보다 쿼리 성능 개선에서 시간을 많이 잡아 먹었고 남은 7일 동안은 부하테스트를 진행해보고자 한다. 살면서 처음으로 부하테스트를 진행하기 때문에 아무것도 모른다. 그래서 멘토님이 추천해주신 책 "아마존 웹 서비스 부하 테스트 입문"으로 공부하면서 진행해보려고 한다.

  • 해당 글은 책을 읽으면서 정리한 내용들인데 더 자세한 내용을 알고싶다면 책을 구매해서 공부하시는 것을 추천한다!

1. 웹 시스템 설계 방법

1-1. 웹 시스템의 가용성

가용성(Availability) : 시스템이 서비스를 정상적으로 제공할 수 있는 상태를 말한다.

📌 서비스 다운의 원인

  • 광역 네트워크 장애
  • 광역 전원 장애
  • 하드웨어 장애
    • 네트워크 기기 장애
    • 서버 물리 장애(전원, CPU, 메모리, 디스크, 메인보드 등...)
  • 소프트웨어 장애
    • 보안에 문제가 있어 시스템을 이용할 수 없는 경우
    • 그 외의 소프트웨어의 버그
  • 점검 기간
    • 하드웨어 교체
    • 소프트웨어 업데이트
    • 미들웨어 업데이트
  • 고부하에 따른 요청 타임아웃

  • 가용성이 높고 낮음은 가동률의 퍼센티지(%)로 표시된다. 가용성이 99.99%라는 경우 99.99% 시간을 정상적으로 이용 가능한 시스템을 말함. => 1년에 53분 정도는 서비스가 다운된다는 의미.

    • 1년(365) : 100% = x : 99.99% => x = (365 * 99.99) / 100 = 364.9635일
    • 다운되는 시간 0.0365(일) => 0.0365 24시간 = 0.876(시간) => 0.876 60(분) = 52.56분

  • 모놀리식이 아닌 만약 마이크로 서비스의 경우라면?

    • 어떠한 마이크로 서비스의 A시스템의 가용성이 a%, B시스템의 가용성이 b%이라면 => a% * b%
    • 서로 독립적으로 99.99%의 가용성을 가진 5대의 시스템을 연동한 경우 => 99.99% 99.99% 99.99% 99.99% 99.99% = 99.95%

1-2. 높은 가용성을 가진 시스템 설계 방법

  • 시스템을 이중화한다.
    • 시스템 이중화 : 단일 장애점(SPOF: Single Poin Of Failure)을 없애는 방법!
    • 단일 장애점 : 그 지점에 장애가 발생하면 서비스르 제공할 수 없는 지점
    • 결론 👉🏻 시스템 이중화는 시스템의 일부분을 사용할 수 없게 되어도 다른 시스템을 이용해 서비스를 계속 제공하는 것을 의미 => 가용성 높음. 👆🏻
    • ex) 백업 시스템
    • 리던던시(Redundancy) : 같은 장비를 병렬로 배열한 대수
  • 시스템을 확장한다.
    • 스케일 업/스케일 다운한다.
      • 시스템의 리소스 처리 능력을 올리거나 내리는 방법을 말함.
      • AWS RDS instance를 large => 8xlarge로 변경
      • 각각의 장 단점이 있음.
    • 스케일 아웃/스케일 인 한다.
      • 시스템 성능을 올리기 위해 시스템 리소스 수를 늘리거나 줄이는 것을 말함.
      • AWS의 로드 밸런서 서비스인 ELB(Elastic Load Balancing)을 이용해 애플리케이션 서버 대수를 동적으로 늘리거나 줄이는 것이 가능.
      • 해당 방법도 각각의 장 단점이 있음.
    • 클라우드 사업자가 확장성을 보증하는 서비스를 사용한다.
      • 각 서비스를 제공하는 리소스에는 접속할 수 없으며, 서비스로 기능을 이용하는 형태다.
      • Rout 53(DNS 제공 서비스)
      • CloudFront(CDN 제공 서비스)
      • Elastc Load Balancing(로드 밸런서 제공 서비스)
      • S3(스토리지 제공 서비스)

2. 부하 테스트 기본 지식

2-1. 부하 테스트 목적

  • 시스템 처리 능력을 계산해 가용성을 높이는 것!!
  • 온프레미스 시스템과 클라우드 시스템의 설계 방법이 다르고 부하 테스트 목적도 서로 다르다. 책에서는 2가지 내용을 모두 다루지만 해당 글에서는 필요한 클라우드 시스템에 대해서만 다루기로 한다.

2-2. 클라우드에서의 부하 테스트 목적

  • 여러 사례를 토대로 각 시스템의 응답 성능을 예측
  • 부하가 많이 발생하면 성능을 개선
  • 원하는 성능을 완성하는 데 필요한 하드웨어를 미리 선정
  • 시스템 확장성을 가졌는지 확인
  • 시스템 확장성에 대한 특성을 파악
    • 해당 내용을 파악하기 위해 사전에 파악해야 할 것들
      • 몇 가지 Throughput 레벨(ex. 100rps, 500rps, 1000rps, 2000rps, 5000rps 등)을 처리하기 위한 최적의 인프라 구성
      • 실제 웹 시스템은 목표치를 넘어 최대 어디까지 Throughput을 처리할 수 있는지(제한 성능)의 기준
      • WHY? => 예를 들어 Throughput을 지금의 2배로 하고 싶을 때 웹 서버만 올리면 되는지, DB 서버도 같이 올려야 하는지, 혹은 반대의 상황을 가정한다면 미리 위 2가지 내용을 파악해야 한다.

2-3. 부하 테스트에서의 시스템 성능 지표

  • Throughput : 시간당 처리량
    • RPS(Request Per Second) : 1초에 처리하는 HTTP 요청 수
    • 시간당 처리량과는 다른 개념으로 네이트워크로 전송되는 데이터 전송 속도를 의미하는 경우도 있음. => Throughput을 네트워크 대역, 최대 Throughput을 네트워크 대역폭이라고 한다.
  • Latency : 처리 시간
    • 사용자가 본 처리 시간 : 사용자가 요청을 보내고 응답을 받을 때까지의 시간 = 시스템에서 본 처리 시간 + 네트워크를 통한 데이터 왕복 시간 + 브라우저가 데이터를 받고 화면에 표시하기 까지의 시간(브라우저 사용을 할 경우)
    • 시스템에서 본 처리 시간 : 웹 시스템이 요청을 받고 응답을 줄 때까지의 시간
  • 여러 하위 시스템으로 구성된 환경에서의 Throughput과 Latency
    • 시스템 전체 Throughput : 각 하위 시스템 Throughput 중 최솟값
    • 시스템 전체 Latency : 각 하위 시스템의 Latency 합계 값

2-4. 시스템 성능 개선 기본 지식

  • Throughput 개선
    • 병목구간 : Throughput이 가장 낮은 하위 시스템
    • 병목구간을 찾아 개선해서 최대 Throughput을 올릴 수 있음.
    • 하지만 병목을 개선하더라도 다른 쪽에서 병목을 발견 될 수 있음 => 즉, 병목은 이동한다!라고 판단이 가능
    • 병목 구간이라고 생각해서 그 구간을 개선했는데 Throughput에 영향을 주지 않았다면? => 병목 확인이 잘못되었으므로 다른 구간을 확인해야 한다. => 해당 과정들을 반복해서 Throughput을 개선해 나가는 것이 중요하다.
  • Latency 개선
    • '긴 처리 시간이 필요한 처리'에서는 순차적으로 개선 사항이 없는지 확인해 나가는 방법을 사용하는 것이 좋다.
    • 각 처리 시간이 적정한 범위 내에 있다면 더 이상 개선하는 것은 어렵다.
    • 비효율 적인 알고리즘, 필요없는 I/O, 데이터베이스 사용 시 인덱스 부족 현상을 확인해야 한다.
    • 처리 시간은 애플리케이션 내부라면 프로파일러라는 도구를 사용하면 비교적 쉽게 파악 가능.
    • Throughput 개선과 달리 일부 구간의 Latency 개선은 전체 Latency 개선과 연결된다. => 병목 구간에 관계없이 가장 시간이 오래 걸린 구간을 개선하는 것이 전체 Latency를 크게 개선하는 방법이다.

2-5. 좋은 부하 테스트에 대한 지표

  • 테스트 대상 시스템은 부하가 집중되고 있는 상태
    • 부하 테스트 : 테스트 대상 시스템에 부하를 준 상태에서 실행하는 테스트.
    • 여러 하위 시스템으로 구성된 테스트일 때 각각의 하위 시스템에 개별적으로 부하를 주고 조사해야한다.
    • 부하 테스트 중 특정 하드웨어 리소스가 과부하 상태가 되는 것은 나쁜 것이 아니라 좋은 부하 테스트가 진행 중임을 의미한다.
  • 병목 지점을 확인한 상태
    • 시스템에 많은 요청을 보낸 부하 테스트인 경우 일반적으로 시스템 어느 한 부분이 과부하 상태가 되어 이 부분이 전체 Throughput을 결정하게 된다.
    • 부하 테스트 실행 중에는 항상 이 테스트에서 병목 구간이 어디인지를 의식하고 확인해야 한다.
    • 병목 구간을 찾기 쉽게 테스트 방법을 준비하면 보다 효율적으로 테스트할 수 있다.

3. 부하 테스트 도구

부하 테스트 도구 : 웹 시스템뿐만 아니라 특정 시스템을 사용하는 입장에서 시뮬레이션하여 대상 시스템의 상태를 고부하로 만들어준다. 시스템에 많은 요청을 일이크기 DoS 공격이나 DDoS 공격이 들어온 것과 같은 상태를 만든다. 부하 테스트 도구를 가동한 서버를 부하 테스트 서버라고 한다.

3-1. 부하 테스트에서 사용하는 3가지 도구

  • 부하 테스트 도구 : 시스템에 부하를 주는 도구
    • 많은 Http(s) 요청으로 인해 시스템에 부하를 준다.
  • 모니터링 도구 : 시스템 리소스 사용률을 가시화해주는 도구
    • 시스템 리소스(CPU, 메모리, 스토리지 등등..) 감시
  • 프로파일링 도구 : 미들웨어나 애플리케이션 내부 동작을 분석하고 가시화해주는 도구
    • 애플리케이션(Spring, MySQL 등등..) 감시

3-2. 부하 테스트 도구 선택 기준

  • 조건1 요청을 정확하게 시뮬레이션한다.
    • Apache Bench를 사용하면 시나리오 기반 테스트 불가능 => 시나리오가 필요한 부하 테스트는 이러한 도구를 사용할 수 없음.
  • 조건2 부하 정도를 조정 가능해야 한다.
    • 클라이언트 동시 접속자 수, 요청 간격, 최대 Throughput 등을 조정하여 공격 강도를 조절해야 한다. 이러한 설정은 대부분의 테스트 도구에서 가능.
  • 조건3 대상 시스템에 충분한 부하를 발생시켜야 한다.
    • 대상 시스템의 성능 지표에 따라 사용할 수 있는 테스트 도구가 달라짐.
  • 조건4 부하 테스트 도구, 설치, 장소 및 가동 장소를 선택할 수 있어야 한다.
    • 부하 테스트 도구에 따라 기동할 수 있는 서버에 제약이 있을 수 있어 부하 테스트 서버를 설치하는 장소 제약이 있을 수 있다.
    • SaaS 서비스로 원격에 설치된 서버에서 부하를 주는 도구도 있지만 원격에서 부하를 주는 형태는 대상 시스템에만 부하를 주는 것이 어려워서 효율적인 부하 테스트를 하기엔 맞지 않다.

📌 부하 테스트 도구 공통 개념

용어설명
클라이언트HTTP 요청을 동시에 1개만 줄 수 있는 요청 생성기
클라이언트 동시 가동 수테스트 시작 후에 테스트 도구에서 사용할 수 있는 클라이언트 수
Ramp-up 기간테스트 시작 후 모든 클라이언트를 기동하기까지의 준비 기간
시나리오클라이언트별로 설정된 HTTP 요청 생성 패턴
시나리오 실행 횟수클라이언트가 시나리오에 따라 요청을 보내는 횟수
Throughput시스템이 시간당 처리할 수 있는 요청 수
Latency테스트 도구가 요청을 보내고 응답을 받을 때까지의 시간

📌 클라이언트가 실제 부하 테스트를 하는 이미지
이미지1 클라이언트별 HTTP 요청 라이프 사이클
(1) 부하 테스트 서버에서 HTTP 요청 생성
(2) HTTP 요청이 네트워크로 이동
(3) 로드 밸런서가 요청을 서버에 전달
(4) HTTP 요청을 웹 서버가 받음
(5) HTTP 응답을 웹 서버가 보냄
(6) 로드 밸런서를 통해 외부로 나감
(7) HTTP 응답이 네트워크로 이동
(8) 부하 테스트 서버가 HTTP 응답 받음. 그 이후로 다시 (1)로 돌아감

⚠ 주의점 3가지

  • 부하 테스트 도구에서 보이는 Latency ≠ 부하 테스트 대상 시스템의 Latency
    • 부하 테스트 도구에서 보이는 Latency = 네트워크로 전송되는 동안 발생하는 Latency나 SSL 디코드에 대한 Latency가 포함된 값 => 부하 테스트 대상 시스템이 빨리 응답해도 이 값이 반영되었는지 모름 👉🏻 각 시스템의 실제 Latency는 서버 로그를 보거나 로드 밸런서에서 보인 Latency를 확인해야만 한다.
  • 부하 테스트 도구의 클라이언트 동시 기동 수 ≠ 시스템에서 처리되는 동시 처리 수
    • 부하 테스트 도구에서 생성된 요청 대부분은 네트워크나 서버에 있으며 실제 부하를 줘야 하는 대상 시스템에서 처리 중인 요청은 전체 요청 중 일부분일 뿐이다. 특히 네트워크 Latency가 클 때는 부하 테스트 도구에서 설정한 클라이언트의 동시 가동 수와 비교하여 실제 시스템에서 처리 중인 요청 비율은 낮다.
  • 부하 테스트 도구의 클라이언트는 앞의 요청이 완료되지 않으면 다음 요청을 생성하지 않는다.
    • 서버나 네트워크 어딘가에서 일부 요청에 대한 응답을 처리하지 못하게 되면 전체 Throughpu에 많은 영향을 준다. 그러나 이 현상은 부하 테스트 특유의 현상!! 실제 사용자가 접속했을 때의 현상과는 다르다. 아래의 부하 테스트 도구상의 부하와 실 운영환경의 차이에서 자세히 알아보자!

📌 부하 테스트 도구상의 부하와 실 운영환경의 차이

  • 요청을 생성하는 서버 대수, 네트워크의 차이
    • 부하 테스트 환경에서 부하 테스트 서버는 1~N대의 범위 BUT, 서비스 환경에서는 요청을 한 수만큼 사용자가 존재 => SSL을 사용한 사이트의 부하 테스트 환경에서는 SSL 접속과 계산 처리 부하가 부하 테스트 서버에 집중되지만, 서비스 환경에서는 한 대의 서버에 집중되는 문제가 없어 큰 문제는 되지 않는다.
    • SSL 접속을 하지 않을 경우도 HTTP 요청 때마다 통신을 끊고 다시 접속하게 되면 부하 테스트 서버에 과부하가 발생! => 시스템에 효율적으로 부하를 주기 위해 Keep-Alive 설정에 대한 테스트도 필요.
    • 네트워크도 마찬가지로 부하 테스트 환경에서는 집중 되지만 실제 서비스 환경에서는 분산된다. 그래서 테스트 서버의 사양이 아무리 높아도 네트워크 대역이 충분하지 않으면 부하 테스트를 실행할 수 없음.
    • 환경에 따라 같은 IP에서 연속적인 접속을 차단하는 구성도 있으므로 테스트 시 주의가 필요.
  • 요청을 보내는 서버와 엔드포인트의 차이
    • 엔드포인트가 되는 서버가 부하 테스트 환경에서는 부하 테스트 서버별로 일정 시간동안 DNS 정보를 캐시할 때가 있다. 그래서 부하를 받는 서버가 스케일 아웃 되더라도 성능을 내지 못할 때가 많다. 그러나 서비스 환경에서는 요청을 보내는 사용자가 하나의 서버가 아닌 여러 곳으로 분산되어 있어 이러한 문제가 발생하지 않는다.
    • 이러한 문제를 해결하기 위해 테스트 대상 시스템의 가까운 지점에서 부하를 주어 네트워크 영향을 최소화시킬 필요가 있고 또 각 엔드포인트에 같은 양의 요청이 있는지를 항상 확인해야 한다.
  • 동시 요청 수의 차이
    • 부하 테스트 환경에서는 먼저 보내진 요청 결과가 부하 테스트 서버에 돌아올 때까지 기다리고 다음 요청을 보내게 된다. 이와 같은 동작으로 시스템의 응답이 아무리 늦어도! 지정한 클라이언트 수의 요청밖에 동시에 발생하지 않는다.
    • 하지만 실제 서비스 환경에서는 특정 사용자 응답이 늦어져 그 요청에 대한 결과를 기다리는 중에도 새로운 사용자가 새로운 요청을 계속 보내게 된다. 그래서 시스템 응답 시간이 늦더라도 처리해야 할 동시 요청 수는 점점 증가하게 된다.
    • 동시 요청 수가 늘어난다는 것은 해당 서버에 메모리 리소스 사용과 외부 서버와의 접속 수 등에 영향을 주기 때문에 주의해야 한다.
  • 일부 느린 처리가 전체 Throughput에 미치는 영향의 차이
    • 부하 테스트 환경에서 시스템 리소스 사용량이 적음에도 실행 시간이 길어지는 요청이 조금이라도 섞여 있다면 다음 요청을 보낼 수 없게 되고 결과적으로 전체 Throughput이 저하되는 경우가 있따.
    • 하지만 실제 서비스 환경에서는 실행 시간이 긴 요청이 전체 처리에 있어 병목이 발생하지 않으며, 부하 테스트 결과와 실제 환경에서 확인되는 결과와는 많이 다를 때도 있다.
    • 이런 경우 시간이 소요되는 요청은 별도 스레드로 테스트를 하거나 시나리오에서 일단 빼고 테스트를 진행하는 등 전체 조정이 필요!

3-3. 부하 테스트 도구 비교

이름특징
Apache Bench- 단일 URL 부하 테스트는 간단히 가능
- POST/PUT 부하 테스트 가능(DELETE 불가능)
- 요청별로 파라미터 변경 불가
- 시나리오 테스트 불가
부하 테스트 서버의 CPU 코어 1개만 사용
Apache JMeter- Apache Bench에서 할 수 없는 DELETE 테스트 가능
- 요청 별로 동적 파라미터 변경 가능
- 복수의 URL에 시나리오 기반의 복잡한 부하 테스트 가능
- 시나리오는 XML을 사용하지만, GUI로 사용할 수 있고 비교적 직관적인 시나리오 작성 가능
- Proxy Recorder를 사용한 시나리오 작성도 가능
- 부하 테스트 결과 출력 기능이 다양
- 복수의 서버를 연계하여 비교적 고부하 테스트 가능
- HTML 콘텐츠는 콘텐츠 내에서 필요한 여러 가지 정적 리소스를 동시에 확인할 수 있는 테스트 가능
Locust- 시나리오를 파이썬 스크립트로 작성할 수 있어 유연한 시나리오를 만들 수 있다.
- 테스트 시나리오가 스크립트로 되어 있어 소스 코드로 관리할 수 있다.
- 필요한 서버 리소스가 작으므로 작은 크기의 부하 테스트 서버로 테스트할 수 있다.
- 테스트 결과 리포트가 간단하다.
Tsung- 시나리오를 XML로 작성하는 것은 JMeter와 같지만, 작성 방식이 JMeter보다 비교적 간단하고 이해하기 쉽다.
- 그러나 GUI로 시나리오를 작성하거나 볼 수 없어 복잡한 시나리오에는 조금 맞지 않는다.
- JMeter와 같이 Proxy Recorder를 사용하고 시나리오 생성이 가능하다.
- 적은 부하 테스트 서버로 고부하 테스트에 적합하다.
- 결과는 JSON으로 표시되고 결과를 보기 위한 웹 화면이 준비되어 있다.

3-4. 모니터링 도구와 프로파일링 도구

  • 3-3에서의 부하 테스트 도구에는 Throughput 모니터링 도구, 시각화 도구가 포함된 것도 있지만, 부하테스트 도구에서 볼 수 있는 Latency는 전체 Latency뿐이며 개별 하위 시스템에 대한 Latency는 볼 수 없다.
  • 부하 테스트 도구에서는 각 시스템이 사용하고 있는 리소스를 모니터링하거나 프로파일링 할 수 없다.
  • 프로파일링 도구는 시스템 외부에서는 볼 수 없는 시스템의 병목 구간을 확인할 수 있는 유요한 것이지만 프로파일링 도구를 활성화하고 부하 테스트를 진행하게 된다면 프로파일링 도구의 움직임 자체가 시스템 리소스 사용 상태에 영향을 주므로 정확한 프로파일링을 할 수 없게 된다.
  • 이 문제를 해결하기 위해 프로파일링 도구를 비활성화한 상태에서 부하 테스트를 하는 동시에! 프로파일링 도구를 활성화한 상태에서 별도의 테스트를 하여 고부하 상태의 프로파일링 결과를 확인할 수 있다.
    • 저부하 상태와 고부하 상태의 시스템은 전혀 다른 상태를 가진다. 저부하 상태 시스템 프로파일링의 결과를 가지고 고부하 상태 시스템을 프로파일링하는 것은 무의미한 경우가 많기 때문에 꼭 부하를 준 상태의 결과를 확인해야 한다.

📌 각 하위 시스템의 상세 모니터링과 시스템 프로파일링을 하기 위한 도구

  • top 명령어
    • 많은 Linux계 OS에는 기본으로 제공되는 명령어로 시스템 전체와 프로세스별 CPU와 메모리 사용량 등을 볼 수 있다. 실시간으로 볼 수 있어 부하 테스트 시에 유용하게 사용된다.
  • netstat 명령어
  • AWS 관리 콘솔
    • CloudWatch 활용
    • 주의점은 1분 간격의 RDS나 5분 간격의 EC2 인스턴스 모니터링때문에 부하가 없는 동안의 리소스 사용량과 부하가 있을 때의 사용량이 평균값으로 보이기 때문에 정상적인 모니터링이 불가 => 추가 과금이 되더라도 부하 테스트를 할 때는 CloudWatch 메트릭스의 상세 모니터링을 최소 1대의 서버에는 적용하도록 한다.
  • Xhprof
    • PHP 애플리케이션 전용 프로파일링 도구
  • New Relic
    • 프로파일링과 모니터링을 할 수 있는 SaaS 제품.
    • Java, Ruby on Rails, PHP, Python, Node.js 등 여러 언어와 웹 프레임워크를 지원
    • 유료 플랜과 무료 플랜이 있고 무료 플랜도 많은 도움이 된다.
하위 시스템WATCH 해야 하거나, 방법을 알아야 하는 항목
네트워크전송량
하드웨어 및 OSCPU, 메모리, 프로세스 수, SWAP, Load Average
TCP외부 커넥션 상태(ESTABLISH나 FIN WAIT 등)
디스크IOPS, R/W 전송 데이터 양
미들웨어커넥션 수(<->Max Connection)
애플리케이션프로파일러로 모니터링
MySQLSlow Query, Process List

마무리

  • [아마존 웹 서비스 부하 테스트 입문]의 1장-4장까지 정리한 내용이다. 웹 시스템 설계 방법부터 시작해서 부하 테스트 기본 지식 그리고 부하 테스트 도구와 선택 기준에 대한 내용들이었다. 5장-9장은 부하 테스트의 큰 PDCA(Plan Do Check Action) 사이클에 대한 설명이다. 그래서 한 번 끊고 가야겠다.

참고자료

profile
컴클로딩
어떠한 가치를 창출할 수 있을까를 고민하는 개발자. 주로 Spring으로 개발해요. https://comclothing.tistory.com/ 👈🏻티스토리 블로그로 이전 완료
이전 포스트

2022-08-15 개발일지

다음 포스트

회고

0개의 댓글