GRPC

비즈니스 로직을 여러 서비스로 분리하는 과정에서 공통된 코드 공유를 어떻게 할 것인가?

1. 라이브러리
   1. 자원관리 책임소재가 명확하지 않음
   2. 모든 사람이 코드에 대한 이해가 있어야한다. (추상화의 이점이 없음)
   3. 러닝타임이 길어진다
2. REST API 서버를 두고 호출하는 방식
   1. 통신 계층이 증가 → 지연 발생의 문제
   2. 클라이언트 코드가 각 서비스에서 독립적으로 작성된다
   3. 데이터의 버전관리가 명확하지 않다.

⇒ RPC 서버를 두고 클라이언트(stub)에서 메서드를 사용하면 위 문제들을 해결할 수 있다.

 

 

gRPC?

google에서 만든 RPC (메타, 트위터 등 여러 rpc가 있음)

RPC?

Remote Procedure call(원격 프로시저 호출)은 별도의 원격 제어를 위한 코딩 없이 다른 주소 공간에서 함수나 프로시저를 실행할 수 있게하는 프로세스 간 통신 기술이다. 다시 말해, 원격 프로시저 호출을 이용하면 프로그래머는 함수가 실행 프로그램에 로컬 위치에 있든 원격 위치에 있든 동일한 코드를 이용할 수 있다. 분산 환경(MSA)에서 여러 서비스로 분리되어 있는 경우 특정 프로시저는 여러 서비스(layer계층에서의 서비스)에서 사용하게 되는데, 해당 특정 프로시저의 관리포인트를 하나로 둘 수 있을 뿐만 아니라, 개발하려는 서비스에 집중하여 개발 가능하다.

한마디로 "공통 메서드의 모듈화"

 

 

gRPC와 JSON사용 HTTP API 비교

기능	gRPC	JSON을 사용하는 HTTP API
계약	필수(.proto)	선택 사항(OpenAPI)
프로토콜	HTTP/2	HTTP
페이로드	protobuf(소형, 이진)	JSON(대형, 사람이 읽을 수 있음)
규범	엄격한 사양	느슨함. 모든 HTTP가 유효합니다.
스트리밍	클라이언트, 서버, 양방향	클라이언트, 서버
브라우저 지원	아니요(gRPC-Web 필요)	예
보안	전송(TLS)	전송(TLS)
클라이언트 코드 생성	예	OpenAPI + 타사 도구

 

 

gRPC 장점

• 작은 메시지 페이로드: gRPC메시지는 이진 메시지인 Protobuf를 사용하여 직렬화되기 때문에 작은 메시지 페이로드를 발생
• 시간 절감과 강력한 클라이언트 형식을 강제: protobuf는 IDL(interface definition language)를 사용해 정의되기 때문에 별도 API 정의서가 없이도 인터페이스를 파악할 수 있음 → .proto 파일을 공유하여 메시지와 클라이언트 코드를 종단 간에 생성가능
• 스트리밍: HTTP/2은 수명이 긴 실시간 통신 스트림을 가능하게 함. → gRPC 서비스는 모든 스트리밍 조합을 지원
  • 단항(스트리밍 없음)
  • 서버-클라이언트 스트리밍
  • 클라이언트-서버 스트리밍
  • 양방향 스트리밍
• 최종 기한/시간 초과 및 취소: gRPC는 클라이언트가 RPC가 완료될 때까지 대기하는 기간을 지정하도록 할 수 있음 → 최종 기한이 서버에 전송되고 서버에서 기한을 초과하는 경우에 특정 작업을 수행할 수 있음

 

gRPC 단점

