gRPC에 대하여

기존에는 Resful API로 개발을 하는데 통신을 주고 받을때 각 모듈별로 웹서버를 띄우는 것이 부담스럽다.

 

좀 더 가볍고 

좀 더  빠르고

언어에 종속적이지 않고

여러가지 Application이 쉽게 메시지를 주고 받을 수 있는 방법이 없을까 할때 gRPC를 쓴다

 

Remote Procedure Call

- 프로세스간 통신을 위한 기법 중 하나

- 다른 컴퓨터에 있는 절차를 호출할때 마치 같은 컴퓨터에 있는 것처럼 호출 할 수 있음

- 클라이언트와 서버간에 각자가 일반 로컬 메소드를 호출하는 것처럼 사용하게 하는 것

- 다양한 언어환경에 제약 없이, 플랫폼 제약 없이 사용할 수 있게 하는 것

 

RPC의 구성요소 

- Caller / Callee는 IDL (Interface Define language)를 통하여 서로의 인터페이스를 명세한다

- Stub는 StubCompiler를 통해 IDL을 기반으로 각각의 플랫폼, 언어에 맞춰 호출 할 수 있는 Code를 생성한다

- Client와 Server간에 서로를 식별 할 수 있는 Communication layer가 있다.

 

gRPC

- 구글에서 만든 RPC Framework

- 저용량 메세지

- 고성능 RPC

 

프로토콜 버퍼로 데이터를 주고 받는다

 

데이터 자체가 바이너리이기 때문에 컴퓨터에서 변환과정 없이 매우 빠르게 처리 할 수 있고 바이너리니까 경량 패킷을 만들 수 있다.

Json과 XML과는 다르게 표현할 수 있는 데이터 구조가 많다

클래스도 전송이 가능하다

 

프로토콜 버퍼 정의하기

- client와 server 모두 동일하게 정의한다

- .proto 텍스트 파일에 IDL 정의 (서비스 정의, 주는 메시지 정의, 받는 메시지 정의)

- .proto 파일 컴파일하기 -> 각각의 플랫폼 / 언어에 맞는 코드 생성

-> 컴파일하면, c#의 경우 baseClass가 생긴다

 

서버측 코드 구현

- proto 파일을 컴파일 후 생기는 BaseClass를 implementation한다

- Server 실행

 

클라이언트 코드 구현

- 서버측 IDL 복사 (.proto파일)

- add reference 라는 기능이 있다. 서버측에 있는 IDL을 동일하게 가지고 온다

- 클라이언트에서는 각자 개발 언어와 interface에 맞춰 호출만 하면 된다

- http2를 기반으로 하기 때문에 httpClient 쓰는 것처럼 base URL을 설정해 주면 된다

- base URL이 셋팅된 http2에 interface를 쓸 수 있는 코드 (stub이 생성한 클래스) 를 포함하여 rpcClient를 생성한다

 

gRPC란?

google에서 처음 개발 한 공개 소스 원격 프로 시저 호출(RPC) 시스템. 전송을 위해 HTTP/2를 사용하고 인터페이스 설명 언어로 프로토콜 버퍼를 사용하며 인증, 양방향 스트리밍 및 흐름 제어, 바인딩 차단 또는 차단 해제 및 취소 및 시간 초과 기능을 제공한다. 그것은 많은 언어에 대한 크로스 플랫폼 클라이언트 및 서버 바인딩을 생성한다

 

gRPC에서 클라이언트 응용 프로그램을 로컬 객체인 것처럼 다른 컴퓨터의 서버 응용 프로그램에서 메서드를 직접 호출 할 수 있으므로 분산 응용 프로그램 및 서비스를 보다 쉽게 만들 수 있습니다. 많은 RPC 시스템에서처럼 gRPC는 서비스를 정의하고 매개 변수와 유형을 사용하여 원격으로 호출 할 수 있는 메소드를 지정한다는 아이디어를 기반으로 한다. 

서버 측에서는 서버 인터페이스를 구현하고 gRPC 서버를 실행하여 클라이언트 호출을 처리한다. 클라이언트 측에서 클라이언트는 서버와 동일한 메소드를 제공하는 스텁을 가지고 있다.

 

주요 사용 시나리오 

- 마이크로 서비스 스타일 아키텍쳐에서 다중 언어 서비스를 효율적으로 연결

- 백엔드 서비스에 모바일 장치, 브라우저 클라이언트 연결

- 효율적인 클라이언트 라이브러리 생성

 

핵심 기능

- 10개 언어로 된 관용적 클라이언트 라이브러리

- 유선 및 간단한 서비스 정의 프레임 워크로 매우 효율적

- http/2 기반 전송을 통한 양방향 스트리밍

- 로드 밸런싱, 추적, 상태 확인 및 인증 플러그인 지원

 

프로토콜 버퍼 

proto 파일에 직렬화하려는 데이터의 구조를 정의하는 것

 

Using API surface

- proto 파일의 서비스 정의에서 시작하여 gRPC는 클라이언트 및 서버 측 코드를 생성하는 프로토콜 버퍼 컴파일러 플러그인을 제공한다. gRPC 사용자는 일반적으로 클라이언트 측에서 이러한 API를 호출하고 서버 측에서 해당 API를 구현한다

