gRPC란?

gRPC 클라이언트와 서버는 Google 내부의 서버에서 사용자 자신의 데스크톱에 이르기까지 다양한 환경에서 서로 실행하고 대화할 수 있으며 gRPC에서 지원되는 모든 언어로 작성할 수 있다. 예를 들어, Go, Python 또는 Ruby의 클라이언트를 사용하여 Java에서 gRPC 서버를 쉽게 만들 수 있다. 또한 최신 Google API에는 gRPC 버전의 인터페이스가 있어 Google 기능을 애플리케이션에 쉽게 구축할 수 있다.

 

프로토콜 버퍼 사용

기본적으로, gRPC는 구조화된 데이터를 직렬화하기 위해 구글의 성숙한 오픈 소스 메커니즘인 프로토콜 버퍼를 사용한다. 다음은 작동 방식에 대한 간단한 소개이다.

프로토콜 버퍼를 사용할 때 첫 번째 단계는 프로토콜 파일에서 직렬화할 데이터의 구조를 정의하는 것이다. 이것은 .proto 확장자를 가진 일반 텍스트 파일이다. 프로토콜 버퍼 데이터는 메시지로 구성되며, 각 메시지는 필드라고 불리는 일련의 이름-값 쌍을 포함하는 정보의 작은 논리적 기록이다. 아래는 간단한 예다.

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

그런 다음 데이터 구조를 지정한 후에는 프로토콜 버퍼 컴파일러 프로토콜을 사용하여 프로토콜 정의에서 원하는 언어로 데이터 액세스 클래스를 생성한다. 이것들은 name()과 set_name()과 같은 각 필드에 대한 간단한 접근자뿐만 아니라 전체 구조를 원시 바이트로 직렬화/파싱하는 방법을 제공한다.

gRPC는 특별한 gRPC 플러그인과 함께 protoc를 사용하여 protoc 파일에서 코드를 생성한다. gRPC 클라이언트와 서버 코드는 물론 메시지 유형을 채우고, 직렬화하고, 검색하기 위한 일반 프로토콜 버퍼 코드를 생성한다. 선택한 언어로 gRPC 플러그인으로 protoc을 설치하는 방법을 포함하여 프로토콜 버퍼에 대한 자세한 내용은 프로토콜 버퍼 설명서를 참조.

 

프로토콜 버퍼 버전

프로토콜 버퍼가 오픈 소스 사용자들에게 한동안 제공되었지만, 이 사이트의 대부분의 예들은 프로토콜 버퍼 버전 3(proto3)을 사용한다. proto3는 현재 java, C++, Dart, Python, objective-C, C#, light runtime(Android Java), Ruby, JavaScript, 골랑/프로토부 공식 패키지의 Go 언어 생성기로 사용할 수 있다.

일반적으로 proto2(현재 기본 프로토콜 버퍼 버전)를 사용할 수 있지만, proto3를 gRPC 지원 언어의 전체 범위를 사용할 수 있으므로 proto3를 gRPC와 함께 사용하는 것이 좋다.

 

 

 

Reference

https://velog.io/@pyohamen/What-is-a-gRPC-gRPC-Remote-Procedure-Calls

What is a gRPC (gRPC Remote Procedure Calls) ?

 

https://velog.io/@dojun527/gRPC%EB%9E%80

gRPC란?

 

https://grpc.io/docs/languages/python/quickstart/

Quick start

---

gRPC

• high performance : 통신 overhead를 최대한 줄이는 것이 목적
• pluggable suppor : 이것 저것 원하는 기능들을 가져다가 쓸 수 있다. flask처럼
• google이 개발한 RPC 기반 Framework
• MSA와 같은 분산 구조에 적합한 효율적인 통신 프로토콜에 대한 고민
• 15년 넘게 google 내부에서 사용한 stubby라는 시스템을 오픈소스로 공개한 버전
• CNCF(Cloud Native Computing Foundation)에서 인큐베이팅한 오픈소스

RPC?

• Remote Procedure Call : 원격지의 프로그램을 마치 로컬에서 실행하는 것처럼! 마치 내부에 있는 function을 Call 하듯이

• Code의 간결함
• RESTful의 HTTP 규격 불필요 (URL, Method, JSON, ...)
  • 메소드와 파라미터만 전달하면 마치 내부적인 함수를 불러다 쓰는 것 같은 효과를 주기 때문.
• 즉, 다른 Service와 통신하지만 마치 Local에서 method를 사용하는 것처럼!

 

예전에 나왔떤 RPC가 왜 최근들어서 다시 핫해졌을까?

grpc 특징 (1) - Protocol Buffers

• gRPC를 쓰려면 protocol buffer를 써야한다.
• 통신 프로토콜을 정의하는 방식
• gRPC 뒷단의 메세지를 처리하는 기술

• Server / Client 간 메세지를 정의하는 역할
• 실제 통신시 byte stream으로 데이터를 encoding 하여 통신, 
• XML보다 3~10배 작고, 20~100배 빠르다고 함. 

• 통신 매체는 protobuf가 담당하고, 그 외에는 각자 사용하는 언어 맞게끔 독립 분리 가능
• proto buffer 전용 IDL을 통해 메세지 정의
• protobuffer를 각 언어에 맞게 build하면, 자동으로 Server와 Client 통신을 위한 코드가 생성
• 통신 채널과 구현부가 분리되어 서로 다른 언어로 구현 가능

 

gRPC 특징(2) - HTTP/2

• gRPC와 Protobuff와는 독립된 기술이지만, gRPC가 통신을 할 때 HTTP/2 기술을 사용한다. 
  • 그 동안에 사용했던 프로토콜(HTTP/1.x) 문법 그대로 가져가지만, 그걸 조금 더 퍼포먼스 위주로 향상시켰다.

 

gRPC 특징(3) - Communication

• Bidirectional Streaming : HTTP/2 기반으로 Server와 Client가 동시에 데이터를 스트리밍으로 주고받을 수 있다. 

 

 

gRPC with Python

^^:;;;

gRPC with python 단점

• MSA에 특화된 Service 간 Message 성능 향상에 집중한 (몰빵한^^) RPC Framwork
  • django의 MVC, ORM, Plugin, 기타 기능들이 gRPC에는 없다고 한다.
• Protobuf 관리가 생각보다 쉽지 않다. 
  • Protobuf는 Server / Client 모두 가지고 있어야한다. (잘개 쪼개진 Service마다!)
  • 모든 서비스별로 Protobuffer 버전 관리, 배포 필요한데 쉽지 않다.
• Protobuf build 어려움
  • 개발자마다 다른 개발 환경 (ex. 로컬, 서버, ... )이기 때문에 준비 과정이 귀찮 
    • build를 위한 준비 과정 
    • 관련 package 설치
    • package 간 dependency 체크
    • Build 명령 수행 
    • ...

그래서, 내부적으로 gRPC를 잘 쓰기 위해 Framework를 만드셨다고 함. 

 

Reference

https://www.youtube.com/watch?v=KGAernd-42M 

---

https://www.youtube.com/watch?v=igHrQPzLVRw