인프런 커뮤니티 질문&답변
작성한 질문수
웹소켓을 이용한 채팅시스템에서 부하테스트를 어떻게 진행해야할까요?
해결된 질문
작성
·
19
·
수정됨
0
안녕하세요.
취준하고있는 예비 개발자입니다.
개인프로젝트를 진행하다가 여쭤보고 싶은게 있어 강의까지 구매하게 되었습니다.
가장 궁금한 질문은 '웹소켓을 이용한 채팅시스템에서 부하테스트를 어떻게 진행해야하는가?'입니다.
추가질문 및 부연설명을 위해 조금만 더 읽어주시면 감사하겠습니다.
현재 진행하고 있는 앱 개발 프로젝트 진행 중입니다.
기술스택은 서버는 코틀린,스프링이고, 클라이언트는 iOS(swift)와 안드로이드(Kotlin)로 구성했습니다.
http요청을 처리하는 서버(스프링 서버)는 단일 서버와 단일 데이터베이스로만 구성한 상황이고, 단일 인스턴스는 aws의 t2.micro를 이용하고 있습니다.
서버에는 nginx / next 서버(홍보용 홈페이지) / 스프링 서버 / github-runner 등의 프로세스가 실행 중에 있습니다.
클라이언트의 무한 재연결 로직의 문제로 인해 인스턴스 내부에서 'ss -s' 명령어를 이용해 소켓상태를 조회해본 결과, 소켓 tcp연결이 폭발적으로 증가하여 400개까지 증가한 상황이 있었습니다. 이 상황에서 소켓을 이용한 채팅뿐만 아니라 사용자 조회와 같은 http요청 모두 느려지는 것을 확인되었습니다.
하지만 재연결 로직을 수정하고 이후 tcp연결이 400(= 클라이언트 - nginx 200개 / nginx - 서버 200개)까지 증가하는 상황을 만들어봐야 또 문제가 발생하는지 확인할 수 있다고 생각했지만 200명의 테스터를 모을 수 없다고 생각했습니다.
또한, 채팅의 API를 하나 파고, ngrinder를 이용해 부하테스트를 요청하는 상황이 적합할까 생각했을 떄, 웹소켓 연결이 되지 않는 상황이라고 생각되어 적합하지 않다고 생각했습니다.
이런 상황에서 어떻게 테스트해볼 수 있을지 고민됩니다.
추가적으로 궁금한 점은
앱 개발에서 채팅시스템을 구축하는 상황이고, 대략 500~1000명을 수용해야한다면 어떤 기술을 적용해 채팅시스템을 구축하셨을 것 같나요?
실시간 통신하면 웹소켓정도 밖에 모르는 상황이었기에 웹소켓을 적용했지만서도 타당했는가? 적합했는가에 대한 의문이 여전히 남아있는 상황이라고 생각하기 때문에 질문드렸습니다.
t2.micro 서버는 얼만큼의 소켓연결까지 버틸 수 있는지 알고 싶습니다.
현재 서비스의 사전예약자가 80명 정도 되는 상황이라 t2.micro를 이용했을 때 서버가 터질까봐 우려스럽습니다. 그래서 서버 스펙을 확장을 고려하고 있는데, 취준생이기에 비용적인 측면에서 고려하지 않을 수가 없는 상황이라 '정말 확장하는게 맞을까?', '내가 능력이 부족한 게 아닐까?' 라는 생각이 들어 갈피를 못잡고 있는 상황이라 질문드렸습니다.
제 질문들이 대부분 인프라 확장의 타당성을 갖추기 위한 질문이라고 생각합니다. 혹시 인프라 확장을 위한 근거로써 어떤 지표가 타당성을 확보할 수 있다고 생각하시는지 궁금합니다.
긴 질문 읽어주셔서 감사합니다.
행복한 하루 되세요~
답변 1
0
안녕하세요 준영님 좋은 질문 주셔서 감사합니다. 사실상 쉽지 않은 질문이라서 여러가지 관점에서 대답을 드리면 좋을꺼같아요.
우선 테스트를 진행하는데에 있어서는 저는 개인적으로 노드 기반의 테스트 도구를 사용하였습니다.
대표적으로 k6 를 사용하여 간단한 스크립트 작성을 하면서 부하 테스트를 진행 할 수 있고, 이를 통해서 가상의 연결을 동시다발적으로 시뮬레이션을 하실수가 있습니다. 이 부분을 알아보시면 부하테스트를 하는데에 있어서 도움이 될 꺼 같습니다.
우선 웹소켓이 음... 보통은 큰 문제가 없습니다. 실시간 통신을 하는데에 있어서는 당연히 사용이되는것이 일반적이지만, 애초에 t2.micro 를 사용하는거부터가 잘못된 상황인거 같습니다. 기본 천장이 너무나도 낮아요.
t2.micro 는 CPU 1, RAM 1GB 정도로 구성이되어 있을텐데, 이미 400개의 웹소켓이 연결이 되었다면, 한계에 가까울꺼같네요. 대략적으로 300~500개 정도 가능할꺼같거든요
물론 이 부분은 저의 일종의 감입니다. 상황에 따라서 당연하게도 달라질 수 있어요.
그래서 이렇게 연결이 되어 있는 상태에서는 애초에 인스턴스의 성능 문제로 대응이 불가능하셨을겁니다. GC나 스레드 스케줄링이 밀려버려요.
웹소켓 서버가 기본적으로 메모리를 많이 잡아먹습니다. 커넥션을 물고있는 상황이기 떄문이에요. 이 커넥션을 유지하기 위해서 고성능의 서버가 필요하죠.
그래서 취준생 입장에서 비용적인 부분이 부담이 되신다면,,, 그냥 HTTP 풀링으로 구현하시는것도 하나의 방법일꺼 같아요.
그리고 해당 인스턴스의 CPU 사용률과 메모리 사용률을 우선적으로 확인하시고 이 부분에 대해서 분석을 하시는게 좋을꺼같습니다. 현재 서버가 과도하게 사용이되고 있는지 등을 확인해야 좀 더 좋은 답변을 드릴 수 있지 않을까 싶어요.
그래서 우선적으로 테스트를 k6 를 통해서 환경을 맞춰주시고, 그 이후에 동일한 환경에서 보시면 되지 않을까 싶네요.
그럼 이제 추가적인 질문에 대해서 답변을 드리도록 할게요.
앱 개발에서 채팅시스템을 구축하는 상황이고, 대략 500~1000명을 수용해야한다면 어떤 기술을 적용해 채팅시스템을 구축하셨을 것 같나요?
우선적으로 웹소켓은 기본적으로 사용할겁니다. 양방향 통신이 필수적으로 필요한 기능이기 떄문이에요.
그래서 저라면, 그냥 현재 강의에서 다루었던 아키텍처를 그대로 구현할꺼 같습니다. 큰 문제가 없이 저정도의 요청은 사실 무리가 없이 처리가 가능하다고 생각을 하거든요
t2.micro 서버는 얼만큼의 소켓연결까지 버틸 수 있는지 알고 싶습니다.
일단 이 질문에 대해서는 단편적으로 이게 맞다 아니다를 말할수는 없습니다. 내부적으로 어떻게 구현하셨는지도 모르고 제가 알 수 있는 정보가 인스턴스 성능밖에 없어요. 그래서 딱 말하기가 어렵지만, 그냥 딱 인스턴스 성능만 봐도 사실상 천장이 낮습니다. 너무 성능이 안좋아요.
우선 80명 정도라면 문제는 없겠죠. 서버가 OOM같은 현상이 발생하지는 않을꺼같아요. 근데 기본적으로 불안한 상태는 맞습니다. 속히 말해서 돌아는 가는데, 여유가 진짜 없다 수준의 성능인거 같습니다.
또한 채팅 메시지가 얼마나 들어오는지도 모르기떄문에 음.. 저라면 성능을 올릴꺼같습니다. 그렇게 트래픽이 없다면, 가볍게
t3.small정도도 괜찮을꺼 같네요.
제 질문들이 대부분 인프라 확장의 타당성을 갖추기 위한 질문이라고 생각합니다. 혹시 인프라 확장을 위한 근거로써 어떤 지표가 타당성을 확보할 수 있다고 생각하시는지 궁금합니다.
지표라는게 추상적인 수치이기도 하고 상황에 따라 다르게 해석이 가능한 수치라고 생각을 합니다. 그래서 이 부분도 참.. 어려운거 같아요.
보통은 CPU 사용률, 메모리 사용률을 저는 주로 봅니다. 그리고 부수적으로 스레드 수 정도까지는 확인을 하는거 같아요.
예를들어서 CPU 사용률이 70~80%인데, 이 현상이 5~10분 이상 계속해서 지속한다. 이런 상황이라면 문제가 있을 수 있겠죠.
배치성 모듈이라면 그럴 수 있습니다. 특정 시간대에 작업이 몰려서 증가하는것이죠.
또한 GC의 활동주기도 종종 확인합니다. GC가 돌았는데, 메모리가 정리가 안된다던지, 아니면 GC가 너무 자주 돈다던지 이런 부분을 확인하는거 같아요.
그래서 이 질문에 대해서는 여러가지 요소들을 확인하셔야 해서... 사실상 경험을 직접 해보시고 다양한 상황을 마주하시는게 더 도움이 되지 않을까 싶습니다 ㅠㅠ 제가 보는 대략적인 관점은 저정도를 확인하고 조합해서 관리를 하는 편입니다.
예를들어서
CPU가 80% 이상이고, 메모리가 계속 높은 상태로 지속하네?? 이 과정에서 GC가 계속 활동하는데 수치가 점진적으로 증가하네??이런 현상이라면 메모리 누수가 있고, 서버의 성능도 올려야 하는 상황인거죠.하지만 앞서 말씀 드린것처럼 일시적으로 작업이 몰리는 상황에서는 확장에 대한 근거로 사용하지는 않습니다.
전반적으로 생각하는 부분을 설명드렸는데 도움이 되셨을지 모르겠습니다. 추가적인 질문 있다면 남겨주세요 감사합니다.