- 서버 측에서는 서버가 서비스에 의해 선언 된 메소드를 구현하고 클라이언트 호출을 처리하기 위해 gRPC 서버를 실행한다. gRPC 인프라는 들어오는 요청을 디코딩하고 서비스 메소드를 실행하며, 서비스 응답을 인코딩한다

- 클라인트 측에서는 클라이언트가 스텁(일부 언어의 경우 선호되는 용어는 클라이언트 임) 이라고 하는 로컬 객체를 서비스와 동일한 메소드를 구현한다. 그런 다음 클라이언트는 로컬 객체의 메소드를 호출하여 해당 프로토콜 버퍼 메시지 유형에서 호출 매개 변수를 래핑한다. gRPC는 요청을 서버로 보내고 서버의 프로토콜 버퍼 응답을 반환 한 후 보인다. 

 

- 장치, 모바일 응용 프로그램 및 브라우저를 백엔드 서비스에 연결하는 분산 컴퓨팅의 마지막 마일에 적용 할 수 있다.

 

- 구글에서 제공하는 오픈 소스 툴중 하나인 protoc을 이용해 data access 클래스 코드들을 빌드한다. 빌드하게 되면 server code뿐만 아니라 client stub 코드도 생성된다.

 

- 클라이언트 측에서 클라이언트는 서버와 동일한 메소드를 제공하는 스텁을 가지고 있다.

 

지원되는 인증 메커니즘

- SSL/TLS: gRPC는 SSL/TLS 통합을 지원하며 SSL/TLS를 사용하여 서버를 인증하고 클라이언트와 서버간에 교환되는 모든 데이터를 암호화한다. 클라이언트가 상호 인증을 위한 인증서를 제공 할 수 있는 선택적 메커니즘을 사용 할 수 있다.

-Google과의 토큰 기반 인증: gRPC는 메타 데이터 기반 자격 증명을 요청 및 응답에 첨부하는 일반 메커니즘을 제공하낟. gRPC를 통해 Google API에 엑세스하는 동안 엑세스 토큰을 얻는 추가 지원은 특정 인증 흐름에 대해 제공된다.

 

- REST 단방향의 한계를 극복하고 HTTP2 기반의 Streaming을 지원

 

- 네이티브 프로토콜의 한계상 데이터 포맷 변환이 런타임시 자유롭지 못하고, 중간에 메세지를 열어서 라우팅이나 메디에이션을 하는 API Gateway 도입이 어려운 구조

 

- 다양한 언어를 지원하기 때문에 MSA 철학과도 일맥상통

 

- MSA에서 외부에 REST API를 제공할때는 grpc-gateway를 활용할 수 있다

 

HTTP/2의 특징

- Header Compression: Header Table과 Huffman Encoding 기법을 사용하여 HTTP/2 헤더 정보를 압출

- Multiplexed Streams: HTTP/1에서 요청마다 새로운 커넥션을 자주 만드는 것과는 달리 HTTP/2는 한개의 커넷견으로 동시에 여러개의 메시지를 주고 받을 수 있다

- Server Push: HTTP/2에서는 클라이언트의 요청 없이도 서버가 리소스를 보낼 수 있습니다. 클라이언트 요청이 최소화되기 때문에 성능이 향상될 수 있다. 

- Stream Priority: 요청에 우선순위를 지정하여 중요한 리소스를 먼저 전달 받을 수 있다.

 

- 일반적인 요청/응답 방식이 아니고 서버와 클라이언트가 서로 동시에 데이터를 스트리밍으로 주고 받을 수 있다

 

gRPC의 4가지 기본 개념

- Unary RPC: 서버에 single request를 보내면, 서버는 single response를 돌려준다

- Server streaming RPC서버에 single request를 보내면, 서버는 stream을 돌려준다. Stream에는 message시퀀스가 들어욌다. 클라이언트는 더 이상의 message가 없을때까지 stream을 읽어들인다

- Client streaming RPC 클라이언트가 주어진 stream을 이용하여 message sequence를 서버에 보낸다. 클라이언트는 메시지들을 모두 작성하고 나면, 서버가 읽고 response를 주기를 기다린다.

- 양방향 streaming RPC Read-write stream을 사용하여 클라이언트와 서버 두 측 모두 message sequence를 보낸다. 두 stream은 독립적으로 동작하여, 클라이언트와 서버는 원하는 순서대로 읽어들일 수 있다. 예를 들어 서버는 클라이언트의 모든 메세지를 읽은 뒤 response를 write할 수도, 아니면 번갈아 가며 한 메시지씩 읽고 쓸 수도 있다. 각 stream에서 메시지의 순서는 보존된다. 

Citation

https://blog.naver.com/phh0606c/221718739856

gRPC 란?

https://postitforhooney.tistory.com/entry/RPCgRPC-%EC%A0%81%EC%9A%A9%EC%9D%84-%EC%9C%84%ED%95%9C-gRPC-%EB%B6%84%EC%84%9D-gPRC%EB%9E%80-%EB%AC%B4%EC%97%87%EC%9D%B8%EA%B0%80

[RPC]gRPC 적용을 위한 gRPC 분석, gPRC란 무엇인가?

https://medium.com/@goinhacker/microservices-with-grpc-d504133d191d

Microservices with gRPC

https://juneyr.dev/2018-07-30/what-is-grpc