아마존 웹 서비스 부하 테스트 입문 - 정리

부하 테스트 용어

Throughput : 시스템이 시간당 처리할 수 있는 요청 수

Latency : 테스트 도구가 요청을 보내고 응답을 받을 때까지의 시간

부하 테스트 계획 준비

1. 일정 결정

• 한번 부하 테스트 시나리오를 완성하게 되면 다시 테스트하는 것은 어렵지 않아, 시스템 전체 완성을 기다리지 않고, 구성과 같이 부하 테스트를 하는 것도 좋은 방법이다.
• 1~2주 정도 일정을 더 잡는 것도 좋은 방법

2. 부하 테스트 목적 설정

부하 테스트의 목적

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

1번의 여러 사례에 대한 예시

• 서비스 시작 직후 많은 사용자가 서비스에 등록된다.
• 서비스를 시작한 후 많은 데이터가 저장된다.
• 이벤트 광고 등으로 갑자기 사용자 요청이 늘어난다.
• 배치 작업 등 다른 시스템으로 인한 DB 작업과 시간이 겹친다.
• 시스템에서 비정상적인 응답을 한다.
• 시스템 재기동 후에 캐시가 초기화된다
• ....

3. 전제 조건 정리

• 테스트 대상 시스템 범위
  • 품질을 보증하는 범위를 명확하게 정의한다.
• 데이터양
  • 부하 테스트 때 스토리지에 저장될 데이터 건수와 크기를 결정한다.
  • 서비스 이용자 수, 예상 사용자 행동, 사용 기간 등을 통해서 계산한다.
• 외부 시스템 Latency, 사용할 시스템 제약
  • 사용할 외부 시스템이라면 그 시스템의 Throughput와 Latency를 파악한다.
  • 최대 가능 동시 접속 수와 시간당 호출 횟수 제한 등의 제약이 있을 수 있다.
  • 외부 시스템과 통합이 어려운 경우, 어떻게 처리할 것인지(더미 서버에 접속 or 일체 접속하지 않는다.)를 정의한다.
• 지속적인 성능 유지 기간
  • 'X 시간 이상 지속해서 성능을 유지할 것' 등과 같은 기간을 결정한다.
  • 최종적으로 목푯값에 대해 기간 성능을 유지할 필요가 있다.
• 부하를 주는 방법
  • 어떤 네트워크에서 부하를 줄 것인지
  • HTTPS를 사용할지
• 그 외 전체 조건
  • 서버에 같이 동작하고 있는 다른 시스템에 영향을 주지 않을지를 확인한다.
  • 일정 제약 및 환경적 제약을 확인한다.
  • 이외 서비스 환경과 테스트 환경과의 차이에 따른 영향도 확인한다.

4. 목푯값 결정

• Latency 목푯값
  • 일반적인 웹 시스템이라면 50~100ms(0.05 ~ 0.1초) 이하로 잡는 것이 하나의 기준으로 생각
  • 복잡한 트랜잭션이 필요한 비교적 무거운 처리나, 외부 서비스와 통신이 필요한 처리에서는 Latency가 커지는 경우가 있다.
  • 작은 Latency의 차이보다 일정 수준 이상 Latency가 커질 경우 서비스 품질이 급격하게 떨어진다.
  • Latency는 요청량 자체가 작고 낮은 Throughput의 경우 작아지고, 요청량이 늘어나 Throughput이 높아지면 Latency도 높아진다.

• 그래프 1은 목표 Throughput을달성한 경우라도 Latency가 목푯값보다 좋은 범위에 있어 이상적인 상태이다.
•  그래프 2는 목표 Throughput을 달성했더라도 전체적으로 Latency가 높은 편이다. 갑자기 Latency가 올라간 것이 아니라 비교적 Throughput이 작을 때부터 Latency가 높으므로 불필요하게 Latency가 높은 하위 시스템이 없는지 확인해야 한다.
• 그래프 3은 Throughput이 올라가면서 급속하게 Latency가 올라가고 있다. 이것은 시스템 Throughput 성능이 부족한 경우 발생하므로, 병목 구간을 확인하여 개선할 필요가 있다.

Throughput 목푯값

• 1일 사용자 수(명/일) X 1인당 1일 평균 접속 수(회/명) = 1일 총 접속 수(회/일)
• 1일 총 접속 수(회/일) / 1일 초 수 86,400(초/일) = 1일 평균 rps(회/초)
• 1일 평균 rps(회/초) X 1일 평균 접속 수에 대한 최대 피크 때의 배유 = 최대 rps(회/초)

