HTTP, Socket
을 많이 사용!polyglot
: 다중 언어 모델-> 이러한 경우에 RPC를 이용하여 언어에 구애받지 않고, 원격에 있는 procdure를 호출
하여 비즈니스 로직에 집중하는 개발 가능!
-> rpc를 이용하면 프로그래머는 함수가 실행프로그램에 로컬이든 원격이든 동일한 코드를 이용할 수 있다.
RPC란 프로세스간 통신을 위해 사용하는 IPC의 한 종류이다.(PIPE, Queue, Socket) 원격지의 프로세스에 접근하여 프로시저 또는 함수를 호출하여 사용.
일반적으로는 프로세스는 자신의 주소공간 안에 존재하는 함수만 호출하여 실행 가능. RPC를 이용하면 다른 주소공간에서 동작하는 프로세스의 함수를 실행할 수 있게 된다. 분산 컴퓨팅 환경에서 프로세스 간 상호 통신 및 컴퓨팅 자원의 효율적인 사용을 위해
RPC는 분산컴퓨팅과 client-server 베이스인 앱을 위한 기술. RPC는 일반적인 로컬 프로시저 호출을 확장! 그래서 호출된 프로시저는 호출하는 프로시저와 같은 주소 공간에 존재하지 않음.
두 프로세스들이 같은 시스템에 있거나 다른 시스템에 존재하며 네트워크가 그들을 연결하는 형태로 존재
RPC는 특히 제어 흐름이 호출자와 수신자 간에 교대로 이루어지는 클라이언트-서버 (쿼리-응답) 상호작용에 적합하다. 개념적으로, 클라이언트와 서버는 동시에 실행하지 않는다. 대신, 실행 스레드가 호출자로부터 수신자에게 점프했다가 다시 돌아온다.(동기적인 느낌)
따라서 Return 값이 있을 수도, 없을 수도 있으며, Server단에서 처리되기 때문에 함수보다 큰 단위의 실행, 프로세싱 등을 할 떄 사용한다.
커다란 프로시저 바구니안에 여러가지 함수들이 존재하는 느낌
[프로시저 [함수1] -> [함수2] -> [함수..n]]
일반적으로 프로세스는 자신의 주소공간 안에 존재하는 함수만 호출하여 실행 가능
그러나, RPC의 경우 자신과 다른 주소공간에서 동작하는 프로세스의 함수를 실행할 수 있게 해주는데, 이는 네트워크를 통한 메세징을 수행하기 때문에 가능하다
client stub procedure
를 호출. client는 클라이언트를 소유한 주소 공간 내에 거주client stub
이 파라미터들을 메세지로 모은다 (파라미터의 표현을 표준 포맷으로 변경하고 각 파라미터를 복사해서 메세지로 넣는 것)trandsport layer
(port 80, 443)로 메세지를 보낸다.transport layer
는 메세지를 server stub
으로 보낸다. server stub은 또 파라미터들을 모아주고 일반적인 프로시저 호출 메커니즘을 사용하여 요구된 서버 루틴을 호출server stub
로 반환(프로시저 호출 반환값을 통해), server stub은 결과 값들을 모아서 메세지에 넣고, trandport layer
에 메세지를 보낸다.client transport layer
로 보내고 client transport layer는 client stub
에 전달client stub
은 반환 파라미터들과 실행 결과값을 다시 해체일반적인 http 와 차이가 있다면
- http는 application 계층을 통해 전달되는 반면
- RPC는 transport 계층을 통해 전달이 되는 듯 하다
IDL 파일
을 rpcgen 컴파일러를 이용하여 stub코드
를 자동으로 생성한다.여러가지 언어를 하나의 중립적인 언어로 변환시키는게 IDL
프로그램에 포함하여 빌드
자신의 프로세스 주소공간의 함수를 호출
하는 것처럼 동일
하게 stub에 정의된 함수를 호출할 수 있다.XDR형식으로 변환
하여 RPC호출을 실행한다.메모리 저장방식
이 CPU 아키텍쳐별로 다르며, 네트워크 전송과정에서 바이트 전송 순서
를 보장 위함RPC 런타임: RPC 런타임 시스템은 RPC 메커니즘을 기반으로한 네트워크 통신을 다루는 서비스의 집합과 루틴의 라이브러리
. RPC호출 과정에서, 클라이언트 사이드와 서버 사이드 런타임 시스템의 코드는 바인딩
을 다루고, 적절한 프로토콜 위에서 통신을 구성
클라이언트와 서버 사이에서 호출 데이터를 넘기고 통신 에러를 다룬다.
stub : stub의 함수는 프로그래머가 쓴 어플리케이션 코드에 투명성을 제공하기 위함
클라이언트 사이드에서는 stub이 클라이언트의 로컬 프로시저 호출
과 런타임 시스템
을 다루고, 데이터를 모으고 해체
하고, RPC 런타임 프로토콜을 호출하
고 만일 요청됐다면, 몇가지 바인딩 스텝을 수행한다.
서버 사이드에서는 stub이 런타임 시스템과 서버에 의해 실행된 로컬 매니저 프로시저 사이에 비슷한 인터페이스를 제공
가장 유연한 해결법은 동적 바인딩을 사용하고 RPC가 처음 만들어졌을 때 런타임에 서버를 찾는 것
. 클라이언트 스텁이 처음 호출됐을 때, 서버가 있는 곳에 transport address를 결정하기 위해 네임 서버에 접근한다.
개발 집중
가능 (하부 네트워크 프로토콜 신경 x)쉽게
구현, 정교 제어가능기존에는 프로세스간 통신을 위해 소켓 통신, 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