2 분 소요

개요

  • 공식 사이트
  • 라이센스: 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;
}


서비스 종류

Unary RPC

  • 클라이언트가 단일 요청을 보내고 단일 응답을 받는 기본 RPC
  • 일반적인 요청-응답 패턴 (REST API와 유사)
  • 흐름: Client → Request → Server → Response → Client

Server Streaming RPC

  • 클라이언트가 단일 요청을 보내고, 서버가 스트림으로 다수의 메시지를 응답
  • 클라이언트는 스트림이 끝날 때까지 메시지를 순서대로 수신
  • 사용 예: 실시간 로그 조회, 대용량 데이터 페이지 스트리밍
  • 흐름: Client → Request → Server → Stream(Response...) → Client

Client Streaming RPC

  • 클라이언트가 스트림으로 다수의 메시지를 서버에 전송하고, 서버가 단일 응답 반환
  • 서버는 모든 메시지를 수신한 후 응답
  • 사용 예: 파일 업로드, 배치 데이터 전송
  • 흐름: Client → Stream(Request...) → Server → Response → Client

Bidirectional Streaming RPC

  • 클라이언트와 서버가 독립적인 스트림으로 동시에 메시지를 주고받는 RPC
  • 두 스트림은 독립적으로 동작하며 순서는 각 스트림 내에서 보장
  • 사용 예: 실시간 채팅, 양방향 데이터 동기화
  • 흐름: Client ↔ Stream ↔ Server


핵심 개념

Deadlines / Timeouts

  • 클라이언트는 RPC 완료 기한(Deadline) 설정 가능
  • 기한 초과 시 DEADLINE_EXCEEDED 오류 반환
  • 서버는 남은 시간 또는 타임아웃 여부를 API로 확인 가능
  • 클라이언트와 서버가 각각 독립적으로 타임아웃 추적

RPC Termination

  • 호출 성공 여부를 클라이언트와 서버가 독립적으로 결정
  • 서버가 응답을 보냈으나 클라이언트 타임아웃이 먼저 만료된 경우
    • 서버 관점: 성공
    • 클라이언트 관점: 실패 (DEADLINE_EXCEEDED)

Cancelling an RPC

  • 클라이언트 또는 서버는 언제든지 RPC 취소 가능
  • 취소는 즉시 처리되며, 이미 완료된 변경 사항은 롤백되지 않음
  • 취소 시 상대방에게 Cancelled 상태 전달

Metadata

  • key-value 쌍으로 구성되는 RPC 호출의 부가 정보 (HTTP 헤더와 유사)
  • 인증 토큰, 요청 ID, 트레이싱 정보 등을 전달할 때 사용

Channels

  • 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 필요)
성능 보통 고성능


언어별 사용방법

  • 예제