Google에서 만든 RPC,

권장 시나리오

• 마이크로서비스 : gRPC는 대기시간이 짧고 처리량이 높은 통신을 위해 설계되어 있어, 효율성이 중요한 경량 마이크로 서비스에 적합하다.
• 지점 간 실시간 통신 : 양방향 스트리밍을 위한 뛰어난 지원기능을 제공, gRPC 서비스는 폴링을 사용하지 않고 실시간으로 메세지를 푸시할 수 있다.
• Polyglot 환경 : gRPC 도구는 널리 사용되는 모든 개발언어를 지원하며 다중언어 환경에 적합하다.
• 네트워크 제한 환경 : gRPC 메세지는 경량 메세지 형식인 Protobuf를 사용하여 직렬화된다. gRPC메세지는 해당 JSON 메세지보다 항상 작다.
• IPC(프로세스 간 통신) : Unix 도메인 소켓 및 명명된 파이프와 같은 IPC 전송은 gRPC에서 동일한 머신에 있는 앱 간에 통신하는데 사용된다.

gRPC 약점

• 제한된 브라우저 지원 : 브라우저에서 gRPC 서비스를 직접 호출하는 것은 불가능하다. gRPC-Web을 이용하여 브라우저에서 gRPC지원을 제공하는 gRPC팀의 추가기술이다. 하지만 gRPC기능을 전부 지원하는 것이 아니고 클라이언트 및 양방향 스트리밍이 지원되지 않으며 서버 스트리밍이 제한적으로 지원된다.
• 사람이 읽을 수 없음 : HTTP API요청은 텍스트로 전송되어 사람이 읽고 만들 수 있지만 gRPC 메세지는 Protobuf로 인코딩된다. Protobuf는 송 수신에는 효율적이지만 사람이 읽을 수 없다. Protobuf를 사용하려면 역직렬화를 위해 .proto파일에 지정된 메세지의 인터페이스 설명이 필요하며 네트워크에서 Protobuf payload를 분석하고 요청을 직접 작성하려면 추가 도구가 필요하다. 서버 리플렉션 및 gRPC명령줄 도구와 같은 기능은 이진 Protobuf메세지를 지원하기 위해 존재하고 Protobuf메세지는 JSON변환을 지원한다. 기본 제공 JSON변환은 디버그할때 Protobuf메세지를 사람이 읽을 수 있는 형식으로 변환하는 효율적인 방법을 제공한다.

등장배경

1. Server-Client Model

PC 개념이 없던 시절, 프로그램은 하나의 메인 Frame에서 동작하는 Monolothic 구조로 설계되었다. 모든 기능들이 한 공간에서 구동되다보니 Network Communication이 중요하지 않았다.

소형 장비(PC, Workstation Server 등)들이 등장하면서 기업입장에서는 고가의 Main Framework를 비교적으로 저가인 Workstation Server로 대체하고자 하였으나 그대로 제공하기에는 한계가 존재했다.

Main Framework의 기능을 Workstaion Server로 분산시키기고 Network 연결로 서비스하는 방식(Server-Client Model)을 채택하게 되었고 서버 간 or 서버와 개인 PC 간 Network 연결/통신이 중요해지면서 OSI 7 layer, TCP/IP 등 Network 계층 구조가 정의되고 발전되기 시작하였다.

2. IPC(Inter Process Commnunication)

프로세스들은 기본적으로 상호독립적이다. 메모리를 공유하지 않기 때문에 각자 자신의 일만 하며 서로 간섭하지 않는다. 하지만 필요에 따라 프로세스 간 정보를 교환해야하는 경우 별도 수단을 이용하여 프로세스 통신하는 방법론을 통칭하여 IPC(Inter Process Communication)이라고 한다.

1) Socket

IPC 기법에는 공유 메모리, PIPE, Message Queue 등 여러가지 중 Socket을 살펴본다.

Socket이란, OSI 7 layer 구조의 Application Layer(L7)에서 Transport Prot(L4)의 TCP or UDP를 이용하기 위한 수단이다. 일종의 창구 역할을 하는데, 목적지와 통신이 컴퓨터 내부가 아니라 온라인 범위에서 이루어지기 때문에 Network 간의 통신이라고 구분되기도 하지만 실질적으로 Local Computer의 프로세스와 원격지 컴퓨터의 프로세스가 IPC 통신을 하는 것이다.

Socket은 대부분의 언어에서 API 형태로 제공하는 편리함 때문에 지금도 많이 사용되지만 일련의 통신 과정을 직접 구현하므로 통신 관련 장애를 처리하는 것은 개발자의 몫이다. 서비스가 고도화될 수록 많은 데이터가 돌아다니게 되며, 이에 따라 data formatting을 하는 것도 어려워진다.

2) RPC(Remote Procedure Call)

서비스가 고도화될 수록 많은 데이터가 돌아다니게 되며, 이에 따라 data formattin을 하는 것도 어려워진다. 이런 Socket의 한계에 RPC(Remote Procedure Call) 기술이 등장하게 된다. Network로 연결된 서버 상의 프로시저(함수, 메서드 등)를 원격으로 호출할 수 있는 기능이다. Network 통신을 위한 작업 하나하나 챙기기 귀찮으므로 통신이나 call방식에 신경쓰지 않고 원격지의 자원을 내 것처럼 사용할 수 있다. IDL(Interface Definication Language) 기반으로 다양한 언어(C++, Java, Python, Ruby, Node.js, C# 등)를 가진 환경에서도 쉽게 확장이 가능하며, 인터페이스 협업에도 용이하다는 장점이 있다.

RPC의 핵심개념은 ‘Stub(스텁)’이라는 것인데, 서버와 클라이언트는 서로 다른 주소 공간을 사용하므로 함수 호출에 사용된 매개변수를 꼭 변환해줘야 한다. 그렇지 않으면 메모리 매개 변수에 대한 포인터가 다른 데이터를 가리키게 된다. 이러한 변환을 담당하는 것이 스텁이다.