RPC와 gRPC

RPC 프로토콜의 탄생 이유

rpc는 같은 프로세스 내부의 기능이 아닌, 다른 프로세스 혹은 다른 서버의 프로세스에 있는 기능을 같은 프로세스 내부의 기능처럼 사용하기 위한 프로토콜이다. 여기서 '같은 프로세스 내부의 기능처럼 사용'의 의미는 다른 프로세스와 통신하기 위한 IPC 작업이나 외부 통신을 위한 네트워크 I/O에 대한 작업(네트워크 프로토콜, 메시지 직렬화 등)을 추상화 하여 개발자가 같은 프로세스에 있는 로컬 함수를 호출하듯이 사용하기 편함을 의미한다.

gRPC

gRPC는 Google에서 개발한 RPC 프레임워크이다. gRPC는 기본적으로 네트워크 통신을 통해 다른 서버에 있는 기능을 사용하기 위해 탄생했다.(내부의 다른 프로세스와의 통신도 가능하다.)
gRPC가 추상화 해준 핵심 기능은 다음과 같다.

 

HTTP/2를 활용한 네트워크 통신

gRPC는 HTTP/2를 사용해서 네트워크 통신을 추상화한다. HTTP/2를 통해서 HTTP/1.1에 비해 좋은 성능을 낼 수 있다. 그 이유는 다음과 같다.

 

멀티플렉싱 : HTTP/1.1은 기본적으로 하나의 TCP 연결에서 하나의 요청만을 처리할 수 있다. Keep-Alive 옵션을 활용할 수 있지만 HOL Blocking (요청이 동기적으로 실행되어야하므로 앞의 요청이 느려지면 다른 요청도 느려지는 문제)가 발생할 수 있다. HTTP/2는 단일 TCP 연결로 한번에 여러 데이터 스트림을 보낼 수 있다. 즉, 단일 TCP 연결로 여러 요청과 응답을 병렬로 처리할 수 있다. 이를 멀티플렉싱이라고 한다. 게다가 HTTP/2는 데이터를 이진 코드로 분할하여 전송하기 때문에 네트워크 대역폭을 절약할 수 있다.

 

헤더 압축 : HTTP/1.1은 각 요청마다 헤더가 전송된다. 반복적일 요청일 경우 불필요한 데이터가 전송된다. HTTP/2는 헤더를 HPACK 알고리즘을 통해 압축한다. HPACK 알고리즘은 HTTP 헤더 패킷에서 중복 정보를 제거한다. 이로 인해 로드 속도가 빨라진다.

 

또한 gRPC HTTP/2에 필요한 메타데이터들을 추상화 시켜주어서 개발자는 필요한 경우에만 이를 설정하거나 읽을 수 있다.

 

데이터 직렬화 형식

gRPC는 ProtoBuf(Protocol Buffer)를 이용해 데이터를 직렬화한다. ProtoBuf는 바이너리 형식으로 저장되므로 텍스트 기반 형식인 XML, JSON 형식에 비해 네트워크 전송이 빠르다.
그리고 ProtoBuf는 다양한 타입을 가지고있어 그 자체로 type safe하고, 플랫폼 독립적인 포맷이라 클라이언트의 언어에 구애받지 않는다.

 

Stub 코드 자동 생성

gRPC는 protoc 컴파일러를 사용해서 .proto 파일을 기반으로 자동으로 stub 코드를 생성해준다. 해당 stub 코드를 통해 클라이언트던 서버든 반복적인 개발 시간을 단축할 수 있다.