gRPC 계약

Nest gRPC 오류 계약

gRPC를 쓰면 HTTP보다 빠르다는 식의 설명만으로는 서비스 간 통신을 운영할 수 없다. proto 메시지 호환성, package와 service 이름, deadline, retry, metadata 인증, status code 매핑을 정해야 호출 실패가 장애로 번지지 않는다.

proto 계약 package, service, message 이름과 field 번호를 먼저 고정한다
status mapping NOT_FOUND, INVALID_ARGUMENT, UNAVAILABLE을 HTTP와 도메인 오류에 맞춘다
trace/retry metadata auth, request id, retry 조건을 운영 로그와 연결한다
01

proto 고정

service 메서드, request, response, field number를 변경 호환성 기준으로 정의한다.

field number 재사용은 오래된 클라이언트를 깨뜨린다
02

클라이언트 연결

ClientGrpc에서 package와 service 이름이 proto와 일치하는지 확인한다.

이름 불일치는 런타임 undefined로 드러난다
03

deadline 설정

무한 대기 대신 호출 목적에 맞는 timeout과 취소 정책을 둔다.

느린 의존성이 전체 요청을 묶어두지 않게 한다
04

오류 매핑

NOT_FOUND, INVALID_ARGUMENT, UNAVAILABLE 같은 status를 HTTP나 도메인 오류로 변환한다.

모든 실패를 500처럼 다루면 복구가 어렵다
05

관측 연결

metadata, correlation id, tracing span으로 서비스 간 요청을 따라갈 수 있게 한다.

분산 호출은 로그가 이어져야 디버깅된다
Proto
호환 계약 새 필드는 번호를 추가하고 기존 의미를 바꾸지 않는다.
required처럼 되돌리기 어려운 제약을 조심한다
Deadline
대기 상한 호출자가 기다릴 수 있는 시간을 명시하고 초과 시 빠르게 실패한다.
서버 처리 시간과 네트워크 시간을 함께 본다
Retry
재시도 가능성 idempotent 읽기와 중복 실행 위험이 있는 쓰기를 분리한다.
재시도는 장애를 증폭할 수 있다
Metadata
인증과 추적 토큰, tenant, request id를 metadata로 전달하고 서버에서 검증한다.
로그에도 같은 id를 남긴다

통신 확인

이름 일치 proto package, service, 메서드명이 Nest 등록 이름과 같은지 확인한다.
실패 재현 서버 중단, timeout, 잘못된 request를 각각 호출해 status 매핑을 본다.
로그 연결 API Gateway에서 내부 gRPC 서비스까지 같은 request id로 추적되는지 확인한다.