부하 테스트

기능이 되는지와 사람이 몰려도 되는지는 다른 질문입니다. 앞쪽은 한 사람이 한 번 눌러 보면 답이 나오지만 뒤쪽은 그렇게 확인할 수 없습니다. 혼자 쓸 때 0.2초에 뜨던 목록 화면이 동시에 2000명이 부르면 8초가 되기도 하고, 그 8초는 기능이 멀쩡히 도는 상태에서 나옵니다. 사용자 쪽에서는 고장과 구분되지 않습니다.

이 숫자는 몰려 보기 전에는 알 길이 없습니다. 동시에 들어올 때만 생기는 다툼이 원인이기 때문입니다.

그래서 과거에는 실제 사용자가 대신 확인해 주는 일이 흔했습니다. 페이지덱도 그랬습니다. 대형 고객사가 전사 도입을 시작한 첫날 아침 아홉 시에 300명이 한꺼번에 들어왔고 문서 목록이 열리지 않았습니다. 태오가 들여다보니 기능 문제가 아니라 데이터베이스로 가는 연결 개수가 정해진 수를 다 써 버려 나머지 요청이 줄을 선 것이었습니다. 데이터베이스는 데이터를 저장하고 꺼내 쓰게 해 주는 시스템인데, 여기에 동시에 붙을 수 있는 연결 수에는 대개 상한이 걸려 있습니다.

부하 테스트는 이 확인을 사용자가 아니라 우리가 먼저 하자는 것입니다. 실제로 들어올 만한 양을 도구로 만들어 밀어 넣고, 어느 지점에서 무엇이 먼저 무너지는지를 사무실에서 봅니다.

돌리는 순서는 여섯 단계이고, 앞의 두 단계를 건너뛰면 나온 숫자를 읽을 수 없게 됩니다.

1. 목표를 정합니다. "동시 사용자 2000명에서 목록 화면 응답이 1초 안" 처럼 숫자로 적습니다. 이미 SLO가 있으면 그 값을 그대로 씁니다. SLO 는 팀이 지키기로 정해 둔 서비스 품질 목표치입니다. 목표 없이 돌리면 나온 숫자가 좋은지 나쁜지 판단할 기준이 없습니다.
2. 시나리오를 고릅니다. 모든 화면을 다 두드리는 것이 아니라 실제 사용 비율을 흉내 냅니다. 페이지덱이라면 문서 목록 열기 70퍼센트, 문서 저장 20퍼센트, 검색 10퍼센트 같은 식입니다. 비율이 실제와 다르면 엉뚱한 데서 병목을 찾게 됩니다.
3. 기준선을 잽니다. 사용자 50명 정도로 먼저 돌려 평상시 응답 시간을 기록해 둡니다.
4. 단계적으로 올립니다. 처음부터 2000명을 밀어 넣지 않고 200, 500, 1000, 2000 으로 나눠 각 구간을 5분에서 10분씩 유지합니다. 이렇게 해야 몇 명부터 꺾이는지가 보입니다. 한 번에 밀어 넣으면 "죽었다" 는 사실만 남습니다.
5. 결과를 읽습니다. 평균 응답 시간은 거의 쓰지 않습니다. 열 명 중 아홉 명이 0.2초에 받고 한 명이 20초를 기다려도 평균은 2초로 나오기 때문입니다. 느린 쪽 5퍼센트를 잘라 보는 값을 같이 봅니다. 오류가 난 요청의 비율과 그때 서버의 처리 부하·메모리도 함께 기록합니다.
6. 가장 먼저 꺾인 곳을 고치고 다시 돌립니다. 병목은 전체 속도를 혼자 결정해 버리는 가장 느린 구간이라, 거길 넓히기 전에는 다른 데를 손봐도 전체 숫자가 움직이지 않습니다. 연결 수가 모자랐다면 상한을 올리고, 같은 질의가 반복되고 있었다면 캐싱을 붙이고, 서버 대수가 모자랐다면 로드 밸런서 뒤에 대수를 더합니다.

