ProtocolBuffer


## Intro

`gRPC`와 `Protocol Buffer`라는 것에 대해서 설명한다. `gRPC`는 `Protocol Buffer`를 교환 가능한 형태의 IDL(Interface Definition Language)과 message를 기술하기 위해서 사용한다.

## gRPC

`gRPC`에서 client application은 전혀 다른 machine의 server application에 존재하는 method를 마치 local object로 존재하는 것처럼 직접적으로 호출할 수 있다. 이는 실제로 distributed application(ex. Web 개발에서의 BackEnd, FrontEnd | Micro Service Architecture)과 service들을 제작할 때 굉장히 유용하다. 다른 RPC System과 마찬가지로, `gRPC`는 원격으로 parameter를 제공하여 호출할 수 있는 method와 return type을 기술하여 service를 정의한다. Server 측에서는 interface를 구현하고, 실제로 client의 호출을 처리할 `gRPC` server를 실행시킨다. Client 측에서는, server의 method와 동일한 method를 제공하는 `stub`(`gRPC` client)를 가진다.

![gRPC overview](/images/grpc-overview.jpeg)

`gRPC` client와 server는 다양한 환경(Cloud, Server, Desktop, etc...)에서도 실행이 가능하며, 서로 의사소통이 가능하고, `gRPC`를 지원하는 어떤 언어로도 구현이 가능하다. 즉, Server와 Client에서 어떠한 언어를 사용해도 상관이 없다. 또한, 최신 Google API들을 `gRPC`로도 제공하고 있기 때문에 쉽게 이용이 가능하다.

기본적으로, `gRPC`는 구조화된 데이터의 Serialization을 위한 Google의 Open Source인 `Protocol Buffer`를 사용한다.

`Protocol Buffer`의 데이터의 구조는 `.proto` 로 끝나는 일반적인 텍스트 파일(proto file)에 정의한다. `Protocol Buffer` data는 `message`라는 형태로 작성되며, 각 `message`는 여러 name-value 쌍으로 구성된 `field`들로 구성된 작은 정보 record이다. 아래는 message의 간단한 예제이다.

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

일단 data 구조를 정의하면, 선호하는 language를 통해 `Protocol Buffer Compiler`(protoc)를 사용해서 data access class들을 생성할 수 있다. 이는 각 field에 대한 간단한 접근자(`name()`, `set_name()`)와 전체 구조를 raw bytes로 serialization/parsing할 수 있는 method를 제공한다. 예를 들어 C++를 선택하였다면, `protoc`은 `Person`이라는 class를 생성할 것이고, 이를 이용해서 `Person`에 대한 message를 얻거나, serialization, 또는 parsing을 수행할 수 있다.

또한, `gRPC` service를 `proto file`에 paramter, return type와 같이 정의할 수 있다.

```proto
// 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;
}
```

`gRPC`는 `protoc`와 특별한 `gRPC` plugin을 사용하여 `proto file`에서 code를 생성한다. 이를 통해, message type들을 얻고, serialization할 수 있는 일반적인 `Protocol Buffer` code와 `gRPC` client 와 server code를 얻을 수 있다.

## Protocol Buffer

`gRPC`를 제대로 활용하기 위해서는 `Protocol Buffer`에 대해서 자세히 알아두어야 하기에 별도의 섹션으로 분리하여 설명한다. `Protocol Buffer`는 구조화된 데이터를 Serialization(구조화된 데이터를 byte형태로 변환하는 과정 또는 이를 통해서 생성된 결과물)하고, 다시 Parsing(Serialization을 통해서 생성된 데이터를 원래의 구조화된 데이터로 변환하는 과정)하는 과정을 언어 중립적(어떤 프로그래밍 언어에서도 사용가능한), 플랫폼 중립적(어떤 플랫폼에서도 사용가능한)으로 확장한 메카니즘이다. **이는 JSON과 유사하지만, 더 작고 더 빠르며, 실제 언어와의 연결을 자동으로 생성해준다.**

`Protocol Buffer`는 다음과 같은 도구의 집합이다.

1. Definition Language(.proto file을 작성하는 언어이다.)
2. data의 interface, language에 따른 runtime library들, data를 위한 serialization format `Proto Compiler`에 의해 생성된 code

### 핵심 Idea

