gRPC란? 아주 쉽게 알아보자 (feat. REST API 언제까지 쓸 거니?)

gRPC의 기초

오늘날 분산 시스템과 마이크로서비스 아키텍처가 대세인 세상에서, 서비스 간 통신은 더 이상 선택이 아닌 필수다. 그런데 이 통신을 어떻게 하면 더 효율적으로, 더 빠르게, 더 안정적으로 할 수 있을까? 여기서 등장하는 것이 바로 gRPC다. 마치 전화를 걸듯이 다른 서버의 함수를 직접 호출할 수 있게 해주는 이 기술은 현대 웹 개발의 핵심 도구로 자리 잡고 있다.

(👨🏻‍🏫 : 안녕하세요! 오늘은 제가 좋아하는 주제인 gRPC에 대해 알아볼 건데요. gRPC는 REST API 와 같이 여러 통신 기법중 하나예요. 그 중 구글이 만들어 앞에 ‘g’ 가 붙었답니다! 저는 처음 gRPC를 접했을 때, REST API와 Web Socket 등 이 둘이 제가 알고 있는 유일한 통신 기법이었습니다. 따라서 이해하고, 적용하는 데까지 처음에 너무 어색했는데, 다들 그러실 거라고 생각합니다! 한번 천천히 읽어보세요! 사고가 확장된답니다.)

gRPC는 단순한 API 통신 방식이 아니다. 이것은 구글이 개발한 차세대 원격 프로시저 호출(RPC) 프레임워크로, 고성능과 효율성을 극대화하도록 설계되었다. 전통적인 REST API와는 다른 접근 방식을 취하며, 특히 마이크로서비스 환경에서 그 진가를 발휘한다.

💡급하신 분들을 위해서 결론 먼저!

1. gRPC는 Google에서 개발한 고성능 오픈소스 RPC 프레임워크로, gRPC란 이름이 붙었다.
2. 이는 REST API 와는 다르게, 다양한 환경(단방향, 양방향, 실시간 등)에서 효율적인 서비스 간 통신을 가능하게 한다.
3. 기존의 REST API에서 사용하는 JSON 이 아닌, Protocol Buffers(Protobuf)를 사용하여 데이터를 직렬화하고, HTTP/2를 기반으로 통신하여 높은 성능을 제공한다.
4. 다양한 언어 지원과 양방향 스트리밍 기능을 통해 실시간 통신이 가능하다.
5. REST API와 비교했을 때 더 빠른 성능과 효율적인 통신을 제공한다.
6. 주로 마이크로서비스 아키텍처, 분산 시스템, 실시간 통신이 필요한 환경에서 활용된다.

1. gRPC의 개념과 정의

gRPC란 무엇인가?

gRPC는 'Google Remote Procedure Call'의 약자로 알려져 있지만, 공식적으로는 'gRPC Remote Procedure Call'을 의미한다. 이는 구글이 개발한 오픈소스 고성능 RPC 프레임워크로, 다양한 환경에서 실행할 수 있는 분산 애플리케이션과 서비스를 구축하기 위한 도구다.

gRPC의 핵심은 클라이언트 애플리케이션이 마치 로컬 객체인 것처럼 다른 머신에 있는 서버 애플리케이션의 메서드를 직접 호출할 수 있게 해준다는 점이다. 이를 통해 분산 시스템 간의 통신이 훨씬 간단해지고 효율적으로 이루어질 수 있다.

(👨🏻‍🏫 : RPC가 뭔지 모르시는 분들을 위해 설명드리자면, 간단히 말해 '다른 컴퓨터에 있는 함수를 마치 내 컴퓨터의 함수처럼 호출하는 기술'이랍니다!)

gRPC의 역사

gRPC는 구글 내부에서 사용하던 'Stubby'라는 RPC 시스템에서 시작되었다. 구글은 이 시스템을 오픈소스로 공개하면서 gRPC로 이름을 바꾸고, 현대적인 기능과 다양한 언어 지원을 추가했다. 현재는 클라우드 네이티브 컴퓨팅 재단(CNCF)의 졸업 프로젝트로서 활발히 발전하고 있다.

2. gRPC의 핵심 기술

Protocol Buffers(Protobuf)

