[프로그래밍] RPC Remote Procedure Call 원격 프로시저 호출

출처

ChatGPT

https://www.ibm.com/docs/ko/aix/7.3?topic=concepts-remote-procedure-call

리모트 프로시저 호출

https://ko.wikipedia.org/wiki/%EC%9B%90%EA%B2%A9_%ED%94%84%EB%A1%9C%EC%8B%9C%EC%A0%80_%ED%98%B8%EC%B6%9C

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

https://www.geeksforgeeks.org/what-is-rpc-mechanism-in-distributed-system/

What is Remote Procedural Call (RPC) Mechanism in Distributed System? - GeeksforGeeks

https://www.guru99.com/remote-procedure-call-rpc.html

Remote Procedure Call (RPC) Protocol in Distributed System

https://engineeringhulk.com/remote-procedure-call-rpc/

Remote procedure call [RPC]: A detailed overview about RCP

 

 

---

RPC Remote Procedure Call 원격 프로시저 호출이란

RPC는 원격으로 다른 주소 공간이나 다른 컴퓨터에서 실행되고 있는 프로시저(함수나 메서드)를 호출하도록 하는 기술이다. 클라이언트가 마치 로컬인 것처럼 원격 서버에서 기능을 실행할 수 있도록 하는 분산 시스템을 프로토콜로 구현되었다. 

 

🤔 프로시저란

특정 작업을 수행하는 명령어들의 집합. 호출할 수 있는 함수(클래스에 속하지 않고 전역적으로 사용 가능)와 메서드(객체나 클래스의 일부분).

🤔 프로시저와 함수랑 뭐가 다른가

프로시저는 일반적으로 값을 반환하지 않고 작업을 수행하는 명령어들의 집합이다. 작업을 수행하는 것에 중점을 둔다.

함수는 반환값이 있는 명령어들의 집합이다. 결과를 반환하는 것에 중점을 둔다.

일부 프로그래밍 언어에서는 두 용어 혼용되기도 한다.

🤔 프로토콜이란

컴퓨터나 시스템 간에 데이터 전송을 할 때 따르는 규칙과 절차를 정의한 표준

 

RPC 주요 특징

1. 투명성

원격 프로시저 호출은 네트워크 통신의 복잡성을 추상화해서 원격 프로시저가 마치 로컬 함수 호출처럼 보인다. 개발자는 네트워크 통신의 복잡성을 신경 쓸 필요없이, 원격 시스템의 함수를 호출할 수 있어 개발을 단순화한다. 

2. 동기적 호출

대부분 RPC는 동기적으로 작동해서 호출자는 원격 프로시저가 완료될 때까지 기다린다. 비동기적 RPC도 가능하다.

3. 언어 및 플랫폼 독립성

다양한 프로그램이 언어나 플랫폼에서 사용할 수 있다. 호출하는 쪽과 호출되는 쪽이 반드시 동일한 시스템일 필요가 없다.

4. 인터페이스 정의

RPC를 사용하려면 호출하고자 하는 함수들의 인터페이스가 정의되어 있어야 한다. 이를 위해 인터페이스 정의 언어(IDL: Interface Definition Language)를 사용해 함수 시그니처를 정의할 수 있다.

 

🤔 IDL이란

서로 다른 시스템이나 프로그래밍 언어 간에 통신할 때, 함수나 데이터 구조의 인터페이스를 정의하는 언어. 이를 통해 분산 시스템에서 클라이언트와 서버가 서로 다른 언어로 구현되어 있더라도, 서로의 인터페이스를 이해하고 상호작용할 수 있게 된다.

 

RPC 종류

콜백 RPC Callback RPC

서버가 클라이언트에게 역으로 프로시저를 호출하는 형태. 일반적인 RPC는 클라이언트가 서버의 프로시저를 호출하는 방식이지만, 콜백 RPC는 클라이언트가 서버에 요청을 보내면, 서버가 다시 클라이언트에게 특정 작업을 수행하도록 요청할 수 있는 기능을 포함한다. 

클라이언트는 서버로부터 콜백이 올 때까지 대기 상태가 될 수 있어서 동시성 문제나 교착 상태(deadlock)가 발생할 수 있다.

