gRPC

gRPC와 REST의 차이점?

gRPC와 REST는 API 설계에 사용되는 2가지 방법이다. API는 정의 및 프로토콜 세트를 사용하여 두 소프트웨어 구성 요소가 서로 통신할 수 있게 하는 메커니즘이다. gRPC는 한 구성 요소(해당 클라이언트)가 다른 소프트웨어 구성 요소(해당 서버)의 특정 함수를 직접 또는 간접적으로 호출한다. REST에서는 함수를 직접적으로 호출하는 대신 클라이언트가 서버의 데이터를 요청하거나 업데이트 한다.

​gRPC(Google Remote Procedure Call)

 : Google에서 만든 RPC. Cloud Native Comuting Foundation 에서 관리하는 오픈 소스 API 아키텍처 및 시스템이다. 원격 프로시저 호출(RPC) 모델을 기반으로 한다. RPC모델은 광범위하지만 gRPC는 특정 구현이다.

 

그럼 RPC는 무엇인가?

: Remote Procedure Call(원격 프로시저 호출)의 약자. 별도의 원격 제어를 위한 코딩 없이 다른 주소 공간에서 함수나 프로시저를 실행할 수 있게 하는 프로세스 간 통신 기술을 말한다. 다시 말해, RPC를 이용하면 프로그래머는 함수 또는 프로시저가 실행 프로그램이 존재하는 로컬 위치에 있든, 원격 위치에 있든 상관없이 동일한 기능을 수행할 수 있음을 의미한다.

 

함수(Function) : Input에 따른 Output의 발생을 목적으로 한다. 따라서 Return값을 필수로 가져야 하며, Client단에서 처리되기 때문에 주로 간단한 계산 및 수치 등을 도출할 때 사용

 

프로시저(Procedure) : Output값 자체에 집중하기보단, '명령 단위가 수행하는 절차'에 집중한 개념이라고 보면 된다. 따라서 Return값이 있을 수도 있고, 없을 수도 있으며, Server단에서 처리되기 때문에 함수보다 큰 단위의 실행, 프로세싱 등을 할 때 사용한다.

 

RPC에 대해 더 자세히 알아볼까?

RPC에 쓰임

 - 일반적으로 프로세스(Process)는 자신의 주소공간 안에 존재하는 함수만 호출하여 실행 가능하다. 그러나, RPC의 경우 자신과 다른 주소공간에서 동작하는 프로세스의 함수를 실행할 수 있게 해 주는데, 이는 네트워크를 통한 메시징을 수행하기 때문이다. 이 말은 "요즘 유행하는 MSA(Micro Service Architecture) 구조의 서비스를 만들 때, 언어나 환경에 구애받지 않고, 비즈니스 로직을 개발하는데에 집중할 수 있다!"는 뜻이다.

 

RPC의 목표

 - Client-Server 간의 커뮤니케이션에 필요한 상세정보는 최대한 감춘다. (=> 언어나 환경에 구애를 받지 않는다! )

 - Client와 Server는 각각 일반 메서드를 호출하는 것처럼 원격지의 프로시저를 호출할 수 있다.

 - 서버도 마찬가지로 일반 메소드를 다루는 것처럼 원격 메서드를 다룰 수 있다. 

RPC의 메커니즘

출처 : geeks for geeks

 

  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은 반환 파라미터들과 실행 결과값을 다시 해체한다.

 

참고 사이트 및 더 깊이 공부해보자.

 

https://co-no.tistory.com/28

[개념] RPC(Remote Procedure Call)의 개념 및 특징

https://velog.io/@jakeseo_me/RPC%EB%9E%80

RPC란?

 

gRPC는 프로토콜 버퍼를 인터페이스 정의 언어( IDL )와 기본 메시지 교환 형식으로 사용할 수 있습니다.

 

개요

gRPC에서 클라이언트 애플리케이션은 로컬 개체인 것처럼 다른 시스템에 있는 서버 애플리케이션의 메서드를 직접 호출할 수 있으므로 분산 애플리케이션과 서비스를 더 쉽게 만들 수 있다. 많은 RPC 시스템과 마찬가지로 gRPC는 서비스 정의, 매개변수 및 반환 유형을 사용하여 원격으로 호출할 수 있는 메서드를 지정한다는 아이디어를 기반으로 한다. 서버 측에서 서버는 이 인터페이스를 구현하고 gRPC 서버를 실행하여 클라이언트 호출을 처리한다. 클라이언트 측에서 클라이언트에는 서버와 동일한 방법을 제공하는 스텁(일부 언어에서는 클라이언트라고도 함)이 있다.

