[gRPC] proto (protocol buffer) 문법

proto란?

grpc에서 통신 규격을 정의하는 기본 단위다.
grpc는 사실 또다른 구글의 자체 포맷인 protobuf라는 것으로 데이터를 주고받는데, 그 형태를 정의하는 것이다.

.proto 파일을 한번만 잘 만들어두면, 주는 쪽이나 받는 쪽이나 약속된대로 통신을 주고받을 수 있다.

버전 문제

특별한 일이 없다면 보통 최신 표준인 proto3을 사용하게 될 텐데, 그러려면 항상 상단에

syntax = "proto3";

정의를 붙여줘야 한다.

이게 없으면 이전버전인 proto2로 인식해버리기 때문이다.

타입

grpc는 성능을 향상시키기 위해 상기한 protobuf라는 포맷을 통해 데이터를 바이너리로 압축해 전달한다.

기존에 주로 사용하던 json 등의 포맷은 대충 사용하기 쉽고 읽기도 편하지만, 데이터를 쌩 문자열로 쏘아보내는 형태이기 때문에 아무래도 비효율이 많이 발생하는 편이다.

그와 다르게 protobuf는 엄격한 타입 정의를 통해 데이터를 바이너리 형태로 가공해서 주고받을 수 있게 한다. 훨씬 가벼워지는 것이다.

protobuf의 기본 타입들은 아래와 같다.
일반적인 언어들와 크게 다르지는 않다.
부동소수점, 정수, 불린, 문자열 등이 제공된다.

메세지 타입

그럼 이제 저 타입들로 주고받을 메세지 타입을 정의해보자.
그냥 일종의 구조체와 같다고 보면 된다.

메세지는 다음과 같이 정의할 수 있다.

message 메세지타입명 {
  타입1 필드명1 = 순서;
  타입2 필드명2 = 순서;
}

타입과 필드명 외에 순서가 존재하는 것이 꽤 특이한 점인데, 이렇게 해야 배열처럼 효율적으로 데이터를 압축할 수 있기 때문이다. 그래서 한번 정해놓고 사용중인 순서는 바꾸면 안된다. 호환성이 깨진다.
정확히는 field number라고 부른다.

만약 어떤 사람의 이름과 나이를 의미하는 메세지를 정의한다면 다음과 같이 구성할 수 있을 것이다.

syntax = "proto3";

message PersonInfo {
  string name = 1;
  int32 age = 2;
}

열거 타입

대다수의 언어에서 제공하는 열거형과 동등한 기능이다.

열거는 다음 형태로 정의할 수 있다.

enum 열거명 {
    필드명 = 0;
    필드명2 = 1;
    ...
}

만약 색상을 의미하는 열거를 만든다면 다음과 같은 형태가 될 것이다.

syntax = "proto3";

enum Color {
    RED = 0;
    BLUE = 1;
    GREEN = 2;
}

그리고 다음과 같이 메세지에 포함시킬 수 있다.

syntax = "proto3";

message Product {
  string name = 1;

  enum Color {
    RED = 0;
    BLUE = 1;
    GREEN = 2;
  }
  Color color = 2;

  int64 price = 3;
}

배열 처리

배열의 표현은 repeated라는 키워드로 처리할 수 있다.

만약 상품정보에 카테고리 문자열 목록을 넣어야 한다면, 다음과 같이 구성할 수 있을 것이다.

syntax = "proto3";

message Product {
  string name = 1;
  int64 price = 2;
  repeated string categoryList = 3
}

메세지 중첩

메세지로 하나의 타입으로 취급되기 때문에, 타입처럼 메세지에 메세지를 또 중첩해넣을 수 있다.

syntax = "proto3";

message WishList {
   int32 customerCode = 1;

   message Product {
     string name = 1;
     int64 price = 2;
     repeated string categoryList = 3
   }
   repeated Product productList = 2
}

보통 2-3중첩 정도는 자주 사용하게 될 것이다.

서비스

근데 타입만 주구장창 만들면 뭐하겠는가? 실제로 뭘 주고받을지도 정해야지.
그게 바로 서비스다.

서비스는 아래와 같이, 함수의 묶음으로 정의된다.

service 서비스명 {
  rpc 함수명(요청메세지) returns (응답메세지);
  rpc 함수명2(요청메세지2) returns (응답메세지2);
  ...
}

service SearchService {
  rpc Search(SearchRequest) returns (SearchResponse);
}

그렇게 특별할 것은 없다. 간단하다.

참조
https://developers.google.com/protocol-buffers/docs/proto3