[TIL] 원격 프로시저 호출 (Remote Procedure Call, RPC)

 

 > 원격 프로시저 호출의 개념에 대해 간단하게 정리해보았다. 추후에 더 자세히 알아보게 되면 내용을 보강해야겠다.

 

학습 키워드: RPC

 

1. Remote Procedure Call (RPC)

1) What is it?:

 원격 프로시저 호출(RPC)은 별도의 원격 제어 기술 구현 없이 원격 프로세스 (혹은 에 있는 함수를 마치 로컬 프로세스에 있는 함수처럼 사용할 수 있도록 설계하는 기술이다. 'RPC 프로토콜'이라고 자주 불리우곤 하지만 실제로 프로토콜인 것은 아니고, 분산 시스템을 구성할 때 쓰이는 메커니즘에 가깝다.

 

 

2) How does it work?:

Figure 1. Complete RPC mechanism (Peterson et al.)

 

 Figure 1은 클라이언트(왼쪽)가 원격 프로시저를 호출할 때의 상황을 나타낸다. 먼저 클라이언트가 클라이언트의 어느 함수가 local stub에 원격 프로시저 호출에 필요한 인자들을 넘겨준다. 이 stub는 인자들을 request 메세지로 변환(marshal)하여 실제 실행될 프로시저가 원격인지 로컬인지를 알 수 없는 상태로 만든 뒤, RPC protocol (다시 말하지만 실제로 네트워크 프로토콜은 아님)을 통해 서버로 해당 메세지를 전송한다. 그러면 서버는 다시 이 메세지를 서버의 stub로 전달하고, stub가 이를 인자의 형태로 해석(unmarshal)하여 서버의 로컬 프로시저에 전달하여 처리하게 된다. 이렇게 처리되어 반환된 결과 값은 다시 위와 같은 과정을 거쳐 클라이언트로 전달되고, 이 과정이 처리될 동안 blocking 상태로 대기하고 있던 클라이언트의 stub가 결과 값을 받아서 해석하고 최종적으로 최초 요청한 함수에 이 값을 반환하게 된다.

 

 

3) REST vs RPC?:

 RPC 관련 내용을 처음 읽었을 때 들었던 의문점은 이게 대체 REST API와 다른 점이 무엇이며 왜 쓰는가 였는데, 둘다 프로토콜이 아니며 그저 구조적인 principle이라는 점도 동일하고 동작 자체도 상당히 비슷하다고 느껴지기 때문이었다. 그래서 두 개념의 비교를 위해 각각이 어떠한 기반 원칙으로 구성되어 있는지를 가볍게 알아보았다.

 

 REST: HTTP methods (CRUD)에 따라 표준화되어 있으며, 이를 따라야만 RESTful 하다고 불리울 수 있다.

1. Client-server 구조: 서버와 클라이언트를 별개의 시스템으로 구분한다.
2. Stateless: 서버는 어떠한 상태도 저장하지 않는다.
3. Cacheable: 클라이언트나 어떤 중간 시스템은 클라이언트의 요구 사항에 따라 서버의 response를 캐싱할 수 있다.
4. Layered system: 클라이언트와 서버 사이에 중간 시스템이 존재할 수 있으며, 서버나 클라이언트 모두 해당 시스템에 대한 존재를 모른 채로 마치 서로 직접 연결된 것 처럼 동작해야 한다.
5. Uniform interface: 서버와 클라이언트는 REST API 형식에 맞춘 일관된 인터페이스를 통해 소통한다. 리소스는 URL을 통해 식별되며, 이 URL을 REST API의 endpoint라고 부른다.

 RPC: REST API와는 다르게 표준화된 principle이 존재하지는 않는다고 한다.

1. Remote invocation: 원격 프로시저 호출은 클라이언트에서 원격 서버의 함수를 마치 로컬 시스템의 함수인 것 처럼 호출한다.
2. Passing parameters: 클라이언트는 서버 함수에 필요한 인자들을 전달한다.
3. Stubs: 서버와 클라이언트 모두에 함수 stub가 존재하며, 클라이언트에서는 function call을 발생시키고, 서버에서는 실제 서버 내부 함수를 동작시킨다.

 정리하자면 RESTful 서버 앱은 CRUD를 기반으로한 기능을 지원하며, RPC도 CRUD와 같은 기능을 구현할 수 있겠지만 REST와는 다르게 해당 기능들에만 국한되지는 않는다. 따라서 REST는 서버가 일관된 인터페이스를 지원해야하는 경우에 사용되고, RPC의 경우 그 외의 상황, 주로 복잡한 계산이 필요한 기능이 요구되거나 원격 프로세스를 트리거해야 할 필요가 있는 경우에 사용된다. 마찬가지로 REST는 무상태성(statelessness)가 요구되지만 RPC는 그러한 제약이 없기 때문에 상태를 유지해도 괜찮다. 마지막이자 핵심 차이점은 데이터를 전달하는 형식인데, REST에서는 API의 실행 결과를 여러 형태로 전달할 수 있지만, RPC의 경우는 전달되는 데이터의 형식이 항상 동일해야 한다. '일관된 인터페이스' 라는 부분 때문에 무슨 소리인가 헷갈릴 수 있지만, 이는 기능적으로 일관되어야 한다는 것이고, RPC의 경우는 함수가 반환하는 결과의 형식이 일관적이어야 한다는 뜻이다.

 

 

4) Why use it?:

 앞서 언급했듯이 RPC를 사용하게되면 원격 함수에 대한 abstraction이 로컬 stub의 형태로 존재하기 때문에 개발자는 본래의 method가 실제로 어느 위치에 있는 어떤 함수인지 알기위해 시간을 허비하는 일 없이 쉽게 개발할 수 있게 된다. 또한 같은 이유로 각 서버 간 통신을 할 때 서로가 다른 언어로 쓰여있더라도 그러한 내용을 개발자가 알 필요가 없게 되는 장점이 있다.

 

 

 

--

 

REFERENCES:

 

원격 프로시저 호출 - 위키백과, 우리 모두의 백과사전

 > Wikipedia, "원격 프로시저 호출", accessed: 2024-07-09

RPC와 REST 비교 - API 아키텍처 간의 차이점 - AWS

 > Amazon, "What's the Difference Between RPC and REST", accessed: 2024-07-09

 

---

 

5.3 Remote Procedure Call — Computer Networks: A Systems Approach Version 6.2-dev documentation

 > "5.3 Remote Procedure Call", Computer Networks: A Systems Approach. Larry Peterson and Bruce Davie