gRPC 에러 처리
gRPC 에러 처리 (Error Handling)
gRPC 호출이 항상 성공하진 않아요. 네트워크 문제부터 인증 실패까지 다양한 이유로 실패하는데, gRPC는 그걸 상태 코드(status code)로 표현해요. 에러 처리를 제대로 알면 클라이언트에서 실패를 예측하고 대응할 수 있어요.
기본(표준) 에러 모델은 간단해요. 호출이 성공하면 서버가 OK 상태를 돌려주고, 실패하면 상태 코드 하나와 옵션인 문자열 에러 메시지를 돌려줘요. 이 모델은 모든 gRPC 언어와 데이터 형식에서 동일하게 지원돼요.
자주 맞닥뜨리는 상태 코드 몇 가지를 볼게요.
| 상황 | 상태 코드 |
|---|---|
| 클라이언트가 요청 취소 | GRPC_STATUS_CANCELLED |
| 서버가 상태를 돌려주기 전에 deadline 만료 | GRPC_STATUS_DEADLINE_EXCEEDED |
| 서버에 메서드 없음 | GRPC_STATUS_UNIMPLEMENTED |
| 서버 종료 중 | GRPC_STATUS_UNAVAILABLE |
| 서버에서 예외 발생 | GRPC_STATUS_UNKNOWN |
| 인증 실패(자격증명 메타데이터 획득 실패 등) | GRPC_STATUS_UNAUTHENTICATED |
프로토콜 버퍼를 데이터 형식으로 쓴다면, 더 풍부한 에러 모델(Google의 richer error model)도 고려할 수 있어요. 이 모델은 에러 상세를 protobuf 메시지로 표현해 응답의 후행 메타데이터(trailer)에 실어 보내요. 잘못된 파라미터, 쿼터 초과, 스택 트레이스 같은 것들을 구조적으로 전달할 수 있죠. 다만 이 모델은 언어별 구현 일관성이 아직 제각각이고, 기존 프록시·로거가 트레일러의 에러 상세를 보지 못한다는 점, 트레일러가 HTTP/2 헤더 압축 효율에 영향을 준다는 점 같은 고려 사항이 있어요. 프로토콜 버퍼를 안 쓴다면 응답 트레일러에 에러 상세를 직접 넣는 유사한 방식도 가능해요.
더 알아보기
- Google의 풍부한 에러 모델: google/apis errors
- 표준 에러 메시지 타입 정의: error_details.proto