gRPC 호출은 빠르게 실패하고 정확한 status를 돌려줄 때 운영 가능하다. 배포 전후에는 proto 호환성, deadline, 오류 매핑, trace 연결을 같은 표에서 확인한다.
필드 번호를 재사용하지 않고 optional 추가로 호환성을 지킨다.
새 서버와 옛 클라이언트의 메시지 해석이 달라진다.
proto review와 consumer test를 배포 조건으로 둔다.
HTTP 요청 시간 안에 gRPC deadline이 더 짧게 잡혀 있다.
하위 서비스 지연이 API thread와 사용자 요청을 붙잡는다.
deadline exceeded를 fallback 또는 명확한 HTTP 오류로 바꾼다.
NOT_FOUND, INVALID_ARGUMENT, UNAVAILABLE 의미를 구분한다.
모든 실패가 500 또는 빈 객체로 숨겨져 원인을 잃는다.
RpcException과 HTTP 변환 규칙을 한 곳에 둔다.
HTTP trace id가 gRPC metadata와 서버 로그까지 이어진다.
느린 호출이 어느 서비스에서 시작됐는지 역추적이 어렵다.
metadata 전파와 service name 태그를 관측 기준에 포함한다.
클라이언트와 서버가 같은 proto version으로 실행되는지 본다.
localhost:50051, TLS, package 옵션이 환경별로 맞는지 본다.
GetUserById 정상, 미존재, 잘못된 id를 모두 호출한다.
한 요청이 HTTP 로그와 gRPC 서버 로그에서 같은 id로 보인다.