성능 테스트
좋은 성능테스트는 정랑적이다. 어떤 질문을 던져도 실험결과를 토대로 수치화한 답변을 내놓을 수 있어야 한다.
성능 테스트 종류
지연테스트
고객이 트랜잭션을 얼마나 오래 참고 기다려야 하는지 측정하는 것
- 단순 평균값은 지연을 측정하는 지표로 소용이 없다
➡️ 개선해야 할 것은 오래 걸리는 트랜잭션이므로 p95, p99 값을 확인한다
p95, p99: 백분위 값(각각 95%, 99%)
시스템의 일반적인 성능뿐만 아니라 극단적인 경우(예: 높은 부하 또는 이상 상태)에서의 성능을 이해하는 데 중요하다
처리율 테스트
시스템이 단위 시간당 처리할 수 있는 최대 처리율을 결정하는 것
- 특정 부하에서 지연분포가 갑자기 변한다면(한계점, 변곡점) 이것이 최대 처리율 이다
부하 테스트
시스템이 이정도 부하를 견딜수 있는지/없는지
- 어떤 부하 수준에서 성능 저하나 오류가 발생하는지를 확인
- 임계치가 초과 하는 그 시점까지 진행한다
스트레스 테스트
일정한 수준의 트랜잭션(특정 처리율)을 시스템에 계속 걸어두고 언제 성능이 저하되는지 확인
- 내구성 테스트이다
- 임계치가 초과 되었을 때 복구되는지 테스트한다
- 내구테스트(Soak 테스트, spike 테스트를 포함한다)
내구 테스트
평균 또는 그 이상의 사용률로 시스템에 일정 부하를 계속 주며 리소스가 고갈되거나 시스템이 깨지는 지점을 찾는다
- 빠른 응답을 요구하는 시스템에서 많이 테스트 한다
용량 계획 테스트
업그레이드한 시스템이 어느 정도 부하를 감당할 수 있는지 테스트
- 예정된 계획의 일부분으로 실행
저하 테스트
복원테스트. 운영환경과 동등한 수준의 부하를 시스템에 가하고, 갑자기 시스템이 능력을 상실하는 시점에 벌어지는 일들을 확인한다
-
트랜잭션 지연 분포와 처리율을 측정해야한다
-
부분 실패 테스트 중에는 카오스멍키가 있다(넷플릭스 인프라 검증 프로젝트)
- 하나의 컴포넌트가 죽어도 잘 돌아가는지 확인하는 테스트
- 랜덤으로 프로세스를 하나씩 죽이면서 검증한다
베스트 프랙티스
쉽게 측정한 것 위주로 보고서를 작성하지 말고, 중요한 관심사에 대해 측정하자
하향식 성능
전체 Application의 성능 양상부터 먼저 알아보는 접근방식
- 테스트팀이 테스트 환경을 구축한 다음, 무엇을 측정하고 무엇을 최적화 하는지 팀원이 명확하게 이해해야 한다
테스트 환경 구축
테스트 환경은 가급적 운영환경과 동일하게 구성해야 한다
- application server, cpu수, os, java runtime version, Web Server, DB, 로드 밸런서, 네트워크 방화벽 등
- 실제 운영 환경에서 어떤일들이 일어날지 예측할 수 있어야 하므로 환경을 맞춰야 함
- 돈아까워서 미리 환경 안맞춰 놓고 나중에 운영환경에서 시스템 중단하지 말고, 테스트를 잘하자
성능 요건 식별
성능을 평가하는 지표는 코드 관점이 아니라, 시스템을 전체적으로 바라봐야 한다
- 최적화 하려는 핵심 지표를 성능 비기능 요건(NFR)이라 한다
ex) p95 트랜잭션 시간을 1--밀리초 줄인다, 평균 응답시간을 30%줄인다
자바의 특정 이슈
JVM은 성능 엔지니어가 잘 이해하고 주의깊게 살펴야 할 부분이 있다.
JIT 컴파일은 중요한 부분이어서 유심히 잘 살펴야 한다.
➡️ 어떤 메서드가 컴파일 중인지 로그를 남겨 살펴야 하고, 중요 메서드가 잘 컴파일 되고 있는지 확인해야 한다.
JIT 컴파일 하지 않는 메소드
- JIT 컴파일 할 정도로 자주 실행되는 메서드가 아닐 경우
- 메서드가 너무 크고 복잡하여 컴파일 분석을 할 수 없는 경우
SDLC(소프트웨어 개발 수명주기) 일부로서 성능 테스트 수행하기
성능 회귀 테스트를 상시 수행하기
회귀 테스트
기존 테스트를 반복하는 것
결함 수정 이후 새롭게 발견되는 버그가 있는지 확인하는 테스트
안티패턴
프로젝트 또는 팀의 좋지 않은 패턴. 왜 이런 패턴이 생길가?
➡️ 의외로 의사소통 같은 인적 요소가 원이이 될 때가 많다
지루함
지루한 프로젝트에서 간단히 구현할 수 있는 것을 필요 이상으로 복잡하게 구현한다
알려지지 않은 기술로 컴포넌트를 제작한다거나, 맞지도 않는 유스케이스에 억지로 기술을 욱여넣거나.
이력서 부풀리기
자신의 몸값을 높이기 위해 불필요한 기술을 덧대게 된다
또래 압박
경쟁심이 불타오르는 팀 분위기 개발이 광속으로 진행되는 듯 보이고자 제대로 따지지 않고 섣불리 중요한 결정을 내리는 것
이해 부족
시금 사용하는 툴의 기능도 온전히 알지 못하는데 무턱대로 새로운 울로 문제를 해결하려는 것
오해와 있지도 않은 문제
문제 자체를 이해하지 못하고 오로지 기술로 해결하려는 것
😅 읽다보니 너무도 공감되는...
안티패턴을 예방하려면?
팀원 모두 참여하여 기술 이슈를 활발히 공유하는 분위기를 적극 장려해야 한다.
불분명한 것에 대해선 사실에 근거한 증거를 수집해야 한다
성능 안티패턴 카탈로그
성능이 안나오네..? 뭐가 문제일까? 어떻게 고쳐야 할까?
🙅🏻♀️ 최신의 멋진 기술을 튜닝 타겟으로 정한다
🙅🏻♀️ 최신의 뜨고있는 기술을 숭배한다
🙆🏻♀️ 측정을 해보고 진짜 성능 병목점을 찾자
🙆🏻♀️ 팀원의 베스트 프랙티스 수준을 정하자
🙅🏻♀️ 객관적인 아픈부위를 들추려 하지 않고, 무작정 시스템에서 제일 간단한 부분만 파고든다
🙅🏻♀️ 처음 개발한 사람에게 성능을 봐달라고 한다
🙆🏻♀️ 측정을 해보고 진짜 성능 병목점을 찾자
🙆🏻♀️ 짝 프로그래밍을 하자
🙅🏻♀️ 성능 전문가를 채용했는데, 특정 이슈를 해결한 방법을 자기만 알고있고 절대 공유하지 않는다
🙆🏻♀️ 측정을 해보고 진짜 성능 병목점을 찾자
🙆🏻♀️ 새로 채용한 팀내 전문가가 팀내에 지식을 공유할 수 있도록 한다
🙅🏻♀️ 웹사이트에서 "마법"의 설정 매개변수를 발견하고 운영서버에 곧장 적용한다... 하지만 그 팁이 어떤 영향을 미칠지 모른다
🙆🏻♀️ 충분히 검증된 것들만 적용한다
🙆🏻♀️ 매개변수를 UAT(인수테스트)에 적용해본다
🙆🏻♀️ 데브옵스팀과 함께 설정 문제를 리뷰하고 토의한다
🙅🏻♀️ 정작 이슈와 관련없는 특정 컴포넌트를 문제삼는다
🙆🏻♀️ 정상적으로 분석한다
🙅🏻♀️ 변경 영향도를 파악하지 않고 일단 JVM 스위치를 변경해본다
🙆🏻♀️ 다음 절차를 따른다
- 운영계 성능 지표 측정
- UAT에서 한번에 스위치 하나씩 변경
- 스트레스를 받는 지점이 UAT와 운영계가 동일한지 확인
- 운영계에서 일반적인 부하를 나타내는 TC 확보
- UAT에서 스위치 바꾸면서 테스트
- UAT에서 다시 테스트
- 추론한 내용 팀원에게 리뷰받기
- 내가 내린 결론을 다른사람과 공유하기
🙅🏻♀️ UAT 환경을 운영환경과 동일하게 설정하려면 돈이 많이든다...
🙆🏻♀️ 서비스 중단 비용과 고객 이탈로 인한 기회비용을 잘 따져본다
🙆🏻♀️ UAT 환경은 운영환경과 동일하게!
🙅🏻♀️ UAT환경에서 운영환경과 맞게 데이터를 만드는건 정말 삽질이야
🙆🏻♀️ 운영데이터를 UAT로 이전하는 프로세스에 시간과 노력을 투자하자
성능 테스트시 주의할 점
주관적인 사고에 빠지지 않도록 조심하자!
