📌 문제 상황 1. 즉각 요청-응답 프로세스는 외부 서비스와의 connection을 유지한 채 비관 lock을 잡기에, lock으로 인한 다양한 이슈가 외부 서비스로 전파될 위험 존재(ex. deadlock 발생시 connection도 대기) 2. 즉각 요청-응답 프로세스는 타행 이체(은행A→은행B 이체)를 2개의 API(이체 입금 요청 API, 이체 입금 완료 응답 API)로 구현하자는 은행 간 약속(프로토콜)을 무시하는 방법임. 📌 접근 방법과 해결과정 원인 분석 - 그림2 즉, 이체 입금 요청을 비동기로 처리하는 구조의 문제점 재파악. - 입금을 위해 비관 lock을 잡고 Network I/O를 하는 것이 가장 큰 문제라고 파악. - 특히 타행(이체 입금 역할)은 당행(이체 출금 역할)의 이체 내역..
목차 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. 이체 입금 요청 API 처리 방법별 장단점 4. API 로직 선정 및 테스트 5. 고민해봐야할 것 ✍️ 사전 지식 용어 당행 : 사용자로부터 이체 요청을 받고, 이체 입금을 진행하는 은행 타행 : 이체 과정에서 출금을 진행하는 은행 당행 이체 : 입금 은행과 출금 은행이 동일한 이체 타행 이체 : 입금 은행과 출금 은행이 다른 이체 OutBox 데이터 : 이벤트나 메시지를 DB에 있는 아웃박스에 저장해서 DB 트랜잭션의 일부로 발행하는 패턴을 Transactinal OutBOx라고 합니다. 서로 다른 서버의 트랜잭션을 관리하고 할 때, eventual consistency를 보장하기 위해 DB ..
목차 1. 문제 상황 2. 요구 사항 분석 3. 스케줄링 전략 선정 테스트 환경 스케줄러 전략 간단 요약 스케줄러 전략별 장단점 스케줄러 전략 상세 설명 및 테스트 결과 스케줄러 전략 3번 선택 4. 개선 필요 사항 ✍️ 사전 지식 용어 당행 : 사용자로부터 이체 요청을 받고, 이체 입금을 진행하는 은행 타행 : 이체 과정에서 출금을 진행하는 은행 당행 이체 : 입금 은행과 출금 은행이 동일한 이체 타행 이체 : 입금 은행과 출금 은행이 다른 이체 OutBox 데이터 : 이벤트나 메시지를 DB에 있는 아웃박스에 저장해서 DB 트랜잭션의 일부로 발행하는 패턴을 Transactinal OutBOx라고 합니다. 서로 다른 서버의 트랜잭션을 관리하고 할 때, eventual consistency를 보장하기 위해..
목차 1. 개요 2. 서버가 다운되면 무슨 일이 일어날까? 기존 타행 이체 순차 다이어그램 서버 다운 가능 지점 3. Transactional Outbox Pattern 이벤트 발행 패턴 선정 아웃박스 패턴을 적용한 순차 다이어그램 서버 다운 check, 아웃박스 패턴을 적용한 순차 다이어그램 이체 입금 요청 API의 멱등성 4. 구현 ✍️ 개요 이체 기능을 설계하면 가장 신경 쓴 것은 데이터 정합성이였습니다. 키워드의 검색 횟수 같은 데이터는 정합성이 완전하게 맞춰질 필요가 없을 수 있습니다. 하지만 돈과 같은 경우는 1원이 없어지더라도 이는 결국 회사 혹은 고객의 돈이 없어지는 것 이기 때문에 큰 문제로 이어질 수 있습니다. 그렇다면 돈은 언제 없어질까요? 돈은 이체 하는 과정에서 해피케이스가 아닌 ..