**`Protocol Buffer`는 megabyte 정도 크기의 구조화된 data를 위한 Serialization format을 제공한다. 이는 단기간의 Network Traffic에서부터 장기간 data 저장에 모두 유리하다. `Protocol Buffer`는 기존 data를 무효화거나 update하는 추가적인 code 작업없이 새로운 정보로 확장되어질 수 있다.** 뿐만 아니라 **하위 호환성(이전 version의 data의 요청에도 대응하는 것)을 유지하는 것이 중요하기 때문에 이들을 장기간 유지한다. `Protocol Buffer`는 새로운 field의 추가/삭제에도 서비스의 중단 없는 환경을 제공한다.**

`Protocol Buffer`들은 구글에서는 굉장히 일반적으로 사용되는 format이다. 이는 대게 광범위한 server간 통신에 사용될 뿐만 아니라 disk에 data를 기록하는데에도 사용되어진다. `Protocol Buffer` message와 service들은 `.proto` 파일에 기술자에 의해 정의되어진다.

`Proto Compiler`는 build time에 `.proto` file에 기반하여 이에 적힌 `Protocol Buffer`를 조작하기 위한 다양한 language의 코드를 생성하기 위해서 실행되어진다. 각각에 생성된 class들은 각 field에 접근하기 위한 간단한 접근자들을 포함하며, serialization과 parsing을 위한 method를 제공한다.

### 장점

`Protocol Buffer`는 구조화된 data를 어떤 언어에서든, 어떤 platform에서든 광범위한 상황에서 serialization/parsing할 필요가 있을 때 굉장히 유용하다. gRPC로 통신도 가능할 뿐만 아니라 이를 위한 data storage도 제공하기 때문이다. 또한 다음과 같은 장점을 포함한다.

1. 적은 data 저장공간
2. 빠른 parsing
3. 많은 programming 언어와의 호환성  
   - C++, C#, Java, Kotlin, Go, Dart, Python, Ruby, Javascript(Node), PHP
4. 자동으로 생성된 class를 통한 최적화된 기능성

### 한계점

`Protocol Buffer`가 항상 모든 데이터에 대해서 적절한 것은 아니다.

- `Protocol Buffer`는 전체 message들이 memory에 모두 load될 수 있고, object graph보다는 크기가 작다고 가정한다. 따라서, 1~2 megabyte 내외의 크기를 넘어선다면, 여러 개의 copy를 만들게 될 것이고, 이는 memory 사용의 비효율을 초래할 것이다.
- `Protocol Buffer`가 serialization되었을 때, 동일한 data는 다양한 형태의 binary serialization 형태를 갖는다. 그렇기에 이들을 직접적으로 parsing하기 전까지는 이것이 서로 동일한지 알 수 있는 방법이 없다.
- Message는 JPEG, PNG와 같은 전용 압축 알고리즘이 존재하지 않는다. (하지만, zip, gzip 등은 가능하다.)
- `Protocol Buffer` message들은 float 및 다차원 배열을 많이 포함하는 과학 및 공학 용도에서 크기와 속도 면에서는 최대 효율보다 낮은 성능을 보인다. 이러한 요구가 많은 경우에는 overhead를 줄이기 위해서 `FITS` 또는 이와 유사한 방식을 활용해야한다.
- `Protocol Buffer` Object Oriented Language가 아닌 경우(Fortran, IDL) 지원이 어렵다.
- `Protocol Buffer` message들은 자체적으로 data를 정의할 수는 없고, 사용자에 의해서 정의된 schema에 기반한다. 따라서, data에 상응하는 `.proto` file이 없다면, 이를 완벽하게 해석하는 것은 불가능하다.
- `Protocol Buffer`는 여러 organization의 표준은 아니다. 따라서, 일반적인 사용 환경에서는 적절하지 않을 수 있다.

### 작동 방식

1. data 구조를 정의하기 위해서 `.proto` file을 생성한다.
2. `.proto` file을 기반으로 `protoc`는 code를 생성한다.
3. 생성된 code와 project code를 같이 compile한다.
4. 이를 통해서 생성되는 `Procotol Buffer` class들을 활용하여 serialization, 공유 및 parsing이 가능하다.

