티스토리 뷰
RPC 와 gRPC
과거에는 Client - Server간에 자료를 요청하고, 받을때 주로 Socket 프로그래밍을 활용하였습니다.
소켓은 대부분의 프로그래밍 언어에서 API 형태로 제공하고 있지만, 실제로 소켓을 통해 서비스되기 위해서는 여러 장애물이 있습니다.
-
네트워크가 언제나 빨라야함
-
서버는 클라이언트의 요청시 언제든 즉시 응답
-
클라이언트는 언제든 서버와 바로바로 연결
때문에 이런 환경 이외의 예외 상황들을 모두 대비해야하는데요, 이것은 순전히 개발자의 몫이었습니다.
이러한 소켓 프로그래밍의 문제점으로 인해 RPC(Remote Procedure Call) 이 등장하게 됩니다.
RPC는 위와 같은 구조로 도식화되는데,
Server에 있는 프로그램 정보를 알고있는 IDL(Interface Definition Langauge)을 활용해서 개발자는 network 통신과 관련된 작업은 신경쓰지 않아도 되고, 원격지에 위치한 프로그램을 로컬에 있는 프로그램 처럼 사용 할 수 있는 기술입니다.
이러한 RPC 기술은 근래의 HTTP기반의 REST가 유행하면서 많이 보이지 않았는데, 반대로 REST의 경우 호출하는 parameter와 응답 값이 명시적이지 않기 때문에, 오류의 여지가 많고 (API 스펙만 의존, 형 체크등을 안함) JSON을 HTTP를 통해서 쏘기 때문에, 속도가 느리다는 단점을 가지고 있습니다.
이러한 이유로 근래에 RPC 개념이 다시 유행하게 되면서 페이스북은 Thrift라는 바이너리 기반의 RPC 프레임워크, 구글은 RPC자체는 지원하지 않고 메세지(JSON 등)을 Serialize 할 수 있는 프레임워크로 PB(Protocol Buffer)를 제공해 왔는데, GRPC라는 개념으로, PB를 기본으로한 Serializer에 HTTP2를 붙여서 GRPC라는 이름으로 프레임워크를 릴리즈 하였습니다.
GRPC는 모던 프로그래밍 언어 (Node.js, python 등등) 대부분을 지원하며 요즘 유행하는 MSA와 물려서 RPC를 하나의 서비스로 하여 배포할 수 있는 대체 수단으로 부상하고 있어서, 만약에 실시간 양방향을 필요로하는 서비스를 구현함에 있어서는 좋은 대체 수단이 될수 있는 요소가 충분하다 볼 수 있습니다.
REST의 단방향의 한계를 극복하고, HTTP2 기반의 Streaming을 지원하며, REST대비 빠른 성능을 지원하기 때문에, 근래에는 외국 서비스 'Netflix'를 비롯하여 국내 서비스
출처