backend-interview-guide

gRPC (Google Remote Procedure Call)

gRPC란?

gRPC는 Google에서 개발한 오픈 소스 원격 프로시저 호출(Remote Procedure Call, RPC) 프레임워크입니다. Protocol Buffers(프로토콜 버퍼)라는 직렬화 메커니즘을 사용하여 클라이언트와 서버 간에 고성능 통신을 지원합니다.

주요 특징

HTTP/2 기반: 멀티플렉싱, 헤더 압축, 스트리밍 등 HTTP/2의 장점을 활용.
다양한 언어 지원: gRPC는 다양한 프로그래밍 언어에서 동작하도록 설계되었습니다(Java, Go, Python, C++, etc.).
프로토콜 버퍼: 데이터 직렬화 포맷으로, 빠르고 효율적인 데이터 교환을 지원.

gRPC의 특징

1. HTTP/2 지원

gRPC는 HTTP/2를 기반으로 동작하며, 다음과 같은 HTTP/2의 기능을 활용합니다:
- 멀티플렉싱: 단일 연결에서 여러 요청과 응답을 동시에 처리.
- 스트리밍: 클라이언트와 서버 간의 양방향 스트리밍 지원.
- 헤더 압축: 네트워크 대역폭 절약.

2. 프로토콜 버퍼

gRPC는 Protocol Buffers(ProtoBuf)를 사용하여 메시지를 직렬화합니다.
- 빠르고 효율적: JSON이나 XML보다 빠르며, 데이터 크기를 줄임.
- 명시적 인터페이스: .proto 파일을 사용하여 메시지와 서비스를 정의.
예시: .proto 파일
```
syntax = "proto3";

service Greeter {
  rpc SayHello (HelloRequest) returns (HelloReply);
}

message HelloRequest {
  string name = 1;
}

message HelloReply {
  string message = 1;
}
```

3. 다양한 통신 모델 지원

gRPC는 다양한 통신 모델을 제공하여 다양한 요구사항을 충족할 수 있습니다.

Unary RPC
- 클라이언트가 서버에 요청 1개를 보내고, 응답 1개를 받는 단순한 호출 방식.
- 예: 일반적인 HTTP 요청/응답과 유사.
Server Streaming RPC
- 클라이언트가 요청 1개를 보내면, 서버가 여러 개의 응답을 스트리밍으로 보냄.
- 예: 대량의 데이터 다운로드, 실시간 피드 제공.
Client Streaming RPC
- 클라이언트가 여러 개의 요청을 스트리밍으로 보내면, 서버가 응답 1개를 반환.
- 예: 로그 업로드, 센서 데이터 수집.
Bidirectional Streaming RPC
- 클라이언트와 서버가 동시에 데이터를 스트리밍.
- 예: 채팅 애플리케이션, 실시간 협업 도구.

4. 다중 언어 지원

gRPC는 클라이언트와 서버를 다양한 프로그래밍 언어로 작성할 수 있도록 지원합니다. 클라이언트와 서버가 서로 다른 언어로 구현되더라도 통신이 가능합니다. 주요 지원 언어:

Java
Python
Go
C++
Ruby
PHP
Kotlin 등

5. 양방향 스트리밍

gRPC는 HTTP/2의 스트리밍 기능을 활용하여 양방향 스트리밍을 제공합니다. 클라이언트와 서버가 독립적으로 데이터를 송수신할 수 있으며, 실시간 애플리케이션에 적합합니다.

gRPC의 장점

고성능
- HTTP/2와 Protocol Buffers를 사용하여 낮은 대기 시간과 높은 처리량을 제공합니다.
- JSON이나 XML보다 데이터 직렬화 속도가 빠르고 메시지 크기가 작아 네트워크 비용 절감.
엄격한 타입 검사
- .proto 파일로 정의된 명확한 스키마를 기반으로 클라이언트와 서버 간의 통신을 진행.
- 컴파일 단계에서 타입 오류를 발견할 수 있어 안정성과 생산성 향상.
다양한 통신 방식
- 단일 요청-응답(Unary), 서버 스트리밍, 클라이언트 스트리밍, 양방향 스트리밍과 같은 다양한 통신 모델 지원.
다중 언어 지원
- 다양한 프로그래밍 언어(Java, Python, Go 등)를 지원하여 이기종 시스템 간 통합이 쉬움.
자동 코드 생성
- .proto 파일에서 클라이언트 및 서버 코드를 자동으로 생성하여 개발 속도 향상.
양방향 스트리밍
- 클라이언트와 서버가 동시에 데이터를 송수신할 수 있어 실시간 애플리케이션 개발에 적합.

gRPC가 고성능인 이유

gRPC는 HTTP/2의 효율적인 전송 방식과 Protocol Buffers의 고속 직렬화를 통해 REST보다 뛰어난 성능을 제공합니다. 이로 인해 gRPC는 실시간 데이터 처리, 스트리밍, 대규모 분산 시스템과 같은 고성능이 요구되는 환경에서 널리 사용됩니다.

1. HTTP/2 기반 통신

