📌 문제 상황

<그림1. 즉시 이체 처리 순차 다이어그램>

1. 즉각 요청-응답 프로세스는 외부 서비스와의 connection을 유지한 채 비관 lock을 잡기에, lock으로 인한 다양한 이슈가 외부 서비스로 전파될 위험 존재(ex. deadlock 발생시 connection도 대기)
2. 즉각 요청-응답 프로세스는 타행 이체(은행A→은행B 이체)를 2개의 API(이체 입금 요청 API, 이체 입금 완료 응답 API)로 구현하자는 은행 간 약속(프로토콜)을 무시하는 방법임.

📌 접근 방법과 해결과정

원인 분석

<그림2. 이체 입금 요청 비동기 처리 순차 다이어그램>

• 그림2 즉, 이체 입금 요청을 비동기로 처리하는 구조의 문제점 재파악.
• 외부 API 호출을 비관 lock을 잡고 하는 것이 가장 큰 문제(Network I/O를 기다려야 함).
• 외부 서비스 또한 DB 호출(Network I/O)를 할 수 있기에, 비관 lock waiting이 외부 API의 RTT에 의존.
  • 특히 타행(이체 입금 역할)은 당행(이체 출금 역할)의 이체 내역(완료) 변경 로직 실행까지 기다려야 하는 책임 존재.

측정

<그림3. Elastic stack으로 확인한 병목 구간. 비관 lock>

• 비관 lock을 잡고 외부 API를 호출 하는 것이 가장 큰 문제(Network I/O를 기다려야 함).
• 비관 락을 잡지 않고 외부 API를 호출하면 됨. 비관 락의 수명은 트랜잭션과 함께함. 따라서 외부 API 호출을 다른 트랜잭션에서 실행하면 lock waiting을 줄일 수 있다고 판단함.

해결 방법-1

1. 다른 트랜잭션에서 외부 API 호출하는 방법엔 2가지가 있었음. 서버 다운 상황에서 ‘이체 입금 완료 응답 API’ 호출을 보장하지 않는 방법과 보장하는 방법이 있었음.
2. 돈과 관련된 기능이기에 사용자 입장에선 어떻게든 빠른 시간 안에 이체 입금 완료 응답을 받는 것이 중요하다고 판단했고 이에 ‘이체 입금 완료 응답 API’ 호출을 보장하기로 결정함.