[gRPC] gRPC에 대해서 알아보자 - 기본 컨셉편

안녕하세요. 오늘은 gRPC에 대해서 알아보는 시간을 가져보도록 하겠습니다.

gRPC 개요

gRPC는 HTTP/2를 기반으로 Protocol Buffers로 정의하며 통신시 바이트 스트림으로 통신하게 됩니다. 따라서 Json 기반으로 통신하는 Rest API 보다 더 가볍습니다. 또한 gRPC는 HTTP/2 기반이기 때문에 하나의 채널 커넥션을 맺고 그 커넥션을 통해서 동시에 메시지를 보내고 처리할 수 있습니다. 이런 이유로 전체적인 통신 속도의 향상 또한 크게 기대할 수 있습니다. ( 바이트 스트림 통신으로 인한 latency 상승은 그렇게 크지 않다고 합니다. Link 참조)

개요

gRPC는 Google Remote Procedure Calls의 약자입니다. 이름에서 알 수 있듯이 RPC의 한 종류입니다. RPC는 Rest API와 다른느낌을 가집니다. 즉, Rest API는 서버의 해당 경로로 호출한다라는 느낌이라면 RPC는 서버에 있는 특정 함수를 내가 호출한다. 라고 생각하시면 됩니다.

위의 그림을 보시면 아시겠지만, 3가지 환경이 모두 다릅니다. gRPC는 특징으로 다양한 개발 환경에서 RPC가 가능하도로 지원해주고 있습니다.

Protocol Buffers

서버에서는 함수의 이름, 파라미터 그리고 리턴값을 정의합니다. 그리고 클라이언트에서 함수를 호출하기 위해서 입력과 함수의 이름을 통해서 함수를 호출하는 것입니다. 이런 과정이 가능하기 위해서는 먼저 서버와 클라이언트 모두 공통된 Interfae를 가져야합니다. 이를 가능하게 해주는 것이 IDL(Interface Definition Language)입니다. gRPC는 IDL로 Protocol Buffers를 이용하고 있습니다.

아래는 protocol buffer의 기본적인 형식입니다. 자세한 내용은 다음시간에 구체적으로 다시 알아보도록 하겠습니다. 아래의 IDL 코드를 간단히 말씀드리면 HelloService라는 서비스에 SayHello 함수가 있는 것입니다. 그리고 그 요청이 HelloRequest이며 응답으로 HelloResponse의 형식을 가지게 된다는 의미입니다. 개인적으로는 직관적이라고 생각되어지는 부분입니다.

syntax = "proto3";

service HelloService {
  rpc SayHello (HelloRequest) returns (HelloResponse);
}

message HelloRequest {
  string greeting = 1;
}

message HelloResponse {
  string reply = 1;
}

gRPC의 rpc 종류

rest api는 Request/Response을 가집니다. 이와는 다르게 gRPC는 다양한 요청/응답 모델을 제공하고 있습니다. 이런 다양한 통신 모델을 가질 수 있는 이유는 gRPC는 http/2를 기반으로 사용하고 있으며 이에 따라 하나의 커넥션으로 여러개의 데이터를 보낼 수 있는 스트림을 지원하기 때문입니다.

• Unary RPC
  • 하나의 request에 하나의 response를 가지는 모델
• Server Streaming RPC
  • 하나의 request에 여러개의 response를 가지는 모델
• Cleint Streaming RPC
  • 여러개의 request에 하나의 response를 가지는 모델
• Bidirection Streaming RPC
  • 여러개의 request에 여러개의 request를 가지는 모델

마무리

오늘은 간단하게 gRPC의 컨셉에 대해서 알아보는 시간을 가져보았습니다.

좀더 깊은 내용은 다음시간부터 이어질 예정입니다.

다음 gRPC 시간에는 Protocol Buffer에 대해서 좀 더 이야기 해보는 시간을 가져보도록 하겠습니다.

감사합니다.

참조

wikipedia_GRPC

grpc_io_basics

q42_graphql-keep-alive