양방향 통신을 가능하게 해서 피어 투 피어 모델을 지원할 수 있다.

분산 시스템이나 대규모 네트워크 응용 프로그램에서 사용되며, 양방향 통신이 필요할 때 유용하게 사용된다.

 

🤔 교착 상태 : 둘 이상의 프로세스가 서로 점유한 자원을 기다리며 무한히 대기하는 상태

🤔 피어 투 피어(Peer-to-Peer) 모델 : 각 노드가 서버와 클라이언트 역할을 동시에 수애하며, 서로 직접 자원을 공유하고 통신하는 네트워크 구조

• 🤔 노드 : 네트워크 내에서 데이터를 송수신하거나 자원을 공유하는 개별적인 장치나 시스템

브로드캐스트 RPC Broadcast RPC

클라이언트의 요청이 네트워크에 연결된 모든 서버로 동시에 브로드캐스트되며, 해당 요청을 처리할 수 있는 서버가 응답을 보낸다.

각 서버는 클라이언트가 보낸 요청을 처리할 수 있고 브로드캐스트된 메시지에 대한 응답을 선택적으로 보낼 수 있는 서버의 자율성이 있다.

네트워크 상의 모든 서버로 메시지가 전송되기 때문에 네트워크 트래픽이 증가할 수 있어서 큰 규모의 네트워크에서 신중한 설계가 필요하다.

여러 서버가 동일한 작업을 수행할 수 있는 환경에서 유용하다. 분산 데이터베이스나 멀티캐스트 네트워크에서 클라이언트가 여러 섭에 요청을 보내고, 이를 처리할 수 있는 서버에서 가장 빠른 응답을 받아 처리하는 경우에 사용될 수 있다.

 

🤔 멀티캐스트 네트워크란

한 출발지에서 여러 수신지로 데이터를 동시에 전송할 수 있는 네트워크 통신 방식. 특정 그룹에 속한 다수의 수신자에게만 데이터를 전송해서, 네트워크 자원을 효율적으로 사용할 수 있다. 동일한 데이터 패킷을 여러 번 전송할 필요 없이, 한 번의 전송으로 여러 대상에게 데이터를 전달할 수 있다. 데이터가 네트워크 상에서 한 번만 전송된 후, 그 데이터를 수신할 필요가 있는 노드(수신자)로 복사되는 구조를 사용한다.

• 주요 특징
  • 그룹 통신 : 여러 수신자를 그룹으로 묶어 데이터를 보내므로, 모든 네트워크 참여자에게 브로드캐스트하는 방식과 달리 특정 그룹 내의 수신자만 데이터를 받는다.
  • 효율성 : 같은 데이터를 다수에게 전송할 때 네트워크 대역폭을 절약할 수 있어, 특히 스트리밍 미디어, 실시간 주식 거래 시스템, 비디오 회의 등 대용량 데이터 전송이 필요한 환경에서 유리하다
  • IP 멀티캐스트 : 주로 IP 기반 네트워크에서 사용되며, IGMP(Internet Group Management Protocal) 같은 프로토콜 사용해 멀티캐스트 그룹을 관리한다. 
    • 🤔 IGMP : IP 멀티캐스를 그룹을 관리하는 프로토콜. 호스트(컴퓨터 등)과 근처의 라우터 사이에서 멀티캐스트 그룹에 참여하거나 나가는 요청을 관리한다.

배치모드 RPC Batch-mode RPC

클라이언트 측에서 여러 RPC 요청을 수집해 한번에 서버로 전송한다. 이렇게 하면 여러 개의 별도 요청을 보내는 네트워크 오버헤드가 줄어든다. 

여러 RPC 요청을 하나의 전송 버퍼에 저장해, 네트워크를 통해 한 번에 서버로 전송한다. 이를 통해 각 요청을 개별적으로 전송할 때 발생하는 네트워크 지연 시간을 줄일 수 있지만, 실시간 응답이 필요한 경우에는 적합하지 않을 수 있다.

