gRPC에 대해서 알아보자

gRPC란?

• 모든 환경에서 실행할 수 있는 최신 오픈소스 고성능 RPC 프레임워크
• 로드 밸런싱, tracing, health checking, authentication을 위한 플러그를 통해 서비스를 효율적으로 연결 가능
• device, mobile application, browser를 백엔드 서비스에 연결하기 위한 분산 컴퓨팅 적용 가능
• 프로토콜 버퍼를 IDL(Interface Definition Language) 및 메시지 교환 format으로 사용
  • 구조화된 데이터를 직렬화하기 위해 프로토콜 버퍼를 사용
• 클라이언트는 로컬의 객체인 것처럼 다른 컴퓨터의 서버에서 메서드를 직접 호출할 수 있음 => 분산 처리 프로그램 및 서비스 개발에 용이
  • 서비스 정의 개념을 기반으로 parameter와 return type을 가지고 특정 메소드를 원격으로 호출 가능
• 서버는 인터페이스를 구현하고, 클라이언트 호출을 처리하기 위한 gRPC 서버를 실행
• 클라이언트는 gRPC stub(gRPC 클라이언트)를 가지고 있음
• Google API에 gRPC 인터페이스를 제공하여, Google 기능을 쉽게 이용 가능

 

gRPC 구조

 

사용 시나리오

• microservice style architecture에서 polyglot service를 효율적으로 connect
• backend service에 모바일 device와 브라우저 클라이언트를 연결
• 효율적인 클라이언트 라이브러리 생성

 

핵심 기능

• 10개 언어 지원하는 클라이언트 라이브러리
• 심플한 service definition famework
• http/2 기반 전송을 통한 양방향 스트리밍
• 플러그 가능한 인증, 추적, 로드밸런싱, 헬스 체크

 

사용예

• NETFLIX
• Google의 Square
• CoreOS
• CISCO

 

지원 언어

 

서비스 정의

1. Unary RPCs : single request - single response

rpc SayHello(HelloRequest) returns (HelloResponse){

}

2. Server streaming RPCs :  single request - stream(multiple) response

- stream message 순서 보장

rpc LotsOfReplies(HelloRequest) returns (stream HelloResponse){

}

3. Client streaming RPCs : stream request - single response

- stream message 순서 보장

rpc LotsOfGreetings(stream HelloRequest) returns (HelloResponse) {

}

4. Bidirectional streaming RPCs : stream request - stream response

- stream message 순서 보장

rpc BidiHello(stream HelloRequest) returns (stream HelloResponse){

}

 

동기 VS 비동기

• 동기식 RPC : 서버에서 응답이 도착할 때까지 현재 스레드 차단 O
• 비동기식 RPC : 서버에서 응답이 도착하지 않아도 현재 스레드 차단 X
  • 동기식 RPC 호출은 RPC가 요구하는 프로시저 호출의 추상화에 가장 가까움
  • (네트워크는 본직적으로 비동기이고, )시나리오가 많은 곳에서는 비동기식 RPC 호출을 사용하는 것을 권고
• 각 언어별 gRPC는 동기와 비동기 모두 제공

 

RPC life cycle

Unary RPCs

1. client가 gRPC stub에서 함수 호출
2. server는 해당 호출에 대한 client의 metadata, 함수명, deadline을 사용하여 RPC가 호출되었음을 알림
3. server는 자신의 초기 metadata를 즉시 client에 보내거나, client의 request message를 기다림
   • server의 초기 metadata는 반드시 client에 response 전 보내야 함
4. server가 client의 request message를 가지면, response를 작성하기 위한 작업을 수행
   • server의 response 내용 : status code, optional status message, optional metadata
5. status가 200이라면 client는 response를 받고, client 측에서 호출을 완료

 

Server streaming RPC

