늦었지만, 꼭 필요했던 성능 테스트프로젝트 초기, WebSocket 기반의 채팅 메시지를 MySQL에 직접 저장하는 방식으로 구현했습니다. 당시에는 기능 구현에 집중했지만, 시간이 지날수록 ‘과연 이 구조가 수많은 사용자가 몰리는 실시간 서비스에 적합할까?’라는 의문이 들기 시작했습니다.이러한 고민 끝에 실시간 처리 성능 향상을 위해 Redis를 도입하여 임시 저장 후 스케줄러를 통해 MySQL에 저장하는 방식으로 구조를 개선했습니다. 단순히 ‘동작하는 시스템’을 넘어, ‘성능적으로 설계된 시스템’이라는 확신을 얻고 싶었기에, Redis 도입의 효과를 정량적으로 검증하고 현재 구조의 한계를 파악하기 위해 성능 테스트를 수행하게 되었습니다. 테스트 환경 구성이번 성능 테스트를 통해 얻고 싶은 점은 Redi..

웹소켓? 그게 뭔데?누구나 전시회를 열어 작품을 전시할 수 있는 프로젝트를 기획하면서, 온라인 전시회의 강점을 살리고자 했습니다.전통적인 전시회에서는 관람 중 침묵을 유지하는 경우가 많지만, 온라인 전시회는 채팅 기능을 통해 관람객들이 자유롭게 소통할 수 있다는 점에서 차별화된 경험을 제공할 수 있다고 판단했습니다. 이에 저는 실시간 채팅 서비스를 구현하기 위해 웹소켓과 STOMP를 결합한 방식을 선택했습니다.웹소켓은 HTTP 요청-응답 모델과 달리, 단 한 번의 연결로 클라이언트와 서버 간에 지속적인 양방향 통신을 제공하여 빠른 실시간 반응을 가능하게 합니다. 이러한 특성은 채팅 서비스처럼 사용자 간 즉각적인 상호작용이 필요한 환경에서 매우 적합하다고 생각했습니다. 하지만 웹소켓만으로는 메시지의 구조화..

배포 방식, 그때는 맞고 지금은 틀리다프로젝트 초기에는 AWS에서 제공하는 배포 도구인 CodeDeploy와 S3를 사용하여 배포를 진행했습니다.CodeDeploy는 학습 비용이 낮고, GitHub Actions와 연계하여 자동 배포를 설정할 수 있어 기본적인 배포 흐름을 익히기에 적합하다고 판단했습니다. 하지만 배포를 진행하면서 몇 가지 한계를 경험했습니다. CodeDeploy 방식은 S3에서 파일을 다운로드한 후, EC2에서 압축을 해제하고 애플리케이션을 재시작하는 과정이 필요했습니다.아래는 CodeDeploy를 통한 배포 단계별 시간으로, 이벤트 로그를 통해 각 단계에서 소요된 시간을 확인할 수 있습니다. CodeDeploy 배포 시간은 현재 서비스가 크지 않은 상태에서 배포 시간이 약 5 ~ 6초..

세션 기반 인증의 한계프로젝트 초기에는 스프링 시큐리티를 기본 기능인 세션 기반 인증을 사용했습니다.세션 기반 인증은 사용자의 로그인 상태를 서버 메모리에 저장하는 방식으로 간단하지만, 세션은 서버에 저장되기 때문에 사용자가 증가함에 따라 서버 메모리에 저장되는 세션 데이터도 증가하고 이로 인해 서버의 부하가 커질 것이라고 생각했습니다. 또한, 세션 하이재킹과 같은 보안 위협에 노출될 가능성이 있었습니다. 이러한 문제를 해결하기 위해 JWT를 도입하기로 결정했습니다. JWT는 클라이언트 측에서 토큰을 저장하고, 서버는 상태를 유지하지 않는 방식으로 동작합니다. 때문에 세션 기반을 사용했을 때의 한계를 극복할 수 있었습니다. 하지만 세션 기반을 버리고 토큰 기반으로 사용을 한다고 해서 모든 문제점이 해결되..