문제 해결

사이드 프로젝트로 커뮤니티 서비스를 개발하고 있습니다. AWS EC2 t2.micro에 Docker로 배포한 뒤 JMeter로 일반 사용자 시나리오 부하 테스트를 돌렸는데 에러가 폭발했습니다.

게시글 상세 조회 시 댓글 첫 페이지가 함께 내려가는 구조였습니다. 댓글은 대댓글을 포함한 트리 구조로 구성되어 있어 재귀 CTE 기반 쿼리로 조회했는데, 게시글 상세를 조회할 때마다 이 무거운 쿼리가 반복 실행되는 것이 문제였습니다.

사이드 프로젝트로 커뮤니티 서비스를 개발하고 있습니다. AWS EC2 t2.micro에 Docker로 배포한 뒤 JMeter로 일반 사용자 시나리오 부하 테스트를 돌렸는데 이상한 점을 발견했습니다.회원과 게스트가 같은 작업을 하는데 응답시간이 14배 차이가 났습니다.G

좋아요 기능은 같은 사용자가 같은 대상에 중복 좋아요를 할 수 없도록 likes 테이블에 unique 제약을 두고, 토글 방식으로 좋아요/취소를 처리하고 있었습니다. DB 레벨에서 중복은 방지되지만, 동시 요청이 들어올 경우 unique 제약 위반 예외가 클라이언트에게

board 목록과 post 목록 조회 시 연관 엔티티(createdBy, author)를 DTO로 매핑하는 과정에서 지연 로딩이 발생하고 있었습니다. 목록 1회 조회 후 각 항목마다 추가 SELECT가 반복되는 전형적인 N+1 문제였습니다.board 목록 조회 시 cr

성능 테스트 중 재기동 직후 GC pause가 300ms까지 치솟으며 처리량이 일시적으로 급감하는 현상이 관측됐습니다. Endpoint Throughput 그래프에서 특정 시점에 처리량이 절반으로 떨어졌다가 회복되는 딥 구간이 나타났고, 이 시점과 GC pause 스파

post 약 100만 건, comment 약 1,180만 건이 적재된 상태에서 실제 서비스에 더 가까운 조건을 만들기 위해 hot post/comment 기준으로 likes 450만 건을 추가한 뒤 부하 테스트를 진행했습니다.테스트는 JMeter 100개 스레드, ra

popping_page_slowSlow Query Log를 분석하던 중 게시글 목록 조회 시마다 아래 쿼리가 반복 실행되고 있었습니다.부하 테스트(10분 구간) 동안 2,173건이 찍혔고, 건당 평균 실행 시간은 1,264ms였습니다.post.board_id에는 idx

댓글 첫 페이지 캐싱을 적용한 뒤, 캐시가 evict되는 순간 동시 요청이 몰리면 어떤 일이 일어나는지 확인하고 싶었습니다. JMeter로 evict 직후 50개 요청을 동시에 보내고 Slow Query Log를 분석했습니다.동일 postId에 대한 CTE 쿼리가 1건

XSS(Cross-Site Scripting)는 공격자가 게시글, 댓글, 닉네임 같은 입력 필드에 악성 스크립트를 삽입하고, 이것이 다른 사용자의 브라우저에서 실행되도록 만드는 공격입니다.이 스크립트가 그대로 저장됐다가 다른 사용자가 게시글 목록을 조회할 때 실행되면,

댓글 트리 최적화로 응답시간은 28% 개선되었지만, App CPU는 여전히 200%(2코어 상한)로 포화 상태였다. 코드 최적화만으로는 한계가 있으므로, App 인스턴스를 추가하는 수평 확장(Scale Out)을 도입했다.

Scale Out(HAProxy + App 2대)으로 App CPU 병목을 해소했지만, 병목이 MySQL로 이동했다.커뮤니티 서비스 특성상 읽기 트래픽이 90%를 차지하는데, 단일 MySQL이 읽기와 쓰기를 모두 처리하면서 CPU가 포화되고 있었다. 읽기 쿼리를 Rep

배경 이전 글에서 Read Replica를 도입하여 TPS +2.3%, 평균 응답시간 -67.1%(32ms → 10ms)를 달성했지만, 부하테스트 중 Replication Lag이 평균 104초, 최대 348초까지 발생했다. Lag 자체는 로컬 Docker 환경(총