문제 해결
1.DB 커넥션 풀 튜닝
사이드 프로젝트로 커뮤니티 서비스를 개발하고 있습니다. AWS EC2 t2.micro에 Docker로 배포한 뒤 JMeter로 일반 사용자 시나리오 부하 테스트를 돌렸는데 에러가 폭발했습니다.
2.게시글 조회 댓글 첫 페이지 캐싱
게시글 상세 조회 시 댓글 첫 페이지가 함께 내려가는 구조였습니다. 댓글은 대댓글을 포함한 트리 구조로 구성되어 있어 재귀 CTE 기반 쿼리로 조회했는데, 게시글 상세를 조회할 때마다 이 무거운 쿼리가 반복 실행되는 것이 문제였습니다.
3.BCrypt strength 분리로 게스트 API 응답시간 55% 개선하기
사이드 프로젝트로 커뮤니티 서비스를 개발하고 있습니다. AWS EC2 t2.micro에 Docker로 배포한 뒤 JMeter로 일반 사용자 시나리오 부하 테스트를 돌렸는데 이상한 점을 발견했습니다.회원과 게스트가 같은 작업을 하는데 응답시간이 14배 차이가 났습니다.G
4.좋아요 중복 insert 경쟁 해결
좋아요 기능은 같은 사용자가 같은 대상에 중복 좋아요를 할 수 없도록 likes 테이블에 unique 제약을 두고, 토글 방식으로 좋아요/취소를 처리하고 있었습니다. DB 레벨에서 중복은 방지되지만, 동시 요청이 들어올 경우 unique 제약 위반 예외가 클라이언트에게
5.N+1 문제 해결
board 목록과 post 목록 조회 시 연관 엔티티(createdBy, author)를 DTO로 매핑하는 과정에서 지연 로딩이 발생하고 있었습니다. 목록 1회 조회 후 각 항목마다 추가 SELECT가 반복되는 전형적인 N+1 문제였습니다.board 목록 조회 시 cr
6.JVM 플래그 최적화
성능 테스트 중 재기동 직후 GC pause가 300ms까지 치솟으며 처리량이 일시적으로 급감하는 현상이 관측됐습니다. Endpoint Throughput 그래프에서 특정 시점에 처리량이 절반으로 떨어졌다가 회복되는 딥 구간이 나타났고, 이 시점과 GC pause 스파
7.likes 풀스캔 제거와 집계 쿼리 분리
post 약 100만 건, comment 약 1,180만 건이 적재된 상태에서 실제 서비스에 더 가까운 조건을 만들기 위해 hot post/comment 기준으로 likes 450만 건을 추가한 뒤 부하 테스트를 진행했습니다.테스트는 JMeter 100개 스레드, ra
8.게시글 목록 COUNT 쿼리 제거
popping_page_slowSlow Query Log를 분석하던 중 게시글 목록 조회 시마다 아래 쿼리가 반복 실행되고 있었습니다.부하 테스트(10분 구간) 동안 2,173건이 찍혔고, 건당 평균 실행 시간은 1,264ms였습니다.post.board_id에는 idx
9.캐시 스탬피드 방지
댓글 첫 페이지 캐싱을 적용한 뒤, 캐시가 evict되는 순간 동시 요청이 몰리면 어떤 일이 일어나는지 확인하고 싶었습니다. JMeter로 evict 직후 50개 요청을 동시에 보내고 Slow Query Log를 분석했습니다.동일 postId에 대한 CTE 쿼리가 1건
10.XSS 공격 방지 처리
XSS(Cross-Site Scripting)는 공격자가 게시글, 댓글, 닉네임 같은 입력 필드에 악성 스크립트를 삽입하고, 이것이 다른 사용자의 브라우저에서 실행되도록 만드는 공격입니다.이 스크립트가 그대로 저장됐다가 다른 사용자가 게시글 목록을 조회할 때 실행되면,
11.Scale Out — HAProxy와 App 수평 확장
댓글 트리 최적화로 응답시간은 28% 개선되었지만, App CPU는 여전히 200%(2코어 상한)로 포화 상태였다. 코드 최적화만으로는 한계가 있으므로, App 인스턴스를 추가하는 수평 확장(Scale Out)을 도입했다.
12.MySQL Read Replica 도입
Scale Out(HAProxy + App 2대)으로 App CPU 병목을 해소했지만, 병목이 MySQL로 이동했다.커뮤니티 서비스 특성상 읽기 트래픽이 90%를 차지하는데, 단일 MySQL이 읽기와 쓰기를 모두 처리하면서 CPU가 포화되고 있었다. 읽기 쿼리를 Rep
13.Replication Lag 완화 - 병렬 복제와 Sticky Primary
배경 이전 글에서 Read Replica를 도입하여 TPS +2.3%, 평균 응답시간 -67.1%(32ms → 10ms)를 달성했지만, 부하테스트 중 Replication Lag이 평균 104초, 최대 348초까지 발생했다. Lag 자체는 로컬 Docker 환경(총
14.부하테스트 수치를 믿을 수 있게 만들기 - 워밍업과 정상상태 판정
게시판 목록 페이지의 응답 크기를 줄이는 최적화를 했다. 게시글 20행마다 같은 SVG 아이콘 4개가 통째로 반복되고 있었고, <symbol> + <use> 스프라이트로 바꾸니 응답이 78,682B → 47,507B (-39.6%)로 줄었다.크기가 줄어든 것
15.왜 워밍업에 20분이 걸렸나 - 2코어 컨테이너의 JIT 컴파일러
부하 테스트 결과가 재현되지 않는 문제를 추적하다가, 원인이 JVM 워밍업이라는 결론에 도달했다. 그래서 측정 절차에 "버리는 워밍업 부하"를 넣었는데, 여기서 예상 밖의 결과가 나왔다.600초 부하를 완주하고도 워밍업이 안 끝났다. 한 번 더 돌려야 했다. 즉 10분