gRPC 소개

우리는 서비스와 통신할때, 많은 경우 REST API를 날려서 통신을 한다. 근데, 프로세스들끼로 통신을 하는데 있어서 굳이 REST API를 써야되는 이유가 있는가?

 

REST API의 단점- 1.텍스트 기반 메세지 프로토콜/ 서비스간의 통신을 사람의 가독성을 보장하는 텍스트 기반으로 해야되는 이유는?

2. 엄격한 타입 점검 부족/ 비호환성 문제 발생

 

gRPC의 장점 - 탄생이유가 프로세스간에 통신기술로 설계됨

1. 프로세스간 통신 효율성/ 텍스트 형식 대신 프로토콜 버퍼 기반의 바이너리 프로토콜을 사용

2. contract-first접근 방식을 권장 -> 서비스 인터페이스가 명확해짐

3. 엄격한 타입 점검 형식/ 서비스를 정의할때 프로토콜 버퍼를 사용하기때문

4. 폴리글랏/ 특정 언어에 구애받지 않는다

5. 이중 스트리밍

6. 유용한 내장기능

7. 클라우드 네이티브 생태계와 통합

단점- 외부서비스 부적합/ 서비스의 급격한 변경에 취약/ 작은 생태계

 

등등의 장점으로 내부 프로세스끼리의 통신에 있어서 gRPC를 고려하는것은 좋은 고민일 것이다.

 

gRPC의 기본 구성도

gRPC를 사용하기 위해서는 다음과 같이, proto파일로 정의된 서비스가 있고, 그 proto파일을 기반으로 각각 client stub와 server skeleton을 생성하고 구축하는게 기본이다.

 

proto 파일은 다음과 같이 정의된다.

syntax = "proto3";

package ecommerce;

service ProductInfo {
    rpc addProduct(Product) returns (ProductID);
    rpc getProduct(ProductID) returns (Product);
}

message Product {
    string id = 1;
    string name = 2;
    string description = 3;
    float price = 4;
}

message ProductID {
    string value = 1;
}

message를 통해서 메세지에 들어갈 필드를 정의하고, 통신할때 숫자는 그 필드를 지칭하는 지칭자로 역할을 하게된다. 그렇기때문에 같은 메세지안에 다른 필드에 같은 숫자를 사용할 수 없다.

service를 통해서 input 메세지와 output 메세지를 정의 내려주게 된다. 각각의 service의 작동방식은 service를 제공하는 프로세스에서 정의내려주게 된다.