gRPC의 가장 중요한 기술적 기반은 Protocol Buffers(줄여서 Protobuf)다. 이는 구글이 개발한 언어 중립적인 데이터 직렬화 메커니즘으로, XML이나 JSON보다 더 작고, 더 빠르며, 더 단순하다. 왜 작고, 왜 더 빠르고, 왜 더 단순할까? (REST API만 사용해봤다면, 뭔가 많이 어색할 것이 분명하다.)

// 간단한 gRPC 서비스 정의 예시
syntax = "proto3";

package helloworld;

// 서비스 정의
service Greeter {
  // 단일 요청-응답 RPC
  rpc SayHello (HelloRequest) returns (HelloReply) {}
}

// 요청 메시지
message HelloRequest {
  string name = 1;
}

// 응답 메시지
message HelloReply {
  string message = 1;
}

출처: https://grpc.io/docs/what-is-grpc/introduction/

Protobuf는 .proto 파일에 데이터 구조를 정의하고, 이를 컴파일하여 다양한 프로그래밍 언어로 코드를 생성한다. 이렇게 생성된 코드는 데이터를 효율적으로 직렬화하고 역직렬화하는 기능을 제공한다. 그 과정에서 왜 JSON 보다 더 작고, 더 빠르고, 더 단순한지는 다음 시리즈에서 훨씬 더 자세하게 설명하겠다.

(👨🏻‍🏫 : 잘 안 읽혀서 넘어갔을 수도 있지만, 하나의 proto 라는 파일로 직렬화하고, 역직렬화 한다는 사실이 gRPC 와 REST API의 차이를 이해하는 데에 있어서 매우 매우 매우 중요해요!!!!!. )

즉 .proto는 프론트와, 백엔드 간의 명세서이자 Service 로직을 구현해주는 코드가 되어준다. 제 생각엔 구글이 ‘REST API’ 의 문제를 아주 깊게 들어갔을 때, 바로 그 설계 단계에서부터 문제가 있다고 생각을 한 것 같다. 오늘은 이렇게 작성한 proto가 어떻게 바뀌는지 정도만 알아가도 도움이 될 거 같다.

PROTOBUF 는 정말 중요한 파일이니만큼 전반적인 도메인이나, 서비스에 대한 이해도가 높은 사람이 보통 이를 관리하는 역할을 맡게 된다.

그렇게 주요한 직책을 맡은 사람과 팀원들이 설계하여 만든 PROTOBUF를 갖고서 프론트, 백엔드 개발자들이 buf라는 컴파일러를 통해 각각 컴파일 해준다.(script로 보통 빼둬서 yarn proto 와 같이 만들어 둔다!) 이 과정에서 호출하려는 함수들이 업데이트 되어 자동으로 생성된다. 즉, 이를 통해서 향후에 함수 호출을 한다. (RPC의 정의에 입각한 방식이다.) 그렇게 된다면 함수를 통한 프론트, 백엔드 개발자 둘 다 보다 더 다른 코드의 관심사 분리나 기능 구현에 시간을 보다 더 쏟을 수 있게 된다.

3. gRPC의 주요 특징

다양한 통신 모델 지원

gRPC는 다음과 같은 네 가지 통신 모델을 지원한다:

1. 단일 요청-응답(Unary RPC): 클라이언트가 단일 요청을 보내고 서버가 단일 응답을 반환하는 전통적인 모델 ( = REST API 의 방식)
2. 서버 스트리밍(Server streaming RPC): 클라이언트가 단일 요청을 보내고 서버가 일련의 응답을 스트림으로 반환
3. 클라이언트 스트리밍(Client streaming RPC): 클라이언트가 일련의 요청을 스트림으로 보내고 서버가 단일 응답을 반환
4. 양방향 스트리밍(Bidirectional streaming RPC): 클라이언트와 서버가 독립적으로 메시지 스트림을 주고받음

이러한 다양한 통신 모델은 실시간 채팅, 데이터 스트리밍, 센서 데이터 수집 등 다양한 사용 사례에 적합하다.

다양한 언어 지원

gRPC는 다양한 프로그래밍 언어를 지원하여 폴리글랏(polyglot) 프로그래밍을 가능하게 한다. 현재 지원하는 주요 언어는 다음과 같다:

