Stress Test

성능 검증(Performance Test) 방법 중 하나인 스트레스 검증(Stress Test)에 대한 이야기를 해보려고 한다. 시스템의 성능을 가늠하고 측정하는 방법에는 여러 가지가 있을 수 있지만, 대표적으로 많이 활용하는 3가지는 부하 검증(Load Test), 스트레스 검증(Stress Test)^[각주:1], 내구성 검증(Endurance Test)이 있다. 클라우드 환경이 널리 퍼지면서 확장성 검증(Scalability Test)도 성능 검증의 범주에 포함되고 있다.

내 주변의 통계^[각주:2]는 늘 틀린다는 것을 알고있지만, 실무에서 많은 소프트웨어 개발자들을 만나다보면 시간부족을 이유로 검증과정을 대충 넘기는 것을 자주 볼 수 있었고, 테스트에 대해 잘 모르는 개발자들도 의외로 많았다. 성능 검증과 성능 분석을 혼용해서 말하기도 하고, 부하 검증과 스트레스 검증을 같은 것으로 생각하는 경우도 더러 있었다. 세세한 차이까지 잘 모를지라도 성능 검증을 하겠다는 의지를 갖는 것만으로도 고마운 일이지만, 성능검증을 하겠다고 생각했다면, 검증의 종류와 목적에 대해 이해하고 도구를 활용할 필요가 있다.

이번에는 스트레스 검증에 대해 이야기 해보려고 한다. 사람에게 스트레스란 만병을 유발하는 안좋은 긴장상태를 말한다. 우리가 흔히 스트레스를 받았다고 말하는 것은 사람이 감당할 수 없을만큼의 압박을 받았다는 뜻이다. 시스템에서의 스트레스도 같은 맥락을 가진다. 쉽게 생각해서, 시스템이 견딜 수 없는 상태가 되었을 때 어떤 이상동작을 보이는 지 확인 하는 것이다. 시스템이 용량의 한계를 넘었을 때 보이는 현상을 이해하는 것은 성능 검증에서 여러 통찰을 얻을 수 있게 해준다.

먼저, 시스템 한계초과 후 발생하는 시스템의 상태변화를 관찰할 수 있다. 이러한 관측은 운영환경에서 시스템이 한계상황을 맞이했을 때 어떻게 동작하는 지 예측할 수 있게 해준다. 또한 주변 시스템과 연계되어 있다면, 한계상황에서 주변 시스템에 끼치는 영향도 미리 파악해 볼 수 있게 해준다. 예를 들어 레디스(Redis)의 경우, 백업을 위해 시스템 메모리를 일시적으로 2배 가까이 사용한다^[각주:3]. 스트레스 검증을 통해서 레디스가 한계상황에 몰리는 현상을 미리 짚어볼 수 있었을 것이고, 그랬다면 'C사의 모든 판매제품 일시품절 사태'를 막을 수 있었을 지도 모른다. 다음, 한계상황이 언제 발생하고 그 전에 어떤 징후가 있는 지 살펴볼 수 있게 해준다. 운영환경에서 비슷한 상황이 되었을 때, 미리 취할 수 있는 대응 조치를 마련해 둘 수 있는 것이다. 만약, 사용자 요청과 메모리 사용량 증가 추세가 일정하다면, 어느 정도의 시간이 흐른 후에 한계치에 도달하는 것을 예측할 수 있다. 그렇다면 자동 조절(Auto-Scaling)이 동작하는 시간을 감안하여 미리 자동 확장 및 축소 조절이 실행되도록 정책을 정의할 수 있다. 운영환경에서 시스템 장애를 막을 수 있는 중요한 정보를 얻게 되는 셈이다. 다음, 시스템의 한계 값을 얻을 수 있다. 사실 이부분 때문에 많은 개발자들이 부하 검증과 스트레스 검증을 혼동하는 경우가 많다. 부하를 주는 것이 스트레스를 주는 것이라고 생각하기 때문이다. 부하 검증은 원하는 기준치의 부하를 견딜 수 있는 지 확인하는 것이고, 스트레스 검증은 시스템이 고장나는 기준을 확인하고 그 기준을 넘었을 때 나타나는 현상들을 확인하는 것이기 때문에 차이가 있다.

스트레스 검증은 시스템의 한계를 측정하고 그 이후에 나타날 고장 증상을 확인하는 점검이다. 그래서 시스템의 여러 고장 증상을 미리 확인하고 정상 동작 범위를 파악할 수 있도록 해준다. 당신이 소프트웨어 개발자이면서 냉장고 사용자라면, 냉장고 사용설명서에 있는 냉장고 사용환경과 고장증상 설명처럼 당신의 소프트웨서 작동범위와 고장증상 설명서를 만들어야 한다. 스트레스 검증은 소프트웨어의 작동환경과 정상 동작 범위 보고서를 작성할 수 있도록 해준다.

---

 

1. 압박 검증으로 번역하지는 않았다 [본문으로]
2. 주변인을 대상으로 직감에 기초한 근거 [본문으로]
3. 최근에는 25% 만 필요하도록 개선했다고 한다 [본문으로]