`Protocol Buffer` class들은 다양한 method를 포함한다. 예를 들어, 특정 데이터를 stream, file로 부터 받아오거나 개별적으로 value를 추출하거나 해당 데이터가 존재하는지 확인하거나 다시 serialization하여 stream 또는 file로 만드는 과정이 가능하다.

### Definition Syntax

`.proto` file을 정의할 때, 먼저 optionality를 설정한다. 이는 `optional` 또는 `repeated` 또는 `singular` 중에 하나를 선택할 수 있다. (v2에는 `required`도 존재하지만 이를 사용하는 것을 좋지 않은 pattern으로 여긴다.)

위의 사항을 정한 후에는 data type을 기술해야 한다. `Protocol Buffer`는 보편적으로 사용되어지는 data type(Integer, Boolean, Float)을 제공한다.

field는 아래와 같은 것도 포함한다.

- `message` : data의 설정을 반복하는 경우 이를 사용할 수 있다.
- `enum` : 해당 type의 종류를 value들의 집합으로 표현할 수 있다.
- `oneof` : message가 여러 optional field를 포함할 때, 단 하나의 field만 가지도록 할 수 있다.
- `map` : key-value 형태로 기술할 수 있다.

optionality와 field type을 설정한 후에, field number를 할당해야 한다. 이는 다른 목적으로 사용하거나 재사용되어서는 안된다. 특정 field를 제거했다면, 이 숫자를 재사용하지 않도록 반드시 유의해야 한다.

### 추가적인 Data Type

`Protocol Buffer`는 다양한 scalar value type을 제공한다. 또한, 자신만의 합성 data type을 message를 정의함으로써 생성할 수 있다. 또한 보편적으로 사용되어지는 다음과 같은 type들도 추가적으로 정의되어있다.

- `Duration` : 시간을 의미한다. (ex. 42s)
- `Timestamp` : 시각을 의미한다. (ex. 2017-01-15T01:30:15.01Z)
- `Interval` : 시간 사이 거리를 의미한다. (ex. 2017-01-15T01:30:15.01Z - 2017-01-16T02:30:15.01Z)
- `Date` : 달력에서의 전체 날짜를 의미한다. (ex. 2025-09-19)
- `DayOfWeek` : 일주일에 요일을 의미한다. (ex. Monday)
- `TimeOfDay` : 하루에서 시간을 의미한다. (ex. 10:42:23)
- `LatLng` : 위도와 경도를 의미한다.
- `Money` : 화폐 단위를 의미한다.
- `PostalAddress` : 우편주소를 의미한다.
- `Color` : RGBA color 값을 의미한다.
- `Month` : 년에 따른 월을 의미한다. (ex. April)

## Outro

현재까지 사용해본 RPC는 ReST API, GraphQL이 있었다. ReST는 워낙 유명하고, JSON, xml기반으로 많이 사용하기 때문에 누구나 알법하다. 그리고, graphQL은 더 유동적인 구현 방식을 제공했기 때문에 Gatsby와 같은 platform이나 Github에서도 사용할 정도로 유명해졌다. 앞 서 얘기한 두 개는 BackEnd에서 FrontEnd로 제공하는 시스템에서 주로 이용된다는 것을 이번 기회로 깨달은 것 같다. 그렇기에 좀 더 사람이 이해하기 쉬운 구조로 되어있을 뿐만 아니라 굉장히 친숙하다. 하지만, `gRPC`는 성능 향상에 좀 더 초점을 두었고, `Server`간 통신에 더 방점을 둔 것이라는 것이 와닿았다. 여러 Virtual Machine이 많아지는 가운데에 이들간에 빠른 통신과 각 Machine간의 호환을 위한 여러 기능들에 좀 더 초점을 맞추고 있다는 것을 알게 되었다. 아마 앞으로 `gRPC`를 사용한다면 이러한 용도로 가장 많이 사용할 것 같다. 아마 이래서 주요 사용처가 Network Vender(CISCO, Juniper), CNCF, Netflix 등인 것일 수도 있겠다. 끝으로 이를 이용한 구현을 직접해보아야 더 나은 설명이 가능할 것 같으므로 후에 이에 대해서 더 자세히 다루겠다.

## Reference

- <https://grpc.io/docs/what-is-grpc/introduction/>
- <https://grpc.io/docs/what-is-grpc/core-concepts/>
- <https://developers.google.com/protocol-buffers/docs/overview>
