RPC (Remote Procedure Control)
- 분산된 환경에서 다른 서버에 있는 함수를 로컬 함수처럼 호출할 수 있게 해주는 기술
- RPC는 개발자가 네트워크 통신의 복잡성을 신경 쓰지 않고도 원격 서비스를 호출할 수 있도록 단순화된 API를 제공
gRPC
- 구글에서 개발한 고성능 RPC 프레임워크
- 프로토콜 버퍼(Protocol Buffers, Protobuf)라는 직렬화 기술을 사용하여 빠르고 효율적인 데이터 전송을 지원
- HTTP/2를 기반으로 작동하며, 다양한 언어와 플랫폼을 지원
즉 서로 다른 서버는 동일한 protobuf(.proto 파일)를 공유하기 때문에 protobuf를 통해 생성된 동일한 API 함수를 서로 공유하고 사용할 수 있도록 한다.
gRPC의 주요 특징
- 효율적인 직렬화 (Protocol Buffers):
Protobuf를 사용하여 JSON이나 XML에 비해 더 작고 빠른 데이터 직렬화.
- HTTP/2 기반 통신:
멀티플렉싱, 흐름 제어, 헤더 압축, 서버 푸시 지원.
- 양방향 스트리밍 지원:
단방향 요청-응답 외에도 클라이언트 및 서버 스트리밍 통신 가능.
- 다양한 언어 지원:
C++, Python, Java, Go, Node.js 등 다양한 언어에 대한 네이티브 클라이언트 라이브러리 제공.
- 자동 코드 생성:
Protobuf 파일(.proto)로부터 클라이언트와 서버 코드를 자동으로 생성.
gRPC vs REST
| 특징 | gRPC | REST |
|---|
| 프로토콜 | HTTP/2 | HTTP/1.1 |
| 데이터 형식 | Protobuf (이진 형식) | JSON (텍스트 형식) |
| 성능 | 고성능, 대역폭 효율적 | 낮은 성능, 높은 대역폭 소비 |
| 스트리밍 | 양방향 스트리밍 지원 | 기본적으로 지원 안 함 |
| 언어 지원 | 다중 언어, 코드 자동 생성 | 언어 독립적 |
| 개발 복잡성 | 초기 설정 복잡 | 간단 |
| 브라우저 지원 | gRPC-Web 필요 | 기본적으로 지원 |
Http와 JSON을 사용한 REST 아키텍쳐 스타일의 애플리케이션 구축은 마이크로서비스가 많아지고 이들간의 네트워크 상호작용의 확산이 많아지는 요즘에는 몇 가지 주요 제한사항이 있다.
1. 비효율적 텍스트 기반 메세지 프로토콜
RESTFul 서비스는 HTTP 1.x와 같은 텍스트 기반 전솔 프로토콜로 수축되어 JSON과 같은 포맷을 이용한다. 그러나 서비스간 통신에서는 텍스트 기반 포맷이 필요없고 바이너리 콘텐츠를 변환하여 전송하는 방식이 더 효율적이다.
2. 엄격한 타입 점검 부족
REST 자체는 타입 점검을 위한 메커니즘을 제공하지 않지만, JSON 스키마, OpenAP/Swagger, 정적 타입 언어 등을 사용하면 타입 안전성을 강화할 수 있다. 그러나 gRPC처럼 내장된 스키마 기반 타입 검증과 자동 코드 생성 기능은 REST에서 기본적으로 지원되지 않으므로, 타입 안전성이 중요한 프로젝트에서는 gRPC가 더 적합하다.
JSON에서의 잘못된 타입 정의 예시
{
"id": "123", // 숫자 대신 문자열로 전달
"name": 42 // 문자열 대신 숫자로 전달
}
3. REST 아키텍쳐 스타일의 강제 어려움
실제 어플리케이션 개발 과정에서 REST 아키텍쳐를 엄격하게 따르는 것은 어렵다. 즉 많은 경우 단순 Http 서비스로 제공되기 쉽다.
gRPC의 단점
- 학습 곡선
HTTP/1.1 및 RESTful API에 익숙한 개발자들에게는 gRPC의 HTTP/2 및 Protobuf 기반 방식이 다소 생소하고 어렵게 느껴질 수 있음
- 디버깅 어려움
Protobuf는 JSON과 달리 사람이 읽기 어려운 이진 형식을 사용하므로 디버깅과 로깅이 어렵고 추가 도구(ex. gRPCurl, Protobuf 디코더)가 필요할 수 있음
- 브라우저에서의 제한
브라우저에서 gRPC를 직접 사용하는 것은 제한적(gRPC-Web과 같은 추가적인 브릿지가 필요)
- REST 대비 표준화 부족
gRPC는 REST에 비해 상대적으로 덜 보편적이고, RESTful API를 중심으로 설계된 기존 시스템과의 통합에서 어려움을 초래할 수 있음
- 배포 및 버전 관리
.proto 파일의 변경 관리와 여러 언어 간 코드 생성은 복잡성을 증가시킬 수 있습니다.
인터페이스 변경 시 하위 호환성을 유지해야 하므로 설계에 신중해야 합니다.
- HTTP/2 의존성
HTTP/2 지원이 제한된 네트워크 환경에서는 gRPC의 성능 이점을 살리지 못할 수 있음