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

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

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

들어가며이번 프로젝트를 진행하면서 로컬 개발 환경의 일관성과 효율성에 대해 고민이 있었습니다. 팀 프로젝트가 진행됨에 따라, 여러 명의 개발자가 동시에 작업을 시작하게 되었고, 프로젝트를 GitHub에서 클론한 뒤, 빠르게 개발을 시작할 수 있는 환경을 제공하는 것이 중요하다는 점을 깨달았습니다.  초기에는 각 개발자가 Redis, MySQL, MongoDB와 같은 외부 데몬은 별도로 설치해야 하는 경우가 많았고, 그로 인해 설정에만 오랜 시간이 걸리거나, 환경 세팅을 하지 못한 채로 진행되는 경우도 있었습니다. 따라서, 프로젝트를 클론한 후 바로 실행 가능한 환경을 구성해야 한다는 생각이 들었고, 이를 위해 로컬에서 독립적으로 실행할 수 있는 기술이 필요하다고 판단했습니다.  이 문제를 해결하기 위한 ..

들어가기 앞서프로젝트를 진행 중, 프론트엔드 개발자분 께서 별점 기능에서 별점 값이 제대로 업데이트되지 않는 문제를 발견하셨습니다. 문제를 정확히 파악하기 위해 데이터베이스를 확인해본 결과, 동일한 별점 데이터가 2개 저장된 것을 확인할 수 있었습니다. public RatingCreateResponse createRating(Long userId, RatingCreateServiceRequest request) { User user = userRepository.findById(userId) .orElseThrow(() -> new BusinessException(USER_NOT_FOUND)); Book book = bookRepository.findById(request.getBookIsbn()) ..

들어가기 앞서저희 프로젝트에서는 매일 오전 4시에 베스트 셀러 도서 100권의 정보를 크롤링하여 서버에 저장하는 작업을 수행해야 했습니다. 처음에는 동기적인 방식으로 코드를 작성하여 이 작업을 테스트해 보았으나, 이 방법으로는 데이터 크롤링에 많은 시간이 소요되었고, 전체 프로세스 효율성에 문제가 있었습니다. 이에 따라, 이 문제를 해결하기 위해 CompletableFuture를 이용한 비동기 처리와 병렬 프로그래밍을 활용한 방법으로 개선을 시도했습니다. 이 글에서는 기존 동기적인 접근 방식에서 겪었던 문제와 그로 인해 발생한 지연 문제를 어떻게 해결했는지, 그리고 새로운 방법으로 개선된 효율성에 대해 공유하려 합니다. 문제 상황@Component@RequiredArgsConstructorpublic..