gRPC 개념 정립
1. RPC(Remote Procedure Call)의 이해
- 현대 소프트웨어 아키텍처, 특히 마이크로서비스 아키텍처(MSA)에서 서비스 간 통신은 시스템의 전체 성능을 결정짓는 핵심 요소
- 구글에서 개발한 gRPC는 기존의 REST API가 가진 한계를 극복하며 차세대 통신 표준으로 자리 잡고 있습니다.
- RPC(Remote Procedure Call): 다른 컴퓨터에 있는 함수를 마치 내 컴퓨터에 있는 함수인 것처럼 호출할 수 있게 해주는 프로토콜입니다
- 추상화: 개발자는 통신 과정의 복잡함을 고민할 필요 없이 비즈니스 로직에만 집중할 수 있습니다
- 언어 독립성: 서로 다른 언어(예: 루비 서버와 C# 클라이언트)로 작성된 시스템 간에도 자유로운 소통이 가능합니다
gRPC는 효율적인 데이터 전송을 위해 프로토콜 버퍼(Protocol Buffers)와 HTTP/2를 채택
- REST API가 텍스트 기반의 JSON을 사용하여 중복된 키(Key) 값을 계속 전송하는 반면, gRPC는
.proto파일에 데이터 형식을 미리 정의 - 데이터를 이진 형식으로 압축하여 전송 + 키 이름 대신 번호를 사용하여 데이터를 구분함(ID 기반 식별)으로써 전송 효율을 극대화
- 기존 HTTP/1.1이 한 번에 하나의 요청만 처리하는 편지 방식이라면, HTTP/2는 실시간 대화가 가능한 전화 방식에 비유
- 즉, 프로토콜 버퍼 + HTTP/2 + 바이너리 압축/직렬화/ID 기반 식별
HTTP/2
- 멀티플렉싱: 여러 메시지를 순서와 상관없이 한 번에 주고받을 수 있습니다
- 양방향 스트리밍: 클라이언트와 서버가 동시에 데이터를 주고받거나, 서버가 능동적으로 메시지를 보낼 수 있습니다
gRPC는 뛰어난 성능을 자랑하지만 모든 상황에 만능은 아닙니다.
- 서버 내부 서비스 간의 빠른 통신이 핵심, 높은 보안(TLS 암호화)과 실시간성이 요구되는 분야 (MSA, 금융 및 의료)
- IoT 및 모바일 게임 : 낮은 대역폭에서도 효율적인 동기화가 필요한 경우
- 제약 사항: 웹 브라우저 지원 미흡, 최신 브라우저들이 HTTP/2를 지원하지만, gRPC에 필요한 상세 기능 지원은 아직 부족
RPC, REST(JSON), GraphQL의 성능 벤치마킹
처리량 (Throughput - 초당 요청 수):
- gRPC: 초당 90,000건의 요청을 처리하며 압도적인 성능
- REST (JSON): 약 66,000건의 요청을 처리
- GraphQL: 쿼리 엔진의 오버헤드로 인해 약 32,000건으로 가장 낮은 처리량
지연 시간 (Latency):
- 부하가 적을 때는 REST가 미세하게 빨랐으나, 부하가 커질수록 gRPC가 훨씬 더 안정적인 지연 시간을 유지했습니다.
리소스 효율성:
- 네트워크 사용량: gRPC는 바이너리 직렬화 덕분에 REST(JSON)보다 훨씬 적은 네트워크 대역폭을 사용합니다. 이는 클라우드 비용 절감으로 직결
- 메모리: gRPC가 가장 적은 메모리 사용량(Memory Footprint)을 기록했습니다.
구현의 선택
- REST API : 표준적이고 구현이 쉬움. 일반적인 웹 애플리케이션용 API로 가장 적합.
- gRPC : 고성능, 저지연, 효율적인 리소스 사용. 마이크로서비스 간 통신(Service-to-Service) 및 사용자 경험 개선이 필요한 모바일 애플리케이션 백엔드에 강력히 추천
- GraphQL : 유연한 쿼리가 가능하지만 쿼리 엔진으로 인한 성능 저하가 있음. 이번 테스트에서는 초당 24,000건 이상의 요청에서 실패하기 시작하여