gRPC를 쓰면 HTTP보다 빠르다는 식의 설명만으로는 서비스 간 통신을
운영할 수 없다. proto 메시지 호환성, package와 service 이름,
deadline, retry, metadata 인증, status code 매핑을 정해야 호출
실패가 장애로 번지지 않는다.
proto 계약package, service, message 이름과 field 번호를 먼저 고정한다
→
status mappingNOT_FOUND, INVALID_ARGUMENT, UNAVAILABLE을 HTTP와 도메인 오류에
맞춘다
→
trace/retrymetadata 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 package, service, 메서드명이 Nest 등록 이름과 같은지
확인한다.실패 재현서버 중단, timeout, 잘못된 request를 각각 호출해 status 매핑을
본다.로그 연결API Gateway에서 내부 gRPC 서비스까지 같은 request id로
추적되는지 확인한다.