[k6] 부하테스트 맛보기

부하테스트의 필요성 인식

• 지금 만든 서비스의 모든 API 에 대해 부하 테스트를 할 필요는 없다
• 지금 서비스의 핵심 기능이 무엇이고 이 기능이 우리가 목표한 혹은 앞으로 달성해야할 포인트에 도달하는가를 생각해야한다
  • "현재 서버는 어느 정도 사용량을 견딜 수 있는건가?"
  • "앞으로 치킨 이벤트가 발생하는게 서버가 견딜 수 있을까?"
• 부하테스트를 해야하는 기능을 찾고 목표를 세우자
• 부하 테스트 목표는 주로 Throughput 과 Latency 를 활용해 설정한다
  • "목표 TPS : 2000 TPS"
  • "평균 Latency : 800 ms"

병목 지점 파악 후 성능 개선

• 성능 개선을 하기 전에 먼저 병목 지점이 어디인지 파악해야 한다
• 그리고 목표치에 대한 현재 성능 지표를 먼저 뽑아내라

주의사항

• 성능을 측정하기에 앞서 해당 서비스가 어떤 도메인과 어떻게 사용자가 사용하는지를 파악해야 한다
• 만약 한 사람당 평균 1시간 정도 사용하는 서비스인데 3분만 테스트 하는 등의 실제 환경과 일치하지 않는 테스트
• 정확한 결과값을 위해 프로덕션 환경과 비슷하게 테스트 해야한다
  • 프로덕션 환경의 데이터들이 포함된 DB 복제본을 떠서 그 DB 로 부하 테스트를 진행하기도 한다
• 프로덕션과 분리된 환경에서 테스트를 해야 한다

실제 테스트 구성

• Ramp-up 방식으로 부하 테스트 진행
  • 부하를 서서히 올리면서 시스템이 점진적으로 늘어나는 트래픽을 어떻게 처리하는지 보는 방식
• RDS 에 테스트 데이터 100만건 생성 (게시글)

k6 script

import http from 'k6/http';
import { sleep } from 'k6';
export const options = {
    // 부하를 생성하는 단계(stages)를 설정
    stages: [
        // 10분에 걸쳐 vus(virtual users, 가상 유저수)가 50에 도달하도록 설정
        { duration: '10m', target: 50 }
    ],
};

export default function () {
    let random = Math.random();
    // ex. 100명 중 5명의 비율로 게시글을 작성
    if (random < 0.05) {
        const data = { title: '제목', content: '내용' };
        http.post('http://{ALB주소}/boards', JSON.stringify(data), {
            headers: { 'Content-Type': 'application/json' },
        });
    } else {
          //ex. 100명 중 95명의 비율로 게시글을 조회
        http.get('http://{ELB 주소}/boards');
    }
    // 1초 휴식
    sleep(1);
}

• 10분에 걸쳐 점진적으로 최대 50명의 요청
• 요청의 5%는 게시글 생성 API 요청
• 1초 주기로 요청

k6 Ramp-up

실제 모니터링

• 위 모니터링을 보고 대략 해당 서비스는 4RPS 정도 되는구나 라고 확인
• 가용가능한 RPS 를 넘어가면 점점 평균 Latency 시간이 늘어남

왜 4 RPS 가 발생했는지 모니터링으로 확인

• EC2 (애플리케이션 서버) 의 CPU, 메모리
• RDS 의 CPU, 메모리
• 각각 지표를 확인한 결과 4 RPS 지점에서 RDS 의 CPU 사용률이 93.7% 라는 것을 알 수 있다