gRPC

gRPC는 2016년 Google에서 개발한 오픈소스 RPC 프레임워크이다.

• 전송을 위해 TCP/IP와 HTTP/2를 사용한다.
• IDL로는 Protocol Buffer를 사용한다.

gRPC가 무엇인지 좀 더 자세하게 이해하기 위해서는 왜 gRPC가 등장했는지에 대한 등장 배경을 이해해야 한다.

 

1️⃣ IPC (Inter Process Communication)

IPC는 프로세스 간에 통신을 가능하게 하는 메커니즘이다.

프로세스들은 메모리를 공유하지 않기 때문에 상호간의 정보를 공유하기 위하여 IPC의 기법 중 하나를 사용하여 통신을 하게 된다.

IPC 기법에는 Shared Memory, Pipe, 메시지 큐, Socket 등.. 여러가지 방법이 있다.

• 이 중 Socket 방법은 TCP, UDP를 이용하기 위한 수단이다.
• 목적지와의 통신이 온라인 범위에서 이루어지기 때문에 네트워크간 통신이라고 구분하기도 하지만, 실질적으로는 로컬 컴퓨터의 프로세스 ↔ 원격지 컴퓨터의 프로세스 끼리 서로 IPC 통신을 하는 것 이다.

💡 Socket 통신

IPC의 여러가지 방식 중 Socket 통신은 대부분의 언어에서 API 형태로 제공하여서 편리하다는 장점이 있어 많이 사용되고 있었으나 다음의 단점들이 존재했다.

단점

1. 통신 과정을 직접 구현하기 때문에 통신 장애처리는 고스란히 개발자의 몫이 된다.
2. 수백 수천가지 데이터가 돌아다니게 될 경우 Data Formatting이 어렵다.

2️⃣ RPC(Remote Procedure Call) 등장

Socket통신의 단점을 보완하기 위해 1980년에 RPC라는 기술이 등장하였다.

RPC는 이름 그대로 네트워크로 연결된 서버의 프로시저 (함수, 메서드 등)을 원격으로 호출할 수 있는 기능임.

• 통신이나 Call 방식에 신경쓰지 않고 원격지의 자원을 내 것처럼 사용할 수 있음.

💡 RPC의 통신 과정

1. IDL (Interface Definition Language)를 사용하여 호출 규약을 정의함.
   • IDL에는 함수명, 인자, 반환값에 대한 데이터형이 정의되어 있음.
   • rpcgen으로 컴파일하면 Stub Code가 생성됨.
2. Stub Code에 명시된 함수는 원시코드의 형태로, 상세 기능은 Server에서 구현된다.
   • 만들어진 Stub Code는 클라이언트/서버에 함께 빌드한다.
3. Client에서 Stub에 정의된 함수를 사용할 때 Client Stub은 RPC runtime을 통해 함수를 호출함.
4. Server는 수신된 Procedure 호출에 대한 처리 후 결과 값을 반환한다.
5. 최종적으로 Client는 Server의 결과값을 반환받고 함수를 Local에 있는 것 처럼 사용할 수 있음.

그러나 RPC 역시 다음의 단점들이 있어서 잘 사용하지 않게되었다.

단점

1. 구현 하기가 어렵다.
2. 지원 기능의 한계
3. etc..

그래서 RPC 프로젝트도 점차 잊혀져갔고 데이터 통신을 익숙한 Web을 활용하는 시도로 이어짐.

3️⃣ REST (REpresentational State Transfer)등장

HTTP/1.1 기반으로 URI를 통하여 모든 자원을 명시하고 HTTP Method를 통하여 처리하는 아키텍쳐이다.

REST는 다음과 같은 장점으로 매우 보편화 되어 있다.

장점

1. 자원 그 자체를 표현하기 때문에 직관적임.
2. HTTP를 그대로 계승하여서 별도 작업없이도 쉽게 사용할 수 있음.

그러나 REST에도 한계가 존재한다.

단점

1. REST는 일종의 스타일일뿐 표준이 아니여서 Parameter와 응답값이 명시적이지 않다.
2. HTTP 메소드의 형태가 제한적이기 때문에 세부 기능 구현에는 제약이 있다.
3. 웹 데이터 전달 시 xml, json 형식을 많이 사용하는데 xml과 json형식에 대한 단점들이 일부 존재함.
   • 데이터를 전송하기 처리하기 위해서는 별도의 Serialization이 필요하다.

gRPC는 이런 REST의 한계점과 기존 모놀리식 구조에서 MSA의 아키텍쳐로 옮겨가게 되는 시기와 맞물려서 등장하게 된 것이다.

gRPC의 기능

1️⃣ ProtoBuf (Protocol Buffer)

Protocol Buffer는 Google에서 개발한 구조화된 데이터를 직렬화(Serializer)하는 기법이다.

*직렬화(Serializer) : 데이터 표현을 Byte단위로 변환하는 작업.

• ProtoBuf를 사용하게 되면 기존에 json, xml로 직렬화와 비교했을 때 Byte단위를 최소화 할 수 있다.

JSON vs ProtoBuf

2️⃣ HTTP/2

REST와 비교 시 가장 큰 차이점 중 하나는 HTTP/2를 사용하는 것이다.

• HTTP/1의 단점
  • HTTP/1.1은 기본적으로 클라이언트의 요청이 올때만 서버가 응답을 하는 구조라서 매 요청마다 connection을 생성해야 한다.
  • 이는 곧, 무거운 header (cookie 등의 많은 메타 정보들을 저장하는)가 요청마다 중복 전달되어 비효율적이고 느린속도를 보여준다.

그러나 HTTP/2는 다르다!

• HTTP/2
  1. 하나의 connection으로 동시에 여러 개 메시지를 주고 받음.
  2. header를 압축하여 중복제거 후 전달하여서 1.1에 비해 훨씬 효율적임.
  3. 필요 시 클라이언트 요청 없이도 서버가 리소스를 전달할 수도 있음. (클라이언트 요청 최소화)

gRPC의 이점

그렇다면 gRPC는 어떤 이점들이 있을까?

1️⃣ 성능

• gRPC는 Protobuf를 사용하여 직렬화 및 역직렬화를 수행한다.
  • 이는 REST 통신에서 사용하는 JSON 형태의 직렬화 및 역직렬화보다 빠르다.
• 또한 Protobuf에 HTTP/2를 결합하여 사용하기 때문에 HTTP/1에 비해 더욱 효율적인 통신을 할 수 있게되었다.

2️⃣ API-우선 방식

• Protobuf를 이용하여 기능을 개발하기 전에 API를 먼저 정의할 수 있기 때문에 개발팀이 병렬적으로 업무를 진행할 수 있다.

3️⃣ REST API 지원

• Protobuf로 정의된 API는 Envoyproxy나 gRPC-gateway 같은 Gateway를 통해 REST API로도 제공이 가능하다.

마치며

간략하게 gRPC의 등장배경과 gRPC의 기능 및 이점에 대해서 알아보았다. 다음에는 Go언어로 gRPC 통신을 실제로 구현해보겠다.

Reference

• https://chacha95.github.io/2020-06-15-gRPC1/
• https://medium.com/naver-cloud-platform/nbp-기술-경험-시대의-흐름-grpc-깊게-파고들기-1-39e97cb3460