본문으로 건너뛰기

1. 부하 테스트 계획의 기본 사항​

부하 테스트를 시작하기 전에 부하 테스트 계획을 세워야 한다. 부하 테스트 계획에는 다음과 같은 내용을 결정해야 한다:

  • 일정
  • 부하 테스트 목적
  • 전체 조건 정리
  • 목표값
  • 사용할 부하 테스트 도구
  • 부하 테스트 환경
  • 부하 테스트 시나리오

1.1 일정 결정​

부하 테스트는 일정을 여유롭게 잡아야 한다. 일반적인 개발 프로젝트에서 부하 테스트에 투입되는 인력과 기간을 잠정하는 어렵다.

  • 예상하기 어려운 가장 큰 이유는 PDCA 사이클에서 Action 항목의 '시스템 개선' 때문
  • 시스템 개선이라고 해도 시스템 설정을 변경하는 간단한 개선에서 코드까지 바꿔야 하는 경우도 있음
  • 또한, 문제 작업의 원인을 찾을 수 있는 경우도 있지만, 그대나 인력과 시간이 필요하다는 관점에서 신중하기가 어렵다

1.2 테스트할 수 없는 시스템이나 복잡한 시스템에서의 전략​

테스트를 해볼 수 없는 시스템이나 복잡한 시스템일수록 신중을 기울여 어려울 것이다. 그러나 부하 테스트는 중요한 작업 중 하나이므로 정확한 값을 확인하는 것이 가장 중요하다.

2. 부하 테스트 목적 설정​

확장성을 가진 시스템을 만들려면 기본적으로 부하 테스트 목적은 3장에서 설명한 것과 같이 다음과 같은 내용이 필요하다:

  1. 여러 시래플 토대로 각 시스템의 응답 성능을 예측한다
  2. 부하가 많이 발생하면 성능 개선을 한다
  3. 원하는 성능을 만드는 데 필요한 하드웨어를 미리 설정한다
  4. 시스템 확장성을 가늠하여 확인한다
  5. 시스템 확장성에 대한 특성을 파악한다

3. 전체 조건 정리​

테스트하기 위한 전체 조건을 정리한다. 어떤 점이 예상한다고 어떤 값이 확정된 값인지 등을 명확하게 해야 한다.

3.1 테스트 대상 시스템 범위​

  • 품질을 보증하는 범위를 명확하게 정의한다
  • 데이터 양
    • 부하 테스트 때 스크립트에 저장될 데이터 건수와 크기를 결정한다
    • 서비스 이용자 수, 예상 사용자 행동, 사용 기간 등을 종합해 계산한다
  • 외부 시스템 Latency, 사용량 시스템 제약
    • 사용량 외부 시스템이라면 그 시스템의 Throughput과 Latency를 파악한다
    • 최대 가능 동시 접속 수와 시간당 호출 제한 등의 제약이 있을 수 있다
    • 외부 시스템과 동일이 어려운 경우 어떻게 처리할 것인지 검토한다

3.2 지속적인 성능 유지 기간​

  • 'X 시간 이상 지속해서 성능을 유지할 것' 등과 같은 기간을 결정한다
  • 최종적으로 목표값에 대해 기간 성능을 유지할 필요가 있다

4. 부하를 주는 방법​

4.1 네트워크 관련​

  • 어떤 네트워크에 부하를 줄 것인지
  • HTTPS를 사용할지

4.2 다양한 페이지 유형별 고려사항​

접속 빈도가 높은 페이지​

  • 사이트의 최상위 페이지 등 많은 사용자가 반드시 액세스하는 페이지는 정적으로 전송하는 값으로 제한하고 반드시 테스트에 포함해야 한다. 특히 액세스 빈도가 높은 값을 등은 시나리오 안에 해당 페이지에 액세스하는 빈도를 올려두는 등 실제 사용자의 액세스 수에 근근해야 한다.

서버 리소스 소비량이 높은 것으로 예상되는 페이지​

예를 들어 액세스 빈도가 낮아도 서버 CPU 리소스와 네트워크 대역, 디스크 I/O 등을 많이 이용할 것으로 예상되는 페이지를 들 수 있다.

CPU 리소스를 소비하기 쉬운 페이지(요청) 예​

  • 사용자가 입력한 비밀번호 암호화나 인증을 하는 페이지
  • 이미지, 동영상 변환을 하는 페이지
  • 파일 압축과 풀기를 하는 페이지

네트워크 대역폭을 소비하기 쉬운 페이지(요청) 예​

  • 용량 콘텐츠 크기가 큰 페이지
  • 이미지, 동영상 업로드와 다운로드를 하는 페이지