1. server가 client의 request message를 받은 후, response stream을 다시 전송한다는 점을 제외하고 Unary RPC와 동일
2. 모든 response를 보낸 후 server의 상태 세부 정보(status code, optional status message, optional metadata)를 response 후 완료
3. client도 server의 모든 response 받은 후에 완료

 

Client streaming RPC

1. client가 single request 대신 request stream을 서버로 전송한다는 점을 제외하고 Unary RPC와 동일
2. server는 single response를 함

 

Bidirectional streaming RPC

1. client가 함수 호출 후, server가 client의 metadata, 함수명, deadline을 수신함으로써 호출이 재시작
2. server는 초기 metadata를 응답하거나, client가 request를 보내기 시작할 때까지 기다릴 수 있음
3. client와 server는 ping-pong을 하거나, client의 모든 message를 수신할 때까지 response를 기다릴 수 있음

 

Deadlines/Timeouts

1. client는 'DEADLINE_EXCEEDED'라는 에러로 RPC가 종료되기 전에 RPC가 완료되기를 기다리는 시간을 지정 가능
2. server는 특정 RPC가 timeout되었는지, 혹은 RPC를 완료하는데 얼마나 시간이 남았는지 확인하기 위해 쿼리할 수 있음
3. deadline과 timeout은 언어마다 다름 - 고정 시점 / 지속 시간

 

RPC 종료

1. client와 server의 결과는 일치하지 않을 수 있음
   • ex) 서버 : 모든 응답을 보냈다 / 클라이언트 : 응답이 deadline 후에 도착했다

 

RPC 취소

1. client와 server 언제든지 RPC를 취소할 수 있음
2. 취소를 하면 RPC가 즉시 종료되므로 더이상 작업을 수행하지 않음
3. 취소 전에 이루어진 변경 사항은 롤백되지 않음

 

Metadata

1. 키(문자열), 값(문자열 혹은 이진데이터) 쌍 목록 형식의 특정 RPC 호출(인증 세부 정보)에 대한 정보
2. client는 호출과 관련된 정보를 server에 제공하거나, 받을 수 있음
3. metadata에 대한 접근은 언어에 따라 다름

 

Channels

1. 지정된 host 및 port에서 gRPC server에 연결하며, client stub을 만들 때 사용
2. client는 message 압축 및 압축 해제와 같은 gRPC의 기본 동작을 수정하기 위해 특정 channel의 argument를 지정 가능
3. channel은 'connected'와 'idle'를 포함한 status를 가지고 있음
4. channel 폐쇄를 처리하는 방법은 언어에 따라 다름
5. 일부 언어는 channel status 조회를 허용

 

Authentication

• Google 토큰 기반 인증 유무에 상관없이 SSL/TLS를 사용하거나 제공된 코드를 확장하여 자체 인증 시스템에 연결 가능
• channel이나 요청을 만들 때, 필요한 'Credentials'이라 불리는 인증 정보를 자격 증명으로 제공하는 인증 API를 제공

지원되는 인증 메커니즘

• SSL/TLS
  • SSL/TLS 통합 기능 보유
  • 해당 메커니즘을 사용하여 서버를 인증하고 클라이언트와 서버간에 교환되는 모든 데이터를 암호화
  • Optional : 클라이언트가 상호 인증을 위한 인증서를 제공
• Google을 통한 토큰 기반 인증
  • metadata기반 자격 증명을 request와 response에 첨부하는 메커니즘을 제공
  • Google의 토큰(OAuth2) 획득 api 제공
  • 해당 메커니즘은 SSL/TLS와 함께 사용해야 함
    • Reason 1) Google이 SSL/TLS가 없는 연결은 허용하지 않음
    • Reason 2) 암호화되지 않은 channel에서 자격증명을 보낼 수 없음
  • Google의 자격 증명은 Google 서비스에 연결시에만 사용해야 함
    • Reason ) 해당 토큰을 Google 이외의 서비스로 전송하면, 해당 토큰이 도용되어 클라이언트를 Google 서비스로 가장하는데 사용 가능

