문제 상황사용자에게 실시간 알림을 제공하기 위해 SSE를 사용하고, 알림 전송 로직은 Spring Event를 통해 구현했습니다. 하지만 1000명이 연결이 되어 있는 상태에서 1000명의 사용자가 10만개의 데이터를 전송하는 부하 테스트 결과, 응답 시간에 심각한 지연과 오류가 발생했습니다. 게다가 알림 메세지 처리 과정에서 오류가 발생하면, 이벤트를 발생시킨 원본 트랜잭션까지 롤백되는 문제가 확인되었습니다. 문제 분석문제의 원인을 찾기 위해 모니터링 결과, 부하 발생 시 HikariCP의 Active 커넥션 수치가 최대치에 도달하고, DB 커넥션을 할당받기 위해 대기하는 Pending 스레드의 수가 급증하는 현상을 확인했습니다. 이는 DB 커넥션이 장기간 점유되어 후속 요청들이 처리되지 못하고 병목..

개요최근 개발 중이던 서비스의 게시글 조회 API에서 대용량 데이터를 추가한 후 성능 테스트를 진행하는 과정에서, 데이터 추가 이전에는 나타나지 않았던 문제점들을 발견하게 되었습니다. 기존에는 원활하게 작동하던 API가 데이터가 급격히 증가하자 응답 속도 지연, 데이터베이스 서버 과부하, 일부 요청에서의 예외 발생 등 다양한 성능 저하 현상을 보였습니다. 이러한 예상치 못한 성능 저하 현상은 단순히 데이터 양이 늘어났기 때문이 아니라, 증가된 데이터 볼륨에 기존 시스템이 어떻게 반응하는지에 대한 면밀한 분석이 필요하다는 점을 시사했습니다. 즉, 기존에는 드러나지 않았던 시스템의 한계나 특정 로직의 비효율성이 대용량 데이터 환경에서 발현된 것으로 판단했습니다. 본 글에서는 다양한 계층의 지표들을 종합적..

들어가며이번 프로젝트를 진행하는 과정에서, 배포 작업 중 서버 다운 문제를 경험하게 되었습니다. 이전까지는 새로운 버전의 애플리케이션을 배포할 때마다 불가피하게 트래픽 중단이나 에러 발생이 동반되었습니다. 특히, 서비스가 실시간으로 운영되는 상황에서 사용자가 접속중일 때 배포가 이루어지면, 잠시 동안 서비스 이용에 불편을 겪거나, 일부 요청이 처리되지 않는 경우가 발생하기도 했습니다. 이러한 문제를 해결하기 위해, 배포 과정에서 발생할 수 있는 다운타임을 최소화할 수 있는 방법을 고민하게 되었습니다. 여러 배포 전략을 살펴본 결과, 무중단 배포 방식을 적용하는 것이 효과적이라 판단하였고, 이를 구현하기 위해 GitHub Actions와 Blue-Green 배포 방식을 도입하게 되었습니다. CI/CD 도구..

프로그래밍에서 함수 호출 방식은 매우 중요한 개념입니다. 특히, Call by Value와 Call by Reference는 두 가지 주요한 호출 방식으로, 각각 고유한 특징과 단점을 가지고 있습니다. 이번 포스팅은 이 두 가지 방법과 Java에서 어떻게 사용되는지에 대해 살펴보도록 하겠습니다.  Call by ValueCall by Value는 함수가 인자로 전달받은 값의 복사본을 사용하여 처리하는 방식입니다. 이 방식은 주로 기본형 또는 원시 타입(primitive type)의 데이터에서 사용됩니다. 예를 들어, 정수나 실수 같은 데이터 타입이 여기에 해당됩니다. 💫 예제 코드는 이해를 위해 C++로 작성되었습니다.#include using namespace std;void modify(int a)..

가비지 컬렉션(GC)의 필요성과 알고리즘가비지 컬렉션(GC) 이란?GC는 메모리 관리 기법 중 하나로, 프로그램이 더 이상 필요로 하지 않는 메모리를 자동으로 해제해 주는 기능입니다. 우리가 흔히 GC가 관리한다고 말하는 메모리는 프로그램 실행 중 동적으로 할당되는 힙(Heap) 영역을 의미하고, GC가 해제하는 대상은 어떤 변수에서도 참조되지 않는 메모리 공간입니다.  C나 C++같은 언어에서는 개발자가 직접 메모리를 할당하고 해제해야 했습니다. 하지만 수동으로 메모리를 관리하는 건 꽤 번거로울 뿐 아니라 메모리 누수(Memory Leak)가 발생할 수 있습니다. 또한 이미 해제된 메모리에 접근하거나 다시 해제하려면 오류가 발생할 수 있습니다. Java에서는 이런 작업을 알아서 처리해주기 때문에 개발자..

개요채팅방 메세지 읽음 처리 기능은 사용자가 마지막으로 읽은 메세지를 추적하여, 읽지 않은 메세지의 개수를 확인하고 각 메세지에 대해 '읽지 않은 개수 (Unread Count)'를 표시합니다. 기존의 메세지 읽음 처리 구조는 각 메세지마다 해당 메세지를 읽은 유저의 ID 리스트를 기록하고, 읽은 유저 ID 배열의 길이를 통해 '읽지 않은 개수 (Unread Count)'를 계산했습니다. 하지만 사용자가 많은 채팅방은 사용자가 적은 채팅방에 비해 더 많은 메세지가 오가므로, 수정해야할 데이터의 개수가 기하급수적으로 늘어나게 됩니다. 이를 해결하기 위해 메세지 읽음 처리 로직을 개선해보겠습니다. 기존의 메세지 읽음 처리 로직먼저, 기존의 채팅 시스템의 메세지 읽음 처리 로직을 살펴보겠습니다. 앞서 설..