스트레스 테스트

스트레스 테스트는 시스템이 감당하리라 여긴 것보다 센 부하를 일부러 걸어 봅니다. 그 부하를 버티는지 봅니다. 버티지 못할 때 어디서 어떻게 무너지는지도 사용자가 몰리기 전에 알아냅니다.

상세

차가 늘어도 어느 정도까지는 도로가 제 속도로 흐릅니다. 그 선을 넘기면 속도가 떨어지기 시작해 결국 멈춰 섭니다. 멈춰 선 뒤에는 뒤에서 들어오는 차를 막아도 줄이 한참 동안 풀리지 않습니다.

스트레스 테스트는 예상하거나 정해 둔 용량보다 센 부하를 걸어 시스템의 행동을 보는 시험입니다. 평소 몰리는 양의 두 배나 세 배를 거는 것이 한 예입니다.

부하를 늘리는 대신 자원을 줄이는 방식도 같은 이름으로 부릅니다. 쓸 수 있는 메모리나 네트워크 대역폭, 계산 능력을 최소 요구보다 줄여 놓고 시스템이 어떻게 행동하는지 봅니다.

부하 테스트와는 거는 부하의 범위가 다릅니다. 부하 테스트는 예상하는 사용량을 평소와 가장 붐빌 때 모두 감당하는지 확인합니다. 스트레스 테스트는 그 범위를 넘겨 시스템이 어디까지 버티고 어디서 무너지는지를 찾습니다.

그 범위를 어디까지 넘겨야 이 이름이 붙는지는 문서마다 갈립니다. 시스템이 무너지는 데까지 미는 것을 이 이름으로 부르는 문서도 있고, 평소보다 센 부하까지만 이 이름에 담는 문서도 있습니다. 이 편은 넓은 쪽을 따라 적습니다. 갈림은 「이견」에서 봅니다.

정해 둔 성능 목표를 지키면서 감당하는 가장 큰 부하를 최대 용량이라고 합니다. 시스템이 더는 버티지 못하고 주저앉는 부하는 그보다 뒤에 있습니다. 이것을 무너지는 지점이라고 부릅니다.

block-beta
columns 4
  a["평소 부하"] b["예상 최대"] c["최대 용량"] d["무너지는 지점"]
  e["부하 테스트"]:2 f["스트레스 테스트"]:2

부하 테스트는 예상하는 사용량이 가장 붐빌 때, 곧 그림의 예상 최대까지만 겁니다. 스트레스 테스트는 그 너머로 밀어 최대 용량과 무너지는 지점을 찾습니다.

시험이 알아내는 세 가지

첫째는 최대 용량입니다. 성능 목표를 지키며 받아 낼 수 있는 부하가 어디까지인지를 값으로 잡습니다.

둘째는 무너지는 방식입니다. 최대 용량을 넘겼을 때 무엇이 먼저 어긋나는지를 봅니다. 응답 시간이 먼저 길어지는 경우도 있고, 응답 시간은 견딜 만한 채로 오류 쪽이 먼저 어긋나는 경우도 있습니다.

오류 쪽이 먼저 어긋나는 경우에 보이는 것은 이렇습니다. 응답은 견딜 만한 속도로 돌아옵니다. 그런데도 오류로 끝나는 요청이 생깁니다. 느려져서 들키는 것이 아니라 오류 수치에서 먼저 들킵니다.

이 경우 밑에 깔린 결함은 셋입니다. 자원 풀이 모자란 것, 대기 줄과 스택을 작게 잡은 것, 응답을 기다리는 시간 한도인 타임아웃을 너무 짧게 둔 것입니다. 대기 줄이 꽉 차 받아 두지 못한 요청과 시간 한도에 걸려 끊긴 요청이 그대로 오류가 됩니다. 무엇이 걸렸는지에 따라 손볼 곳이 달라집니다.