gRPC는 HTTP/2 프로토콜을 사용하여 성능을 극대화합니다. HTTP/2는 기존의 HTTP/1.1보다 여러 면에서 개선되어, 통신 효율성을 높이고 지연 시간을 줄입니다.

HTTP/2의 주요 성능 장점

멀티플렉싱(Multiplexing)
- 하나의 TCP 연결에서 여러 요청과 응답을 동시에 전송 가능.
- HTTP/1.1의 경우 하나의 연결에서 한 번에 하나의 요청만 처리 가능하며, 여러 요청을 처리하려면 추가 연결이 필요합니다.
- HTTP/2는 동일한 연결을 재사용하므로, 연결 오버헤드와 대기 시간을 줄입니다.
헤더 압축
- HTTP/2는 HPACK이라는 헤더 압축 기술을 사용하여, 요청과 응답의 헤더 크기를 크게 줄입니다.
- REST API의 경우, 반복적인 헤더 정보(예: Content-Type, Authorization)가 많아지는 대규모 요청에서 이점이 큽니다.
스트리밍 지원
- HTTP/2는 단방향 요청/응답뿐 아니라, 서버 스트리밍, 클라이언트 스트리밍, 양방향 스트리밍을 지원.
- REST는 기본적으로 단방향 요청/응답 모델만 제공.
연결 유지(Persistent Connection)
- HTTP/2는 연결을 지속적으로 유지하여, 매 요청마다 새로운 연결을 열고 닫는 HTTP/1.1의 오버헤드를 제거합니다.
- 이는 특히 짧은 시간에 많은 요청이 오가는 환경에서 성능을 크게 향상시킵니다.

2. Protocol Buffers 사용

gRPC는 데이터를 직렬화할 때 JSON이나 XML 대신 Protocol Buffers(ProtoBuf)를 사용합니다. 이는 데이터 크기와 직렬화/역직렬화 속도에서 뛰어난 성능을 제공합니다.

Protocol Buffers의 주요 성능 장점

바이너리 데이터 형식
- Protocol Buffers는 바이너리 포맷으로 데이터를 인코딩하므로, JSON이나 XML과 같은 텍스트 포맷보다 데이터 크기가 작음.
- 작은 데이터 크기는 네트워크 대역폭 사용량을 줄이고, 전송 속도를 향상시킵니다.
빠른 직렬화/역직렬화
- Protocol Buffers는 데이터를 빠르게 직렬화 및 역직렬화할 수 있도록 설계되었습니다.
- JSON이나 XML은 텍스트 포맷이라 파싱 오버헤드가 크지만, ProtoBuf는 미리 컴파일된 스키마를 사용하여 더 빠르게 처리.
스키마 기반
- .proto 파일에서 데이터 구조를 정의하므로, JSON처럼 런타임에 데이터를 파싱하고 타입을 추론하는 과정이 필요 없습니다.
- 타입 안정성과 함께 처리 속도도 향상됩니다.
데이터 크기 비교
- 동일한 데이터의 크기를 비교했을 때:
  - JSON: 300바이트
  - Protocol Buffers: 100바이트
- 이는 대규모 데이터 전송에서 큰 네트워크 비용 절감으로 이어집니다.

3. 스트리밍 지원

gRPC는 HTTP/2의 스트리밍 기능을 활용하여, 데이터 전송 효율을 높입니다.

주요 스트리밍 모델

서버 스트리밍
- 클라이언트가 요청을 보내고, 서버가 여러 응답을 순차적으로 스트리밍.
- 예: 대량의 데이터 다운로드, 실시간 피드 제공.
클라이언트 스트리밍
- 클라이언트가 여러 요청을 스트리밍으로 서버에 보냄.
- 예: 센서 데이터 업로드, 대규모 로그 전송.
양방향 스트리밍
- 클라이언트와 서버가 동시에 데이터를 스트리밍하며, 실시간 통신에 적합.
- 예: 채팅 애플리케이션, 실시간 협업 도구.

4. 낮은 지연 시간

지연 시간 최적화 요소

네트워크 호출 수 감소
- HTTP/2 멀티플렉싱은 다중 요청과 응답을 단일 연결에서 처리하므로, 네트워크 지연 시간을 줄입니다.
- REST는 다수의 요청이 발생하면 추가 연결이 필요하여 지연 시간이 증가할 수 있습니다.
헤더 크기 최적화
- HTTP/2 헤더 압축은 반복적인 헤더 데이터를 줄여, 요청 크기를 최적화하고 전송 시간을 단축합니다.
효율적인 메시지 처리
- Protocol Buffers를 사용하여 메시지 크기를 줄이고, 처리 속도를 높임으로써 응답 시간이 짧아집니다.

5. 통합 및 확장성

확장성과 통합 지원

다중 언어 지원
- gRPC는 다양한 언어(Java, Python, Go 등)를 지원하며, 클라이언트와 서버가 서로 다른 언어로 구현되더라도 성능 저하 없이 동작.
분산 시스템에 최적화
- gRPC는 분산 시스템의 고성능 통신 요구사항에 맞게 설계되었습니다.
- 마이크로서비스 아키텍처에서 REST보다 낮은 오버헤드로 대규모 데이터 처리 가능.