고친 뒤 다시 돌리면 병목이 다음 자리로 옮겨 갑니다. 이게 정상입니다. 목표 숫자를 넘길 때까지 이 순환을 반복합니다.

쓸 자리는 몰릴 시점을 미리 아는 경우입니다. 대형 고객사 전사 도입, 광고 집행 시작일, 신규 기능 공개, 결제일이 몰리는 매달 말처럼 날짜가 잡혀 있으면 그 전에 돌려 봅니다.

반대로 한계도 분명합니다.

1. 만든 요청은 진짜 사용자가 아닙니다. 도구가 만드는 것은 정해진 순서를 반복하는 요청이라, 사람이 중간에 멈추거나 뒤로 가거나 탭을 열어 두는 행동은 들어 있지 않습니다. 그래서 통과했다고 실제 트래픽에서 안전하다고 단정하지 못합니다.
2. 환경이 다르면 숫자가 다릅니다. 시험용 환경이 운영 환경의 절반 사양이면 나온 값을 두 배로 늘려 읽고 싶어지지만 그렇게 맞아떨어지지 않습니다. 운영과 같은 사양에서 재는 것이 가장 정확하고, 그러려면 사람이 적은 새벽에 돌리는 준비가 따로 듭니다.
3. 바깥 서비스를 함께 두드리게 됩니다. 결제사나 문자 발송처럼 남의 서버를 부르는 구간은 우리 쪽 부하 테스트에 끌려 들어가면 상대편에 장애를 냅니다. 그 구간은 흉내만 내는 가짜로 바꿔 두고 돌립니다.

"다음 주 도입 전에 2000명으로 한 번 돌려 보죠."

몰릴 날짜가 정해져 있으니 그 전에 버티는지 확인하자는 제안입니다.

"1000명까지는 괜찮은데 1500에서 꺾여요."

한계 지점을 찾았고 그 구간에서 무엇이 먼저 무너지는지를 봐야 한다는 뜻입니다.

"평균 말고 상위 5퍼센트 잘라낸 값으로 봅시다."

느린 요청이 평균에 묻히고 있으니 실제로 기다린 사람 기준으로 읽자는 말입니다.

페이지덱에서는 그 사고 이후 태오가 분기마다 한 번씩 돌립니다. 새벽 세 시에 운영과 같은 사양의 환경을 띄우고 2000명까지 올려 본 뒤, 꺾인 지점과 그때 APM에 찍힌 구간별 시간을 정리해 공유합니다. APM 은 어느 요청이 어디서 시간을 썼는지 추적해 주는 모니터링 도구입니다.

부하 테스트를 한 번 통과하면 이제 괜찮다고 여기는 경우가 많습니다. 시험을 붙었으니 자격을 얻은 것 같지만, 이건 그 시점의 코드와 그 시점의 데이터양에 대한 측정입니다. 문서가 10만 건일 때 2000명을 버티던 서비스가 문서 300만 건이 되면 같은 인원에서 꺾입니다. 목록을 뽑는 질의가 훑어야 할 양이 서른 배로 늘었기 때문입니다. 한 번 재고 덮어 두면 반년 뒤에 같은 사고가 같은 자리에서 다시 납니다.

숫자가 안 나오면 서버를 늘리면 된다고 생각하는 것도 흔합니다. 대수를 늘리는 것이 가장 손쉬운 수단이고 오토스케일링을 켜 두면 자동으로 늘어나기까지 하니 그렇게 읽기 쉽습니다. 하지만 병목이 데이터베이스 한 대에 있으면 앞단 서버를 4대에서 12대로 늘려도 응답 시간은 그대로이고, 연결만 더 붙어 오히려 느려집니다. 부하 테스트의 값어치는 버티는 인원 수를 아는 데 있는 게 아니라 무엇이 먼저 무너지는지를 아는 데 있습니다. 그걸 모른 채 대수만 늘리면 요금만 올라갑니다.