이 경우는 아래 「최대 용량을 넘긴 뒤의 두 모습」에 셋째로 더해지는 모습이 아닙니다. 두 모습은 제대로 처리해 내는 요청의 양이 유지되는지로 가른 것이고, 여기서 본 것은 응답 시간과 오류 가운데 어느 쪽이 먼저 어긋나는지입니다.

셋째는 회복입니다. 부하를 걷은 뒤 시스템이 정상으로 돌아오는지, 돌아오는 데 무엇이 필요한지를 봅니다.

최대 용량을 넘긴 뒤의 두 모습

부하가 늘어도 시스템은 어느 지점까지는 대개 요청을 잘 처리합니다. 그 지점을 넘기면 더는 처리하지 못하는 요청이 생깁니다. 이때 보이는 모습이 둘로 갈립니다.

버티는 쪽은 넘치는 요청 일부를 거절하거나 품질을 낮춘 결과를 돌려줍니다. 대신 제대로 처리해 내는 요청의 양은 크게 줄지 않습니다. 몇 개를 버리고 살아남는 셈입니다.

주저앉는 쪽은 프로세스가 죽기 시작하거나 아주 많은 요청에 오류를 냅니다. 아래에서 볼 고리에 쉽게 휘말리는 구성 요소가 이런 모습을 보입니다. 둘 중 어느 모습이 나타나는지가 시험이 알아내는 둘째 것입니다.

무너짐을 키우는 고리

과부하가 걸린 서버는 응답이 늦어집니다. 늦은 응답은 클라이언트가 정해 둔 타임아웃을 넘길 수 있습니다. 그러면 서버가 그 요청에 들인 일은 버려집니다.

클라이언트는 실패한 요청을 다시 보낼 수 있습니다. 이것을 재시도라고 합니다. 재시도는 원래 요청 위에 얹히는 부하라서 과부하를 더 키웁니다.

실패가 이어지는 동안 재시도는 초마다 쌓입니다. 첫 1초에 초당 100건이던 재시도가 다음에는 200건, 그다음에는 300건이 되는 식입니다. 첫 시도에 성공하는 요청이 줄어 쓸모 있는 일의 몫도 줄어듭니다.

들어오는 요청이 처리 속도보다 빠르면 요청은 대기 줄에 쌓입니다. 쌓인 요청은 메모리를 먹고 지연을 늘립니다.

대기 줄을 스레드 수의 열 배로 잡았다고 해 봅니다. 스레드에서 요청 하나를 처리하는 데는 100밀리초가 듭니다. 줄이 꽉 차 있으면 요청 하나를 처리하는 데 1.1초가 걸립니다.

1.1초 가운데 1초는 앞에 선 열 차례가 100밀리초씩 빠지기를 기다리는 시간입니다. 남은 100밀리초가 제 요청을 처리하는 시간입니다. 그래서 그 시간 대부분을 줄에서 보냅니다.

flowchart TD
    A["부하가 처리 속도를 넘는다"] --> B["대기 줄이 쌓인다"]
    B --> C["응답이 타임아웃을 넘긴다"]
    C --> D["서버가 들인 일이 버려진다"]
    C --> E["클라이언트가 재시도한다"]
    E --> A

이 고리는 스스로를 키웁니다. 이렇게 되먹임으로 시간이 갈수록 커지는 장애를 연쇄 장애라고 부릅니다. 시스템의 한 부분이 무너지면 다른 부분도 무너질 가능성이 커집니다.

부하를 걷은 뒤의 회복

부하를 걷어도 시스템이 곧바로 돌아오지 않을 수 있습니다. 재시도가 그 까닭 하나입니다. 부하를 무너지기 전 수준으로 되돌려도 앞서 실패한 요청의 재시도는 계속 들어옵니다.

실패를 돌려주는 일에도 비용이 듭니다. 요청을 받아 처리하는 뒤쪽 서버가 그 비용을 치릅니다. 그 비용이 얼마인지에 따라 재시도만으로도 과부하가 유지될 수 있습니다. 그런 경우에 빠져나오려면 재시도가 멈추고 뒤쪽 서버가 안정될 때까지 부하를 크게 줄이거나 아예 끊어야 합니다.

