
1. 서론서비스에서 자주 조회되는 인기글 API의 응답 속도를 개선하고자, Spring Boot에서 제공하는 @Cacheable 어노테이션을 활용해 캐시를 빠르게 붙였습니다. 간단하게 붙이고 성능도 챙기자는 의도였고, 처음에는 실제로 응답 속도도 빨라지고, 서버 부담도 줄어드는 듯 보였습니다. 하지만 운영을 지속하면서 이상한 지점을 발견했습니다. JVM Heap 사용량이 점점 누적되는데도, Full GC 이후에도 메모리 사용량이 줄지 않는 현상이 반복되었고, 같은 시점에 TPS가 급격히 하락하고 응답 지연이 늘어나는 문제도 함께 나타났습니다. 처음에는 일시적인 부하인가 싶었지만, Scouter로 수치를 확인하고 나니 이건 단순한 GC 문제만은 아니구나를 생각했습니다. 관련해서 어떤 점 때문에 메모리..

1. 서론인기글 API의 성능 문제를 해결하기 위해, 먼저 쿼리 구조를 개선하고 적절한 인덱스를 적용하여 DB 부하를 줄이고 응답 속도를 개선했습니다. 하지만, 사용자 접근 빈도가 높은 인기글 페이지의 특성상, 여전히 반복적인 조회에 의한 DB 접근 비용이 부담으로 남아있었습니다.이번 글에서는 이를 해결하기 위해 적용한 캐싱 전략에 대해 다뤄보겠습니다. 캐싱이란 무엇인지, 왜 Redis를 선택했는지, 그리고 실제 적용 방식을 함께 살펴보겠습니다. 2. 데이터베이스는 왜 느릴까 우선 데이터 베이스의 종류를 간단히 살펴보면, [RDB 특정] - 안정성HDD 혹은 SSD같은 보조기억 장치에 데이터를 저장행과 열 구조의 정형 데이터 저장(엑셀처럼 생각하면 쉬움)SQL 언어로 데이터 조회 및 관리테이블 간 관계를..

1. 서론이전 포스팅에서 불필요한 전체 조회와 반복 쿼리를 제거하고, ID 기반 분리 조회 방식으로 인기글 API의 쿼리 구조를 개선했었습니다. 그 결과, 쿼리 수는 1,000회 이상 → 9회, 응답 시간은 5초 이상 → 약 80ms 수준으로 크게 줄일 수 있었습니다. 이번에는 DB 레벨에서 성능을 더 끌어올려 보기 위해 인덱스를 적용해보도록 하겠습니다. 2. 왜 인덱스가 필요할까?지금 구조에서는 다음과 같은 쿼리들이 실행됩니다. 1) 인기글 ID 조회 쿼리 SELECT m.id FROM meeting mLEFT JOIN like l ON l.meeting_id = m.idWHERE m.recruitment_type = ? AND m.is_confirmed = falseGROUP BY m.id..

1. 서론처음에는 단지 인기글 3개만 보여주는 구조였기 때문에, 성능상 큰 문제가 없을 것이라 생각했습니다.게다가 테스트 당시에는 좋아요 수가 많지 않아, API 응답 속도나 쿼리 수에 대한 문제를 명확히 인식하지 못했습니다. 하지만 더미 데이터를 생성하여 좋아요 수를 Meeting 1,000개에 걸쳐 5만 건 이상 생성하고 테스트해본 결과,생각보다 심각한 성능 저하와 타임아웃 현상이 발생하기 시작했습니다. 이에 따라 쿼리 구조를 분석하고, 병목의 원인을 찾아 해결해보기로 결정했습니다. 2. 인기글 API를 테스트해보자Starhub에는 인기글을 확인할 수 있는 페이지가 있습니다. 사용자는 이 페이지에서 프로젝트 / 스터디 / 마감임박 기준으로 각각 3개씩 인기글을 확인할 수 있습니다. 총 9개의 ..

1. 성능 테스트를 위한 Mock 이메일 서버 설계 프로젝트에서는 Gmail SMTP 서버를 이용해 이메일 발송 기능을 구현했습니다. 하지만 부하 테스트를 진행하기 위해 실제 Gmail SMTP 서버를 사용할 경우 몇 가지 제약이 발생했습니다. 1. 발송 횟수 제한Gmail 무료 계정은 하루 500회의 발송 제한이 있습니다. 이로 인해 대규모 부하 테스트를 충분히 수행하기 어려웠습니다. 2. Rate Limit의 유동성 Gmail의 초당 처리 제한(Rate Limit)은 사용량에 따라 동적으로 변경됩니다. 이 특성은 성능 테스트 결과를 왜곡할 가능성을 높였습니다. 위와 같은 문제를 해결하기 위해 Gmail 대신 Mock 이메일 서버를 구축하여 성능 테스트를 진행했습니다. 이 서버는 실제 Gmai..

이전 글에서 동기 방식으로 이메일을 발송하는 기능에 대해 살펴보았습니다. 하지만 동기 방식으로 처리했을 때 문제점이 있었는데, 비동기 방식으로 전환했을 때 어떤 변화가 있는지 자세히 알아보겠습니다. 1. 동기 방식의 문제점이메일 인증 코드를 요청하는 API를 동기 방식으로 처리했을 때 생기는 문제점을 다시 정리해보겠습니다. 동기 방식에서의 주요 문제는 외부 API의 응답 속도에 따라 전체 성능이 감소한다는 점입니다. 2. 비동기 방식 적용메인 프로세스의 성능에 영향을 주는 문제는 API 호출 로직을 비동기로 처리하도록 하여 해결할 수 있습니다. 여기서 비동기 처리란 간단히 다른 프로세스나 스레드에서 로직을 처리하는 것으로 정의하겠습니다. 예를 들어, 이메일을 발송하는데 4초나 걸리던 것을 별도의 스레..
- 비영속
- 즉시 로딩
- @GeneratedValue
- mappedBy
- 단일 테이블 전략
- N + 1
- JPA
- 비동기
- @Table
- @MappedSuperclass
- @Id
- 1차 캐시
- 스키마 자동 생성
- @OneToMany
- 영속성 컨텍스트
- 연관관계
- Redis
- 메일
- onetoone
- @Entity
- 조인 전략
- 준영속
- 인메모리 db
- @Cacheable
- @joincolumn
- 엔티티 매니저
- @TransactionalEventListener
- @ManyToOne
- 최적화
- 변경감지