Backend

나는 현재 뱅킹 시스템을 혼자 만들어 보고 있었고 locust로 테스트를 하는데 deadlock을 만나게 되었다 transfer 서비스는 HTTP 요청을 받아 실제 이체를 처리하는 온라인 트랜잭션이다.available_balance에서 출금 가능 금액을 차감하고snap

0. 문제 상황 이전 글과 이어진다. 이전 글에서 snapshotbalance / availablebalance 업데이트 과정에서 데드락이 났던 원인과 해결 과정을 정리했다. 이번에는 스냅샷 프로젝터 (consumer) 쪽에서 비슷한 데드락이 다시 발생했다. 이전에

0. 3줄 요약 Actuator 의존성 추가 서버 재시작 후 터미널에 명령어 치고 커넥션 상태 확인 application.properties 기준 1. 왜 커넥션 풀을 볼까 저는 서버에 부하 테스트를 하였고 RPS가 올라감에 따라 응답속도가 증가하는 경험을 하였

0. 문제 상황 컨슈머 처리량이 20~40 msg/s 정도로 매우 느렸습니다. publish는 300~400 msg/s 까지 발행되었는데, 컨슈머가 따라가지 못해서 snapshot의 반영이 지연되었습니다. 1. 조건 DB: MySQL (동일 인스턴스) 테이블/

블로그 서버를 만들고 있었고, 인기글 기능을 추가한 뒤 부하 테스트를 돌리고 있었다.테스트 시나리오는 단순했다.상세 조회 API는 조회할 때 조회수(view_count)를 1 증가시킨다.인기글 API는 view_count DESC 로 상위 N개를 가져온다.게시글 상세

이전 글에서 약 10만 건 데이터 기준으로 부하 테스트를 했고, connection refused / 지연 폭증 / Hikari pending 증가 / InnoDB row lock wait 증가까지 연쇄 병목을 확인했다. 이번 글에서는 무엇을 어떻게 개선했고, 왜 그

ECS + ECR + GitHub Actions로 CI/CD를 구축하였다. 1. 먼저 ECR에 리포지토리 만들고 docker 빌드 파일 업로드하기 2. ECS에서 클러스터를 하나 만들고 태스크 정의를 ECR에서 만든 docker로 설정하기

지난 글에서는 git tag 푸시로 GitHub Actions => ECR push => ECS 롤링 배포가 되는 CI/CD 파이프라인을 구성했다.이번 글에서는 구축 과정에서 실제로 마주쳤던 오류들을 증상 => 원인 => 확인 => 해결 순서로 정리했다.같은 에러를 다