비워진 캐시가 또 하나의 까닭입니다. 캐시에 값이 없어 원본까지 가야 하는 것을 캐시 미스라고 합니다. 캐시가 값으로 채워진 평소에는 캐시 미스가 몇 번 안 납니다.

캐시가 완전히 비면 모든 요청이 비싼 길로 갑니다. 막 재시작한 서버는 캐시를 다시 채우는 데 시간이 걸립니다.

높은 부하에서 품질을 낮춘 결과를 내며 버티는 상태를 저하 모드라고 부릅니다. 회복을 볼 때는 두 가지를 묻습니다. 하나는 저하 모드에 들어간 구성 요소가 사람 손 없이 빠져나오는지입니다. 다른 하나는 서버 몇 대가 죽었을 때 부하가 얼마나 내려가야 시스템이 안정되는지입니다.

stateDiagram-v2
    state "정상" as N
    state "저하 모드" as D
    state "서버 일부가 죽음" as K
    state "사람이 손봄" as M
    N --> D: 부하가 최대 용량을 넘는다
    N --> K: 부하가 최대 용량을 넘는다
    D --> N: 스스로 빠져나온다
    D --> M: 스스로 못 빠져나온다
    K --> N: 부하가 충분히 내려간다
    M --> N

이웃한 성능 시험

부하를 걸어 성능을 보는 시험은 여럿입니다. 거는 방법이 비슷해서 이름이 섞여 쓰입니다. 가르는 기준은 무엇을 알아내려는가입니다.

소크 테스트는 내구 테스트라고도 부릅니다. 무너지는 지점을 찾는 것은 스트레스 테스트의 몫입니다. 몇 시간 뒤에야 드러나는 메모리 누수는 소크 테스트만 보여 줍니다.

배경

시스템에는 평소보다 센 부하가 몰리는 때가 있습니다. 처리 마감일, 월급날, 출퇴근 시간, 한 주가 끝나는 때처럼 요청이 평균을 웃도는 때입니다.

부하 테스트는 예상 범위 안에서 부하를 겁니다. 그 범위 밖에서 시스템이 어떻게 행동하는지는 보여 주지 않습니다. 그러면 그 행동을 처음 보는 날이 사용자가 몰리는 날이 됩니다.

과부하에서 시스템이 어떻게 행동하는지 알면 장기적으로 무엇부터 고칠지가 보입니다. 무너지는 지점이 어디인지는 앞으로 자원을 얼마나 갖출지 정하는 용량 계획의 바탕이 됩니다. 예상 범위 밖을 일부러 걸어 보는 시험은 그래서 부하 테스트와 따로 둡니다. 기본 부하 테스트로 기준 성능을 먼저 잡은 뒤 넓혀 가는 다음 단계가 됩니다.

예시

k6 스트레스 테스트 설정

k6 는 부하를 거는 도구입니다. 시험 스크립트의 options.stages 에 단계마다 걸리는 시간과 목표 가상 사용자 수를 적습니다. 가상 사용자는 도구가 흉내 내는 사용자 한 명 몫의 요청 흐름입니다.

export const options = {
  stages: [
    { duration: '10m', target: 200 }, // traffic ramp-up from 1 to a higher 200 users over 10 minutes.
    { duration: '30m', target: 200 }, // stay at higher 200 users for 30 minutes
    { duration: '5m', target: 0 }, // ramp-down to 0 users
  ],
};

10분에 걸쳐 가상 사용자를 200명까지 올립니다. 그 수를 30분 동안 유지한 뒤 5분에 걸쳐 0명으로 내립니다. 평균 부하를 거는 시험과 모양은 같습니다. 목표 부하만 높습니다.

xychart-beta
    title "올리고 유지하고 내리는 모양"
    x-axis "경과 시간(분)" [0, 10, 40, 45]
    y-axis "가상 사용자" 0 --> 250
    line [0, 200, 200, 0]

