성능 최적화 기록기 - v1

해당 글은, 현재 실행중인 백과블로그 서버를 성능 기록 개선한 이력입니다.
추후, 비공개 처리될 수도 있습니다.

해당 V1 개선에서는, 인프라적인 개선 보다는, Query 튜닝이나 Cache 처리 등이 주를 이룰 예정입니다.
V2 개선에서는 아마도 인프라를 분리하여 관리할 예정입니다.
현재, 한 EC2 에서, DB Application Front Redis 를 띄우고 있어 자원 경쟁이 매우 심한것은 인지하고 있는 상황이다.

인프라 구성 및 설정들

인프라

EC2(Spring) - t4g.small

t4g.small spec
cpu - 2core
mem - 2GB

실행되는 인스턴스

Spring Application (Docker)
MySQL (Docker)
Next.js (Docker)
Redis (Docker)

Spring JVM 설정 Default

사전 테스트

사용한 툴은, K6
모니터링은 전반적으로 ELK 스택과 JMX over HTTP 브리지는 Elasitc APM 과 Jolokia 채택
테스트 시간 : Jan 23, 2026 @ 12:48:14.051 ~ Jan 23, 2026 @ 13:16:29.819

테스트 시나리오

테스트 시나리오는, 사용자가 메인페이지에 접속해서, 특정 게시글을 보는 시나리오로 작성하였습니다.

Github 를 통해 전체 시나리오 스크립트를 확인할 수 있습니다.

해당 스크립트를,

3분간 0 -> 400 (Ramp Up)
20분간 400 (Sustain)
3분간 400 -> 0 (Ramp Down)

하였습니다.

결과 확인

최대 Throughput 은 14,005TPM 확인
P95 지표에서, Sustain 구간에서 가장 높은 Latency 는 1063ms
평균 적인 각각의 API 들은, P95 295ms ~ 350ms
CPU 사용율은 최대 피크에서 거의 100% 사용하는 것으로 판단

결과 상세 분석 (병목 지점 확정)

현재, 초반 Ramp-UP 구간에서는, P95 가 50ms 정도로 찍히는 것에 반해, 부하 단계에 갈 수록, 응답 속도가 저하.

Tomcat Thread Pool 역시 최대로 설정해둔 200보다 더 많은 양의 트래픽이 몰리는 것을 확인.

요청이 많아져 부족해졌다고 판단이 되어 200 보다 더 높게 설정해보는 것도 방법이겠지만, 정답은 아니라고 느낌

가장 큰 문제로 생각되는 DB Connection Pool 부족 현상이 발생

Active Connection 수가 증가됨에 따라, 커넥션이 부족해 연결을 처리하지 못하는 현상이 발생. (CP Pendding 상태 다수 증가)
요청에 비해서 데이터 처리 시간이 늦어, 반납이 늦는 것으로 확인

특히, 300ms 이상의 시간이 걸리는 트랜잭션을 확인해보면 실제 SQL 이 처리되는 시간보다, 대기시간이 압도적으로 길어 처리가 늦어지는 것을 원인으로 파악
단, Hikari CP 는, 현재 5로 설정되어있는데, 인프라의 한계로 더 늘려도 처리가 늦을 것으로 판단. (Hikari CP Connection Pool Size 계산식)

GC 관련되어서도 문제가 있다.

현재 너무 많은 GC 를 진행하고 있다.

부하 상황에서 10초에 GC 를 10회씩 진행하고 있는데 정말 말이 안되는 수치이다.

개선 방향

현재 인프라를 scale-up 하고, pool size 를 늘리면 확실히 더 많은 throughput 을 가져올 수 있을 것 이다.

단, 이 방향은 현재 제한적인 상황에서 먼저 해볼 해결 방안은 아니기 때문에 다음 두가지로 개선을 진행해볼 것 이다.

Query 개선
캐싱 처리
JVM 힙 메모리 증설

Query 개선

현재 블로그 서버에는 나 혼자만 글을 올리고 있기 때문에 큰 데이터가 들어가 있지 않다.

따라서 Query 자체를 개선해서 얻을 수 있는 효과는 미미할 것이다.

단, 추후 글을 계속 작성하게 되어 데이터가 많아질 경우, 혹은 검색 조건이 세분화될 경우를 대비해서 미리 이슈가 될만한 부분들을 개선한다.

캐싱 처리

현재 블로그 서버는 대부분 변화가 많이 없는 데이터가 서빙되는 경우가 많다.

따라서, 캐싱 처리를 통한 이점을 매우 크게 얻을 수 있을 듯 하다.

또한, 대부분의 병목 지점이 DB Connection 에서 진행되고 있기 때문에, DB Connection 자체를 없앨 수 있다면 매우 큰 폭의 성능 향상을 기대할 수 있을 것 이다.

JVM 힙 메모리 최적화

GC Count 또한 매우 빈번하게 이뤄지고 있는데, GC 를 할때 결국 Application 은 멈추게 되므로 이 또한 영향이 있을 것이다.

GC가 빈번한 이유는 객체 생성 자체가 많아서이기도 하지만, DB 커넥션을 기다리는 동안 쓰레드가 잡고 있는 객체들이 Eden 영역에 머무는 시간이 길어지기 때문일 것으로 판단하고 있다.

위의 2가지 개선을 처리하면 GC Count 또한 현저히 줄어들 것 이지만, 현재 Heap Mem 설정을 아예 진행하지 않았기 때문에 EC2 상황에 맞게 추가할 예정이다.

다음으로

다음 포스팅에서는 분석한 대로, 최적화를 진행해보겠습니다.

블로그 성능 개선기 V1 - (1) 지표 분석 및 병목 지점 파악

스택 시리즈🚀 백엔드 성능 최적화 관련!