금융서비스 MSA 전환기: 서버 간 비동기 메시지 기반 통신 처리(3편)

FINDA 자산/신용관리 PT는 대량 트래픽이 몰리는 운영 환경에서 동기식 통신만으로는 처리 효율과 안정성을 확보하기 어렵다고 판단했고, 서버 간 의존성을 줄이는 EDA(Event Driven Architecture) 기반 비동기 구조로 전환했다.

핵심 선택지는 세 가지였다.

• Apache Kafka: 서버 간 비동기 메시지 전달을 위한 Produce/Consume 채널
• Redis: SSE 통신의 서버 스케일아웃 대응용 Pub/Sub과 Distributed Lock
• SSE: 클라이언트로 단방향 이벤트를 전달하는 방식

실시간 이벤트 전달 방식은 Polling, Long Polling, WebSocket과 비교한 끝에 SSE가 가장 적합하다고 정리했다. 마이데이터 조회처럼 클라이언트가 요청을 보내고 서버가 결과를 받아오는 단방향 갱신 흐름에는, 양방향 통신보다 SSE가 더 단순하고 목적에 맞았다. HTTP/2가 없을 경우 브라우저 연결 수 제한이 있다는 점도 함께 짚었다.

구조는 다음 흐름으로 설계됐다.

1. 클라이언트가 AMS API에 SSE 연결을 생성하고, Redis로 중복 호출 여부를 확인한다.
2. 여신/수신 관리 서버가 마이데이터관리 서버로 Kafka topic에 메시지를 보내 Refresh를 요청한다.
3. 여신/수신 관리 서버는 캐시를 먼저 응답하고, 비동기 결과가 오면 SSE로 다시 내려준다.
4. 마이데이터관리 서버는 Worker와 Kafka로 요청/응답을 주고받고, 상태 관리를 위해 Redisson 기반 Distributed Lock을 사용한다.
5. Worker는 외부 마이데이터 포털이나 금융사와 통신해 실제 데이터를 수집한다.
6. 최종 응답은 Kafka를 통해 다시 소비되어 DB와 Redis에 저장된다.

특히 getLmsAccountListByAsync, send, hincrByLock, loanRefreshResponseListen 같은 코드 조각을 통해, 요청 접수부터 결과 반영까지를 메시지 기반 비동기 흐름으로 끊어냈다는 점을 보여준다. 결과적으로 클라이언트는 캐시 여부를 구분해 다루지 않고도 화면을 렌더링할 수 있게 되었고, 서버 간 느린 API 호출이 전체 요청 처리 경로를 막는 문제를 줄이려는 방향이 분명해졌다.