올리고 내리는 구간을 더 길게 잡아 시스템이 좀 더 현실적으로 반응하게 둡니다. 목표를 평균보다 50퍼센트나 100퍼센트 높게 잡는 사람도 있습니다. 하지만 정해진 비율은 없습니다. 시스템이 받을 수 있는 위험한 부하 모양에 맞춰 정합니다.

k6 브레이크포인트 테스트 설정

무너질 때까지 미는 시험은 k6 가 다른 이름으로 부릅니다(이견 절). 설정은 이렇습니다.

export const options = {
  executor: 'ramping-arrival-rate', // assure load increase if the system slows
  stages: [
    { duration: '2h', target: 20000 }, // just slowly ramp-up to a huge load
  ],
};

설정의 executor 칸이 부하를 만드는 방식을 고릅니다. ramping-arrival-rate 는 요청이 들어오는 속도인 도착률을 올려 가는 방식입니다. 그래서 목표값 20,000 은 가상 사용자 수가 아니라 도착률의 목표입니다.

2시간에 걸쳐 그 목표값까지 천천히 올리기만 합니다. 유지 구간도 내리는 구간도 없습니다. 대개 그 값에 닿기 전에 실패합니다.

xychart-beta
    title "올리기만 하는 모양"
    x-axis "경과 시간(분)" [0, 120]
    y-axis "도착률 목표값" 0 --> 20000
    line [0, 20000]

다른 시험은 시스템이 어느 수준까지 나빠지면 멈춥니다. 이 시험은 시스템이 나빠지기 시작해도 부하를 계속 올립니다. 그래서 느려져도 부하가 계속 오르도록 ramping-arrival-rate 를 쓰기를 권합니다. 기준을 넘기기 시작하면 대개 사람이 멈추거나 자동으로 멈춥니다.

stress-ng 명령

앞의 두 설정은 서비스에 요청을 보내 부하를 겁니다. 자원을 줄이거나 조여 거는 쪽도 같은 이름으로 부른다고 상세에서 적었습니다. stress-ng 는 그쪽 도구입니다.

stress-ng 는 요청을 보내는 대신 컴퓨터 자체를 세게 돌립니다. CPU(Central Processing Unit, 중앙 처리 장치)와 메모리, 디스크를 직접 바쁘게 만듭니다. 처음에는 과열 같은 하드웨어 문제와 시스템이 심하게 시달릴 때만 나는 운영체제 버그를 드러내려고 만들었습니다.

한 종류의 부하를 만드는 작업을 스트레서라고 부릅니다. 아래 명령은 CPU 스트레서 8개를 60초 동안 돌립니다.

stress-ng --cpu 8 --timeout 60

아래 명령은 관리자 권한(root)으로 가상 메모리 스트레서 2개를 돌립니다. 가용 메모리의 95퍼센트를 씁니다. 결과는 example.log 에 남깁니다. 커널 로그의 오류도 확인합니다.

sudo stress-ng --log-file example.log --vm 2 --vm-bytes 95% --klog-check -v -t 1h --vmstat 10 --verify

1시간 동안 돌리는 내내 10초마다 가상 메모리 통계를 찍습니다. 메모리 시험 결과도 검증합니다.

설계가 부실한 하드웨어에서는 일부 시험이 기계를 뜨겁게 만들 수 있습니다. 멈추기 어려운 과도한 스래싱을 일으킬 수도 있습니다. 스래싱은 자원이 모자라 일보다 자원을 바꿔 들이는 데 시간을 더 쓰는 상태입니다. 처리율을 재는 기능도 있지만 정밀한 벤치마크로 쓰라고 만든 도구는 아닙니다.

동작

이 절은 서비스 하나에 요청 부하를 걸어 스트레스 테스트를 한 번 돌리는 순서를 다룹니다. 대상은 그 서비스입니다. 단계마다 재는 것은 응답 시간과 오류와 자원 사용입니다. 순서는 아래 그림과 같습니다.