gRPC

 

gRPC 클라이언트와 서버는 Google 내부 서버부터 사용자 데스크톱까지 다양한 환경에서 서로 실행하고 통신할 수 있으며 gRPC가 지원하는 모든 언어로 작성될 수 있다. 예를 들어 Go, Python 또는 Ruby 클라이언트를 사용하여 Java로 gRPC 서버를 쉽게 만들 수 있다.

 

기본적으로 gRPC는 프로토콜 버퍼를 사용한다.

 

프로토콜 버퍼로 작업할 때 첫 번째 단계는 proto 파일에서 직렬화하려는 데이터의 구조를 정의하는 것이다. 이는 확장명이 있는 일반 텍스트 파일로 .proto. 프로토콜 버퍼 데이터는 메시지로 구성된다.

각 메시지는 필드 라고 하는 일련의 이름-값 쌍을 포함하는 작은 논리적 정보 레코드이다 .

 

<간단한 예시>

message Person {
  string name = 1;
  int32 id = 2;
  bool has_ponycopter = 3;
}

 

데이터 구조를 지정하고 나면 프로토콜 버퍼 컴파일러를 사용하여 protocproto 정의에서 원하는 언어로 데이터 액세스 클래스를 생성한다. 예를 들어, 선택한 언어가 C++인 경우 위 예제에서 컴파일러를 실행하면 Person이라는 클래스가 생성된다. 그런 다음 애플리케이션에서 이 클래스를 사용하여 Person프로토콜 버퍼 메시지를 채우고, 직렬화하고, 검색할 수 있다.

 

프로토콜 버퍼 메시지로 지정된 RPC 메서드 매개 변수 및 반환 유형을 사용하여 일반 proto 파일에서 gRPC 서비스를 정의한다.

 

프로토콜 버퍼 버전

일반적으로 proto2(현재 기본 프로토콜 버퍼 버전)를 사용할 수 있지만 gRPC와 함께 proto3을 사용하는 것이 좋다. gRPC 지원 언어의 전체 범위를 사용할 수 있을 뿐만 아니라 proto2 클라이언트와 통신하는 호환성 문제를 피할 수 있기 때문이다. (프로토콜 버퍼 버전 3(proto3)은 구문이 약간 단순화되고 몇 가지 유용한 새 기능이 있으며 더 많은 언어를 지원한다.)

 

핵심 개념

서비스 정의

service HelloService {
  rpc SayHello (HelloRequest) returns (HelloResponse);
}

message HelloRequest {
  string greeting = 1;
}

message HelloResponse {
  string reply = 1;
}

 

gRPC를 사용하면 네 가지 종류의 서비스 방법을 정의할 수 있다.

1. 일반 함수 호출과 마찬가지로 클라이언트가 서버에 단일 요청을 보내고 단일 응답을 다시 받는 단항 RPC.
   rpc SayHello(HelloRequest) returns (HelloResponse);
2. 클라이언트가 서버에 요청을 보내고 일련의 메시지를 다시 읽기 위한 스트림을 가져오는 서버 스트리밍 RPC. 클라이언트는 더 이상 메시지가 없을 때까지 반환된 스트림에서 읽는다. gRPC는 개별 RPC 호출 내에서 메시지 순서를 보장한다.
   rpc LotsOfReplies(HelloRequest) returns (stream HelloResponse);
3. 클라이언트가 일련의 메시지를 작성하고 이를 다시 제공된 스트림을 사용하여 서버에 보내는 클라이언트 스트리밍 RPC. 클라이언트는 메시지 쓰기를 마치면 서버가 메시지를 읽고 응답을 반환할 때까지 기다린다. 다시 gRPC는 개별 RPC 호출 내에서 메시지 순서를 보장한다.
   rpc LotsOfGreetings(stream HelloRequest) returns (HelloResponse);
4. 양쪽에서 읽기-쓰기 스트림을 사용하여 일련의 메시지를 보내는 양방향 스트리밍 RPC. 두 스트림은 독립적으로 작동하므로 클라이언트와 서버는 원하는 순서로 읽고 쓸 수 있다. 예를 들어 서버는 응답을 쓰기 전에 모든 클라이언트 메시지를 수신하기를 기다릴 수도 있고, 교대로 메시지를 읽은 다음 메시지를 쓸 수도 있다. 또는 읽기와 쓰기의 다른 조합. 각 스트림의 메시지 순서는 유지된다.
   rpc BidiHello(stream HelloRequest) returns (stream HelloResponse);

https://grpc.io/docs/what-is-grpc/core-concepts/

Core concepts, architecture and lifecycle