RPC

등장배경

초기 웹은 단순한 HTML 페이지를 제공하는 정적인 형태였습니다. 클라이언트가(브라우저) 요청하면 서버는 해당 HTML 페이지를 전송하는 것이 전부였습니다. 하지만, 사용자와의 상호작용이 필요한 웹 애플리케이션의 수요가 증가함에 따라, 서버 측 스크립트(예: PHP, ASP)와 데이터베이스의 사용이 보편화되었습니다. 이러한 발전은 사용자 맞춤형 콘텐츠 제공을 가능하게 했습니다.

AJAX(Asynchronous JavaScript and XML) 기술의 도입은 웹 페이지의 일부만을 동적으로 업데이트할 수 있게 하여 사용자 경험을 크게 향상시켰고, 웹 애플리케이션의 복잡성을 증가시켰습니다. 그 후, RESTful API가 웹 서비스의 통신에 대한 표준 접근 방식으로 자리 잡았지만, 이 방식에는 몇 가지 한계가 있었습니다. 특히, 클라이언트가 필요한 것보다 많은 데이터를 받아오는 '오버페칭'과 필요한 모든 데이터를 한 번의 요청으로 받아오지 못하는 '언더페칭' 문제가 있었습니다. 모바일 애플리케이션과 같이 네트워크 대역폭이 제한적인 환경에서는 이러한 문제가 더욱 심각해질 수 있습니다. REST API는 이러한 환경에서 최적화된 요청을 구성하는 데 한계가 있었습니다.

 

기본개념

```원격 프로시저 호출(영어: remote procedure call, 리모트 프로시저 콜, RPC)은 별도의 원격 제어를 위한 코딩 없이 다른 주소 공간에서 함수나 프로시저를 실행할 수 있게하는 프로세스 간 통신 기술이다. 다시 말해, 원격 프로시저 호출을 이용하면 프로그래머는 함수가 실행 프로그램에 로컬 위치에 있든 원격 위치에 있든 동일한 코드를 이용할 수 있다```

 

RPC(Remote Procedure Call)란 프로세스간 통신을 위해 사용하는 IPC(Inter Process Communication) 방법의 한 종류이다. 원격지의 프로세스에 접근하여 프로시저 또는 함수를 호출하여 사용한다. 말 그대로 원격지의 프로시저를 호출하는 것이다.

일반적으로는 프로세스는 자신의 주소공간 안에 존재하는 함수만 호출하여 실행 가능하다. 하지만, RPC를 이용하면 다른 주소공간에서 동작하는 프로세스의 함수를 실행할 수 있게 된다. 분산 컴퓨팅 환경에서 프로세스 간 상호 통신 및 컴퓨팅 자원의 효율적인 사용을 위해서 발전된 기술이다.

RPC는 분산 컴퓨팅과 client-server를 베이스로 한 앱을 위한 강력한 기술이다. RPC는 일반적인 로컬 프로시저 호출을 확장하는 것을 기반으로 한다. 그래서 호출된 프로시저의 필요가 호출하는 프로시저 처럼 같은 주소 공간에 존재하지 않는다. 두 프로세스들이 같은 시스템에 있거나 다른 시스템에 존재하며 네트워크가 그들을 연결하는 형태로 존재한다.

+ RPC 는 특히 제어 흐름이 호출자와 수신자 간에 교대로 이루어지는 클라이언트-서버 (이를테면 쿼리-응답) 상호작용에 적합하다. 개념적으로, 클라이언트와 서버는 동시에 실행하지 않는다. 대신, 실행 스레드가 호출자로부터 수신자에게 점프했다가 다시 돌아온다.

 

• 함수는 인풋에 대비한 아웃풋의 발생을 목적으로 한다.
• 프로시저는 결과 값에 집중하기 보단 '명령 단위가 수행하는 절차'를 목적으로 한다.

 

목표

• 클라이언트-서버 간의 커뮤니케이션에 필요한 상세정보는 최대한 감춘다.
• 클라이언트는 일반 메소드를 호출하는 것처럼 원격지의 프로지서를 호출할 수 있다.
• 서버도 마찬가지로 일반 메소드를 다루는 것처럼 원격 메소드를 다룰 수 있다.

 

