작성
·
97
0
안녕하세요! 최근 다시 고민이 있어 영상 보며 해소해 나가고 있는데, 몇가지 궁금증이 해소 할 곳이 없어 문의 드립니다.
사전 설명
배포는 완료되었고, 실 사용자 수는 없음.
하지만, 현재 서버의 최대 TPS와 다양한 성능 개선의 방법을 익히기 위함
시나리오는 어떤 기준으로 체크를 해 나가는게 나을까요? 단순 FE 클라이언트와 통신을 위한 api 서버라면, 화면 구성 기준으로 혹은, 실제 사용자 흐름 기준으로 시나리오를 작성해보면 될까요?
혹은, 다른 좋은 테스트 방법이 있을까요?
현재는, 모든 api 에 대해 기본적인 레이턴시 스펙 확인과 프론트 화면 기준 TPS 와 레이턴시를 확인하려고 합니다.
이렇게 구성 시, 사용자가 접할 수 있는 시나리오 중, 최악의 시나리오의 TPS 결과가 서버 최대 동접자 수로 판단?
현장에서 테스트 스크립트는 github 에 같이 올려 공유를 하게 하나요? 아니면 별도의 테스트 파일을 어딘가에 업로드 해서 팀원과 공유를 하게 되나요?
내용과 관련 없는 얘기지만... 현재 병목 지점을 명확하게 하기 위해, 모니터링 툴을 적용하려고 합니다. 취준생 관전에서 추천 하실 만한 툴이 있을까요?
현재 api 서버 인프라 구성은, mysql, redis, enginX, springboot 로 구성되어 있습니다.
고려하고 있는 조합은, Prometheus + Grafana
에, 여유가 된다면 스카우터 추가 생각하고 있습니다.
많은 질문 드려 죄송하고 좋은 강의 내용 감사합니다~!
답변 3
1
BeakGwa님 기다려 주셔서 감사합니다!
덕분에 잘 다녀왔습니다. 😀
질문 주신 내용에 대해 답변 드려볼게요.
시나리오는 어떤 기준으로 체크를 해 나가는게 나을까요? 단순 FE 클라이언트와 통신을 위한 api 서버라면, 화면 구성 기준으로 혹은, 실제 사용자 흐름 기준으로 시나리오를 작성해보면 될까요?
혹은, 다른 좋은 테스트 방법이 있을까요?
현재는, 모든 api 에 대해 기본적인 레이턴시 스펙 확인과 프론트 화면 기준 TPS 와 레이턴시를 확인하려고 합니다.
이렇게 구성 시, 사용자가 접할 수 있는 시나리오 중, 최악의 시나리오의 TPS 결과가 서버 최대 동접자 수로 판단?
-> 가능하다면 실제 사용자들이 서비스를 사용할 것 같은 형태로 시나리오를 작성해주시는게 좋습니다. 1-b에 적어주신 것처럼 프론트엔드에서 호출되는 API, 기타 API들을 구분하여 "최대한 실제에 가깝게" 시나리오를 구성할수록 좋습니다. 그러나 모든 API, 모든 유즈 케이스를 고려하여 시나리오를 작성할 수는 없기 때문에, 우리가 핵심적인 기능이라고 생각되는 요소에 집중하는게 좋긴합니다.
예를들면, 인프런에서 할인 행사를 한다고하면 카카오톡, 이메일 등으로 이벤트 페이지의 링크를 발송하겠죠? 그럴 때 이벤트 페이지로 높은 트래픽이 들어올겁니다. 그럼 이벤트 페이지로 유입이 예상되는 유저들의 수를 계산해보고, 예상되는 트래픽을 이벤트 페이지로 접속했을 때 호출되는 API들을 기준으로 시나리오를 작성해보는겁니다.
통상적으로 지금 남겨주신 Q&A의 경우 트래픽이 높진 않을겁니다. 따라서 상대적으로 성능 테스트 우선순위는 위의 할인 행사 이벤트 페이지보다는 낮을겁니다.
일부러 최악의 케이스를 가정할 필요는 없지만, 보통 실제 예상되는 TPS보다 3~4배 정도의 양으로 테스트 해보시는게 좋긴합니다. 그렇게 됐을 때도 문제없이 트래픽을 처리할 수 있어야 예상보다 높은 트래픽이 오더라도 문제없이 처리할 수 있을겁니다.
현장에서 테스트 스크립트는 github 에 같이 올려 공유를 하게 하나요? 아니면 별도의 테스트 파일을 어딘가에 업로드 해서 팀원과 공유를 하게 되나요?
-> 필요하다면 GitHub에 올려서 공유할 수도 있겠지만, 보통 nGrinder 같은걸 공용으로 구축해두고 사용하는 경우가 많은데요, 이때 nGrinder 내에 자체적으로 스크립트를 저장하는 기능이 있습니다. 폴더, 파일 형태로 나눠서 저장해둘 수 있어요. 이걸 주로 활용하고 있긴 합니다.
내용과 관련 없는 얘기지만... 현재 병목 지점을 명확하게 하기 위해, 모니터링 툴을 적용하려고 합니다. 취준생 관전에서 추천 하실 만한 툴이 있을까요?
현재 api 서버 인프라 구성은, mysql, redis, enginX, springboot 로 구성되어 있습니다.
고려하고 있는 조합은, Prometheus + Grafana 에, 여유가 된다면 스카우터 추가 생각하고 있습니다.
-> 1번과 함께 이야기 드릴까 하다가 여기서 이야기 드립니다.
성능 테스트와 개선을 진행할 때 유용한 2가지 도구가 있는데, 적어주신 Prometheus + Grafana 같은 '메트릭 수집 도구'와 다른 하나는 적어주신 스카우터나 Pinpoint 같은 APM 입니다. Prometheus + Grafana를 통해 메트릭을 수집해보면서, 트랜잭션 정보 같은건 APM의 도움을 받으시면 좀 더 효율적으로 성능 테스트와 개선을 진행해보실 수 있을겁니다. 메트릭 수집 도구만으로는 분명 한계를 느끼실겁니다.
1번이랑 이어서 더 이야기 드리고 싶은건, 애초애 취준생에게는 실제 서비스 같은 높은 트래픽도 없고 높은 트래픽을 감당할 수 있는 높은 비용의 인프라(서버)도 없습니다. 따라서 예상되는 TPS 자체를 정하는게 어려운 일입니다. 따라서 어느정도 시나리오를 만드시고, APM과 메트릭 수집 도구들을 활용하여 성능 테스트와 개선을 진행해보시기 바랍니다.
이렇게 APM, 메트릭 수집 도구에서 병목을 찾아내고 개선하는 과정 그 자체가 취준생이 해볼 수 있는 현실적이고 좋은 성능 테스트, 성능 개선 학습 방법이라고 생각됩니다.
질문에 대한 답변은 여기까지고, 또 궁금한 내용 있으면 질문 남겨주세요~
감사합니다.
0
안녕하세요, 인프런 AI 인턴입니다. BeakGwa님.
성능 테스트 시나리오 작성과 관련하여 문의 주셨군요. 질문에 대한 답변과 관련한 자료를 몇 가지 정리해 보았습니다.
Prometheus + Grafana
는 고성능 모니터링 및 시각화 툴로 인기가 높습니다. 시스템의 메트릭을 수집하고 시각화하여 병목 현상을 파악하고 성능을 최적화할 수 있습니다.Scouter
는 서버에서 운영 중인 애플리케이션의 성능을 실시간으로 모니터링하는 데 유용한 툴입니다. CPU 사용량, 메모리 사용량, 트랜잭션 속도와 같은 다양한 성능 지표를 제공합니다.아래 유사한 질문과 답변을 참고하면 도움되실 수 있습니다:
- 무중단 배포시 질문 - Nginx를 이용한 성능 관리와 모니터링 방법에 대해 논의됩니다.
- 로그인 한 유저만 접근 가능한 API도 부하테스트가 필요할까요? - 부하 테스트의 필요성과 접근 방법에 대해 논의됩니다.
저는 질문자님의 이해를 돕고자 지식공유자님의 기존 답변을 참고하여 유사한 답변 링크를 추천해드리고 있습니다. 현재 베타 기능으로 답변이 만족스럽지 않을 수 있는 점 양해 부탁드립니다. 🙏 추가적으로 궁금한 점이 있으시면, 이어서 질문해 주세요. 곧 지식공유자께서 답변해 주실 것입니다.
감사합니다! 현재는 prometheus + grafana 를 통해 mysql, jvm, hikari 와 관련된 매트릭 정보를 수집하고있습니다.
또한 현재 한정된 인프라에 대해 최대한의 효율을 내는 cp 들을 밸런싱 해보고 있습니다.
말씀주신대로, APM 없이 판단이 안되는 부분이 있긴 하네요 ㅠㅠ
생각보다 어렵지만 재밌는 주제네요!
좋은 답변 + 강의 감사합니다!! 늦었지만 새해복 많이 받으세요~