목차 1. 간단 요약 2. 사전 지식 3. 문제 상황 4. 접근 방법과 해결 과정 Gap lock 분석 현 설계의 문제점 로컬 테스트로 검증 개선 방향 성능 테스트 5. 결과 6. 배운점 ✍️ 간단 요약 OutBox 데이터를 polling 하는 스케줄러가 읽기 연산을 할 경우, connection은 (마지막 레코드, 무한대) 범위에 gap lock을 겁니다(MySQL ver 8.0 innodb, Repeatable-read 기준). 그로 인해 이체 출금의 insert 쿼리가 병목이 되어 TPS가 낮게 나왔었습니다. Read Committed로 변경한 결과, gap lock의 해제를 기다리지 않고 insert할 수 있게 됐습니다. 이는 Mean Test Time 감소로 이어져 tps를 86%(66.6 → ..
목차 1. 개요 2. 서버가 다운되면 무슨 일이 일어날까? 기존 타행 이체 순차 다이어그램 서버 다운 가능 지점 3. Transactional Outbox Pattern 이벤트 발행 패턴 선정 아웃박스 패턴을 적용한 순차 다이어그램 서버 다운 check, 아웃박스 패턴을 적용한 순차 다이어그램 이체 입금 요청 API의 멱등성 4. 구현 ✍️ 개요 이체 기능을 설계하면 가장 신경 쓴 것은 데이터 정합성이였습니다. 키워드의 검색 횟수 같은 데이터는 정합성이 완전하게 맞춰질 필요가 없을 수 있습니다. 하지만 돈과 같은 경우는 1원이 없어지더라도 이는 결국 회사 혹은 고객의 돈이 없어지는 것 이기 때문에 큰 문제로 이어질 수 있습니다. 그렇다면 돈은 언제 없어질까요? 돈은 이체 하는 과정에서 해피케이스가 아닌 ..
목차 1. 프로젝트 소개 2. 프로젝트 개선 그래프 3. 트래픽의 개략적인 측정 4. 서버 인프라 구성 5. 문서화 ✍️ 프로젝트 소개 카카오 뱅크, 토스 뱅크, 케이 뱅크 등 은행 도메인의 돈통을 구현하는 프로젝트 입니다. 은행에서는 이자 적립, 예약 이체 등 여러 기능들이 있지만, 현 프로젝트에선 대용량의 트래픽이 발생하는 상황에서 '이체' 기능을 잘 수행할 수 있는 백엔드 개발을 중시했습니다. 데이터 정합성, 속도와 사용자 경험을 생각하며 이체 기능을 설계하고 구현했습니다. 서버에 장애가 일어나는 상황을 생각하며 데이터 정합성을 고려했고, 속도 관련 이슈를 해결하기 위해 nGrinder와 APM을 이용하여 객관적인 근거를 찾았습니다. 해결 방법을 찾을 때는 사용자 경험을 고려하며 기획과 Engine..