1. 클라이언트가 일반적인 방식으로 파라미터를 넘겨 client stub procedure를 호출한다. client stub은 클라이언트를 소유한 주소의 공간 내에 거주한다.
2. client stub이 파라미터들을 메세지로 모은다. 여기서 모은다는 것에 파라미터의 표현을 표준 포맷으로 변경하고 각 파라미터를 복사해서 메세지로 넣는 것도 포함된다.
3. client stub은 원격 서버 머신으로 메세지를 보내는 계층인 transport layer로 메세지를 보낸다.
4. 서버에서, transport layer는 메세지를 server stub으로 보낸다. server stub은 또 파라미터들을 모아주고 일반적인 프로시저 호출 메커니즘을 사용하여 요구된 서버 루틴을 호출한다.
5. 서버 프로시저가 완료될 때, 서버 프로시저는 server stub으로 반환된다. (이를테면 일반적인 프로시저 호출 반환값을 통해), server stub은 결과 값들을 모아서 메세지에 넣고, transport layer에 메세지를 보낸다.
6. transport layer는 결과 메세지를 다시 client transport layer로 보내고 client transport layer는 그 결과를 또 client stub에게 전달한다.
7. client stub은 반환 파라미터들과 실행 결과값을 다시 해체한다

1. IDL(Interface Definition Language)을 사용하여 서버의 호출 규약을 정의한다. 함수명, 인자, 반환값에 대한 데이터 형이 저장된 IDL 파일을 rpcgen 컴파일러를 이용하여 stub 코드를 자동으로 생성한다.
2. Stub은 원시소스코드 (C코드 등)의 형태로 만들어지므로 클라이언트, 서버 프로그램에 포함하여 빌드한다.
3. 클라이언트 프로그램 입장에서 자신의 프로세스 주소공간의 함수를 호출하는 것처럼 동일하게 stub에 정의된 함수를 호출할 수 있게 된다.
4. stub 코드는 데이터형을 XDR(External Data Representation) 형식으로 변환하여 RPC 호출을 실행한다.
   4.1. XDR 변환 이유는 기본 데이터 타입(정수형, 부동소수점 등)에 대한 메모리 저장방식(리틀엔디안, 빅엔디안)이 CPU 아키텍쳐별로 다르며, 네트워크 전송과정에서 바이트 전송 순서를 보장하기 위함이다.
5. 서버는 수신된 함수/프로시저 호출에 대한 처리 완료 후, 결과값을 XDR 변환하여 반환한다.
6. 최종적으로 클라이언트 프로그램은 서버의 결과값을 반환받는다.

 

이슈

1. RPC 런타임: RPC 런타임 시스템은 RPC 메커니즘을 기반으로한 네트워크 통신을 다루는 서비스의 집합과 루틴의 라이브러리이다. RPC 호출 과정에서, 클라이언트 사이드와 서버 사이드 런타임 시스템의 코드는 바인딩을 다루고, 적절한 프로토콜 위에서 통신을 구성하고 클라이언트와 서버 사이에서 호출 데이터를 넘기고 통신 에러를 다룬다.
2. 스텁(Stub): 스텁의 함수는 프로그래머가 쓴 어플리케이션 코드에 투명성을 제공하기 위함이다.

클라이언트 사이드에서는 스텁이 클라이언트의 로컬 프로시저 호출과 런타임 시스템을 다루고, 데이터를 모으고 해체하고, RPC 런타임 프로토콜을 호출하고 만일 요청됐다면, 몇가지 바인딩 스텝을 수행한다.

서버 사이드에서는 스텁이 런타임 시스템과 서버에 의해 실행된 로컬 매니저 프로시저 사이에 비슷한 인터페이스를 제공한다.

1. 바인딩(Binding): 클라이언트는 누구를 호출해야 할지 어떻게 알고 서비스가 위치한 곳을 어떻게 알까?

가장 유연한 해결법은 동적 바인딩을 사용하고 RPC가 처음 만들어졌을 때 런타임에 서버를 찾는 것이다. 클라이언트 스텁이 처음 호출됐을 때, 서버가 있는 곳에 transport address를 결정하기 위해 네임 서버에 접근한다.