Skip to main content

4. 성능 테스트 패턴 및 안티패턴

해당 챕터에서는 성능 테스트에 좋지 않은 영향을 끼치는 몇 가지 일반적인 안티패턴을 설명하고, 이가 문제가 되지않도록 리팩터링하는 방법을 설명합니다.

성능 테스트 유형#

일반적으로는 아래의 성능 테스트가 존재합니다.

  • 지연 테스트(Latency test)
    • 종단 트랜잭션에 걸리는 시간은
  • 처리율 테스트(Throughput test)
    • 현재 시스템이 처리 가능한 동시 트랜잭션 개수는
  • 부하 테스트(Load test)
    • 특정 부하를 시스템이 감당할 수 있는가
  • 스트레스 테스트(Stress test)
    • 이 시스템의 한계점은 어디까지인가
  • 내구성 테스트(Endurance test)
    • 시스템을 장시간 실행할 경우, 성능 이상 증상이 나타나는가
  • 용량 계획 테스트(Capacity planning test)
    • 리소스를 추가한만큼 시스템이 확장되는가
  • 저하 테스트(Degradation)
    • 시스템이 부분적으로 실패할 경우 어떤일이 벌어지는가

지연 테스트#

  • 가장 일반적인 성능 테스트
  • 고객이 트랜잭션을 얼마나 기다려야하는지 측정
  • 제대로 정의하지 않는다면, 목적을 잃어버립니다.

처리율 테스트#

  • 지연 테스트 다음의 일반적인 성능 테스트
  • 어떤 측면에서 처리율은 지연과 동등한 개념입니다
  • 지연 분포가 갑자기 변하는 점을 한계점이라고 하며, 이를 최대 처리율이라고 합니다.
  • 시스템 성능이 급락하기전 최대 처리율 수치를 측정하는 것이 목표입니다.

부하 테스트#

  • 시스템이 이정도 부하는 견딜 수 있을까에 y/n을 경정하는 과정입니다.
  • 새로운 시장이나 신규 고객 유치 때, 트래픽이 상당할 때를 예측해서 진행합니다.

스트레스 테스트#

  • 시스템 여력이 어느 정도인지 알아보는 수단입니다.
  • 일정한 수준의 트랜잭션(특정 처리율)을 시스템에 계속 걸어놔서, 점점 더 동시 트랜잭션이 증가하고 시스템 성능이 저하됩니다.
  • 측정값이 나빠지는 시작하기 직전의 값이 바로 최대 처리율입니다.

내구성 테스트#

  • 메모리 누수, 캐시 오염, 메모리 단편화 등은 결국 CMF가 발생합니다.
  • 보통 이러한 문제를 해결하는 방법은 내구 테스트입니다.
  • 평균 사용률로 시스템에 일정 부하를 계속 줘서 모니터링하다가 갑자기 리소스가 고갈되거나 시스템이 깨지는 지점을 찾습니다.
  • 일반적으로 빠른 응다을 요구하는 시스템에서 많이 사용합니다.

용량 계획 테스트#

  • 스트레스 테스트와 여러모로 비슷합니다. (현재와 미래의 차이)
  • 업그레이드한 시스템이 어느 정도 부하를 감당할 수 있을지 알아보는 것입니다.
  • 예정된 계획의 일부분으로 실행하는 경우가 많습니다.

저하 테스트#

  • 부분 실패 테스트라고 합니다.
  • 저하테스트 도중에 봐야하는 측정값은 트랜잭션 지연 분포와 처리율입니다.
  • 대표적인 하위 유형으로 카오스 멍키라고 있습니다.
    • 진짜 복원성이 있는 아키텍처에서는 어느 한 컴포넌트가 잘못돼도 다른 컴포넌트까지 연쇄적으로 무너뜨리는 일은 없어야합니다.
  • 운영 환경에서 라이브 프래세스를 랜덤으로 죽여보면서 테스트하며 검증합니다.

기본 베스트 연습 예제#

기본적으로 세가지 기본 원칙에 따라 결정합니다.

  • 나의 관심사가 무엇인지 식별하고 그 척정 방법을 고민합니다.
  • 최적화하기 용이한 부분이 아니라, 중요한 부분을 최적화합니다. (쉽게 측정 가능한 양에 큰 의미를 부여하는 실수를 저지르면 안됩니다.)
  • 중요한 관심사를 먼저 다룹니다.

하향식 성능#

  • 전체 애플리케이션의 성능 양상부터 먼저 알아보는 접근 방식입니다.

다만, 이를 극대화하려면 테스트팀이 테스트 환경을 구축한 다음 무엇을 측정하고 무엇을 최적화해야하는지, 어떻게 개발 주기에 적용할지를 이해해야합니다.

테스트 환경 구축#

