RPC 란?

지정온·2023년 10월 16일
0

정의

  • 원격 제어를 위한 코딩 없이 다른 주소 공간에서 함수나 프로시저를 실행할 수 있게 하는 프로세스간 통신 기술

탄생 배경

  • 분산 네트워크 컴퓨터 환경에서 프로그래밍을 쉽게 할 수 있는 방법을 찾다가

일반적인 통신 패턴

  • Client to Server
    • Server를 켜 -> Client는 Server에 요청 -> Server는 응답 반환 -> Client는 응답으로 요청 결과 확인
    • HTTP, Socket 을 많이 사용!

RPC가 필요한 이유

  • MSA 구조로 서비스를 만들다보면, 다양한 언어 + 프레임워크로 개발
  • Polyglot한 구조에서는 프로토콜을 맞춰서 통신해야 하는 비용 발생
    • polyglot : 다중 언어 모델

-> 이러한 경우에 RPC를 이용하여 언어에 구애받지 않고, 원격에 있는 procdure를 호출하여 비즈니스 로직에 집중하는 개발 가능!

RPC란?

  • remote procedure call은 별도의 원격 제어를 위한 코딩 없이 다른 주소 공간에서 함수나 프로시저를 실행항 수 있게ㅏ는 프로세스 간 통신 기술

-> rpc를 이용하면 프로그래머는 함수가 실행프로그램에 로컬이든 원격이든 동일한 코드를 이용할 수 있다.

RPC란 프로세스간 통신을 위해 사용하는 IPC의 한 종류이다.(PIPE, Queue, Socket) 원격지의 프로세스에 접근하여 프로시저 또는 함수를 호출하여 사용.

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

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

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

프로시저와 함수의 차이

  • 함수는 인풋으로인한 아웃풋의 발생을 목적으로 Client단에서 처리되어서 간단 계산, 수치 도출
  • 프로시저는 결과보다는 '명령 단위가 수행하는 절차'를 목적

따라서 Return 값이 있을 수도, 없을 수도 있으며, Server단에서 처리되기 때문에 함수보다 큰 단위의 실행, 프로세싱 등을 할 떄 사용한다.

커다란 프로시저 바구니안에 여러가지 함수들이 존재하는 느낌

[프로시저 [함수1] -> [함수2] -> [함수..n]]

그래서, RPC 어디에 쓰는데

일반적으로 프로세스는 자신의 주소공간 안에 존재하는 함수만 호출하여 실행 가능
그러나, RPC의 경우 자신과 다른 주소공간에서 동작하는 프로세스의 함수를 실행할 수 있게 해주는데, 이는 네트워크를 통한 메세징을 수행하기 때문에 가능하다

RPC의 목표!

  • 클라이언트 - 서버 간의 커뮤니케이션에 필요한 상세정보 감추기 ( => 언어 환경 구애 x)
  • 클라이언트는 일반 메소드를 호출하는 것처럼 원격지의 프로시저를 호출할 수
  • 서버도 마찬가지로 일반 메소드를 다루는 것처럼 원격 메소드를 다룰 수

RPC의 동작 방식

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

일반적인 http 와 차이가 있다면

  • http는 application 계층을 통해 전달되는 반면
  • RPC는 transport 계층을 통해 전달이 되는 듯 하다

동작방식 (with IDL)

  1. IDL을 사용하여 서버의 호출 규약을 정의. 함수명, 인자, 반환값에 대한 데이터 형이 저장된 IDL 파일을 rpcgen 컴파일러를 이용하여 stub코드를 자동으로 생성한다.
    • IDL(Interface Definition Language) : 인터페이스 정의 언어. 어느 한 언어에 국한되지 않는 언어 중립적인 방법으로 인터페이스를 표현함으로써, 구현 언어(C, C++, Java 등)가 아닌 정의 언어로, 구현 언어로의 매핑(mapping)을 지원.

여러가지 언어를 하나의 중립적인 언어로 변환시키는게 IDL

  1. stub는 원시소스코드의 형태로 만들어지므로 클라이언트, 서버 프로그램에 포함하여 빌드
  2. 클라이언트 프로그램 입장에서 자신의 프로세스 주소공간의 함수를 호출하는 것처럼 동일하게 stub에 정의된 함수를 호출할 수 있다.
  3. stub코드는 데이터형을 XDR형식으로 변환하여 RPC호출을 실행한다.
  • 변환의 이유는 기본 데이터 타입에 대한 메모리 저장방식이 CPU 아키텍쳐별로 다르며, 네트워크 전송과정에서 바이트 전송 순서를 보장 위함
  1. 서버는 수신된 함수/프로시저 호출에 대한 처리 완료 후, 결과값을 XDR변환후 반환.
  2. 클라이언트가 서버의 결과를 반환받는다.

RPC 이슈들

  1. RPC 런타임: RPC 런타임 시스템은 RPC 메커니즘을 기반으로한 네트워크 통신을 다루는 서비스의 집합과 루틴의 라이브러리. RPC호출 과정에서, 클라이언트 사이드와 서버 사이드 런타임 시스템의 코드는 바인딩을 다루고, 적절한 프로토콜 위에서 통신을 구성 클라이언트와 서버 사이에서 호출 데이터를 넘기고 통신 에러를 다룬다.

  2. stub : stub의 함수는 프로그래머가 쓴 어플리케이션 코드에 투명성을 제공하기 위함

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

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

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

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

RPC의 장점

  1. 고유 프로세스 개발 집중 가능 (하부 네트워크 프로토콜 신경 x)
  2. 프로세스간 통신 기능을 비교적 쉽게 구현, 정교 제어가능

RPC의 단점

  1. 호출 실행과 반환 시간이 보장되지 않음(네트워크 구간을 통해 RPC통신 하는 경우, 네트워크가 끊겼을 때 치명적 문제 발생)
  2. 보안이 보장되지 않음

현재 통신 방법의 트렌드

기존에는 프로세스간 통신을 위해 소켓 통신, RPC 같은 방식이나 RPC 활용한 CORBA, RMI 같은 방식이 많이 사용됐다.

현재는 웹기술이 발달해서 SOAP, REST 등과 같은 방식이 대세를 이루고 있다. 2015년에는 구글에서 RPC와 웹기술을 혼합한 gRPC를 처음 발표

RPC모델은 분산 컴퓨팅 에서 많이 사용. 현재는 MSA에서 마이크로 서비스 간에 많이 사용한다. 서로 다른 환경이지만 서비스간의 프로시저 호출을 가능하게 해서 언어제 구애 받지 않고 환경에 대한 확장이 가능, 비즈니스 로직에 집중하여 생산성 증가.

참고문헌

https://velog.io/@jakeseo_me/RPC%EB%9E%80
https://co-no.tistory.com/28

profile
가보쟈고

0개의 댓글

관련 채용 정보