부하는 한 번에 끝까지 올리지 않고 단계를 나눠 올립니다. 그래서 버티면 다음 단계로 다시 올라가는 되돌이가 생깁니다. 소절마다 한 단계씩 풉니다.

flowchart TD
    A["부하 테스트를 먼저 통과시킨다"] --> B["부하를 천천히 올린다"]
    B --> C["그 부하를 한동안 유지하며 읽는다"]
    C --> D{"성능과 자원 사용이 안정적인가"}
    D -->|"버틴다"| B
    D -->|"무너진다"| E["어느 실패 단계인지 적는다"]
    E --> F["부하를 걷고 돌아오는지 본다"]

앞서 통과할 부하 테스트

스트레스 테스트는 평균 부하를 거는 부하 테스트를 통과한 뒤에만 겁니다. 평균 부하에서 나는 문제를 먼저 찾아 둬야 합니다. 그러지 않으면 낮은 부하에서 나는 문제를 스트레스 테스트에서 만나 원인을 짚기 어려워질 수 있습니다. 스크립트는 부하 테스트의 것을 다시 쓰고 부하만 올립니다.

올리는 속도와 유지 구간

부하는 천천히 올립니다. 갑자기 올리면 시스템이 왜, 언제 실패하기 시작했는지 짚기 어려워질 수 있습니다. 한 번에 일정량씩 올리는 계단 모양도 씁니다. 5분마다 가상 사용자를 100명씩 더하는 식입니다.

천천히 올릴 때와 단숨에 올릴 때는 캐시 효과 때문에 결과가 다를 수 있습니다. 그래서 두 모양을 다 시험해 보기를 권하기도 합니다.

목표 부하에 닿으면 한동안 그 부하를 유지합니다. 그동안 성능과 자원 사용이 안정되게 머무는지 확인합니다. 부하를 올리는 동안에도 응답 시간이 나빠지는 첫 모습이 보입니다. 부하가 평균을 넘어갈 때입니다.

실패 단계의 기록

실패는 한 가지가 아닙니다. 무엇을 실패로 볼지는 팀마다 다를 수 있습니다. 그래서 아래 단계마다 그때의 부하를 따로 적어 두기도 합니다.

표의 성능 저하는 응답이 느려지는 것입니다. 상세의 저하 모드처럼 품질을 낮춘 결과를 내며 버티는 것과는 다릅니다.

부하를 걷은 뒤의 관찰

부하는 천천히 내리거나 바로 멈춥니다. 정상 부하보다 훨씬 위로 밀렸던 시스템이 정상 부하로 돌아오는 동안 어떻게 행동하는지 봅니다. 이때 묻는 것은 상세의 「부하를 걷은 뒤의 회복」과 같습니다.

시험을 거는 환경

스트레스 테스트는 시스템이 운영에 들어갈 준비가 되기 전에, 성능 시험 전용 환경에서 겁니다.

자동으로 늘어나는 클라우드 환경에서 무너질 때까지 밀면 환경이 시험을 따라 커집니다. 그러면 찾는 한계가 클라우드 계정 청구서의 한계뿐일 수 있습니다. 그런 환경에서 돌린다면 영향을 받는 구성 요소의 자동 확장을 모두 꺼 두기를 강하게 권합니다.

성능 시험을 종류마다 다 갖추려면 시간과 인프라가 많이 듭니다. 그래서 기본 부하 테스트부터 시작해 위험이 보이는 만큼 스트레스 테스트로 넓혀 갑니다.

이견

어디까지 미는 것을 스트레스 테스트라 부르는지가 문서마다 갈립니다. 미는 데까지를 시스템이 무너지는 지점에 두는 문서가 있습니다. 예상하거나 정해 둔 작업량의 한계 위에 두는 문서가 있습니다. 평소보다 센 부하에 두는 문서도 있습니다.

Azure Well-Architected 의 성능 시험 지침은 무너지는 지점까지를 이 이름에 담습니다. 스트레스 테스트를 시스템의 한계와 무너지는 지점을 알아내는 시험으로 적습니다. 드러나는 것으로 최대 용량과 실패 방식과 회복 행동을 듭니다.

