gRPC(general-purpose Remote Procedure Calls)란?

gRPC 시리즈에서 다룰 내용

• 왜 gRPC인가?
• gRPC로 unary RPC 구현
• gRPC로 stream RPC 구현
• gRPC로 REST API 구현

서론

 

전 편에서 프로토콜 버퍼에 대해 언급했었습니다. 프로토콜 버퍼를 사용해 REST 통신을 하던 구글은, '이거, RPC로 구현하면 되게 편하고 효율적이지 않을까?' 생각하게 됩니다.

먼저 우리는 RPC에 대해 알 필요가 있습니다.

 

RPC는 쉽게 말해서 통신 기술 중 하나로, 로컬 함수를 호출 하듯 다른 프로세스에 있는 내용을 호출 할 수 있도록 하는 기술입니다. 네트워크 간 통신의 추상화가 아름답게 이루어져, 다른 프로세스에 있는 내용을 로컬 함수처럼 호출 할 수 있다는것이죠.

 

RPC 개념에 대해 익숙치 않아도 괜찮습니다. HTTP 기반의 REST API 가 유행이 되며 RPC는 잊혀져갔기 때문에, 충분히 모를 수 있는것이죠.

그렇다면, 'REST 와 RPC가 사용 용도에 있어 비슷한 역할을 한다' 는 말이 됩니다.

그런데 gRPC가 다시 주목을 받기 시작한다는건, RPC → REST → gRPC 라는 흐름이 이어져 오고 있다는겁니다. 왜 다시 RPC, 그것도 하필 gRPC일까요? 그게 뭐길래?

 

gRPC, 너 정체가 뭐냐! - 왜 gRPC인가

 

역시 오늘도 사전적 정의부터 찾아보겠습니다.

 

gRPC(gRPC Remote Procedure Calls[1])는 구글이 최초로 개발한 오픈 소스 원격 프로시저 호출 (RPC) 시스템이다. 전송을 위해 HTTP/2를, 인터페이스 정의 언어로 프로토콜 버퍼를 사용하며 인증, 양방향 스트리밍 및 흐름 제어, 차단 및 비차단 바인딩, 취소 및 타임아웃 등의 기능을 제공한다. 수많은 언어를 대상으로 크로스 플랫폼 클라이언트 및 서버 바인딩을 생성한다. 가장 흔한 사용 시나리오에는 마이크로서비스 스타일 아키텍처의 서비스 연결, 모바일 장치, 브라우저 클라이언트를 백엔드 서비스에 연결하는 일 등이 포함된다. - 한국어 위키피디아

 

뭔가 알 수 없는 말이 잔뜩 있다고 생각 할 수 있지만, 그래도 익숙한 용어들이 몇개 보입니다.

 

• HTTP/2
• 프로토콜 버퍼

 

이 두개의 키워드는, 다음과 같은 요약을 내릴 수 있게 해줍니다.

 

HTTP/2를 기반으로, 프로토콜 버퍼를 사용하여 통신하는 RPC 시스템

 

전 편에서 다루었던 프로토콜 버퍼를 사용하여 통신한다 하니, 둘은 밀접하게 닿아 있다는 생각이 들죠. 실제로도 그렇습니다. 이제 그 내용에 대해서 다뤄보도록 하겠습니다.

그러면 다시 원래 질문으로 돌아오겠습니다.

왜 그냥 RPC도 아니고, HTTP 기반의 REST 통신도 아닌 gRPC일까요?

나중에 네트워킹의 발전사를 언급하며 이 부분을 다시 한번 언급하겠습니다만, 다음과 같은 내용을 봅시다.

gRPC 이전의 통신 구현 환경은 다음과 같았습니다.

 

1. REST 자체는 명확하게 통신 데이터의 모델을 다루는 내용이 없다.

• REST는 표준이나 규약보단 스타일에 가까워서, 명확히 관리되지 않는다.
• 통신 데이터의 모델을 문서화로 진행해야한다는 점은 매우 번거롭다.
• XML은 비효율적이다.
• JSON은 통신 이후 데이터를 처리하는 별도의 과정(Serialization)이 필요하다.

2. HTTP/1.1 는 비효율적이고, 느리고, 유연하지 못하다.

• 요청 → 응답의 구조로 인해 매번 새로 connection을 생성해야 한다.
• cookie 같은 메타 데이터가 중복 전달 된다.

 

그렇다면 gRPC는 이 문제들을 어떻게 해결 했을까요?

 

1. 프로토콜 버퍼 사용
   • 전 편에서 프로토콜 버퍼를 보았듯, 통신 데이터의 형식을 지정 할 수 있다.
2. HTTP/2 사용
   • HTTP/2는 매 요청마다 Connection을 생성하지 않을 수 있다.
   • 요청 → 응답의 구조가 아닌 양방향 통신이 가능하다. (스트림 통신이 가능하다)

 

그래서 gRPC로 뭘 할 수 있는데?

 

• 높은 성능을 보장하는 인터페이스 파일(stub) 생성
• MSA 서비스 간 통신에서 활용
• 필요시 HTTP/2 기반의 REST API도 같이 사용 가능

 

그래서 gRPC 사용 시나리오는 다음과 같습니다...

 

1. 전달 할 값(파라미터)의 사양, 실행 될 프로시져(실행 될 내용)을 프로토콜 버퍼 스키마(.proto 파일)로 작성
2. 프로토콜 버퍼 컴파일러(protoc)를 통해 언어에 맞는 인터페이스 파일(stub) 생성
3. gRPC의 SDK를 활용, 서버 및 클라이언트 작성 - 인터페이스 파일을 사용하여 프로시져 구현 및 전달 할 값 생산

1번과 2번은, 전 편에서 어느정도 다루었습니다. 사용 시나리오를 보니, gRPC와 프로토콜 버퍼가 얼마나 밀접하게 닿아있는지 와닿지않나요?

protoc를 통해 stub을 생성 할 수 있다는 점은, 언어가 다른 경우에도 스키마 문서 없이 컴파일만 진행하면 해당 데이터들을 쉽게 다룰 수 있다는 점에서 매우 매력적으로 들립니다.

다음 편부터, 이렇게 멋진 gRPC를 직접 구현해보도록 하겠습니다!

 

참고한 링크

 

https://lejewk.github.io/grpc-go-example/

https://juneyr.dev/2018-07-30/what-is-grpc

https://blog.naver.com/n_cloudplatform/221751268831

https://blog.banksalad.com/tech/production-ready-grpc-in-golang/