안녕하세요, 씨앤텍 시스템즈 황순호 연구원입니다.
이번 포스트는 gRPC에 대해 소개하는 내용을 작성하겠습니다.
RPC(Remote Procedure Call)는 이름 그대로 원격 프러시저의 호출이 가능한 프로세스 간 통신 방식입니다. 실행 주체가 아닌 다른 주소상의 함수를 마치 로컬에 가지고 있던 것처럼 사용할 수 있습니다. gRPC는 구글에서 이러한 RPC를 바탕으로 개발한 고성능 원격 프로시저 호출 프레임워크입니다.
● 그렇다면 gRPC를 왜 사용하는걸까요?
gRPC가 가지는 이점으로는 다양한 언어에서의 개발을 지원한다는 점, HTTP/2를 지원한다는 점 등이 있으나 개인적으로 가장 중요한 이유로는 속도를 들 수 있겠습니다.
높은 생산성과 확장을 위해 어떤 서비스를 제공함에 있어 하나의 서버에 모든 기능을 구현하여 제공하기보다 여러 서버에 걸쳐 독립적으로 기능을 구현하고 서버 간 통신을 통해 서비스 제공을 가능케 하는 Microservice가 떠오르면서 서버 간 통신 속도 또한 주요한 문제로 부각되었습니다. 기존 HTTP API(일반적으로 JSON을 이용한 통신)와 비교했을 때 gRPC는 이러한 아키텍처에서 탁월한 선택이 될 수 있습니다.
[HTTP API와 gRPC의 비교]
{Microsoft 문서 참조}
| 기능 | gRPC | JSON을 이용한 HTTP API |
| Contract | Required | Optional |
| Protocol | HTTP/2 | HTTP |
| Payload | Protobuf(small, binary) | Json |
| Prescriptiveness | Strict specification | Loose. Any HTTP is valid. |
| Streaming | Client, server, bi-directional | Client, server |
| Browser support | No (requires grpc-web) | Yes |
| Security | Transport (TLS) | Transport (TLS) |
| Client code-generation | Yes | OpenAPI + third-party tooling |
HTTP API의 JSON을 이용한 통신의 경우 JSON 자체가 사람이 읽기 쉽도록 문자로 직렬화되어 전송되다 보니 데이터 크기에 대한 낭비가 발생합니다. gRPC의 경우 바이너리 형태로 직렬화되며 또한 메시지 형식에 대해 사전에 정의를 해두기 때문에 인코딩을 통해 메시지의 크기를 획기적으로 줄일 수 있습니다. 같은 데이터를 전송하더라도 네트워크상 트래픽 발생도 적으며 더 빠르게 전송할 수 있게 됩니다.
장점만 있진 않습니다. 앞서 말한 내용에도 JSON 형식은 사람이 읽기 편한 형태인 것에 반해 바이너리 형태의 데이터는 곧바로 사람이 해석할 수 없습니다. 브라우저와 서버 사이에선 gRPC 통신을 지원하지 않으므로 기존 HTTP API 사용하는 경우 이를 gRPC로 변환해줄 수 있는 별도의 gRPC-gateway 구축도 필요할 수 있습니다. gRPC를 구현함에 있어서 전반적인 이해 과정이 필요합니다.
감사합니다.