최대 rps에 안전 계수로 2~3배를 곱한 숫자를 Throughput의  목푯값으로 한다.

CDN 등의 캐시를 이용하는 경우 이 1명당 1일 평균 접속 수는 이미지, CSS, JavaScript와 같은 정적 리소스에 대한 요청은 고려하지 않아도 된다. 부하가 클 때도 캐시되어 있는 상황이라면 서버까지 들어오는 요청은 거의 없다.

1일 사용자 수

• DAU(Daily Access User : 1일에 접속하는 유니크한 접속자 수)
• MAU(Monthly Access User : 1개월에 접속하는 유니크한 접속자 수)
• DAU는 어느 정도 서비스가 성장했을 때의(1~2년) 값을 이용한다. 

1명당 1일 평균 접속 수

• 라이트 사용자 이용 시나리오를 생각하여 2~3배 정도를 평균으로 보면 큰 문제는 없다고 생각한다. (저자의 생각)

1일 평균 접속 수에 대한 최대 피크 때의 비율

• 시간대에 따라 변화가 없는 표준적인 서비스라면 대충 피크 때 평균 약 2~3배 접속이 발생하는 경우가 많다.
• 패턴이나 피크 때의 갑은 서비스마다 다르다. 예를 들어, 경매 서비스와 같은 경우 조금 더 높은 값을 예상하는 경우가 좋다.

스파이크 ~ 짧은 시간 동안의 접속 집중

• 대량 메일이나 스마트폰 푸쉬, TV CM 방송 등에서 몇 분 정도의 짧은 시간에 평소보다 높은 접속이 집중될 때가 있다. 이와 같은 집중을 '스파이크'라고 한다.
• 스파이크 대책은 일반적으로 부하에 대한 대책과 같지만, 다음과 같은 점에 주의해야 한다.
  • 오토 스케일링 설정에서는 요청 증가에 따른 애플리케이션 준비가 늦어질 수도 있다.
  • ELB 자체 오토 스케일링이 요청 증가에 따라 스케일링이 늦어질 수도 있다.
• AWS의 오토 스케일링 설정은 웹 서버에 부하가 늘어나면 자동으로 웹 서버 대수를 늘리는 기능이다. 하지만, 스파이크에는 그렇게 도움이 되지 않는다. 이유는 서버 대수가 늘어난 상태에서는 이미 부하가 줄어들고 있기 때문이다. 그러므로, ELB가 추가되는 시간을 맞출 수 없는 부하가 예상되는 경우 미리 'ELB 프리워밍'을 신청해야 한다.

클라우드 서비스의 버스트 기능

• AWS 서비스에는 평소에 사용하지 않을 때는 성능을 모아 두었다가 부하를 발생할 경우 모아둔 크레딧을 사용하여 일시적으로 성능을 올리는 '버스트'라는 기능이 있다.

5. 사용할 부하 테스트 도구 결정

• 간편하게 사용하는 도구(Apache Bench, JMeter 등)
• 많은 테스트 시나리오로 테스트할 수 있는 도구(JMeter, Locust 등)
• 많은 부하를 줄 수 있는 도구(tsung, JMeter, Locust 등)

6. 부하 테스트 환경 결정

• 서비스 환경과 똑같은 환경을 구축하는 것이 가장 좋다.
• 서비스 환경과 같은 환경을 구축하지 못할 경우, 각 서버의 인스턴스 타임을 스케일 다운이나 스케일 인 된 환경을 사용하여 전체 Throughput을 산정하는 방법도 있다. 
  • 확장성을 확인하는 데는 좋지만, 실제 시스템의 Throughput 최댓값을 찾기는 매우 어려우므로 주의해야 한다.
• 이중화는 서비스 환경과 똑같은 구성으로 구축한다.
• 성능이 낮은 인스턴스와 성능이 높은 인스턴스에서 볼 수 있는 결과는 인스턴스 타입 비교표에는 없으므로 두 타입 모두를 테스트하고 각각의 Throughput 비율을 측정해둔다.
• 테스트를 위해 import한 더미 데이터가 부하 테스트 결과에 영향을 많이 끼치는 시스템과 영향을 거의 끼치지 않는 시스템을 구분해둔다.

외부 시스템과 연동된 경우의 환경 구축

