당근페이 - 확장성 있는 TCP 통신 시스템 구축하기

[ecsimsw]

https://medium.com/daangn/%ED%99%95%EC%9E%A5%EC%84%B1-%EC%9E%88%EB%8A%94-tcp-%ED%86%B5%EC%8B%A0-%EC%8B%9C%EC%8A%A4%ED%85%9C-%EA%B5%AC%EC%B6%95%ED%95%98%EA%B8%B0-981c230cdc77

[ecsimsw]

환경

• 대외기관에서 TCP 통신을 직접 사용하는 경우가 발생함
• 각각의 마이크로 서비스에서 TCP 연동 처리 vs TCP를 위한 공통 시스템 개발을 고민
• 후자 선택, 마이크로 서비스에서 HTTP로 요청을 보내면 공통 시스템 (TCP gateway)에서 중개

• 공통 시스템 개발 프레임워크로 Netty 결정 (TCP를 사용하는 서버와 클라이언트를 쉽고 빠르게 개발할 수 있어요)

@PostMapping("v1/telegram/abank")
fun aBank(@RequestBody request: TelegramDto): ABankTelegramPayload {
    // 공통부 Deserialize
    val ABank헤더 = request.parseHeader(ABankTelegramHeader::class.java)
    // 공통부에 존재하는 전문 코드 값으로 전문 클래스 포맷 조회
    val 전문Class = TelegramClassResolver.getTelegramClass(ABankTelegramHeader)
    // 전체 전문 Deserialize
    val 요청전문 = request.parseTelegram(ABankGetBalanceOutboundPayload::class.java)
    // ABank 전용으로 구성한 TcpClient로 요청
    val 응답전문 = aBankTcpClient.process(요청전문)

    return 응답전문
}

[ecsimsw]

재밌는 포인트 : 요청과 응답의 서버가 다를 수 있다?

비동기방식의 TCP 통신에서는 이러한 방식의 구현으로는 제대로 동작되지 않아요. 비동기방식의 통신에서는 요청을 보낸 세션으로 응답이 오지 않을 수 있기 때문이에요.

• TCP 요청
• TCP 응답 / 요청한 서버와 다른 서버로 응답될 수 있음
• 응답을 받은 서버에서 Redis pub/sub으로 이벤트 발행.
• subscribe 하고 있는 서버 중 요청했던 서버에서 비동기 작업 완료 처리 (CompletableFuture)
• 요청한 서버 외 나머지 서버는 이벤트를 그저 버리는 것 같고.
• 이벤트가 유실되면? 처리 결과 조회로 거래 성공 여부 확인
• (MQ나 이벤트 브로커를 사용하지 않고, Redis pub/sub으로 처리한 이유도 궁금하군)

TCP Gateway와 마이크로 서비스 간 유실이 발생한 경우

통지를 받아야 할 마이크로 서비스에 장애가 발생할 경우 TCP Gateway가 전달한 전문들이 그대로 유실될 수 있어요. 따라서 TCP Gateway는 통지 전문에 한해서 전문을 미리 저장소에 저장해 두고, 재처리 가능한 기능을 제공했어요.