네트워크 오버헤드를 줄여 성능을 최적화할 수 있찌만, 낮은 호출빈도를 요구하는 애플리케이션에 적합하다. 

데이터를 한 번에 전송하기 때문에 신뢰성이 있는 전송 프로토콜이 필요하다.

분산 시스템이나 네트워크 통신이 빈번하지 않는 환경에서 유용하다.

Stateless RPC

서버가 클라이언트의 이전 요청 상태를 기억하지 않고, 각 요청을 독립적으로 처리한다. 각 호출은 클라이언트가 필요한 모든 정보를 포함한 요청을 서버에 보내고, 서버는 요청을 처리한 후 결과만 반환한다. 클리언트와 서버 간의 상호작용이 이전 요청과 무관하게 별도로 이루어진다.

확장성, 단순성을 제공한다. HTTP와 같은 프로토콜에서는 RESTful API와 유사하게 적용될 수 있다.

Stateful RPC

서버가 클라이언트의 이전 요청 상태를 기억하고 유지하는 원격 프로시저 호출 방식이다. 이 방식에서는 클라이언트와 서버 간의 여러 요청이 연결되어, 서버가 각 요청에 대해 세션 정보나 상태를 유지하면서 처리한다. 

상태를 관리하는 데 필요한 추가적인 로직이 필요하며, 이로 인해 시스템이 더 복잡해지고 확장성이 어려울 수 있다.

상태가 중요한 애플리케이션(예 : 온라인 게임, 금융 거래 시스템)에서 자주 사용되며, 상태 정보를 공유하거나 지속적인 인터렉션이 필요한 경우에 유용하다. 그러나 분산 시스템에서는 상태를 관리하는 것이 까다롭고 서버 장애 시 상태 정보 복구에 추가적인 노력이 필요하다.

 

비동기 RPC Asynchronous RPC

클라이언트가 원격 프로시저 호출을 보낸 다음 서버가 요청을 처리하는 동안 다른 작업을 계속할 수 있다. 클라이언트는 서버가 요청 처리를 완료하면 알림을 받는다. 비동기 RPC는 완료하는 데 오랜 시간이 걸리는 작업에 유용하다. 클라이언트가 서버가 요청을 처리하는 동안 다른 작업을 동시에 수행할 수 있어서 병렬 처리가 가능하다. 네트워크 지연기 길거나 처리 시간이 긴 작업에 유용하며, 클라이언트가 응답 대기 시간 없이 다른 작업을 계속 할 수 있다. 비동기 초리게 추가적인 콜백 관리와 에러 처리 로직이 필요하며, 코드의 복잡도는 증가할 수 있다.

 

동기 RPC Synchronous RPC

클라이언트가 다른 작업을 계속하기 전에 서버가 요청 처리를 마칠 때까지 기다려야 한다. 동기 RPC는 클라이언트가 즉시 응답을 받을 수 있도록 보장하므로 빠른 응답이 필요한 작업에 유용하다. 그러나 클라이언트가 서버가 요청 처리를 마칠 때까지 다른 작업을 계속할 수 없으므로 복잡한 작업을 처리할 때 비효율적일 수 있다. 요청 후 응답을 기다리기 때문에 클라이언트-서버 통신의 흐름이 직관적이고 복잡성이 적다.

 

RPC 동작 과정

1. 클라이언트 요청

클라이언트 프로그램은 로컬 함수처럼 원격 프로시저를 호출한다. 이때 원격 시스템의 IP주소와 함수 이름이 필요할 수 있다.

2. 스텁

클라이언트와 서버 간의 네트워크 통신을 숨기기 위해 스텁(stub)이라는 중간 계층이 존재한다. 클래이언트를 이 스텁을 통해 원격 호출을 수행한다.

• 클라이언트 스텁 : 호출된 함수의 인자를 네트워크로 전송할 수 있도록 직렬화(마샬링)한다.
• 서버 스텁 : 네트워크에서 받은 데이터를 역직렬화(언마샬링)하고 실제 원격 프로시저를 호출한다.

🤔 마샬링 : 프로시저 인수와 반환 값을 네트워크를 통해 전송할 수 있는 형식으로 변환하는 프로세스. 일반적으로 데이터를 바이터 스트림으로 직렬화하는 것을 포함하낟.

