개요
- 공식 사이트
- 라이센스: Apache 2.0
- 구글이 개발한 고성능 오픈소스 RPC 프레임워크
- CNCF Incubating Project
- 20개 이상의 언어 공식 지원, HTTP/2 기반 크로스 플랫폼
- REST API 대비 특징
- Protocol Buffers (이진 직렬화) → 페이로드 크기 약 60~80% 감소
- HTTP/2 멀티플렉싱 → 단일 연결로 다수의 스트림 병렬 처리
- 양방향 스트리밍 지원
- 강타입(Strongly Typed) IDL로 API 계약 명확화
- 주요 사용 시나리오
- MSA 기반 내부 서비스 간 통신
- 모바일·IoT 클라이언트와 백엔드 연결 (낮은 대역폭)
- 실시간 스트리밍 (채팅, 로그 수집, 센서 데이터)
Protocol Buffers (protobuf)
- gRPC의 기본 IDL(Interface Definition Language) 및 직렬화 포맷
.proto 파일에 서비스 및 메시지 정의 → 각 언어 코드 자동 생성
- 특징
- 이진(Binary) 직렬화 → JSON 대비 빠른 파싱, 작은 크기
- 스키마 버전 관리 (필드 번호 기반 하위 호환성)
protoc 컴파일러로 다언어 코드 생성
- 예시 (
.proto 파일)
syntax = "proto3";
package hello;
option go_package = "example/hello";
// 서비스 정의
service Greeter {
// Unary RPC
rpc SayHello (HelloRequest) returns (HelloReply);
// Server Streaming RPC
rpc SayHelloStream (HelloRequest) returns (stream HelloReply);
}
// 메시지 정의
message HelloRequest {
string name = 1;
}
message HelloReply {
string message = 1;
}
서비스 종류
- 클라이언트가 단일 요청을 보내고 단일 응답을 받는 기본 RPC
- 일반적인 요청-응답 패턴 (REST API와 유사)
- 흐름:
Client → Request → Server → Response → Client
- 클라이언트가 단일 요청을 보내고, 서버가 스트림으로 다수의 메시지를 응답
- 클라이언트는 스트림이 끝날 때까지 메시지를 순서대로 수신
- 사용 예: 실시간 로그 조회, 대용량 데이터 페이지 스트리밍
- 흐름:
Client → Request → Server → Stream(Response...) → Client
- 클라이언트가 스트림으로 다수의 메시지를 서버에 전송하고, 서버가 단일 응답 반환
- 서버는 모든 메시지를 수신한 후 응답
- 사용 예: 파일 업로드, 배치 데이터 전송
- 흐름:
Client → Stream(Request...) → Server → Response → Client
- 클라이언트와 서버가 독립적인 스트림으로 동시에 메시지를 주고받는 RPC
- 두 스트림은 독립적으로 동작하며 순서는 각 스트림 내에서 보장
- 사용 예: 실시간 채팅, 양방향 데이터 동기화
- 흐름:
Client ↔ Stream ↔ Server
핵심 개념
- 클라이언트는 RPC 완료 기한(Deadline) 설정 가능
- 기한 초과 시
DEADLINE_EXCEEDED 오류 반환
- 서버는 남은 시간 또는 타임아웃 여부를 API로 확인 가능
- 클라이언트와 서버가 각각 독립적으로 타임아웃 추적
- 호출 성공 여부를 클라이언트와 서버가 독립적으로 결정
- 서버가 응답을 보냈으나 클라이언트 타임아웃이 먼저 만료된 경우
- 서버 관점: 성공
- 클라이언트 관점: 실패 (
DEADLINE_EXCEEDED)
- 클라이언트 또는 서버는 언제든지 RPC 취소 가능
- 취소는 즉시 처리되며, 이미 완료된 변경 사항은 롤백되지 않음
- 취소 시 상대방에게
Cancelled 상태 전달
- key-value 쌍으로 구성되는 RPC 호출의 부가 정보 (HTTP 헤더와 유사)
- 인증 토큰, 요청 ID, 트레이싱 정보 등을 전달할 때 사용
- gRPC 채널은 특정 호스트와 포트에 대한 연결을 추상화
- 채널은 연결 풀링, 부하 분산, 재연결 등을 내부적으로 처리
- Stub(클라이언트 객체)은 채널 위에서 동작
상태 코드
- gRPC는 HTTP 상태 코드 대신 자체 상태 코드를 사용
| 코드 |
이름 |
설명 |
| 0 |
OK |
성공 |
| 1 |
CANCELLED |
호출 취소됨 |
| 2 |
UNKNOWN |
알 수 없는 오류 |
| 4 |
DEADLINE_EXCEEDED |
데드라인 초과 |
| 5 |
NOT_FOUND |
엔티티를 찾을 수 없음 |
| 7 |
PERMISSION_DENIED |
권한 없음 |
| 8 |
RESOURCE_EXHAUSTED |
리소스 한계 초과 |
| 14 |
UNAVAILABLE |
서버 일시 불가 |
| 16 |
UNAUTHENTICATED |
인증 정보 없음 또는 유효하지 않음 |
REST vs gRPC 비교
| 항목 |
REST |
gRPC |
| 프로토콜 |
HTTP/1.1 (주로) |
HTTP/2 |
| 데이터 포맷 |
JSON (텍스트) |
Protocol Buffers (이진) |
| API 계약 |
OpenAPI (선택) |
.proto 파일 (필수) |
| 스트리밍 |
제한적 (SSE, WebSocket 별도) |
기본 지원 (양방향) |
| 코드 생성 |
선택 |
자동 생성 |
| 브라우저 직접 호출 |
가능 |
제한적 (grpc-web 필요) |
| 성능 |
보통 |
고성능 |