미리보기

저는 Spring 프레임워크와 자바 프로그래밍 언어를 활용하여 다양한 웹 애플리케이션을 개발하고, 해당 애플리케이션의 배포 및 운영에 대한 경험이 있습니다. 특히, 최근에 참여한 coffee-meet 프로젝트에서는 AWS를 활용한 배포를 통해 실제 서비스 운영 및 성능 테스트를 진행하며, 사용자 경험을 향상시키기 위해 다양한 기능에 대한 성능 개선을 수행했습니다.

첫째로, 채팅방 백업 성능 개선입니다.
사용자가 현재 진행 중인 매칭을 종료하면 활성화된 채팅방이 종료되고 동시에 백업이 진행됩니다. 그러나 이때 10,000개의 채팅 메세지를 백업하는데 10초라는 큰 시간이 소요되는 성능 문제가 발생했습니다.
이 문제를 해결하기 위해, 기존 JPA를 활용해 각각의 채팅 메세지를 저장하는 방식 대신에 JDBC를 활용한 벌크 연산(INSERT)을 도입하여 한 번에 채팅 메세지를 저장하는 방식으로 변경했습니다. 하지만 10,000개의 채팅 메세지를 한 번에 백업하는 과정에서 Stack Overflow 오류가 발생했습니다. 이 오류의 원인은 채팅 메세지를 백업하고 기존 메세지를 삭제하는 과정에서 발생한 벌크 연산(DELETE)에 있었습니다. JPA의 deleteAllInBatch()가 실행되면, 10,000개의 채팅 메세지의 식별자(Id) 값을 HQL에서 SQL로 파싱하는 과정에서 내부적으로 재귀 호출이 발생해 Stack Overflow가 발생한 것이었습니다.
이 문제를 해결하기 위해 스택의 기본 크기가 수용할 수 있는 최대 채팅 메세지 개수를 약 5,000개로 분석한 후, 10,000개의 채팅 메세지를 5,000개씩 2번에 나눠 백업하는 로직을 작성하여 문제를 극복했습니다. 더 나아가 어떤 벌크 사이즈가 가장 효율적일지에 대한 의문이 들었고, 이에 대한 비교 분석을 통해 10,000개의 데이터를 1,000개씩 10번에 나눠 백업하는 방식이 가장 효율적이라는 결론을 도출하였습니다. 이로써 채팅 메세지에 대한 백업 성능은 평균 10,272ms에서 1,886.6ms로 약 81.6% 향상되었습니다.

둘째로, DB 인덱스를 활용한 신고 목록 조회 쿼리 성능 개선입니다.
기존에 사용 중이던 관리자의 신고 목록 조회 API에서 발생한 성능 저하 문제를 해결하기 위해 인덱스를 활용해 쿼리를 개선했습니다. 초기에는 풀 테이블 스캔을 수반하는 오프셋 기반의 페이징 기법을 활용하고 있었으나, 이로 인해 대량의 데이터를 처리할 때 응답 시간이 길어지는 문제가 발생했습니다. 분석을 위해 1,000,000개의 테스트 더미 데이터를 삽입하고 성능 테스트를 진행했으며 특히, 풀 테이블 스캔을 최소화하고자 인덱스 레인지 스캔을 하는 커서 기반의 슬라이싱 기법을 도입함으로써 쿼리 성능을 향상시켰습니다. 이에 따라 조회 응답 시간이 평균 195ms에서 63.5ms로 약 67.4% 향상되었습니다.

마지막으로, 캐시 적용을 통한 이전 채팅방의 메세지 조회 처리 성능 최적화 및 서버 부하 경감입니다.
서비스 특성상 이전 채팅방의 메세지 조회는 3일 동안만 유지되며, 사용 빈도가 높고 데이터의 변동이 없어 정합성 문제를 고려하지 않아도 됐습니다. 이에 따라 캐시를 적용하여 서버 부하를 최소화했습니다. Scale Out 환경에서의 확장성을 고려하여 글로벌 캐시를 고려했고, 특히 다양한 데이터 타입을 저장할 수 있는 Redis를 도입하여, 이전 채팅방 메세지 조회 결과를 메모리에 보관함으로써 데이터베이스로의 접근 및 애플리케이션 서버의 연산을 효율적으로 최소화하였습니다. 결과적으로 1,000,000개의 이전 채팅 메세지에 대한 조회 성능이 평균 61.8ms에서 11.6ms로 약 81.2% 향상되었습니다.