RPC, IPC 그리고 gRPC

RPC(Remote Procedure Call)은 IPC(Inter Process Communication)의 한 종류입니다.

https://www.rfc-editor.org/rfc/rfc1057.txt

https://en.wikipedia.org/wiki/Remote_procedure_call

 

IPC(Inter Process Communication)는 프로세스간 통신을 의미하며 multi process, multi thread 프로그래밍에서 중요하게 다루는 내용중 한부분입니다.

https://en.wikipedia.org/wiki/IPC_(electronics) 

https://www.ipc.org/ipc-standards

(추후 IPC는 다른 포스트로 작성예정)

 

IPC는 다양한 종류가 있으며 각 종류마다 특징이 있습니다.

	PIPE	Named PIPE	Message Queuue	Shared Memory	Memory Map	Sokcket
방향	단 방향	단 방향	단 방향	양 방향	양 방향	양 방향
공유 방법	파일	파일	메모리	메모리	파일, 메모리	소켓
단위	Stream	Stream	구조체	구조체	페이지	Stream

 

socket이 등장한 시점 부터 점점 local process 통신에서 외부 process와 통신에 대한 방법들이 많이 등장하게 되었고 그에 따른 고민사항들도 많이 등장하게 되었습니다.

RPC는 수많은 IPC 고민들 중에 하나인 통신 설정의 귀찮음을 해소하기 위해 등장한 기술이라고 생각합니다.

 

RPC는 맞는지는 모르겠으나.. 기존에 socket의 개선판으로 생각하면 조금 이해하기 쉬울 것 같습니다. socket, http, tcp들의 특징은 각자 헤더를 가지고 있고 통신하려는 remote에 맞춰서 통신해야 되는데 타겟이 바뀔때마다 통신 설정을 다르게 써야하며 각자 통신하는 운영체제 환경에 따라 메시지 내용이 바뀔수도 있습니다.

예를 들면

client/server 사이의 socket 통신을 하기위해 개발을 해야하는데 server pc는 64bit인데 client에는 64bit도 있고 32bit도 있다고 가정하면 개발자 입장에서는 고려해야할 사항이 상당히 많아집니다. 서버 입장에서는 32bit에 해당하는 messages를 받아들이는 기능을 개발해야 하고 이에 따른 테스트를 작성하는데도 많은 리소스를 사용하게 됩니다.

 

그래서 나타난 개념이 remote 서버, 즉 message를 전달하려는 pc에 접속해 직접 process를 돌리고 결과값을 가져오자. 라는 RPC(Remote Process Call)입니다. 

https://grpc.io/

RPC를 활용하면 개발자는 RPC 규격에만 맞춰서 server/client를 설계하고 개발하기 때문에 상대방의 pc환경이 32bit인지 64bit인지, 혹은 os가 linux인지 window인지에 대한 고민이 필요없습니다. 

즉 앞서 고민 거리였던 개발자의 리소스가 많이 들어가던 고민 거리를 어느정도 해결할 수 있고 프로세스 개발에 집중할 수 있는 장점이 있습니다. 

 

실제 동작은 아래 이미지와 같은 방식으로 사용하겠지만  개발자는 pack/unpack 과정을 신경쓰지 않을 수 있습니다.

https://getoutsidedoor.com/2019/07/11/what-is-grpc/

 

RPC의 구현체로, google, facebook, twiter 등이 있지만

RPC 구조를 사용하는 라이브러리 중 가장 유명한 라이브러리는 Google의 gRPC이며 구글만의 기술인 프로토콜 버퍼를 사용해서 다른 RPC 라이브러리보다 탁월한 성능을 보여준다고 합니다.

https://grpc.io/

gRPC

이미 많은 기업에서 사용중이라고 합니다.

 

gRPC를 적용한 유명한 사례로 Netflex를 소개합니다.

Netflex는 REST에서 gRPC로 API를 바꾸고 나서 스루풋, 레이턴시, cost 등의 부분에서 많은 성능향상이 있다는 발표와 함께 API 서비스의 진화라고 표현하였습니다.

 

짧게 짧게 봤는데 나름 괜찮았습니다.