• 제한된 브라우저 지원: 현재 브라우저에서 gRPC서비스를 직접 호출하는 것은 불가능, HTTP/2 기능을 많이 사용, 브라우저에서 gRPC 클라이언트를 지원하기 위해 웹 요청에 필요한 제어수준을 제공하지 않음.
  • 추가 설명
    • 일반적으로 웹 브라우저는 서버와 통신할 때 HTTP 프로토콜을 사용합니다. 그러나 gRPC는 HTTP/2의 고급 기능을 사용하고, 이러한 기능은 브라우저에서 기본적으로 지원되지 않거나, 브라우저가 필요한 수준의 제어를 제공하지 않는다. 예를 들어, gRPC는 HTTP/2를 통한 특정 종류의 통신 방식을 요구하는데, 대부분의 브라우저는 이를 지원하지 않거나, HTTP/2 프로토콜의 내부 구조에 대한 접근을 제공하지 않음.
    • 따라서, gRPC-Web을 이용하여 프록시와 함께 브라우저에서 사용해아 함.
• 읽을 수 없음: gRPC 메시지는 기본적으로 Protobuf로 인코딩되기 때문에 이진 형식은 사람이 읽을 수 없다. Protobuf를 사용하려면 올바른 역직렬화를 위해 .proto 파일에 지정된 메시지의 인터페이스 설명이 필요함.

 

gRPC Overview

 

• local object를 사용하여 클라이언트 애플리케이션에서 서버 애플리케이션을 call 할 수 있다. → 이런 방식은 분산된 환경을 쉽게 만듬. 파라미터와 리턴 타입을 지정하는 방식을 사용함.
• 서버는 이 인터페이스를 구현하고 gRPC 서버를 실행하여 클라이언트 호출을 처리한다.
• 클라이언트는 서버와 마찬가지의 기능을 하는 stub을 가지고 있다.
• 서버와 클라이언트는 서로 다른 다양한 환경(구글 api부터 본인 컴퓨터까지)에서 grpc가 지원하는 언어로 상호작용가능. 자바 서버, 파이썬 클라이언트로 작성가능.
• gRPC는 protocol buffers를 사용하여 구조화된 데이터를 직렬화함.
• gRPC는 protocol buffers를 인터페이즈 정의 언어(IDL)와 근본적인 메시지 교환 형식으로 사용함.

 

 

Protocol Buffers 동작

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

// The greeter service definition.
service Greeter {
  // Sends a greeting
  rpc SayHello (HelloRequest) returns (HelloReply) {}
}

// The request message containing the user's name.
message HelloRequest {
  string name = 1;
}

// The response message containing the greetings
message HelloReply {
  string message = 1;
}

1. .proto 확장자를 가진 텍스트 파일로 직렬화고자하는 데이터 구조를 정의. 메시지로 구조화 되어있으면 각 메시지는 필드(name-value 쌍)들로 이루어짐
2. protocol buffers 컴파일러인 protoc를 사용하여 proto정의에서 선언한 언어로 데이터 접근 클래스를 만듬. 해당 클래스는 각 필드에대해 접근자(get, set)와 원시바이트로부터 직렬화, 구문 분석하는 메소드 제공
3. proto파일에 grpc 서비스를 정의(parameter와 return 은 protocol buffers로 지정된 메시지만 가능)
4. gRPC에서는 protoc을 gRPC 플러그인과 함께 사용하여 proto 파일에서 코드를 생성.

 

 

gRPC 데모 구현

GitHub - KIJUNG-CHAE/grpc-demo: spring-grpc demo

코틀린 언어로 작성된 데모 버전입니다. 인터페이스, 서버, 클라이언트로 구성되어 있습니다.

 

---

Reference

gRPC

Introduction to gRPC

gRPC 서비스와 HTTP API 비교

Kotlin

[NBP 기술&경험] 시대의 흐름, gRPC 깊게 파고들기 #1

[NBP 기술&경험] 시대의 흐름, gRPC 깊게 파고들기 #2

RPC와 REST 비교 - API 아키텍처 간의 차이점 - AWS

 

browser와 통신시 왜 gRPC-web이 필요한가?

Proxy still needed with HTTP/2 supported by most browsers? · grpc grpc-web · Discussion #1348

 

gRPC spring liberary

GitHub - grpc-ecosystem/grpc-spring: Spring Boot starter module for gRPC framework.

 

gRPC 동향

Grpc framework, protobuf 관리, grpc 기본 톺아보기

 

Protocol Buffers

Protocol Buffers