아마존 웹 서비스 부하테스트 입문 시리즈
서론
최근 프로젝트를 진행하면서 부하테스트를 적용하기 위해 관련 내용을 공부하고, JMeter를 사용하여 테스트해보려고 했는데 잘 안됐다. JMeter는 GUI가 잘되어있어서 사용이 어렵지 않고, 실제로 몇 번 클릭만 하면 쉽게 부하를 일으킬 수 있는 도구이긴 했다. 하지만 다음과 같은 생각이 자꾸 들었다.
- 부하를 얼만큼 줘야하지? 동시 접속자 수가 많을수록 좋나? 200명이면 충분할까?
- 지표는 뭘 봐야하지? TPS, Response타임을 본다고 쳤을 때 이 항목들에 대한 목표 수치는 어떻게 세워야하지?
- TPS를 개선할 병목 지점을 도대체 어떻게 찾지? 찾으면 얼마나 개선해야하지?
부하 테스트라는 개념에 대해 익숙하지도 않았고, 왜 적용해야하는지와 어떻게 적용해야하는지에 대한 의문을 해결하지 못한데다 다른 일이 급해서.. 결국은 부하테스트를 제대로 적용하지 못했다. 프로젝트가 끝난 시점에는 부하테스트를 적용하지 못한 게 제일 아쉬웠다.
그래서 찾아보던 중 좋은 책을 발견했고, 한 번 읽어보면서 부하테스트와 더 친해져보려고 했다! 책 이름은 아마존 웹 서비스 부하 테스트 입문이다. 이번 게시글에서는 4장까지 읽은 후 후기를 써보려고 한다.
책을 읽기로 한 이유 + 목표
이 책에서는 부하 테스트가 왜 중요한지를 알아보고 부하 테스트의 목적과 부하 테스트를 어떻게 할 것인지, 시나리오는 어떻게 할 것인지, 부하를 어떻게 주어야 할지, 보고서 작성에 대한 가이드 등 부하 테스트의 시작부터 끝까지 설명하고자 한다.
책 초장에 다음과 같은 문장이 나오는데, 내가 선뜻 JMeter를 적용하지 못했던 이유들이 그대로 나와있었다. 부하 테스트에 대한 지식이 없는 사람도 읽기 좋게 쓰여있다고 나와있어서 한 번 읽어보기로 다짐했다.
목표
부하 테스트는 단순하게 사양에 따라 테스트 항목의 합격 여부만을 확인하는 것이 아니라 테스트를 진행하는 과정에서 시스템과 대화하면서 상태에 따라 개선 방법을 찾아가는 개발 과정의 일부다.
이 책을 다 읽은 후에는 부하테스트에 대한 지식을 왕왕 가지고 자신있게 우리 서비스를 테스트해보고 싶다. 그리고 서비스의 쿼리 등을 개선하면서 서비스의 성능을 높여보려고 한다.
1장. 부하 테스트의 문제와 웹 시스템의 실패 사례
1장에서는 잘못된 부하 테스트 진행과정을 스토리형식으로 보여준다. 서비스를 개발하는 회사가 고객에게 요청을 받고, 개발 후 부하테스트 보고서를 내는 과정까지 쭉 보여주는데 굉장히 잘 읽히고 부하테스트에 대한 흥미가 더 높아졌다. 아직은 부하테스트에 대한 지식이 부족하기 때문에 왜 특정부분이 문제가 되는지 의문이 생기면서, 책 뒷장이 너무 궁금해졌다.
또한 부하테스트를 제대로 진행하지 않고 서비스를 출시한 실제 실패사례를 보며, 부하테스트의 중요성을 깨닫게 되었다.
2장. 웹 시스템 설계 방법
부하테스트는 가용성을 확보하기 위한 수단 중 하나
2장에서는 가용성, 리던던시, 스케일업 등의 용어를 설명해주고, 웹 서비스의 가용성을 높이는 방법을 소개해준다. 또한 온프레미스와 클라우드 시스템을 비교하면서 AWS의 제품들도 소개해준다.
이 장을 통해서 확장 가능한 시스템을 위해 어떤 식으로 설계해야하는지 감을 잡을 수 있었다. 소개해준 AWS 제품들을 모두 사용하면 돈이 꽤 많이 나가겠지만 취준기간동안 한 번은 꼭 써보고 싶었다.
3장. 부하 테스트 기본 지식
부하 테스트의 최종적인 목적은 시스템 처리 능력을 계산하여 가용성을 높이는 것
3장에서는 온프레미스와 클라우드 시스템에서의 부하 테스트가 다르다는 걸 알려준다. 온프레미스는 구입할 하드웨어를 미리 선정하는 과정도 필요하기 때문에 서비스를 운영하기 전 미리 예측하는 과정이 들어가는데, 쉽지 않다는 게 느껴졌다.
그리고 클라우드 시스템은 알아서 확장이 될텐데, 왜 부하테스트를 해야하는지 의문이 잠시 들었는데 여기서 해결되었다. 클라우드 환경에서 실제 부하가 많이 발생했을 때 시스템 구성을 변경해도 성능이 향상되지 않는 경우가 많기 때문에 부하 테스트가 필수적이라고 한다! 특히 클라우드 시스템의 확장은 개발자가 아닌 사용하는 클라우드 서비스에 달려있기 때문에 확장이 잘 되는지 확인하는 게 중요하다고 하였다.
그리고 부하 테스트에서 사용되는 지표인 Throughput과 Latency에 대해서도 이해할 수 있었다. Throughput을 위해 병목지점을 찾는 게 부하테스트의 숙제라는 것도 알게되어 흥미로웠다. 테스트 서버에 부하를 테스트하지 않고 실제 대상 시스템에 부하를 주는게 중요하다는 것도 알게되었다.
4장. 부하 테스트 도구
4장에서 부하 테스트를 위한 도구가 3가지로 나뉜다는 것을 알게되었다. 부하 테스트를 위한 도구 세 가지는 다음과 같다.
- 부하 테스트 도구
- 모니터링 도구
- 프로파일링 도구
JMeter에서 자동으로 그려주는 Latency, TPS 그래프로도 충분할 줄 알았는데 생각해보니 병목지점을 찾기 위해서는 모니터링 도구와 프로파일링 도구가 필수였다. 그리고 부하 테스트 도구도 NGrinder와 JMeter밖에 몰랐는데 꽤 다양한 친구들이 있다는 걸 알게되었다. 시나리오가 필요한 경우, 많은 부하를 줘야하는 경우 등에 따라 도구를 선택하는게 필요하다는 걸 알았다.
SaaS 부하 테스트 도구를 피해야한다는 팁도 알게되어 좋았다. 왜 JMeter를 직접 깔아야하는지, 간편한 SaaS는 없나? 라는 생각을 한 번 한 적이 있었는데 정확한 부하테스트를 위해서는 실제 서버와 물리적으로 가까운 곳에 있어야 한다고 하였다. (네트워크 통신 지연을 줄이기 위해서)
그리고 부하테스트 도구 상의 부하와 운영환경에서 차이가 존재하고, 이를 고려해야한다는 사실도 알게되었다. 이 부분이 4장에서 가장 흥미로웠다. 부하테스트 서버에 부하가 올 수 있다는 점과, 테스트 클라이언트 동시 요청 수와 실제 동시 요청 수가 다를 수 있다는 것 등은 정말 생각도 못했다.
마치며..
시간이 늦어 4장까지밖에 못읽었지만 궁금증이 많이 해소되어 기분이 좋다. 많은 내용을 배울 수 있었고, 부하테스트를 어떻게 써야하는지 감이 조금 잡힌 것 같다. 뒷 장 내용도 얼른 읽고싶다.
