서론
백엔드를 공부하다보면 대용량 트래픽의 상황에서 상상놀이를 많이 하게되는 것 같다.
- 만약 우리 서비스에 1억명이 들어오면?!
- 그래서 동시에 1천만명이 뭔가를 한다면?!
- DB에 데이터가 너무 많아져버리면..??
등등...
API를 하나 만들때마다 천만고객 딱기다려.. 라는 상상만 해본다
종종 이런 상상을 하는 사람들에게 항상 이런 질문이 들어온다.
그래서 왜 그런 선택을 해야하죠?, 근거는요?, 오버엔지니어링아닌가요? 등등..
현실로 돌아오면 우리 서비스는 상상하고 원하는만큼 트래픽을 내지 못한다.
그렇지만 내가 대용량 트래픽에도 견딜 수 있는 구조로 잘 짰는가?에 대한 검증은 해보고싶다.
이럴때 우리는 성능테스트를 시도해볼 수 있다.
(물론 현업의 입장이라면 많은 트래픽을 감당하고 손해를 미리 감수하자는 입장이 될 수도 있겠지만 이 서론은 수입없는 학생들의 프로젝트가 페르소나다)
성능테스트?
말 그대로 서비스 혹은 애플리케이션의 성능을 테스트해보는 것을 의미한다.
성능 테스트의 종류에는 여러가지가 있다.
그 중 몇가지를 소개해본다.
스모크 테스트 (Smoke Test)
시스템이 최소한의 부하에서 정상적으로 작동하는지 확인하고 기본 성능 값을 수집한다. 적은 수의 가상 사용자(VU)로 짧은 시간(몇 초에서 몇 분) 동안 테스트를 수행한다.
Health Check와 유사한 성질을 띄는 테스트로 신규 기능이 머지되었을 때 스모크 테스트를 이용하여 정상적으로 서비스가 동작하는지 테스트해보는 상황이 있을 것이다.
평균 부하 테스트 (Average-Load Test)
시스템이 일반적인 사용량에서 어떻게 작동하는지를 평가한다. 평균적인 동시 사용자 수와 요청 수를 시뮬레이션하며, 일정 시간 동안 유지한다.
서비스의 활성 사용자, DAU 등을 분석하여 이에 해당하는 가상유저를 만들어 지속적인 요청을 보내고, 서비스가 이를 처리할 수 있는지 확인한다.
스트레스 테스트 (Stress Test)
시스템이 피크 트래픽에서 어떻게 작동하는지를 평가한다. 평균 이상의 부하를 가하여 시스템의 안정성과 신뢰성을 테스트한다.
연말정산같이 사람들이 가장 많이 활성화되는 시점을 기준으로 가상유저를 설정한다. 일반적인 사용량의 150% 정도의 유저를 할당하고 테스트한다.
스파이크 테스트 (Spike Test)
갑작스러운 대규모의 트래픽 급증 상황에서 시스템이 어떻게 반응하는지를 평가한다. 매우 짧은 시간에 급격히 높은 부하를 가하고, 빠르게 감소시킨다.
인터파크 티켓과 같은 티켓팅 서비스에서는 이러한 스파이크테스트를 꼼꼼히 수행하면서 서비스를 구성해야할 것 같다.
브레이크포인트 테스트 (Breakpoint Test)
시스템의 한계를 발견하고, 그 한계에 도달했을 때의 시스템 반응을 평가한다. 부하를 진적으로 증가시켜 시스템이 실패하는 지점을 찾는다.
클라우드 기반 애플리케이션이 최대 몇 명의 동시 사용자를 지원할 수 있는지 확인하기 위해, 부하를 점차 증가시켜 시스템이 더 이상 정상적으로 작동하지 않는 지점을 찾는 상황이 있을 것 같다.
다만 이런 테스트를 할 때 자동 스케일아웃이 적용된 환경은 지양해야하겠다.
소크 테스트 (Soak Test)
장시간 동안 지속적인 부하에서 시스템의 성능 저하와 자원 소비를 평가한다. 평균 부하를 오랜 시간 동안 유지하여 시스템의 안정성과 가용성을 테스트한다.
최장 며칠동안 지속적인 사용자 접속을 견딜 수 있는지 확인한다. 대표적으로 여러명이 장기간 접속하는 게임들이 이러한 테스트 대상이 되지 않을까 생각이 든다.
성능테스트에 종류가 참 많다.
각 테스트들이 어떤 특징을 가지는지 정리된 표를 보고 실제로 수행해보도록 하자.
| 유형 | VUs/처리량 | 지속 시간 | 시기 및 목적 |
|---|---|---|---|
| 스모크 | 낮음 | 짧음 (몇 초 또는 몇 분) | 관련 시스템 또는 애플리케이션 코드가 변경될 때. 기능 로직, 기준 메트릭 및 편차를 확인합니다. |
| 평균 부하 | 평균적인 생산 부하 | 중간 (5-60분) | 시스템이 평균 사용량에서 성능을 유지하는지 자주 확인합니다. |
| 스트레스 | 높음 (평균 이상) | 중간 (5-60분) | 시스템이 평균 이상의 부하를 받을 때 어떻게 관리하는지 확인합니다. |
| 소크 | 평균 | 김 (몇 시간) | 변경 후 시스템이 장시간 지속적인 사용에서 어떻게 작동하는지 확인합니다. |
| 스파이크 | 매우 높음 | 짧음 (몇 분) | 시스템이 계절적 이벤트를 준비하거나 빈번한 트래픽 급증을 받을 때. |
| 브레이크포인트 | 한계까지 증가 | 필요할 만큼 긴 시간 | 시스템의 상한선을 찾기 위해 몇 번 수행합니다. |
테스트 선택하기
무조건 모든 테스트를 해서 좋은건 아니다. 부하테스트를 수행하는 목적과 상황을 적절하게 선택해야 의도한 좋은 테스트가 나온다.
의도 없이 무지성으로 테스트하면 안성재셰프한테 한소리 들을 수도 있다.
Koin 서비스
현재 내가 참여하고있는 교내 IT 동아리에서 운영하고있는 Koin 서비스를 대상으로 부하테스트를 진행해보려고한다.
Koin 서비스는 특성상 한국기술교육대학교 교내 학생들에게 초점이 맞춰져있는 서비스다. 그렇기 때문에 천만유저같은 대용량 트래픽에는 다소 적합하지 않은 경향이있다.
우선! 우리 서비스의 DAU를 한번 분석해보자
라고 하면서 우리 동아리의 DA에게 요청하기
평일에 학생들이 일 평균 800명 가량 사용하고 최대 1000명정도 사용하는것을 확인할 수 있었다.
서비스 평시 유저를 1000명으로 설정하고 시나리오를 구성해보도록 하자.
테스트 시나리오
안정적으로 서비스를 운영해나가기 위해 평균 부하, 스트레스, 스파이크 테스트를 시도해보자.
추가로 시스템 상한선도 한번 알아보고자 브레이크 포인트 테스트도 한번 시도해보려고한다.
테스트별로 각각 어떤 상황을 가정할지 알아보자.
1. 스모크 테스트
- 목적: Koin 서비스의 기본 기능이 최소한의 부하에서 정상적으로 작동하는지 확인한다.
- 설정:
- 사용자 수: 50명 (최소한의 부하)
- 지속 시간: 5분
- 측정 항목: 기본 기능의 정상 작동 여부, 초기 응답 시간
- 시나리오:
- 로그인 및 로그아웃
- 주요 데이터 조회 (버스, 공지사항, 상점정보)
2. 평균 부하 테스트
- 목적: Koin 서비스가 일반적인 사용량에서 안정적으로 작동하는지 확인한다.
- 설정:
- 사용자 수: 1000명 (평균 DAU)
- 지속 시간: 30분
- 측정 항목: 응답 시간, 오류율, 시스템 자원 사용률(CPU, 메모리)
- 시나리오:
- 로그인 및 로그아웃
- 게시글 조회 및 작성
- 알림 확인
- 일정 조회
3. 스트레스 테스트
- 목적: Koin 서비스가 피크 트래픽에서 어떻게 작동하는지를 평가한다.
- 설정:
- 사용자 수: 1500명 (평균 사용량의 150%)
- 지속 시간: 45분
- 측정 항목: 응답 시간, 오류율, 시스템 안정성
- 시나리오:
- 동시다발적인 게시글 작성 및 삭제
- 대량의 이미지 업로드 (영양사 식단이미지 업로드)
4. 스파이크 테스트
- 목적: 갑작스러운 트래픽 급증 상황에서 시스템의 반응을 평가한다.
- 설정:
- 사용자 수: 2000명 (급증 시나리오)
- 지속 시간: 10분
- 측정 항목: 응답 시간, 오류율, 복구 시간
- 시나리오:
- 상점 이벤트 발생 시 대량의 사용자 접속을 가정, 이벤트 페이지 접속
- 대량의 데이터 조회 및 검색 (공지사항, 상점, 이벤트 등)
5. 브레이크포인트 테스트
- 목적: 시스템의 한계를 발견하고, 그 한계에 도달했을 때의 시스템 반응을 평가합니다.
- 설정:
- 사용자 수: 점진적으로 증가 (1000명부터 시작하여 시스템이 실패할 때까지)
- 지속 시간: 시스템이 한계에 도달할 때까지
- 측정 항목: 최대 동시 사용자 수, 시스템 자원 한계, 오류 발생 지점
- 시나리오:
- 점진적으로 증가하는 사용자 수에 따라 기본 기능(로그인, 게시글 조회 등) 반복
- 시스템이 더 이상 정상적으로 작동하지 않는 지점 확인
후기
이번 기회에 테스트의 종류와 시나리오를 한번 정리해볼 수 있었다.
다음 글에서는 실제로 어떤 도구를 선택해서 테스트를 수행해볼 것인지, 실제로 테스트 했을 때 어떤 결과가 나왔는지를 분석해보려고한다.
성능 테스트.. 볼수록 알쏭달쏭하지만 내주장에 근거를 뒷받침해줄 좋은 기회라고 생각해 잘 정리해봐야겠다.
Reference
