최근 회사에서 서버간 gRPC 통신, 프로세스간 RPC 통신 등… 체결엔진을 개발하면서 RPC 통신을 하기도 하고,

IPC를 시도하는 등 성능을 끌어올리기 위해 많은 시행착오를 거쳤다.

그 중에서 에러를 처리하는 것으로 잠시 나왔던 안건이 있는데, 간단하게 소개하면서 TCP와 UDP에 대해서 왜 다루게 되었는지 소개하고자 한다.

당시 체결 관련된 서버에서는 5가지의 프로세스가 있었다.

• gRPC gateway: 지정가/시장가 주문 받고 오더북 관리, 매칭되는 주문은 체결 프로세스로 전송

• Matching process: 받은 주문을 조건에 맞게 체결, 체결 이벤트(matching event)를 전송

• Placement process: 지정가 주문이 오더북에 등록되면 등록 이벤트(placement)를 전송

• Refund process: 시장가 주문 실패, 주문 취소 등의 경우 환불 처리 후 이벤트 전송

• Event process: 이벤트를 수거해서 알맞은 서버로 전송 및 db 반영

go 언어 기반으로 짜여진 코드에서 에러 처리 구문을 하다보면 코드가 몇 백줄은 기본으로 넘어갔다.

에러에 에러처리, 다시 그 에러의 에러 처리… DRY 원칙은 이미 먼 얘기가 되어 있었다.

(redis에 set이 실패하면, rds 에러 테이블에 insert, 그것도 실패하면 슬랙 알림, 그것도 실패하면 syslog…)

그 때 나온 안건이 바로 다음 안건이었다.

• Error process 생성

• critical한 에러가 아닌 경우는 UDP 통신으로 Error process에 전송

• Error process는 받은 에러에 대해서는 Slack 알림 전송 보장

• Sender(보낸 프로세스)에서는 에러를 처리한 것으로 간주하고 다른 작업 수행

UDP로 에러를 전송하는 것에 대해서 회의적이기도 했고, 사실 에러를 명시적으로 무시하고 가는 것과 큰 차이가 없다고 판단해서 다른 방법으로 처리되었다.

그래도 이왕 얘기가 나온 김에 차이점에 대해서 간단하게 짚고 넘어가면 좋을 것 같다.

TCP는 연결 지향형 프로토콜이고 UDP는 데이터를 데이터그램단위로 전송하는 프로토콜이다.

TCP는 가상 회선을 만들어 신뢰성을 보장하도록(흐름 제어, 혼잡 제어, 오류 제어) 하는 프로토콜이다.

당연히 따로 신뢰성을 보장하기 위한 절차가 없는 UDP에 비해 속도가 느린편이다.

물론 UDP도 신뢰성을 UDP자체에서 보장하지 않는 것 뿐이지, 개발자가 직접 신뢰성을 보장하도록 할 수 있다.

그래서 HTTP/3은 QUIC이라는 프로토콜을 기반으로 하는데, QUIC은 UDP를 기반으로 한다.

즉, UDP 자체는 신뢰성을 보장하지 않지만, 추가적인 정의를 통해 신뢰성을 보장받을 수 있다.

++ golang에서 net/rpc package와 net package의 UDPConn package를 사용해서 간단한 프로세스간 통신을 구현한 예시

https://github.com/Gimmingyu/golang-ipc

최근 회사에서 서버간 gRPC 통신, 프로세스간 RPC 통신 등… 체결엔진을 개발하면서 RPC 통신을 하기도 하고,

IPC를 시도하는 등 성능을 끌어올리기 위해 많은 시행착오를 거쳤다.

그 중에서 에러를 처리하는 것으로 잠시 나왔던 안건이 있는데, 간단하게 소개하면서 TCP와 UDP에 대해서 왜 다루게 되었는지 소개하고자 한다.

당시 체결 관련된 서버에서는 5가지의 프로세스가 있었다.

• gRPC gateway: 지정가/시장가 주문 받고 오더북 관리, 매칭되는 주문은 체결 프로세스로 전송

• Matching process: 받은 주문을 조건에 맞게 체결, 체결 이벤트(matching event)를 전송

• Placement process: 지정가 주문이 오더북에 등록되면 등록 이벤트(placement)를 전송

• Refund process: 시장가 주문 실패, 주문 취소 등의 경우 환불 처리 후 이벤트 전송

• Event process: 이벤트를 수거해서 알맞은 서버로 전송 및 db 반영

go 언어 기반으로 짜여진 코드에서 에러 처리 구문을 하다보면 코드가 몇 백줄은 기본으로 넘어갔다.

에러에 에러처리, 다시 그 에러의 에러 처리… DRY 원칙은 이미 먼 얘기가 되어 있었다.

(redis에 set이 실패하면, rds 에러 테이블에 insert, 그것도 실패하면 슬랙 알림, 그것도 실패하면 syslog…)

그 때 나온 안건이 바로 다음 안건이었다.

• Error process 생성

• critical한 에러가 아닌 경우는 UDP 통신으로 Error process에 전송

• Error process는 받은 에러에 대해서는 Slack 알림 전송 보장

• Sender(보낸 프로세스)에서는 에러를 처리한 것으로 간주하고 다른 작업 수행

UDP로 에러를 전송하는 것에 대해서 회의적이기도 했고, 사실 에러를 명시적으로 무시하고 가는 것과 큰 차이가 없다고 판단해서 다른 방법으로 처리되었다.

그래도 이왕 얘기가 나온 김에 차이점에 대해서 간단하게 짚고 넘어가면 좋을 것 같다.

TCP는 연결 지향형 프로토콜이고 UDP는 데이터를 데이터그램단위로 전송하는 프로토콜이다.

TCP는 가상 회선을 만들어 신뢰성을 보장하도록(흐름 제어, 혼잡 제어, 오류 제어) 하는 프로토콜이다.

당연히 따로 신뢰성을 보장하기 위한 절차가 없는 UDP에 비해 속도가 느린편이다.

물론 UDP도 신뢰성을 UDP자체에서 보장하지 않는 것 뿐이지, 개발자가 직접 신뢰성을 보장하도록 할 수 있다.

그래서 HTTP/3은 QUIC이라는 프로토콜을 기반으로 하는데, QUIC은 UDP를 기반으로 한다.

즉, UDP 자체는 신뢰성을 보장하지 않지만, 추가적인 정의를 통해 신뢰성을 보장받을 수 있다.

++ golang에서 net/rpc package와 net package의 UDPConn package를 사용해서 간단한 프로세스간 통신을 구현한 예시

https://github.com/Gimmingyu/golang-ipc