Cursor AI 개발 기록 3 - 서버 부하를 해소 해보자(1)

문득 내가 만든 서비스가 많은 사람이 접속했을 때에도 서버가 무리없이 굴러갈지 궁금해졌다.

그래서 아래와 같이 구체적인 사람의 수 100명을 언급해주고 필요한 하드웨어 사양을 물어봤다.

 

동시 접속자가 100명일 때 필요한 CPU, 메모리, 스토리지, 네트워크를 제안해줬다.

생각보다 저사양 PC로도 잘 굴러갈 것 같다.

그리고 클라우드 환경인 AWS나 Azure의 서버 상품도 제안해줬다.

 

동시접속자 100명이 저 정도 하드웨어에서 잘 굴러간다면 몇 명부터 서버가 감당하지 어려운지 궁금해졌다.

한번 물어보자!

 

서버 코드 분석 후 주요 리소스 사용 기능을 알려준다.

 

내 프로젝트의 경우 Node.js 기반의 Socket.io로 전반적인 통신환경이 구축되어있기 때문에 일반적으로 수천 명의 동시 접속자 까지 처리할 수 있다고 한다.

하지만 서버 하드웨어 사양과 네트워크 대역폭, 사용자 발생 이벤트 양에 따라 그 한계가 달라진다고 한다.

 

드로우 투게더의 경우 그림 그리기 이벤트가 있어서 많은 사용자가 동시에 그림을 그릴 경우 캔버스 이미지가 base64형태의 문자열로 변환되어 다른 사용자에게 전송되는 형태로 구축되어 있다.

아무래도 그 부분에서 많은 양의 메모리를 사용시키고 트래픽 사용량이 증가할 것으로 예상 해줬다.

 

Claude-3.7 이녀석 서버 최적화를 위한 문제점 분석까지 해주다니 아주 훌륭하다.

어쨌든 결론은 녀석의 조언에 따르면 안정적인 서비스를 위해서 50~100명 정도를 단일 서버에서 처리하는 것이 적절하다고 한다.

 

사실 동시 접속자에 관해서 질문하기 전부터 현재 드로우 투게터의 설계에 문제가 있다고 생각하고 있었다.

열명 정도야 같은 캔버스에 그림을 그릴 수 있겠지만 몇 백명대가 된다면 캔버스가 난장판이 될게 뻔했다.

 

결국 이 문제를 해결하기 위해서는 동시접속자가 많으면 분산해서 room을 생성하고 캔버스에 접근할 수 있도록 구현해야 한다.

내 생각에 대한 claude-3.7의 의견을 물어보자.

 

 

 

내가 제안한 방식은 서버 부하 해소에 상당한 도움이 될 것이라고 한다.

claude-3.7에게 인정받은 것 같아서 기분이 나쁘지 않다. ㅋㅋ

 

언뜻 생각하면 한번에 100명이 접속한 1개의 room 혹은 20명씩 분산된 5개의 room 결국은 접속자는 둘다 100명이지 않나 싶지만 메모리 사용량 분산 및 Socket.io의 Room을 병렬 처리하여 시스템 리소스를 효율적으로 사용할 수 있다고 한다.

 

Room 코드 구현을 요청하고 테스트를 진행해보자.

 

 

서버 재실행 후 페이지에 접속했더니 Data is not defined 오류가 발생했다.

 

아마도 객체를 선언하고 생성하는 부분이 누락된 것 같은데 내가 고치기 귀찮으니 오류가 발생했다고 알려보자.

 

 

역시 Data 객체가 정의되지 않아 오류가 발생 한거라고 한다.

그런데 내가 요청한 오류 수정 뿐만 아니라 Room기능을 구현하기 위해서 부족했던 다른 여러가지 변경 사항도 알아서 수정 및 추가 해줬다.

 

테스트를 진행 하기 위해 크롬 브라우저 탭을 20개까지 켜고 모두 접속해 준 다음 마지막으로 21번째 사용자로 접속했다.

과연 Room이 잘 분리가 될까?

 

아니다.. 사용자 목록 리스트에 21번째 사용자가 떠버렸다..

그리고 다른 문제점도 생겼다.

캔버스에 그림을 그렸을 때 정상적으로 그림 공유가 되지 않는다.

 

오류를 수정해야한다!

이어지는 다음 글에서 Cursor AI를 활용하여 서버 부하를 최소화 하는 룸 분할 기능을 완벽 구현 해보자!