🤔 언마샬링 : 수신된 바이트 스트림을 수신 시스템에서 사용할 수 있는 원래 데이터 형식으로 다시 변환하는 역과정.

3. 네트워크 통신

클라이언트 스텁이 생성한 요청이 네트워크를 통해 서버로 전송된다. 이때 TCP, UDP와 같은 프로토콜을 사용할 수 잇다.

4. 원격 프로시저 실행

서버에서 요청을 받은 후 해당 프로시저를 실행하고, 결과를 클라이언트로 반환한다.

5. 결과 반환

서버가 반환한 결과는 클라이언트 스텁을 통해 다시 역직렬화되어 클라이언트에게 전달된다.

 

RPC 장점

추상화

네트워크 통신을 추상화해서 개발자가 마치 로컬 프로시저를 호출하는 것처럼 원격 프로시저를 쉽게 호출할 수 있다.

분산 시스템 지원

RPC는 IPC(프로세스 간 통신)으로 다양한 노드 간 상호작용이 필요한 분산 컴퓨팅을 용이하게 만들어 준다. 이를 통해 여러 서버에 기능을 분산시킬 수 있다. 

데이터베이스, 컴퓨팅 능력, 전문 기능 등의 리소스와 서비스를 네트워크 전체에서 공유할 수 있다.

유연성

다양한 언어와 플랫폼 간의 통신을 가능하게 해, 이질적인 환경에서도 효율적인 원격 호출을 지원한다.

향상된 모듈성 및 재사용성

RPC는 시스템 구성 요소의 커플링을 줄인다. 유지 관리 및 확장성이 더 뛰어난 시스템을 구축하는데 도움이 되고, 구성 요소를 재상요할 수 있다.

 

RPC 단점

성능 문제

로컬 함수 호출에 비해 네트워크 통신이 발생하므로 지연 시간이 증가할 수 있으며, 네트워크 상태에 따라 성능 저하가 발생할 수 있다.

오류 처리

네트워크 오류, 타임아웃, 서버 불능 등의 문제가 발생할 수 잇으며, 이러한 경우 로컬 호출과 달리 복잡한 오류 처리가 필요하다.

상태 관리

원격 시스템 간의 상태 공유가 어렵기 때문에 상태를 유지하려면 추가적인 처리가 필요할 수 있다.

 

RPC 예시

• gRPC : 구글에서 개발한 RPC 프레임워크로, 성능이 뛰어나며, Protocal Buffers라는 직렬화 방식과 함께 사용된다.
• XML-RPC : XML을 기반으로한 RPC 방식. 간단하나 구조와 HTTP를 사용해 널리 사용된다.
• JSON-RPC : JSON 포맷을 사용하는 RPC 방식. 경량의 프로토콜이며 웹 환경에서 자주 사용된다. 

 

RPC와 REST의 비교

RPC와 REST는 서로 다른 방식으로 클라이언트와 서버 간의 통신을 지원하는 분산 시스템에서 사용하는 프로토콜 또는 아키텍처 스타일이다. 둘의 차이점은 주로 통신 방식, 데이터 전송 방식, 사용 목적 등에서 나타난다.

둘 중 어느 것이 더 적합한지는 사용 목적에 따라 다른다. 고성능, 효율성이 필요하면 RPC가, 간편하고 웹 친화적인 상호 운용성이 중요한 경우 REST가 적합하다.

	RPC	REST
