RPC? gRPC? 에 대해서 알아보자 -(1)
요즘 컨테이너 환경에서 서버를 구축하거나 운영하려고 할때 통신 방식으로 gRPC 라고 하는 것을 종종 접한적이 있을것입니다. 이 gRPC 라고 하는것은 무엇일까요? 그리고 기존의 http 와 어떤 관계가 있고 REST API 와 어떤 차이가 있을까요?!
우선 gRPC 에 대해서 자세히 알아보기 전에 그 기반이 되는 RPC 에 대해서 먼저 알아가보도록 하겠습니다.
RPC 란?
RPC 는 Remote Procedure Call 의 약자로, 해석하자면 원격 프로시저 호출이라는 뜻입니다. 먼저 원격 프로시저 호출 이라는게 어떤것을 의미하는지 알아보겠습니다. 우리는 프로그램을 구현하고 실행할때 당연하게 하나의 프로그램안에 내가 실행하고자 하는 함수를 구현하고 호출하는 일련의 과정을 생각합니다. 하지만, RPC 를 이용하게 된다면 쩌기 친구 컴퓨터에 구현되어 있는 함수를 내 컴퓨터의 프로그램에서 호출하고 결과를 받을 수 있다는 의미입니다.
아래 그림은 기본적인 RPC 동작 방법에 대한 예시입니다. 예를 들어, 클라이언트에서 P(X, Y, Z) 라고 하는 함수를 이용하려고 하는 상황인데 해당 함수에 대한 구현이 클라이언트에 없고 서버 쪽에 구현이 되어 있는 상황입니다. 그러기 위해서는 함수를 호출 하고 결과를 받기 위해 네트워크를 타고 넘어갈 수 밖에 없고, 서버에 도착해서 해당 함수에 대한 호출이 끝나고 결과값을 받아서 다시 네트워크를 통해 응답을 받는 구조로 이루어집니다.
물론, 단순히 호출한다고 실행되지는 않겠죠? 내가 호출한 이 함수가 저쪽에 있는 서버에 구현되어 있고, 네트워크를 통해 어떻게 넘겨줘야 한다는 그런 통신 규약들을 네트워크가 알아야 서버쪽에 전달해서 응답을 받아올 수 있습니다. RPC 에서는 이런식으로 네트워크가 알아들을 수 있는 코드를 구현해야 하는데 이러한 코드들을 stub 코드라고 합니다. 다행히도 이러한 코드들은 직접 구현하는 것은 아니고 프로그래밍 언어별로 구현 로직이 제공되는 해당 로직을 이용하면 된다.
그러면 RPC 는 어떨때 사용되나?
RPC 가 다른 프로세스, 서버와 연결해서 통신하는 방식이라면.. 떠오르는 방식 중에 하나가 HTTP 기반의 REST API 방식입니다. (참고: REST API -Red Hat doc) 실제로 예전 RPC 를 통해 통신하는 방식에서 json 데이터를 통해 통신하는 REST API 방식이 많이 사용되면서 RPC 를 사용하는 곳이 줄어들었다고 합니다. 하지만, 최근에는 다시 RPC 를 이용한 방식들이 많이 등장하고 있습니다. 왜그럴까요?
최근에는 하나의 어플리케이션을 개발하고자 할때 모놀리스 방식에서 MSA(Micro Service Architecture) 방식으로 많이 넘어가고 있는 추세입니다. 이 말의 의미는 하나의 서버에 DB, 백엔드, 모니터링 등등 다양한 기능들을 모두 합쳐서 개발한 반면에 최근에는 유연된 확장을 위해 이 서버는 DB, 저 서버는 백엔드 이런식으로 나눠서 개발을 하고 각각의 컴포넌트들을 네트워크를 통해 연결하는 방식을 추구하고 있습니다.
이러한 MSA 구조에서 각 컴포넌트 끼리 REST API 를 통신하는 것은 적지않은 부담이 있고 속도가 떨어진다는 단점이 있습니다. 왜냐하면 REST API 는 json 데이터를 들고 이동하기 때문에 인코딩 된 바이트 스트림을 통해 통신하는 RPC 보다 당연히 처리 면에서 늦어질 수 밖에 없습니다. 이러한 이유들로 최근 MSA 방식에서 통신을 위해 RPC 를 사용하는 적용하는 케이스가 많이 생기고 있습니다.