ProtoBuf(Protocol Buffers)는 Google에서 개발한 데이터 직렬화 방식이다.
Json과 비교했을 때 빠른 역직렬화, 데이터 경량화와 같은 장점 덕분에 차세대 프로젝트에서도 적용해 사용하고 있으며, 확실한 성능 향상도 확인하였다.
어떻게 Protobuf는 이런 장점을 가지는지, 적용 전에 공부했던 내용을 간단하게 정리해보고자 한다.
1. Key 값 alias화 (숫자 필드 번호 사용)
JSON과 같은 텍스트 기반 직렬화 방식에서는 각 데이터 항목을 텍스트 형태로 전달해야 하므로, "name": "John"과 같이 "name"이라는 문자열 키를 포함해야 한다. 이는 데이터를 전송할 때 상당한 크기를 차지하게 된다. 특히 데이터 양이 많을수록 각 키에 대해 문자열을 전송해야 하는 오버헤드가 커진다.
반면, ProtoBuf에서는 기존에 정의된 필드는 숫자로 구분시킨다. 예를 들어, "name"을 필드 번호 1로 정의하고, "id"를 필드 번호 2로 정의하는 방식이다. 필드 번호는 1, 2, 3와 같이 짧은 숫자로만 표시되므로, 각 항목의 이름을 텍스트로 전달할 필요가 없어서 데이터 크기를 대폭 줄일 수 있다.
JSON 예시:
{
"name": "John",
"id": 123,
"email": "john@example.com"
}ProtoBuf 예시:
message Person {
string name = 1;
int32 id = 2;
string email = 3;
}위의 ProtoBuf 예시처럼, name, id, email을 1, 2, 3이라는 숫자로 변경하여 저장한다. 이 숫자들은 필드 번호(field number)라고 하며, ProtoBuf는 이 필드 번호를 사용하여 데이터를 직렬화한다. 이렇게 숫자 기반의 필드 번호를 사용해 빠른 역직렬화를 할 수 있게 해준다.
2. 가변 길이 인코딩
ProtoBuf는 데이터를 바이너리로 압축할 때, 가변 길이 인코딩(varint)을 사용한다. 숫자와 같은 데이터는 필요한 바이트만 사용하여 인코딩되므로, 데이터를 더 작은 크기로 효율적으로 압축할 수 있다. 예를 들어, 작은 숫자는 적은 바이트만 사용하고, 큰 숫자만 더 많은 바이트를 사용한다. 이 방식은 JSON에서 각 숫자가 텍스트로 처리되는 것과는 달리 훨씬 더 효율적으로 데이터를 저장한다.
ProtoBuf는 각 데이터 타입에 맞는 최적화된 이진 포맷을 사용하여 데이터를 직렬화하고, 역직렬화한다. 예를 들어, int32는 4바이트 크기로, string은 길이에 따라 필요한 만큼만 바이트를 할당한다. 이로 인해, 텍스트 기반 JSON보다 더 적은 공간에 데이터를 효율적으로 저장할 수 있다.
JSON 예시:
{
"id": 12345
}message Person {
int32 id = 1;
}ProtoBuf는 int32 값인 12345를 바이너리 형식으로 압축하여 저장하며, 실제 저장되는 크기는 JSON보다 훨씬 작다.
사용 후기
백엔드 서버의 응답 속도를 높일 방법을 구상하던 도중, 레디스에서 데이터를 가져와서 역직렬화하는 오버헤드를 줄이는 시도를 했다. 과거에 gRPC에 대한 공부를 하던 중 인상깊었던 protobuf의 데이터 직렬화 방식이 떠올라서 적용해 보았는데, 데이터 용량도 획기적으로 줄일 수 있었으며(약 70%) TPS도 증가(약 2배)하였다.
구글에서 만든 프로토콜이니만큼 확실한 성능 보장과 지원하는 라이브러리가 많다는 점도 좋은 것 같다.
하지만 proto 파일을 데이터 producer/consumer 모두가 공유해야 한다는 점과, 이를 전/후처리 하는 과정이 필요하다는 점, 바이너리로 인코딩되는 만큼 json처럼 직관적으로 데이터 형식을 확인하기엔 어렵다는 단점이 존재한다.
-> 데이터를 Redis에 적재하는 용도로 사용하는 경우, Another Desktop Manager에서 protobuf 형식 인코딩 viewer를 지원하니 단점는 어느 정도 보완이 가능한 점도 알아두면 좋을 것 같다.