디스크 I/O를 소비하기 쉬운 페이지(요청) 예​

  • 로그가 많은 페이지
  • 동적 파일 내에 검색 등을 하는 페이지

DB를 접근하는 페이지​

공유 리소스인 DB를 접근하는 페이지이다. DB 접근은 접근과 다른 부하 상태가 되기 쉽다:

  • 마스터 데이터 형태의 참고 페이지
  • 모든 인원이 최신 사용자 계정부을 참고하는 페이지

DB를 갱신하는 페이지​

공유 리소스인 DB를 갱신하는 페이지이다. DB 갱신은 참고와 다른 부하 상태가 되기 쉽다:

  • 상품 재고 관리 처리
  • 경매 입찰 처리
  • 로그인 세션 발행 페이지

외부 시스템과 통신하는 페이지​

DB 접속 이외에도 외부 시스템과 통신이 많이 발생한다:

  • 공유 개시 서버를 사용하는 페이지
  • 로그를 외부 시스템에 전송하는 페이지
  • SNS/Simple Notification Service)/SQS(Simple Queue Service) 등의 시스템 이용
  • 그 외의 외부 API 등의이 발생하는 페이지

5. Throughput 목표값 설정​

실제로 목표 Throughput을 달성하려면 실제 시간에 어느 정도 접속이 발생하는지를 생각해야 한다.

5.1 1일 사용자 수​

일반적으로 웹 서비스 구축을 계획할 때 'DAU(Daily Active User: 1일에 접속하는 유니크한 접속자 수)'나 'MAU(Monthly Active User: 1개월에 접속하는 유니크한 접속자 수)' 등의 지표를 예상하는 경우가 많다.

예를 들어:

  • DAU가 10배가 된 50만 명이고 평균 접속 수가 2배인 40회가 된다면 위의 수식에 20배를 한 약 2,000rps라고 계산할 수 있다
  • 만약 MAU가 100만 명이라면 1일 평균으로 는 약 3만 명이다
  • 1일의 접속한다고 하면 DAU는 3만(2~3으로 대략 10만 명이라고 예상할 수 있다

5.2 1일 평균 접속 수에 대한 최대 피크 배율​

웹 서비스에는 서비스의 성질에 따라 시간대별로 접속 수가 증감하는 형태를 보인다. 예를 들어 웹 서비스는 밤 12시 이후부터 접속이 줄어들어 아침 5시가 가장 적으며, 출근 시간이나 점심시간에 조금 높아나고 18시에서 23시 시이에 정점을 찍는 경우가 많다.

6. 서비스 환경과 테스트 환경의 차이​

서비스 환경과 테스트 환경 구성이 많이 다른 경우의 주의점:

  • 서비스 환경과 같은 환경을 구축하는 것이 가장 중요하다
  • 프로그램 내부에서 외부 시스템 연동 부분에 스터브를 준비한다
  • 스터브란 시스템 외부 기능을 대신하기 위한 사이드 이펙트 없는 더미 시스템을 만들며 주로 테스트를 할 때 사용한다
경고

서비스 환경과 많이 다른 환경에서 부하 테스트를 하면:

  • 가용성 및 확장성 확인이 어려움
  • 병목 구간 파악이 부정확
  • 신뢰할 만한 각 레포트 지수에 대한 측정이 불가능

7. AWS CloudWatch 스케일링 주의사항​

AWS의 오토 스케일링 설정은 웹 서버에 부하가 늘어나면 자동으로 웹 서버 대수를 늘리는 기능이다. 오토 스케일링 설정을 하게 되면 먼저 몇 번 안에 서버가 늘어나게 되어 다음과 같이 부하하는:

  • 오토 스케일링이 유효한 경우 동일한 애플리케이션 준비가 늦어질 수도 있다
  • ELB 차원 오토 스케일링이 유효 증가에 따라 스케일링이 늦어질 수 있다

ELB 차체에도 부하에 따라 스케일아웃을 하는 오토 스케일 기능이 있으므로 ELB가 처리하는 시간을 빛출 수 있는 부하가 예상되는 경우 미리 'ELB 프리워밍'을 신청해야 한다. 더 자세한 내용은 ELB 문서 또는 필요 것처해보면 된다다.

8. 결론​

부하 테스트 계획은 단순히 테스트를 실행하는 것이 아니라, 시스템의 실제 운영 환경과 사용 패턴을 고려한 종합적인 접근이 필요합니다. 특히 페이지 유형별 특성과 리소스 사용 패턴을 이해하고, 이에 맞는 적절한 테스트 시나리오를