ISTQB(International Software Testing Qualifications Board) 의 성능 시험 실러버스는 선을 작업량에 긋습니다. 이 실러버스는 최대 부하를 견디는 능력에 초점을 둔다고 적습니다. 그 최대 부하는 예상하거나 정해 둔 작업량의 한계에 이르거나 그 한계를 넘는 부하입니다.

용어 표준도 작업량과 용량에 선을 긋습니다. ISO/IEC/IEEE 29119-1 은 소프트웨어 시험 표준입니다. 국제표준화기구 ISO(International Organization for Standardization)와 국제전기기술위원회 IEC(International Electrotechnical Commission), 전기전자기술자협회 IEEE(Institute of Electrical and Electronics Engineers)가 함께 냈습니다. 이 표준은 스트레스 테스트를 예상하거나 정해 둔 용량 요구를 넘는 부하에서 시험 대상의 행동을 평가하는 시험으로 정의합니다.

이 두 문서는 자원을 줄여 거는 것도 같은 이름에 넣습니다. 29119-1 은 자원을 쓸 수 있는 정도가 최소 요구 아래인 상태를 함께 적습니다. ISTQB 실러버스는 계산 능력과 대역폭과 메모리를 덜 쓸 수 있는 상태를 함께 적습니다.

평소보다 센 부하까지만 담는 쪽은 k6 문서입니다. k6 문서는 스트레스 테스트를 평소보다 무거운 부하에서 시스템이 어떻게 하는지 평가하는 시험으로 적습니다. 그 부하가 평균보다 몇 퍼센트만 높을 수도 있고, 두세 배나 몇 자릿수까지 높을 수도 있다고 적습니다. 러시아워 테스트, 서지 테스트, 스케일 테스트라는 다른 이름도 듭니다.

k6 문서는 한계를 찾으려고 무너질 때까지 미는 시험을 따로 브레이크포인트 테스트라 부릅니다. 이 이름에는 뚜렷한 합의가 없다고 스스로 적습니다. 용량 시험, 포인트 부하 시험, 한계 시험이라고도 부른다고 덧붙입니다.

같은 「용량 시험」이 다른 문서에서는 다른 뜻입니다. ISTQB 실러버스의 용량 시험은 성능 목표를 지키면서 시스템이 받아 내는 사용자나 트랜잭션 수를 정하는 시험입니다.

미확인 칸은 그 문서가 그 시험에 따로 이름을 두는지 가리지 못한 것입니다.

관련 항목

스트레스 테스트와 목적이 갈리는 성능 시험

부하 테스트 · 스파이크 테스트 · 소크 테스트 · 브레이크포인트 테스트 · 용량 시험 · 성능 테스트 · 벤치마크 · 스모크 테스트 · 카오스 엔지니어링 · 장애 주입

무너지는 지점을 읽을 때 보는 지표

응답 시간 · 처리량 · 오류율 · 초당 요청 수 · 지연 · 백분위수 · 사용률 · 가용성

부하를 만들어 거는 도구와 그 설정값

k6 · Locust · JMeter · stress-ng · 부하 생성기 · 가상 사용자 · 램프업 · 임계값

한계를 넘겼을 때 먼저 주저앉는 고장

병목 · 커넥션 풀 고갈 · 메모리 누수 · 연쇄 장애 · 썬더링 허드 · 큐 대기 · 콜드 캐시 · 스래싱

무너지지 않게 버티려고 두는 장치

서킷 브레이커 · 우아한 저하 · 저하 모드 · 부하 차단 · 스로틀링 · 재시도 · 타임아웃 · 백프레셔 · 오토스케일링 · 로드 밸런서 · 수평 확장

시험 결과를 받아 쓰는 운영 작업

용량 계획 · 모니터링 · 경보 · 대시보드 · SLO · 성능 기준선 · 성능 회귀 · QA와 테스트