이전 글 보러가기 [최종프로젝트] WebSocket 실시간 채팅 서비스 개발개요스포츠 경기 일정 및 결과를 제공하는 서비스인 최종프로젝트에서 스포츠 게임별로 사용자들이 실시간으로 소통할 수 있는 채팅 기능을 제공하고자 하였다. 네이버 스포츠, 아프리카TV 등zzzzseong.tistory.com  개요기존 프로젝트에서 스포츠 게임별로 사용자들이 실시간 소통을 할 수 있는 채팅 기능을 개발했다. 개발 기간이 짧아 러닝커브를 고려해 채팅 데이터를 전달하는 브로커를 STOMP에서 기본적으로 제공하는 인메모리 브로커를 사용했다. 인메모리 브로커를 사용했기 때문에 서버의 스케일아웃에 대비할 수 없었다. 프로젝트 마무리 후 개인적으로 채팅 데이터 저장과 스케일아웃이 가능한 서버 아키텍처로 개선해보고자 했다. 해..

개요프로젝트 통합테스트로 상품 구매에 대한 테스트를 진행하던 중 멀티스레드 환경에서 상품 구매 기능에 접근할 시 레이스 컨디션이 발생하는 문제를 확인할 수 있었다. 이러한 이유로 상품 구매 기능에 동시성 제어가 필요할 것이라고 판단했고 동시성 제어에 필요한 기술의 의사결정, 기술 적용, 테스트 코드 작성 및 회고를 진행하고자 한다.  동시성 처리가 필요한 이유동시성 처리가 필요한 이유는 레이스 컨디션 발생에 있다. 레이스 컨디션이란 공유 자원에 대해 스레드가 동시에 접근해 값을 조작할때, 조작 순서가 보장되지 않아 잘못된 값이 저장되는 문제를 말한다. 레이스 컨디션의 가장 많이 알려진 예는 아래 코드라고 생각한다. 두 스레드가 동시에 count의 값을 증가시키려고 접근할때 count는 thread-sa..

성능 개전 전 부하테스트 리포트성능 개선 전 10명의 사용자가 30분간 지속적으로 요청을 보내는 환경에서 TPS가 1.2, MTT가 8000ms로 매우 비정상적인 매트릭을 보여주었다. 개발 단계에서는 데이터량이 많지 않았기 때문에 성능에 문제가 있다는것을 파악할 수 없었지만 데이터가 많아지면서 아래와 같은 비정상적인 매트릭을 측정할 수 있었다.   성능 개선 후 부하테스트 리포트상품 검색 기능에 대한 성능 개선을 완료하고 다시 한 번 부하테스트를 진행했다. 테스트를 진행한 서버의 스펙은 모두 t3.medium으로 동일하며 2vCPU와 4GiB 메모리를 가지는 EC2 환경에서 진행했다. 테스트는 30분 동안 N명의 사용자가 계속해서 요청을 보내는 환경으로 진행했고 사용자수를 10명, 100명, 1000명으..

개요프로젝트 개발의 마무리 단계로 개발한 서비스에 대한 테스트를 진행하였다. 그동안 개발을 해오면서 JUnit과 Mockito를 이용한 통합 및 단위테스트는 많이 진행했지만 외부 도구를 사용해 실제 서버에 올라간 애플리케이션에 대한 테스트를 진행해본 경험이 없어 이번 기회에 테스트를 진행하고 그 과정을 정리해보고자 한다. 해당 글은 테스트를 위한 문서인 테스트 시나리오 작성에 대한 내용을 정리한 글이다.  테스트 시나리오 작성 관련 참고사항먼저 애플리케이션을 테스트할 수 있는 도구로 아파치에서 제공하는 Jmeter와 네이버에서 제공하는 nGrinder 중 한가지를 선정해야 했다. Jmeter의 경우 nGrinder보다 제공하는 기능이 많았기 때문에 더욱 세부적인 테스트가 가능할 것이라고 판단했지만, 테..

상품 검색 성능 문제 발견 및 테스트최종프로젝트에서 상품 검색 기능을 구현하고 프로젝트를 배포했을때, 아래와 같이 조회 속도가 매우 느린 문제가 발생했다. 포스트맨으로 응답 시간을 확인해 보았을때, 5000~6000ms의 비정상적인 응답시간을 반환하는것을 확인할 수 있었다. 클라이언트의 입장에서 2000ms를 초과하면 서비스를 제공하기 어렵다는 점을 기준으로 봤을때 확실히 개선이 필요한 부분이었다. 또한, 정확한 지표를 통한 성능 차이를 확인하기 위해 nGrinder로 부하테스트를 진행했다. 개선 전 TPS가 1.2, MTT는 8000ms로 매우 비정상적인 매트릭을 확인할 수 있었다. 반면, 메모리와 CPU 사용률은 안정적인 모습을 보여주고 있었는데 이를 통해 서버 외부의 문제일 가능성이 크다고 예측했다..

개요스포츠 경기 일정 및 결과를 제공하는 서비스인 최종프로젝트에서 스포츠 게임별로 사용자들이 실시간으로 소통할 수 있는 채팅 기능을 제공하고자 하였다. 네이버 스포츠, 아프리카TV 등과 같은 플랫폼에서 제공하는 실시간 채팅 기능을 모티브로하여 개발하였고 그 과정에서 기술 의사결정 및 개발 그리고 느낀점에 대한 회고를 기록하고자 글을 작성한다.  실시간 채팅 서비스 개발을 위한 기술 선정: 폴링과 웹소켓✅ Polliing 방식 사용 시 발생하는 서버 부하Polliing 방식은 지정한 인터벌마다 HTTP요청을 보내기 때문에 서버에 많은 부담을 줄 것으로 판단했다. WebScoket도 클라이언트와 연결을 유지하는데 비용이 발생하지만 HTTP도 Keep-Alive로 인해 일정시간 연결을 유지하는 비용이 발생한다..