• Java
• C#
• Go
• Python
• Ruby
• JavaScript (Node.js)
• Objective-C
• PHP
• C++
• Dart

이러한 다양한 언어 지원은 서로 다른 언어로 작성된 서비스 간의 원활한 통신을 가능하게 한다. 예를 들어, Java로 작성된 서버와 Python으로 작성된 클라이언트가 쉽게 통신할 수 있다.

타입 안전성

gRPC는 Protocol Buffers를 통해 강력한 타입 안전성을 제공한다. 이는 컴파일 시점에 타입 오류를 발견할 수 있게 해주며, 런타임 오류를 줄이는 데 도움이 된다. 또한 API 계약을 명확하게 정의하고 문서화하는 데도 유용하다.

4. gRPC와 REST API 비교

통신 방식의 차이

gRPC와 REST API는 통신 방식에서 근본적인 차이가 있다:

• REST API: HTTP 메서드(GET, POST, PUT, DELETE 등)와 URI를 사용하여 리소스를 조작하는 방식
• gRPC: 정의된 서비스의 메서드를 직접 호출하는 방식

REST API가 리소스 중심적이라면, gRPC는 함수 중심적이라고 볼 수 있다.

성능 차이

일반적으로 gRPC는 REST API보다 더 나은 성능을 제공한다:

• 메시지 크기: Protocol Buffers의 바이너리 형식은 JSON보다 훨씬 작은 메시지 크기를 가진다.
• 직렬화/역직렬화 속도: 바이너리 형식은 텍스트 기반 형식보다 처리 속도가 빠르다.
• HTTP/2의 이점: 다중화, 헤더 압축 등 HTTP/2의 기능을 활용하여 네트워크 효율성이 높다.

(👨🏻‍🏫 : 실제 벤치마크 테스트에서는 gRPC가 REST보다 최대 10배까지 빠를 수 있다고 합니다! 특히 대량의 데이터를 처리할 때 그 차이가 더 두드러진답니다.)

사용 사례 비교

특성	gRPC	REST API
통신 모델	단일, 스트리밍, 양방향	주로 요청-응답
데이터 형식	Protocol Buffers	주로 JSON, XML
프로토콜	HTTP/2	주로 HTTP/1.1
브라우저 지원	우수하나 일부 제한됨	우수함
코드 생성	자동 생성	수동 또는 도구 사용
타입 안전성	높음	낮음 (스키마 없음)

5. gRPC의 활용 사례

마이크로서비스 아키텍처 (MSA)

gRPC는 마이크로서비스 아키텍처에서 서비스 간 통신에 이상적이다. 높은 성능, 강력한 타입 시스템, 코드 생성 기능은 복잡한 마이크로서비스 환경에서 개발 생산성과 시스템 안정성을 높인다.

모바일 애플리케이션과 백엔드 통신

모바일 환경에서는 네트워크 대역폭과 배터리 사용량이 중요한 고려 사항이다. gRPC의 효율적인 바이너리 프로토콜과 HTTP/2 기반 통신은 모바일 애플리케이션과 백엔드 서버 간의 통신을 최적화하는 데 도움이 된다.

실시간 통신 시스템 및 일방향 통신이 동시에 사용되는 서비스

gRPC의 양방향 스트리밍 기능은 실시간 채팅, 게임, 협업 도구 등 실시간 통신이 필요한 애플리케이션에 적합하다. 클라이언트와 서버가 지속적으로 메시지를 주고받을 수 있어 실시간 상호작용을 구현하기 쉽다.

대표적인 사용 기업

gRPC는 다음과 같은 주요 기업에서 활발히 사용되고 있다:

• Google: gRPC를 개발한 구글은 내부 서비스 간 통신에 광범위하게 사용
• Netflix: 마이크로서비스 아키텍처에서 서비스 간 통신에 활용
• Square: 결제 시스템과 같은 고성능 서비스에 적용
• Cisco: 네트워크 장비 관리 및 모니터링 시스템에 활용
• IBM: 클라우드 서비스 및 엔터프라이즈 솔루션에 통합

🙇🏻 글 내에 틀린 점, 오탈자, 비판, 공감 등 모두 적어주셔도 됩니다. 감사합니다..! 🙇🏻