금융결제원 연계 프로젝트를 14개월, 최종 오픈을 3월에 했다.
그리고 이제 운영모드에 들어섰다.
금결원은 백여개가 넘는 은행 사이에서 거래를 중계하며, 각종 자금 처리를 한다.
그러기 위해 각종 기관이 장애일 경우에에도, 사라지는 거래가 없고, 금융 거래가 한정된 시간 내에 문제 없이 수행되도록 업무를 설계해두어서
설계서를 읽으면서 장애에 대비한 설계에 대해 배우는 점이 있다.
- 장애가 발생했을 때
- 어떤 은행이 장애 상태인지 확인할 수 있는 ‘장애통보’ api가 있다.
- 장애가 풀렸을 때 다시 수행할 수 있도록, 영업 종료 후에 특정 시간대에 거래 재처리 시간을 준다.
- 응답이 누락된 거래의 경우 응답을 다시 요청하는 재시도 flag가 있다.
- 만약 A은행에서 B은행으로 보낸 거래를 B은행에서 받지 못했을 경우를 대비해, 당일에 거래완료 응답을 받지 못한 거래를 ‘미완료거래’로 리스트업 하여 전달하여 최종적으로 처리한다.
- 장애 전파를 막기 위해서인지, 타 은행이 장애 상태일 때, 거래를 보내면 그 거래를 선재적으로 무시한다.
- SAF (store and foward) 파일에 저장해두었다가 장애 상태 회복 후 전송하여 처리할 수도 있다.
- 만약 저장해두었던 파일을 처리하는데, 그 거래건이 이미 취소로 들어와 있으면 취소대상거래를 삭제처리하여 뒤늦게 처리되는 일이 없도록 한다.
- http 상태코드마냥 거래에 대한 응답코드가 0번대부터 900번대까지(업무에 따라 1000자리까지 가는 업무도 있다) 세팅되어 어떤 오류인지 표기하여 응답을 준다.
- 각 기관 (취급은행, 개설은행, 결제원)간 거래 tracking
- 각 api의 고유한 전문번호가 있고, 각 거래의 serial번호가 있다. serial번호는 매일 초기화된 후 다시 초기값부터 채번된다. 이 고유번호로 비동기로 처리되는 거래의 응답이 들어오면 요청 전문을 복원할 수 있다.
- 각 기관이 공유하는 거래고유번호가 상이하게 비어있는 구간이 있을 경우 각 거래들이 분실되는 것에 대비해 ‘결번조회’를 해서 없어진 번호를 계속해서 추적한다.
장애에 대비한 설계를 할 때 생각해볼만한 포인트들을 짚어가면서 대비해놓은 것이 인상적이다.
