얼마 전 회사에서 만든 gRPC 서비스의 성능 테스트를 진행했다. 이유는 현재 시스템 상태에서 특정 조건의 DB 데이터를 count 하는 기능이 있었는데, count 쿼리 특성 상 DB 데이터가 많아지면 많아질수록 쿼리 속도가 선형적으로 증가하기 때문이다. (이런 경우는 Index로 해결되지 않는다.)
이런 경우에는 Workaround로 현재 DB 환경에서 count 의 쿼리가 데이터 양이 어느 정도의 수준까지 먼저 허용될지 확인하는 것이 중요하다. 그리고 해당 데이터가 적재되기 전까지 적절한 방법을 고민해서 시스템 업데이트를 해야한다.
아무튼 성능 테스트를 진행하면서 테스트 관련된 용어가 조금 헷갈렸는데, 그 이유는 평소 성능 테스트와 부하 테스트 용어를 별 생각없이 비슷한 개념으로 섞어서 사용했기 때문이다. 이참에 시스템 테스트에 대한 개념을 정리해봤다.
성능 테스트(Performance Test)
시스템이 특정 상황에서 어느 정도 수준의 성능을 보이는지 확인하는 테스트이다. 성능 테스트는 시스템의 결함을 찾는 것이 아니기 때문에 성공과 실패의 개념으로 결과를 분석하지 않는다. 현재 시스템의 정확하고 면밀한 객관적인 데이터 확보가 확보해서 성능에 대한 현재 상황을 이해하는 것이 중요하다. 예를 들면, 특정 시나리오 상황에서의 API의 평균 처리 속도를 파악하는 테스트가 성능 테스트로 볼 수 있다.
부하 테스트(Load Test)
임계 값 한계에 도달하는 순간까지 시스템의 부하를 지속적으로 증가하면서 진행하는 테스트이다. 보통 LoadRunner 등의 테스트 도구를 활용해서 다양한 부하 시나리오를 설정하고, 강도를 지속적으로 증가하면서 결과를 확인한다. 이 테스트의 목적은 부하를 증가시키면서 생기는 다양한 시스템의 한계를 찾아내는 것이 목표인데, 버퍼 오버플로우, 메모리 누수, JVM의 Garbase Collection 동작 확인, DB 병목점 확인 등을 생각하면 된다. 각 상황에서의 최대 상한 값을 확인해서 각각의 시나리오에 대한 계획을 세우는 것이 최종 목표이다. 예를 들면, 서비스 오픈 이벤트를 대비한 최대 부하 확인, 무료 경품 이벤트로 인한 시스템 부하 대비 등을 위해 진행하는 테스트로 적절하다.
스트레스 테스트(Stress Test)
시스템이 과부하 상태에서 어떤 동작을 보이는지 확인하는 테스트이다. 과부하 상태에서 모니터링 도구는 정상적으로 동작하는지, 시스템의 Failover는 적용되는지, SPoF 혹은 보안 상의 문제가 존재하는지 등을 확인한다. 예를 들면, 시스템 과부하 상태에서 모니터링의 알림이 잘 오거나 시스템의 Auto Scaling 계획이 잘 동작하는지 등을 확인하는 테스트로 적절하다.
'개발 이야기 > ETC' 카테고리의 다른 글
Gradle Wrapper란? (0) | 2021.03.23 |
---|---|
임의(Arbitrary)값과 무작위(Random)값은 어떻게 다를까? (0) | 2021.03.18 |
[기타] 병행(Concurrency)과 병렬(Parallelism)의 차이에 대해서 (2) | 2021.02.24 |
[기타] Retry 전략에 대해서(Exponential Backoff, Jitter) (5) | 2021.02.23 |
[기타] 개발 환경(Phase)이란 무엇일까? (0) | 2021.02.22 |