Remote Procedure Call (RPC): 다른 시스템의 함수 호출
원격 프로시저 호출(RPC) 이란 다른 컨텍스트에서 함수의 원격 실행을 허용하는 사양이다. RPC는 로컬 프로시저 호출 개념을 확장하지만 이는 HTTP API 컨텍스트에 포함되는 개념이다.
초기 XML-RPC는 XML 페이로드 데이터의 타입을 보장하기 어렵다는 문제를 내포하고 있었다. 그래서 차후의 RPC API는 보다 정형화된 JSON-RPC를 사용하여 SOAP보다 단순한 구조를 지닌 SOAP의 대안으로 인식되었다. gRPC는 2015년 Google에서 개발한 최신 버전의 RPC이다. gRPC는 로드 밸런싱, 추적, 상태 확인, 그리고 인증을 위한 플로그인을 지원하기 때문에 때문에 마이크로 서비스 연결에 매우 적합하다.
RPC 동작 방식
클라이언트는 원격 프로시저를 호출하고 매개 변수와 추가 정보를 직렬화하여 생성한 메시지를 서버로 보낸다. 서버에서는 받은 메시지를 역직렬화하여 요청받은 작업을 실행하고, 그 결과를 다시 클라이언트에게 보낸다. 서버 stub과 클라이언트 stub은 매개 변수의 직렬화와 역직렬화를 담당한다.
RPC의 장점
RPC는 직관적이고 단순한 상호 작용 메커니즘을 가지고 있다. RPC는 GET을 통해 정보를 가져오고, 그 외 모든 것을 POST를 통해 처리한다. 서버와 클라이언트 간의 상호 작용 메커니즘은 endpoint를 호출하고 응답을 받는 것으로 완료된다.
RPC는 기능을 추가하기 쉽다. API에 대한 새로운 요구사항 발생하는 경우, 단순히 새로운 endpoint를 추가하여 다음 요구 사항을 충족할 수 있다.
1) 새로운 기능을 작성하고 새로운 endpoint에 할당한다.
2) 클라이언트에서 새로운 endpoint에 접근하여 요구사항을 충족하는 정보를 얻는다.
RPC는 고성능이다. RPC가 사용하는 가벼운 페이로드는 공유 서버 및 워크스테이션의 네트워크에서 병렬 처리에 중요한 요소이기 때문에 네트워크가 성능을 유지하는데 기여한다.
High performance. Lightweight payloads go easy on the network providing high performance, which is important for shared servers and for parallel computations executing on networks of workstations.
RPC는 네트워크 계층을 최적화하고 여러 서비스 간 오고 가는 수 많은 메시지들을 효율적으로 전송할 수 있게 한다.
RPC의 단점
RPC는 기반 시스템과의 결합도가 높다. API의 추상화 정도는 API의 재사용성과 비례한다.
즉, API와 기반 시스템의 결합도가 높을수록 API가 다른 시스템에서 재사용되기 어려워진다. RPC와 기반 시스템의 결합도가 높은 경우, 기반 시스템의 기능과 외부 API 사이의 추상화 계층을 허용하지 않는다. 이 경우 기반 시스템 상세 구현 정보가 API를 통해 누출되기 쉽다는 보안상의 문제가 발생한다. 또한 높은 결합도의 RPC는 API의 확장성과 느슨하게 결합된 아키텍처를 구현하기 어렵게 한다. 따라서 클라이언트는 높은 결합도로 인해 특정 endpoint를 호출할 때 발생 가능한 부작용에 대해 걱정을 하거나 서버가 기능의 이름을 정하는 규칙을 이해하지 못한 관계로 어떤 endpoint를 호출해야 되는지 파악해야 한다.
RPC는 파악하기 어렵다. RPC에서는 API를 introspect할 방법 또는 요청을 보내고 요청에 따라 호출해야되는 endpoint를 파악할 방법이 없다.
RPC에서 제공하는 기능이 과다할 수 있다. RPC에서 새로운 endpoint를 추가하기 쉬운 관계로, 기존의 endpoint을 수정하기보다는 다른 endpoint와 겹치는 측면이 있는 새로운 endpoint를 추가할 가능성이 높다.
RPC 사용 예시
RPC 패턴은 1980년대부터 사용되기 시작했지만 처음부터 널리 사용된 것은 아니다. 구글, 페이스북(Apache Thrift), 그리고 트위치(Twirp) 같은 대기업에서는 매우 고성능의 낮은 오버헤드 메시징이 가능한 RPC 고성능 변형을 내부적으로 사용하고 있다. 이러한 기업의 대규모의 마이크로 서비스 시스템은 짧은 메시지가 직렬화되는 동안 내부 통신간 문제가 없어야 한다.
Command API에 사용된다. RPC는 원격 시스템에 명령을 보내기에 매우 적절한 선택이다. 예를 들어, 채널 가입, 채널 탈퇴, 메시지 전송 기능을 제공하는 Slack API는 매우 명령 중심적이다. 그래서 Slack API 설계자들은 작고 단단하며 사용하기 쉬운 RPC 스타일로 Slack API를 모델링했다.
내부 마이크로 서비스 제공을 위한 고객별 API 구현에 사용된다. RPC는 단일 공급자와 단일 소비자를 직접 연결하기 위해, REST API 처럼 유선으로 수 많은 메타데이터 주고 받는데 많은 시간을 할애하기를 원하지 않는다. 높은 메시징 속도와 메시징 성능을 가진 gRPC와 Twirp가 마이크로 서비스의 훌륭한 사례이다. gRPC는 HTTP 2를 기반으로 네트워크 계층을 최적화하고, 서로 다른 서비스간 매일 오가는 수 많은 메시지의 송수신을 효율적으로 만든다. 하지만 뛰어난 네트워크 성능을 목표로 하는 것이 아니라, 상이한 마이크로 서비스를 배포하는 팀 사이의 안정적인 API 연동을 목표로 한다면 REST API를 추천한다.
참조: https://www.altexsoft.com/blog/soap-vs-rest-vs-graphql-vs-rpc/
