gRPC 핵심 개념과 RPC 생명주기

gRPC 핵심 개념과 RPC 생명주기 (Core Concepts)

gRPC를 쓰려면 서비스 정의, 네 가지 RPC 유형, 그리고 호출이 어떻게 이루어지는지(생명주기)를 아는 게 중요해요. 이 개념이 잡히면 언어 가이드가 훨씬 쉽게 읽혀요.

출처: https://grpc.io/docs/what-is-grpc/core-concepts/

서비스 정의는 .proto 파일에서 이뤄져요. gRPC는 네 가지 RPC 유형을 지원해요.

service HelloService {
  rpc SayHello (HelloRequest) returns (HelloResponse);            // unary
  rpc LotsOfReplies(HelloRequest) returns (stream HelloResponse); // server streaming
  rpc LotsOfGreetings(stream HelloRequest) returns (HelloResponse); // client streaming
  rpc BidiHello(stream HelloRequest) returns (stream HelloResponse); // bidirectional
}
  • Unary: 클라이언트가 요청 하나, 서버가 응답 하나 — 일반 함수 호출과 같아요.
  • Server streaming: 클라이언트가 요청 하나를 보내면 서버가 메시지 스트림을 돌려줘요.
  • Client streaming: 클라이언트가 메시지 스트림을 보내고 서버는 응답 하나를 돌려줘요.
  • Bidirectional streaming: 양쪽이 읽기·쓰기 스트림으로 메시지를 주고받아요. 두 스트림은 독립적이라 순서가 자유로워요. 예를 들어 서버가 핑퐁처럼 요청-응답을 번갈아 할 수도 있어요.

호출이 일어나는 흐름(RPC life cycle)도 특징적이에요. 단항 RPC에서는 클라이언트가 스텁 메서드를 부르면 서버에 RPC 호출이 알려지고, 서버가 초기 메타데이터(응답 전에 보내야 함)를 먼저 보내거나 클라이언트 요청을 기다려요. 그다음 서버가 응답과 함께 상태 코드·상태 메시지·후행 메타데이터를 돌려주고, OK면 클라이언트 쪽 호출이 완료돼요.

몇 가지 핵심 메커니즘을 짚어볼게요.

  • Deadline/Timeout: 클라이언트가 RPC 완료까지 기다릴 시간을 지정할 수 있어요. 넘기면 DEADLINE_EXCEEDED로 끝나요. 언어마다 시간(타임아웃) 기준이거나 고정 시점(deadline) 기준이에요.
  • Cancellation: 클라이언트나 서버 어느 쪽이든 RPC를 취소할 수 있어요. 취소 전에 일어난 변경이 롤백되지는 않아요(주의).
  • Metadata: 호출에 딸린 키-값 목록이에요(인증 정보 등). 키는 대소문자 구분 없고, grpc- 접두는 gRPC가 예약해요.
  • Channel: 지정한 호스트·포트의 gRPC 서버로 가는 연결이에요. 클라이언트 스텁을 만들 때 사용하고, 압축 설정 같은 채널 인자를 줄 수 있어요.

더 알아보기