통신 방식	클라이언트가 원격 서버에 있는 특정 프로시저나 함수를 호출하는 방식. gRPC같은 현대적인 RPC 구현체는 프로토콜 버퍼 같은 이진 형식으로 데이털르 직렬화하고, HTTP/2를 통해 데이터를 전송한다.	리소스 기반 통신으로 중심으로 한느 아키텍처 스타일이다. RESTful API는 HTTP 메서드(GET, POST, PUT, DELETE)를 사용해 서버의 리소스를 조작하고, 리소스는 주로 URL을 통해 접근된다. 데이터는 주로 JSON이나 XML 형식으로 전송된다.
상태 관리	상태 유지가 가능할 수 있다.  클라이언트와 서버 간의 세션이 유지되는 상황에서 상태 기반으로 호출을 관리할 수 있다. 요청과 응답 간에 일정한 컨텍스트를 유지할 수 있다.	완전히 상태가 없다.  서버는 클라이언트의 이전 요청 상태를 기억하지 않고, 모든 요청은 독립적이다. 클라이언트는 필요한 상태를 매번 요청에 포함시켜야 한다.
성능 및 효율성	gRPC같은 RPC 구현체는 이진 형식으로 데이터를 직렬화하고, HTTP/2와 같은 고성능 프로토콜을 사용해 통신해서 REST보다 더 빠르고 더 작은 데이터 패킷으로 높은 성능을 제공한다. 이는 대규모 분산 시스템이나 마이크로서비스 아키텍처에 특히 유리하다.	텍스트 기반(주로 JSON, XML) 통신을 사용해서 데이터 패킷의 크기가 상대적으로 크로 처리 성능은 떨어질 수 있다. 시스템 간 상호 운용성이 뛰어나고, API 구현과 사용이 상대적으로 간편하다.
데이터 형식	주로 이진 형식(예 : gRPC의 ProtocolBuffers)으로 데이터를 추고 받아 데이터 전송 효율성이 높다. RPC는 호출 시 특정 데이터 포맷에 맞춰진다.	주로 JSON, XML과 같은 텍스트 형식을 사용한다. 텍스트 기반 데이터 형식은 사람이 읽기 쉽지만, 이진 형식에 비해 전송 시 더 많은 네트워크 대역폭이 필요할 수 있다.
사용 사례	고성능이 요구되는 시스템에서 주로 사용된다. 예를 들어, 마이크로서비스 간 통신, 대규모 분산 시스템, 실시간 데이터 처리 등의 상황에서 RPC가 유리하다. 특히, gRPC는 양방향 스트리밍 및 동시성을 지원해, 복잡한 클라이언트-서버 통신이 필요한 경우 유용하다.	웹 애플리케이션과 모바일 API에서 주로 사용된다. API 사용이 간단하고, 범용적이며 웹 표준을 따르므로 브라우저 기반 애플리케이션 및 간단한 API를 제공하는 서비스에 적합하다.
성숙도 및 표준	여러 RPC 프로토콜들이 있지만, 표준화가 덜 되어 있어서 다양한 방식으로 구현된다.  예를 들어, XML-RPC, JSON-RPC, gRPC 등이 있으며, 각기 다른 직렬화 및 통신 방식을 사용한다.	웹 표준은 기반으로 한다. 널리 사용되고 성숙된 방식이다. RESTful API는 HTTP와 함께 사용되며, 표준화된 방식으로 쉽게 구축할 수 있다.

 

🤔 HTTP/2 : 웹 페이지 로딩 속도를 향상시키기 위해 멀티플렉싱, 헤더 압축, 서버 푸시 등을 지원하는 고성능 웹 프로토콜

• 🤔 멀티플렉싱 : HTTP/2에서 여러 요청과 응답을 한 번의 RCP 연결로 병렬 처리해서, 각각의 요청이 독립적으로 동시에 전송되도록 하는 기능
• 🤔 헤더 압축 : HTTP 요청과 응답에 사용되는 헤더를 HPACK 알고리즘으로 압축해, 네트워크 전송 크기를 줄이고 통신 성능을 높이는 기술
• 🤔 (HTTP/2의) 서버 푸시 : 클라이언트 요청 전에 서버가 필요할 것으로 예상되는 자원을 미리 클라이언트에게 전송해 웹 페이지 로딩 시간을 단축시키는 기능

🤔 마이크로서비스 : 독립적으로 배포되고 관리되는 작은 서비스들이 모여 하나의 애플리케이션을 구성하는 방식. 각각의 서비스는 특정 비즈니스 기능을 담당한다.

🤔 마이크로서비스 아키텍처 : 애플리케이션을 작은, 독립적으로 배포 가능한 서비스들로 구성하는 아키텍처 스타일.