오늘 오랜 시간 성능 테스트를 해오신 분과 이야기를 하면서 많은 것을 깨달았다.
성능 테스트란 걸 태어나서 알게 된 건 창피하게도 회사에 입사하고 나서부터다.
업무가 성능테스트만 있는 게 아니라 완벽히 배우지는 못했지만 그동안 봐오면서, 성능 테스트는 단순히 우리의 서비스 아키텍처(시스템)가 얼마나 많은 사람들을 얼마의 시간 안에 안정적으로 처리할 수 있는지, 시스템 자원은 얼마나 사용했느지 등등 단순하게 생각했다.
하지만 잘못된 생각이였다.
가령 제공하는 서비스가 웹,앱이라고 생각해보자.
간단하게 딱 6개의 페이지가 있고 이런 페이지들에 여러 기능들이 붙어있다고 생각해보자.
1. 메인페이지
2. 로그인 페이지
3. 상품 페이지
4. 상품 상세 페이지
5. 주문페이지
6. 주문완료 페이지
1번 메인페이지에는 회사 로고, 검색할 수 있는 검색창, 로그인, 고객센터, 각종 상품 이미지 등 굉장히 많은 것들이 연결되어 있다. 당연히 메인 페이지는 서비스의 첫 시작에 보이기 때문에 회사의 입장에서 매출에 가장 영향력이 있을만한 상품들의 사진과 로그인 기능 등 많은 기능들이 있을 것이다.
2번 로그인 페이지에는 ID,PW를 입력하게 되어있고 로그인 버튼, 아이디 찾기, 비밀번호 찾기 등이 있을 거고 버튼을 누르면 DB를 찌르는 API가 연결되어 있을 것이다.
3번 상품 페이지는 고객이 특정 상품(바지,니트, 카디건 등)을 검색하고 그에 맞는 상품들이 나오는 페이지라고 생각해보자. 이 페이지 역시 여러 상품들의 이미지, 설명, 버튼들이 있을 것이다.
4번 상품 상페 페이지에는 고객이 특정 상품을 눌러서 그 상품에 대한 각종 정보들, 구매 버튼, 장바구니 버튼들이 있을 것이다.
5번 주문페이지는 아마도 고객이 특정 상품의 구매버튼을 누르고 들어간 화면이다. 배송 예정일, 수량, 사이즈, 상품명, 결제방법, 배송 주소, 결제 버튼 등 꽤 많은 정보들이 들어가 있고, 결정적으로 고객의 최종 결정이 이루어지는 페이지이다.
6번 주문완료 페이지는 고객이 주문을 완료했으니 감사합니다. 등의 문구와 주문번호 등이 나올 것이다.
자, 이제 시나리오를 생각해보자.
고객은 메인페이지에 들어와 둘러보다가 로그인을 한다. 그리고 관심 있는 상품을 검색한 뒤 상품의 상세 페이지를 들어가 색상과 사이즈 수량을 누른 후 구매하기 버튼을 누른다. 최종 결제 페이지에서 배송지 등 각종 정보를 확인하고 결제 버튼을 누른다. 고객은 주문 완료 페이지가 뜸과 동시에 다시 메인으로 가거나 쇼핑몰을 빠져나간다.
맨 위에 나열한 1~6번 url을 기반으로 실제 스크립트를 작성했다고 하자. 각 페이지 번호마다 트랜잭션을 설정하여 각 url페이지마다의 응답속도를 측정해본다고 하자.
첫 번째로 중요한 건, 부하의 비율이다. 회사에서 이벤트를 해서 평소보다 많은 사람들이 물건을 구경하거나 사러 들어왔다고 해보자. 대부분의 쇼핑몰들은 메인 페이지를 구경하는 사람이 특정 상품을 검색해서 보는 페이지보다 월등히 많다.
특정 상품을 검색해서 보는 페이지가 실제 물건을 결제하는 페이지에 머무르는 사람보다 월등히 높다.
즉, 크게 보면 하나의 웹사이트 일지 몰라도 실제 부하를 더 많이 주어야 하는 페이지와 덜 주어야 하는 페이지를 구분해야 한다. ( 물론, 회사마다 다를 것이다. 평소에 GA툴을 이용해 PV를 수집했을 것이다. 이 기록을 통해 결정해야 한다.)
두 번째로 중요한 건, 응답속도의 기준이다. 2가지 케이스를 생각해보자.
( case 1,2 두 case모두 총 60 tps 부하를 주며 페이지 순서대로 50%, 10%, 20%, 15%, 5% 비율로 tps를 나누었다고 가정한다. )
case 1. 6개 페이지 모두 3초가 나와서 평균 응답속도는 3초가 되었다.
case 2. 6개 페이지 평균 응답속도가 3초로 case 1과 똑같다.
하지만 1번 페이지: 1초
2번 페이지: 3초
3번 페이지: 2초
4번 페이지: 3초
5번 페이지: 3초
6번 페이지: 6초
가 나왔다고 해보자 얼핏 보면 모든 페이지가 일관성 있게 3초가 나온 case 1이 잘 짜인 아키텍처라고 할 수 있다. 하지만 이것은 비즈니스 관점에 따라 case 2가 훨씬 영리하게 설계했다고 볼 수 있다.
앞서 말했듯이 우리의 웹이나 모바일 서비스를 이용하고 가는 사람들의 대부분은 메인 페이지에 머무른다.
1번 메인 페이지에 대하여 case 1은 3초, case 2는 1초가 나왔다. 즉, 같은 사람들이 들어왔을 때 case 2는 더 빠른 속도로 자신들의 정보를 웹에 뿌린다. ( 흔히 로딩 시간이 2~3초가 넘어가면 고객은 쇼핑몰을 닫거나 새로고침을 계속 누른다...)
자, 그럼 case 1과 case 2가 제일 많이 차이나는 6번을 보자. 6번은 주문서 페이지에서 결제하기를 누른 순간부터 주문번호가 화면에 나타날 때까지의 응답속도를 나타낼 것이다.
case 1은 3초, case 6은 6초가 나왔다. 쇼핑몰의 경우 비즈니스를 잘 이해해야 한다. 고객은 메인에 들어오고, 상품을 검색하는 2가지 임무가 중요할 것이고 이 2가지 임무에 참을성이란 없다. 하지만 이미 물건을 사기로 마음먹고 카드번호를 입력하고 결제를 누르는 순간 고객의 임무는 끝이다. 또한 쇼핑몰의 입장에서도 이미 주문은 들어갔으며 매출도 올라갔다. 즉, 1번 메인 페이지만큼 6번 주문 완료 페이지는 고객의 구매에 큰 영향을 미치지 않는다는 것이다.
이렇게 자기 회사의 비지니스를 이해하고 좀 더 살펴봐야할 부분, 개선이 필요한 부분들을 찾아내야 한다.
물론 전체적으로 다 빠른 응답 시간이 나오면 좋겠지만, 매우 힘들고 수많은 이슈를 개선해야 하니깐....
오늘, 비록 다른 회사지만 나보다 훨씬 많은 경력을 가지신 분과 대화를 하면서 단순히 성능을 테스트하는 게 아니라, 우리의 비즈니스를 이해하고, 좀 더 전략적으로 성능 테스트를 한다면 개발팀에 더 좋은 피드백과 결과적으로 우리의 서비스 향상까지 이어질 수 있다는 생각을 가지게 되었다.
'성능테스트' 카테고리의 다른 글
| 성능테스트 종류 (0) | 2019.10.03 |
|---|---|
| Thread Dump는 무엇이고 언제 하는가? (0) | 2019.10.02 |
| 다시 시작 (0) | 2019.10.02 |
