Backend
1.Spring mysql jpa 데드락 상황 해결 과정
나는 현재 뱅킹 시스템을 혼자 만들어 보고 있었고 locust로 테스트를 하는데 deadlock을 만나게 되었다 transfer 서비스는 HTTP 요청을 받아 실제 이체를 처리하는 온라인 트랜잭션이다.available_balance에서 출금 가능 금액을 차감하고snap
2.Spring mysql jpa 데드락 상황 해결 과정 (REQUIRES_NEW)
0. 문제 상황 이전 글과 이어진다. 이전 글에서 snapshotbalance / availablebalance 업데이트 과정에서 데드락이 났던 원인과 해결 과정을 정리했다. 이번에는 스냅샷 프로젝터 (consumer) 쪽에서 비슷한 데드락이 다시 발생했다. 이전에
3.스프링 서버에서 커넥션 풀(Connection Pool) 확인하고 조절하는 방법 (HikariCP/Actuator)
0. 3줄 요약 Actuator 의존성 추가 서버 재시작 후 터미널에 명령어 치고 커넥션 상태 확인 application.properties 기준 1. 왜 커넥션 풀을 볼까 저는 서버에 부하 테스트를 하였고 RPS가 올라감에 따라 응답속도가 증가하는 경험을 하였
4.RabbitMQ consumer 처리량 개선 과정
0. 문제 상황 컨슈머 처리량이 20~40 msg/s 정도로 매우 느렸습니다. publish는 300~400 msg/s 까지 발행되었는데, 컨슈머가 따라가지 못해서 snapshot의 반영이 지연되었습니다. 1. 조건 DB: MySQL (동일 인스턴스) 테이블/
5.블로그 인기글 부하 테스트 병목현상 개선 과정
블로그 서버를 만들고 있었고, 인기글 기능을 추가한 뒤 부하 테스트를 돌리고 있었다.테스트 시나리오는 단순했다.상세 조회 API는 조회할 때 조회수(view_count)를 1 증가시킨다.인기글 API는 view_count DESC 로 상위 N개를 가져온다.게시글 상세
6.블로그 인기글 부하 테스트 병목현상 개선 과정 2
이전 글에서 약 10만 건 데이터 기준으로 부하 테스트를 했고, connection refused / 지연 폭증 / Hikari pending 증가 / InnoDB row lock wait 증가까지 연쇄 병목을 확인했다. 이번 글에서는 무엇을 어떻게 개선했고, 왜 그