gRPC의 고성능 활용 사례

실시간 애플리케이션
- 채팅 앱, 실시간 협업 도구, 스트리밍 플랫폼 등에서 낮은 지연 시간과 양방향 스트리밍 제공.
데이터 파이프라인
- 대규모 로그 데이터 수집, 실시간 데이터 분석에 적합.
마이크로서비스 아키텍처
- REST보다 효율적으로 서비스 간 통신을 지원하며, 확장성 높은 시스템 구축 가능.
IoT 환경
- Protocol Buffers의 작은 데이터 크기와 빠른 직렬화를 활용해, IoT 장치와의 통신 최적화.

gRPC의 단점

학습 곡선
- Protocol Buffers와 HTTP/2를 이해해야 하므로 REST보다 초기 학습 비용이 높음.
브라우저 지원 제한
- 브라우저에서 직접 gRPC를 사용할 수 없으며, gRPC-Web을 사용해야 함.
디버깅 어려움
- Protocol Buffers는 바이너리 포맷을 사용하므로, JSON처럼 사람이 읽기 쉬운 포맷이 아님.
- 디버깅과 로깅을 위해 추가적인 도구가 필요.
복잡한 설정
- HTTP/2와 TLS 설정이 필요하며, 기존 HTTP/1.1 기반 인프라와의 호환성이 제한됨.
단순한 CRUD 작업에 비효율적
- REST API가 더 직관적이고 사용이 간편한 경우가 많음(특히 JSON 기반 API).

gRPC의 주요 구성 요소

.proto 파일
- 서비스와 메시지 구조를 정의하는 파일.
- .proto 파일에서 gRPC 클라이언트 및 서버 코드를 생성.
Stub
- 클라이언트에서 서버 호출을 추상화한 인터페이스 역할.
- 클라이언트는 Stub을 호출하여 서버와 통신.
Channel
- 클라이언트와 서버 간의 HTTP/2 연결을 관리.
- 연결 상태와 재시도 로직을 처리.
Server
- gRPC 서버는 .proto 파일에서 정의된 서비스의 구현체.
- 클라이언트 요청을 처리하고 응답 반환.

gRPC의 사용 사례

마이크로서비스 아키텍처(MSA)
- 서비스 간 통신에서 REST API보다 효율적.
- 낮은 지연 시간과 높은 처리량이 필요한 대규모 시스템에 적합.
실시간 애플리케이션
- 채팅, 비디오 스트리밍, IoT 디바이스 통신 등 실시간 데이터 전송이 필요한 경우.
데이터 스트리밍
- 데이터 파이프라인에서 대규모 데이터를 처리하고 스트리밍.
다중 언어 통합
- 서로 다른 프로그래밍 언어로 작성된 시스템 간 통합.
클라우드 네이티브 애플리케이션
- Kubernetes와 같은 컨테이너 오케스트레이션 환경에서 사용.

gRPC 사용 시 주의사항

TLS 설정
- HTTP/2를 사용하기 위해 TLS 인증서를 구성해야 하며, 초기 설정이 복잡할 수 있음.
Backward Compatibility
- .proto 파일 수정 시 하위 호환성을 유지해야 함.
- 메시지 구조 변경 시 필드 번호 관리가 중요.
디버깅 도구 활용
- 바이너리 포맷의 메시지는 디버깅이 어려우므로, gRPCurl과 같은 도구를 사용하여 문제를 해결.
HTTP/2 지원
- HTTP/2를 지원하지 않는 네트워크 환경에서는 사용할 수 없으며, gRPC-Web과 같은 대안을 고려해야 함.
브라우저와의 통합
- 클라이언트가 브라우저라면, gRPC-Web을 통해 gRPC를 프록시하는 방식을 사용해야 함.

gRPC와 REST 비교

특징	gRPC	REST
프로토콜	HTTP/2 기반	HTTP/1.1 기반
데이터 형식	Protocol Buffers (바이너리 포맷)	JSON, XML (텍스트 포맷)
성능	빠르고 효율적	상대적으로 느림
스트리밍 지원	양방향 스트리밍 가능	단방향 요청/응답
브라우저 지원	직접 지원하지 않음 (gRPC-Web 필요)	브라우저에서 기본적으로 사용 가능
디버깅	복잡 (바이너리 포맷 디코딩 필요)	쉬움 (JSON으로 디버깅 가능)
배포 복잡성	HTTP/2 및 TLS 설정 필요	상대적으로 단순
주요 사용 사례	실시간 통신, 스트리밍 데이터, MSA	CRUD API, 웹 애플리케이션, 단순 API

결론

gRPC는 고성능, 다중 언어 지원, 스트리밍과 같은 강점을 통해 마이크로서비스, 실시간 애플리케이션, 데이터 스트리밍 등에 적합합니다. 그러나 초기 설정 및 학습 비용, 디버깅 어려움과 같은 단점도 존재하므로, REST와의 장단점을 비교하여 시스템 요구사항에 맞는 방식을 선택하는 것이 중요합니다.

This site is open source. Improve this page.