Authentication API

• Credential types
  1. Channel credentials : SSL과 같은 Channel에 연결된 자격증명
  2. Call credentials : 호출에 첨부된 자격증명

 

기타 정보

- 개발언어 : C(core) / Java, CPP, Python 등

- 라이센스 : Apache V 2.0

 

알아두면 좋은 추가 정보

RPC(Remote Procedure Call, 원격 프로시저 호출)

* 설명

** 분산 네트워크 환경에서 조금 더 편하게 프로그래밍하기 위해 등장

*** 일반적인 communication pattern : Client-Server 패턴

*** MSA를 통해 정말 다양한 언어와 프레임워크가 존재하고, 그 구조를 지탱하기 위해서 프로토콜을 맞춰줘야 함

** 별도의 원격 제어를 위한 코딩없이 다른 서버에서 함수나 프로시저를 실행할 수 있게하는 프로세스 간 통신

** 원격 호출에 사용되는 프로토콜은 네트워크 전송 시 TCP/IP, IPx, Named Pipe 프로토콜 중 하나를 사용하도록 설계

** RPC 프로그래밍 인터페이스 : 사용자들이 시스템이 제공하는 RPC 함수들을 호출하는 최상위 계층 ~ RPC API들을 사용하여 사용자들이 RPC 프로그램을 생성하는 하위 계층

* 목표

** 클라이언트와 서버간의 커뮤니케이션에 필요한 상세 정보는 최대한 감춘다

** 클라이언트는 일반 메소드를 호출하는 것처럼

** 서버는 일반 메소드를 다루는 것처럼

* 장점

** 비즈니스 로직에 집중 가능

** polyglot 환경에서 쉽게 확장 가능

** 인터페이스 협업이 쉬움

* 단점

** 새로운 학습 비용이 듦

** 사람의 눈으로 읽기 힘듦

* 사용예

** Window 인증

** MSMQ

** SMS Servder

** DCOM

** DTC

 

프로토콜 버퍼(Protocol Buffer)

• Google의 오픈 소스 메커니즘(JSON format과 유사)
• 확장자 .proto
• 해당  파일에 서비스를 정의
• 데이터는 message로 구성
  • 각 message는 field라고 불리는 name-value 쌍을 포함하는 정보의 작은 논리적 레코드

message Person {

  string name = 1;

  int32 id = 2;

  bool has_ponycopter = 3;

}

• 데이터 구조 지정 시 프로토콜 버퍼 컴파일러인 'protoc'를 사용하여, 각 proto 정의에서 사용한 언어로 data access class를 생성(client와 server의 언어로 플러그인 생성)
  • 각 field에 대한 접근자를 제공 - name()(get name), set_name(), 전체 구조를 원시 바이트 / 직렬화 / 파싱하는 함수
• gRPC는 proto2 버전을 계속 지원하지만, proto3를 권고(이유: 보다 사용하기 쉽고, 더 많은 언어를 지원)

< Defining A Message Type >

----------------------------------------

syntax = "proto3";



message SearchRequest {

  string query = 1;

  int32 page_number = 2;

  int32 result_per_page = 3;

}

----------------------------------------

- syntax : proto3를 사용함을 지정, 지정하지 않으면 proto2

--> 반드시 파일 내 코드 시작 전에 존재해야 함(주석, 빈줄 제외)

- message를 정의, 예제에는 3개의 field(name-value) 존재

 

 

IDL(인터페이스 정의 언어, Interface Definition Language)

• 소프트웨어 컴포넌트의 인터페이스를 묘사하기 위한 명세 언어
• 어느 한 언어에 국한되지 않는 언어중립적인 방법으로 인터페이스를 표현함으로써, 같은 언어를 사용하지 않는 소프트웨어 컴포넌트 사이의 통신을 가능하게 함
• 보통 RPC를 이용한 소프트웨어에서 사용

출처

https://grpc.io/

gRPC