API는 모든 기능 테스트를 통과하더라도 프로덕션 환경에서는 실패할 수 있습니다. 올바른 데이터를 올바른 상태 코드로, 올바른 스키마에 따라 반환하더라도 수천 명의 사용자가 한 번에 접속하는 순간 작동이 멈출 수 있습니다. 기능 테스트는 API가 올바르다는 것을 알려줍니다. 성능 테스트는 API가 올바르고 실제 트래픽을 견딜 만큼 충분히 빠르다는 것을 알려줍니다.
이 가이드는 API 성능 테스트가 무엇인지, 중요한 테스트 유형, 주목해야 할 지표, 그리고 Apidog에서 성능 테스트를 단계별로 실행하는 방법을 설명합니다.
API 성능 테스트란 무엇인가
API 성능 테스트는 API가 부하 하에서 어떻게 작동하는지 측정합니다. 즉, 얼마나 빨리 응답하는지, 얼마나 많은 요청을 처리할 수 있는지, 그리고 언제 성능이 저하되거나 중단되는지를 측정합니다. 응답이 올바른지 여부는 중요하지 않습니다. 그것은 기능 테스트의 영역입니다. 중요한 것은 시스템이 압력을 받을 때 응답이 빠르고 안정적으로 도착하는지 여부입니다.
목표는 사용자가 한계에 도달하기 전에 그 한계를 찾는 것입니다. 모든 API에는 응답 시간이 길어지고, 오류가 발생하거나, 서비스가 응답하지 않는 지점인 한계가 있습니다. 성능 테스트는 통제된 환경에서 그 한계를 찾아낼 수 있도록 하여, 한계를 높이거나, 그에 맞춰 용량을 계획하거나, 적어도 한계가 존재한다는 것을 알게 합니다.
API는 결정적이고 호출 속도가 빠르기 때문에 성능 테스트에 좋은 대상입니다. 렌더링할 브라우저도, 기다릴 UI도 없습니다. 요청을 보내고 응답을 측정합니다. 이것은 API 성능 테스트가 전체 엔드투엔드 부하 테스트보다 실행 비용이 저렴하고 더 안정적이라는 것을 의미합니다.
성능 테스트의 유형
"성능 테스트"는 포괄적인 용어입니다. 그 아래에는 각각 다른 질문에 답하는 여러 가지 개별적인 테스트 유형이 있습니다.
부하 테스트는 실제로 예상하는 트래픽, 즉 정상 및 최대 요청 볼륨을 적용하고 API가 허용 가능한 응답 시간 내에 이를 처리하는지 확인합니다. 이것은 대부분의 팀이 가장 먼저 실행하는 기준 테스트입니다.
스트레스 테스트는 예상 트래픽을 초과하여 API가 성능 저하를 보이거나 실패할 때까지 부하를 증가시킵니다. 목표는 한계점을 찾고, 그것이 어떻게 실패하는지 확인하는 것입니다. 우아하게 느려지는지, 아니면 오류를 반환하고 데이터를 손실하는지 등입니다.
스파이크 테스트는 플래시 세일이나 바이럴 상황에서 발생하는 것과 같은 갑작스럽고 급격한 트래픽 증가를 적용하고 API가 이를 흡수하는지 아니면 붕괴하는지 확인합니다. 꾸준한 부하를 처리하는 시스템도 스파이크에는 실패할 수 있습니다.
소크 테스트(내구성 테스트라고도 함)는 메모리 누수, 연결 풀 고갈, 디스크를 채우는 로그 파일과 같은 느린 문제를 노출하기 위해 몇 시간 또는 며칠 동안 중간 정도의 부하를 유지합니다. 이러한 문제는 5분짜리 부하 테스트에서는 절대 나타나지 않습니다.
스모크 테스트는 가벼운 사전 점검입니다. 즉, 길고 비용이 많이 드는 실행에 착수하기 전에 API와 테스트 설정이 작동하는지 확인하기 위한 소량의 부하 테스트입니다.
대부분의 팀은 최소한 부하, 스트레스, 소크 테스트가 필요합니다. 트래픽이 급증하는 경우 스파이크 테스트가 중요합니다.
중요한 지표
성능 테스트는 숫자를 생성합니다. 다음은 읽어야 할 숫자들입니다.
응답 시간은 API가 요청을 수신, 처리 및 반환하는 데 걸리는 시간입니다. 평균뿐만 아니라 백분위수를 살펴보세요. 평균은 건강해 보일 수 있지만, 가장 느린 요청의 5%와 1%에 해당하는 95번째 및 99번째 백분위수는 용납할 수 없을 수 있습니다. 실제 사용자는 지연을 느낍니다.
처리량은 API가 초당 완료하는 요청 수입니다. 연결된 사용자 수와 관계없이 시스템의 실제 용량을 알려줍니다.
동시 사용자 또는 가상 사용자는 테스트가 시뮬레이션하는 동시 호출자 수입니다. 용량은 종종 응답 시간이 예산을 초과하기 전에 API가 유지할 수 있는 최대 동시성으로 표현됩니다.
오류율은 부하 하에서 실패하는 요청의 비율입니다. 빠르기는 하지만 높은 동시성에서 500 오류를 반환하기 시작하는 API는 여전히 테스트에 실패한 것입니다.
서버의 CPU 및 메모리와 같은 자원 활용률은 성능이 저하되는 이유를 알려줍니다. CPU가 100%인 상태에서 응답 시간이 길어진다면 컴퓨팅 자원에 제약이 있는 것입니다. CPU가 유휴 상태인데 대기 시간이 증가한다면 병목 현상은 다른 곳에 있으며, 종종 데이터베이스나 다운스트림 호출일 수 있습니다.
좋은 성능 보고서는 이러한 요소들을 함께 연결합니다. 이 동시성에서 처리량은 최고치를 기록했고, 95번째 백분위수 응답 시간은 이러했으며, 오류율은 그러했습니다.
Apidog에서 API 성능 테스트를 실행하는 방법
Apidog는 API를 설계하고 기능적으로 테스트하는 동일한 작업 공간에 부하 테스트 기능을 내장하고 있으므로, 별도의 도구가 필요하지 않습니다.
1단계: 테스트할 엔드포인트 또는 시나리오를 선택합니다. 단일 중요 엔드포인트를 선택하거나, 로그인 후 데이터 가져오기와 같은 실제 사용자 흐름을 모방하는 다단계 테스트 시나리오를 선택합니다. 현실적인 흐름을 테스트하면 단일 엔드포인트를 개별적으로 반복해서 호출하는 것보다 더 정직한 숫자를 얻을 수 있습니다.
2단계: 먼저 기능적으로 통과하는지 확인합니다. 어설션과 함께 요청을 한 번 실행합니다. 잘못된 데이터를 반환하는 엔드포인트를 부하 테스트하는 것은 아무런 가치가 없습니다. 속도를 측정하기 전에 정확성을 먼저 해결하십시오.
3단계: 부하를 구성합니다. 가상 사용자 수와 테스트 기간을 설정합니다. Apidog를 사용하면 모든 사용자가 한 번에 접속하는 대신 시간이 지남에 따라 사용자가 점진적으로 증가하도록 시뮬레이션할 수 있으며, 이는 더 현실적인 그림을 제공하고 성능이 저하되는 동시성 수준을 정확히 파악하는 데 도움이 됩니다.
4단계: 테스트를 실행합니다. Apidog는 부하를 실행하고 응답 시간, 처리량, 오류율 및 동시성이 증가함에 따라 각 지표가 어떻게 변하는지 실시간으로 보고합니다. 부하보다 응답 시간이 더 빨리 증가하기 시작하는 변곡점을 주시하세요.
5단계: 결과를 읽고 병목 현상을 찾습니다. 300명의 동시 사용자에서 95번째 백분위수 응답 시간이 예산을 초과하면 현재 한계점입니다. 원인을 이해하기 위해 서버 CPU 및 메모리와 교차 참조하십시오. 해결 후 다시 실행하여 한계점이 이동했는지 확인하십시오.
6단계: 더 무거운 요구 사항의 경우 JMeter로 내보냅니다. 단일 시스템을 넘어 분산 부하 생성이 필요한 경우 Apidog는 시나리오를 JMeter로 내보낼 수 있으므로, 부하 소스를 확장하면서 동일한 테스트 정의를 유지할 수 있습니다.
이미 가지고 있는 엔드포인트에 대해 첫 번째 부하 테스트를 실행하려면 Apidog를 다운로드하십시오.
실제 성능 결과 읽기
해석 없는 숫자는 잡음일 뿐입니다. 구체적인 실행을 예로 들어 보겠습니다. 5분 동안 가상 사용자를 0명에서 500명으로 증가시키면서 GET /products를 부하 테스트합니다.
처음 200명의 사용자에게는 95번째 백분위수 응답 시간이 약 180ms로 꾸준히 유지되고 처리량은 부하에 비례하여 증가합니다. 이것은 건강한 구간입니다. API는 잘 작동하고 있습니다. 대략 280명의 사용자에서 95번째 백분위수 시간이 240ms, 400ms, 900ms로 증가하기 시작하고, 처리량은 증가하는 대신 정체됩니다. 이 정체는 API가 한계점에 도달했다는 신호입니다. 이제 사용자를 더 추가해도 더 많은 작업을 완료하는 것이 아니라 응답만 느려집니다. 420명을 넘어서면 요청이 시간 초과되기 시작하면서 오류율이 1%를 초과합니다.
결과는 구체적입니다. 이 API는 200ms 예산 내에서 약 250명의 동시 사용자를 편안하게 서비스할 수 있습니다. 실제 한계점은 약 280명 근처이며, 420명 정도에서 실패하기 시작합니다. 예상 최대 트래픽이 200명의 동시 사용자라면 여유가 있습니다. 350명을 예상한다면, 출시 후가 아니라 출시 전에 해결해야 할 문제가 있는 것입니다.
이것이 성능 테스트가 제공하는 것입니다. "통과" 또는 "실패"가 아니라, API가 편안하게 작동하는 곳, 부하를 받는 곳, 그리고 고장나는 곳에 대한 명확한 지도를 제공합니다.
일반적인 API 성능 병목 현상
테스트가 한계점을 드러낼 때, 원인은 일반적으로 몇 가지 익숙한 범인 중 하나입니다.
느린 데이터베이스 쿼리가 가장 흔합니다. 색인화되지 않은 컬럼, N+1 쿼리 패턴 또는 누락된 쿼리 제한은 데이터 볼륨이나 동시성이 증가하는 순간 빠른 엔드포인트를 느리게 만듭니다. 서버 CPU가 낮은 상태에서 대기 시간이 길어진다면 먼저 데이터베이스를 의심해야 합니다.
블로킹 외부 호출은 가장 느린 종속성의 속도로 엔드포인트를 저하시킵니다. 결제 제공업체 또는 타사 서비스를 동기적으로 호출하는 API는 해당 서비스의 대기 시간과 중단을 상속받습니다.
연결 풀 고갈은 지속적인 부하 하에서 나타납니다. API가 데이터베이스 연결 또는 HTTP 클라이언트가 부족해지고 요청이 대기열에 쌓입니다. 이것은 고전적인 소크 테스트 결과입니다.
큰 응답 페이로드의 비효율적인 직렬화는 CPU를 많이 소모합니다. 클라이언트가 필요로 하는 것보다 더 많은 데이터를 반환하면 모든 응답을 구성하는 데 더 많은 시간이 걸리고 전송 속도도 느려집니다.
성능 테스트는 한계점이 어디에 있는지 지적하고, 서버 측 지표와 결합하면 왜 그런지 알려줍니다.
프로세스에 성능 테스트 구축
대규모 출시 전에 한 번 실행되는 성능 테스트는 유용합니다. 정기적으로 실행되는 성능 테스트는 성능이 조용히 저하되기 때문에 훨씬 더 가치가 있습니다. 새로운 데이터베이스 쿼리, 추가된 다운스트림 호출 또는 색인화되지 않은 컬럼은 기능 테스트에서 감지되지 않는 지연 시간을 추가할 수 있습니다.
중요한 엔드포인트에 대한 응답 시간 및 오류율 예산을 설정하고, 위반을 실패로 처리하십시오. 이는 깨진 어설션을 처리하는 것과 같습니다. CI/CD의 일부로 가벼운 부하 테스트를 실행하여 풀 리퀘스트에서 성능 저하가 드러나도록 하고, 무거운 스트레스 및 소크 테스트는 예정된 사전 출시 테스트를 위해 남겨두십시오.
성능 테스트를 기능 테스트와 함께 유지하십시오. 두 가지가 함께 존재하면 모든 API 변경 사항이 정확성과 속도 모두에 대해 확인되며, "작동한다"와 "충분히 빠르게 작동한다"는 별개의, 쉽게 잊혀지는 질문이 되는 것을 멈춥니다.
자주 묻는 질문
부하 테스트와 스트레스 테스트의 차이점은 무엇인가요? 부하 테스트는 예상 트래픽을 적용하고 API가 이를 처리하는지 확인합니다. 스트레스 테스트는 이를 넘어 한계점을 찾습니다. 부하 테스트는 정상 작동을 확인하고, 스트레스 테스트는 실패 모드를 매핑합니다.
평균 또는 백분위수 응답 시간을 봐야 하나요? 백분위수를 봐야 합니다. 평균은 느린 꼬리를 숨깁니다. 95번째 및 99번째 백분위수는 가장 운이 없는 사용자들이 실제로 경험하는 것을 보여주며, 이것이 불만을 야기하는 요소입니다.
백엔드가 완료되기 전에 API 성능 테스트를 할 수 있나요? 계약 및 설계를 테스트할 수 있지만, 의미 있는 대기 시간 숫자를 얻으려면 실제 인프라가 필요합니다. 초기 기능 작업에는 모의 서버를 사용하고, 실제 구현에 대해 부하 테스트를 실행하세요.
성능 테스트는 얼마나 자주 실행해야 하나요? 중요한 엔드포인트에 대한 모든 변경 사항에 대해 CI에서 가벼운 부하 테스트를 실행하고, 주요 출시 전에 전체 스트레스 및 소크 테스트를 실행하세요. 성능은 조용히 저하되므로, 한 번의 대규모 출시 전 실행보다는 정기적인 점검이 더 효과적입니다.