RPC통신이란?

# gRPC 프레임워크와 RPC 통신에 대한 기술조사를 진행한다.
  gRPC프레임워크를 알기전 RPC통신에 대한 선수지식이 필요하다는 생각이 들어 우선 RPC 통신에대   한 조사부터 진행한다.

---

● Remote Procedure Call (원격 프로시저 호출) 의 약자로 , 별도의 원격제어를 위한 코딩 없이 다른 주소 공간에서 함수나 프로시저를 실행할 수 있게 하는 프로세스 간 통신 기술을 일컫는다.
즉, RPC통신을 하게되면 프로그래머는 함수 또는 프로시저가 실행 프로그램에 존재하든 로컬 위치에있든, 원격위치에 있든 상관없이 동일한 기능을 수행할 수 있음을 의미한다.

위 그림은 기본적인 RPC 통신에 대한 그림이다 , Client가 P라는 함수를 이용하고 싶어하는데 이 함수는 Server에 위치해있고이를 RPC통신을 이용하여 네트워크를 통해 함수에 대한 호출을 끝내고 결과값을 받아서 네트워크로 응답을 받는 구조로 이루어진다.

물론 , 이 사이에는 어떻게 데이터가 넘어와서 어떻게 다시 넘겨주어야 한다는 통신규약이 존재하고 이를 네트워크가 알아야 서버쪽에 전달해서 응답을 받아올 수 있습니다. RPC에서는 이런식으로 네트워크가 알아 들을 수 있는 코드를 구현해야 하는데 이러한 코드들을 stub이라고 합니다. 이 stub은 직접구현하는것 보다는 프로그래밍 언어별로 구현 로직이 제공되는 로직을 이용하면 됩니다.

RPC통신은 어디서 이용되어지나..?

● RPC 가 다른 프로세스, 서버와 연결해서 통신하는 방식이라면.. 떠오르는 방식 중에 하나가 HTTP 기반의  REST API 방식입니다. (참고: REST API -Red Hat doc) 실제로 예전 RPC 를 통해 통신하는 방식에서 json 데이터를 통해 통신하는 REST API 방식이 많이 사용되면서 RPC 를 사용하는 곳이 줄어들었다고 합니다. 하지만, 최근에는 다시 RPC 를 이용한 방식들이 많이 등장하고 있습니다. 왜그럴까요?

● 이러한 MSA 구조에서 각 컴포넌트 끼리 REST API 를 통신하는 것은 적지않은 부담이 있고 속도가 떨어진다는 단점이 있습니다. 왜냐하면 REST API 는 json 데이터를 들고 이동하기 때문에 인코딩 된 바이트 스트림을 통해 통신하는 RPC 보다 당연히 처리 면에서 늦어질 수 밖에 없습니다. 이러한 이유들로 최근 MSA 방식에서

● 최근에는 하나의 어플리케이션을 개발하고자 할때 모놀리스 방식에서 MSA(Micro Service Architecture) 방식으로 많이 넘어가고 있는 추세입니다. 이 말의 의미는 하나의 서버에 DB, 백엔드, 모니터링 등등 다양한 기능들을 모두 합쳐서 개발한 반면에 최근에는 유연된 확장을 위해 이 서버는 DB, 저 서버는 백엔드 이런식으로 나눠서 개발을 하고 각각의 컴포넌트들을 네트워크를 통해 연결하는 방식을 추구하고 있습니다.