1. 현상 (PROBLEM)GATEWAY → EUREKA → SERVICE 구조 구축 후, 유레카 대시보드를 통해 모든 인스턴스가 정상적으로 등록된 것을 확인했습니다. 하지만 포스트맨으로 게이트웨이(8080)를 통해 회원가입 API를 호출했을 때, 기대와 달리 500 INTERNAL_ERROR가 발생했습니다.서비스가 살아있는데 500이 뜨는 이유를 확인하기 위해 로그를 추적한 결과 다음 메시지를 발견했습니다. java.lang.IllegalStateException: No servers available for service: remitro-member(원래 로드밸런싱 실패 시 503이 떠야 하지만, 내부 필터 예외 처리 과정에서 500으로 래핑 되어 출력되었습니다.) 2. 원인 분석 (ANALYSIS)..

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

보호되어 있는 글입니다.

보호되어 있는 글입니다.