테스트 환경 구축은 테스트 팀이 가장 먼저해야하는 일이며, 가급적 모든 면에서 운영환경과 똑같이 복제해야합니다. (운영 환경과 많이 차이가 나는 성능 테스트 환경에서는 쓸모있는 결과를 못 얻을 확률이 높습니다... 현실은 어렵지만)

성능 요건 식별#

성능을 평가하는 지표는 코드 관점에서 생각하는 것이 아니라, 시스템을 전체적으로 바라보는 것이 중요합니다. 이렇게 최적화하려는 핵심 지표를 성능 비기능 요건(NonFunctional Requirement, NFR)이라고 합니다.

자바에 특정한 이슈#

JVM의 경우에도 신경써야하는 요소가 있습니다. 특히 JIT 컴파일은 중요한 뿐이며, 최신 JVM은 어떤 메서드를 JIT 컴파일해서 최적화한 기계어로 변환할지 분석해야합니다. JIT 컴파일 안하기로 결정된 메서드는 다음 중 하나입니다.

  • JIT 컴파일할 정도로 자주 실행되는 메서드가 아닙니다.
  • 메서드가 너무 크고 복잡해서 도저히 컴파일 분석을 할 수 없습니다.

SDLC 일부로 성능 테스트 수행하기#

수준이 높은 팀일수록 성능 테스트를 전체 SDLC(Software Development LifeCycle, 소프트웨어 개발주기)의 일부로서 수행하며 특히 성능 회귀 테스트(Performance regression testing)을 상시 수행합니다.


성능 안티패턴 개요#

안티패턴은 소프트웨어의 좋지 않는 패턴입니다. 이러한 잘못된 패턴을 분류하고 유형화함을 통해서 팀원들이 서로 소통하고, 안티패턴을 제거할 수 있도록 패턴 언어(pattern language)를 개발합니다.

이러한 잘못된 패턴들이 생기는 이유는 5개로 분류할 수 있습니다.

지루함#

지루하다고 맞지 않는 기술을 억지로 끼워넣는 경우가 존재합니다.

이력서 부풀리기#

이력서를 부풀리기 위해서, 프로젝트를 불필요한 방향으로 갈 때가 존재합니다.,

또래 압박#

팀원들이 기술을 결정할 때 관심사를 분명히 밝히지 않고 충분희 논의 없이 진행하는 경우에도 발생할 수 있습니다.

이해 부족#

지금 사용하는 툴의 기능도 온전히 모르는데, 새로운 툴로 문제를 해결하는 경우가 있습니다. 하지만 이런 것은 기술복잡도를 높이기 때문에 복잡도를 높익는 것과 현재 툴 사이의 균형을 맞추는 것이 중요합니다.

오해와 있지도 않은 문제#

문제 자체를 제대로 이해하지 못한채 오로지 기술을 이용해서 문제를 해결할려는 사람도 있습니다. 이는 성공확률도 좋지 않으며, 성능 수치를 측정도 안했기 때문에 문제의 본질을 정확하게 이해할 수 없습니다.


성능 안티패턴 카탈로그#

갖가지 성능 안티패턴을 유형별로 간략히 소개합니다.

  • 화려함에 사로잡히는 경우
  • 단순함에 사로잡히는 경우
  • 성능 튜닝에 관심이 있는 경우
  • 민간 튜닝에 관심이 있는 경우
  • 안되면 조상 탓
  • 숲을 못 보고 나무만 보는 경우
  • 내 데스크톱이 UAT인 경우
  • 운영 데이터처럼 만들기는 어려워라고 말하는 경우

인지 편향과 성능 테스트#

환원주의#

  • 시스템을 아주 작은 조각으로 나누어서 그 구성 파트를 이해하면 전체 시스템도 다 이해할 수 있다는 분석주의적 사고방식입니다.
  • 그러나, 복잡한 시스템에서는 그렇지 않습니다.

확증 편향#

  • 확증 편향은 성능 면에서 중대한 문제를 초래하거나 애플리케이션을 주관적으로 바라보게 합니다.
  • 보통 강력한 동기로 인해서 진행이 되기 때문에 거스르기가 어렵습니다.

행동 편향#

  • 시스템이 예상대로 작동하지 않는 상황, 또는 아예 중단된 시간 중에 발현되는 편향입니다.

위험 편향#

  • 위험을 피하고 변화를 거부하는 본성에 따라 발생합니다.

엘스버스 역설#

  • 인간이 확률을 이해하는 데 서투른지를 잘 보여주는 사례입니다.

마무리#

성능 결과를 평가할 때는 데이터를 적절한 방법으로 처리하고 비과학적이거나 주관적인 사고에 빠지지 않도록 조심해야합니다.

Edit this page
Last updated on