• 외부 시스템의 더미 응답을 하는 스터브 서버를 구축한다.
• 프로그램 내부에서 외부 시스템 연동 부분에 스터브를 준비한다.

7. 부하 테스트 시나리오 결정

부하 테스트 시나리오에 다음과 같은 페이지(요청)

• 접속 빈도가 높은 페이지
• 서버 리소스 소비량이 높을 것으로 예상되는 페이지
• DB를 참고하는 페이지
• DB를 갱신하는 페이지
• 외부 시스템과 통신하는 페이지

엑세스 빈도가 높은 페이지

• 사용자가 반드시 엑세스하는 페이지는 정적으로 전송하는 경우를 제외하고는 반드시 테스트에 포함해야 한다.
• 페이지(요청) 예시
  • 사이트 최상위 페이지
  • 앱 기동마다 발생하는 기동 시 체크 API

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

• CPU 리소스를 소비하기 쉬운 페이지(요청) 예
  • 사용자가 입력한 비밀번호 암호화나 인증을 하는 페이지
  • 이미지, 동영상 변환을 하는 페이지
  • 파일 압축과 풀기를 하는 페이지
• 네트워크 대역을 소비하기 쉬운 페이지(요청) 예
  • 응답 콘텐츠 크기가 큰 페이지
  • 이미지, 동영상 업로드와 다운로드를 하는 페이지
• 디스크 I/O를 소비하기 쉬운 페이지(요청) 예
  • 응답 콘텐츠 크기가 큰 페이지
  • 동적 파일 내에 검색 등을 하는 페이지

DB에 참고하는 페이지

• 여러 사용자가 같은 리소스를 참고하고, 같은 응답을 반환하는 페이지
  • 마스터 데이터 형태의 참고 페이지
  • 모든 인원이 최신 사용자 게시물을 참고하는 페이지
• 리소스 전체를 검색하고, 그 결과를 보여주는 페이지
  • 포인트 랭킹을 실시간으로 표시하는 페이지
  • 사용자 게시판을 최신순으로 정렬하여 표시하는 페이지
  • 자신과 비슷한 사용자 검색, 표시 페이지
• 접속하는 사용자별로 다른 리소스를 참고하고, 개별적으로 응답을 보여주는 페이지
  • 사용자별 마이 페이지
  • 사용자 속성에 있는 결과를 표시하는 페이지
  • 사용자가 소유한 타임라인

DB를 갱신하는 페이지

• 여러 사용자가 같은 리소스를 갱신하는 페이지
  • 상품 재고 관리 처리
  • 경매 입찰 처리
• 사용자별로 다른 리소르를 갱신하는 페이지
  • 댓글 페이지
  • 방명록 기능
  • 로그인 세션 발행 페이지

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

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

---

부하 테스트 대상 환경 구축

테스트 대상 환경 구축

• 마지막에 ELB를 사용할 때도, 하위 애플리케이션 서버로 직접 들어오는 요청을 허용한다.
• ELB 앞에 별도 라우팅을 하는 경우에도 ELB를 직접 접속할 수 있는 엔드포인트를 사용할 수 있도록 한다.
• 엑세스 로그에 실행 시간을 확인할 수 있도록 변경한다.
• (추천) HTTP 접속을 허용해둔다.
• 외부 시스템과 연동되는 부분을 ON/OFF 할 수 있도록 스터브 등을 준비한다.

부하 테스트 전용 엔드포인트 추가

• 정적 콘텐츠만을 응답하는 URL
• 웹 프레임워크를 이용한 Hello World 페이지를 응답하는 URL

 

부하 테스트 도구 준비

부하 테스트 도구 구축과 설치, 시나리오 작성

부하 테스트 계획에서 선정한 사용자 동선 시나리오 기준으로 실제 테스트 도구에서 시나리오를 작성하지만, 이외에도 위의 두 가지 URL을 불러올 수 있는 시나리오를 만들어둔다.

• 공격 대상 서버의 정적 파일을 불러오는 시나리오
• 웹 프레임워크를 사용한 Hello World URL을 불러오는 시나리오

시나리오 작성 시 주의점

• 시나리오 작성 중에는 동시 접속 수를 1로 하는 것이 로그나 결과를 추적하기 쉽다.
• 시나리오 작성 중에는 상세 결과 보고서를 작성하기 쉽지만, 서비스 환경에서 부하를 줄 때는 출력이 쉽지 않아 빼는 것이 좋다.
• 시나리오 작성은 네트워크 적으로 떨어진 장소에서 해도 된다.