gRPC란 무엇인가요?

Google 원격 프로시저 호출(gRPC)은 HTTP/2를 통해 API를 구현하기 위한 고성능 오픈 소스 프레임워크입니다. 특히 코드가 서로 다른 머신에서 실행될 수 있는 환경에서 개발자가 분산 애플리케이션을 더 쉽게 구축할 수 있도록 설계되었습니다.

Google 원격 프로시저 호출(gRPC)은 HTTP/2를 통해 API를 구현하기 위한 고성능 오픈 소스 프레임워크입니다. 특히 코드가 서로 다른 머신에서 실행될 수 있는 환경에서 개발자가 분산 애플리케이션을 더 쉽게 구축할 수 있도록 설계되었습니다.

gRPC는 처음에 Google이 원격 프로시저 호출(RPC)을 구현하기 위한 기술로 개발했습니다. 현재 gRPC는 Cloud Native Computing Foundation의 인큐베이팅 프로젝트로, 실제 프로덕션 환경에서 사용되고 있으며 활발한 기여자 커뮤니티의 지원을 받고 있습니다.

gRPC는 왜 만들어졌을까요?

Google이 gRPC를 개발한 이유를 이해하기 위해, API 설계의 역사를 간략히 살펴보겠습니다.

RPC는 API를 설계하고 구축하는 가장 오래된 방식 중 하나입니다. RPC를 사용하면 실제로는 다른 컴퓨터(일반적으로 로컬 네트워크에 있는 컴퓨터)에서 실행되는 서비스를 호출하더라도, 마치 로컬 컴퓨터에서 실행되는 것처럼 코드를 작성할 수 있습니다.

실제로 이를 통해 개발자는 네트워크 세부 사항을 고려하지 않고도 SendUserMessages, addEntry 등의 직접적인 작업을 사용할 수 있습니다. RPC 메시지는 가볍고 효율적이지만 기반 시스템과도 긴밀하게 결합되어 있습니다. 따라서 통합하거나 변경하기가 어렵고 시스템의 세부 정보가 노출될 가능성이 더 큽니다.

When the REST API 아키텍처가 도입되면서 범용 HTTP 메서드인 GET, POST, PUT, DELETE를 사용해 데이터와 리소스에 일관된 방식으로 접근할 수 있게 되었고, 그 결과 이러한 문제 중 일부가 해결되었습니다. REST는 데이터 접근을 간소화하지만, API가 필요 이상의 메타데이터를 반환하는 경우가 많습니다. 또한 REST API를 사용하려면 요청을 어디로 보내야 하는지 등 네트워크에 관한 더 많은 정보가 필요하므로 RPC만큼 가볍고 효율적이지 않습니다.

gRPC의 장점은 무엇인가요?

gRPC는 최신 기술을 도입하여 기존 RPC 방식을 상호 운용이 가능하고 더욱 효율적으로 개선합니다. 오늘날 이는 마이크로서비스 아키텍처용 API를 개발할 때 매력적인 선택지입니다.

gRPC의 장점은 다음과 같습니다:

• 성능 – gRPC는 HTTP/2를 전송 프로토콜로 사용하고 기본적으로 Protocol Buffers를 사용하므로 REST 및 JSON 통신보다 성능을 향상할 수 있습니다.
• 스트리밍 – gRPC는 이벤트 기반 아키텍처를 위한 데이터 스트리밍을 지원합니다. 여기에는 서버 측 스트리밍, 클라이언트 측 스트리밍, 그리고 클라이언트 요청과 서버 응답을 동시에 전송하는 양방향 스트리밍이 포함됩니다.
• 상호 운용성 – gRPC는 기본 제공 코드 생성 기능을 통해 C++, Java, Python, PHP, Go, Ruby, C#, Node.js 등 다양한 프로그래밍 언어를 지원합니다.
• 보안 – gRPC는 보안과 복원력을 향상하기 위해 플러그형 인증, 추적, 부하 분산, 상태 확인 기능을 제공합니다.
• 클라우드 네이티브 – gRPC는 컨테이너 기반 배포 환경에서 원활하게 작동하며 Kubernetes 및 Docker와 같은 최신 클라우드 기반 기술과 호환됩니다.

전반적으로 gRPC는 고도로 분산된 마이크로서비스 아키텍처에서 서비스 간 통신에 적합한 고성능의 유연한 프레임워크를 제공합니다.

gRPC 이해하기: 기본 개념

gRPC의 장점과 이점은 주로 다음 두 가지 기술을 채택한 데서 비롯됩니다:

• 메시지 구조화를 위한 Protocol Buffers
• 전송 계층으로 HTTP/2 사용

메시지 구조화를 위한 프로토콜 버퍼

gRPC는 Protocol Buffers(또는 Protobuf)를 사용하여 XML이나 JSON 대신 서비스와 메시지를 정의합니다. 이는 서비스 간에 주고받을 구조화된 메시지를 직렬화하는 언어 중립적 메커니즘입니다.

REST API의 OpenAPI 사양 개념과 마찬가지로, gRPC의 API 계약은 개발자가 원하는 데이터 구조를 정의하는 .proto 텍스트 파일로 구현됩니다. 그런 다음 protoc 컴파일러가 .proto 텍스트 파일을 지원되는 언어로 자동 컴파일합니다. 런타임에는 메시지가 압축되어 바이너리 형식으로 전송됩니다.

이는 두 가지 주요 이점을 제공합니다:

• gRPC는 데이터를 바이너리 형식으로 표현하여 메시지 크기를 줄이므로 CPU 사용량이 적습니다.
• 스키마가 명확하게 정의되어 있어 클라이언트와 서버 간에 메시지를 원활하게 주고받을 수 있으며 오류를 줄일 수 있습니다.

전송 계층으로서의 HTTP/2

전통적으로 REST API는 HTTP/1.1을 전송 계층으로 사용했습니다. REST API도 HTTP/2를 통해 제공할 수 있지만, gRPC는 HTTP/2만 사용하기 때문에 몇 가지 중요한 이점이 있습니다. 그중 하나는 바이너리 형식으로 데이터를 전송할 수 있다는 점입니다. 또한 HTTP/2는 요청을 한 번에 하나씩 처리하는 대신 여러 요청을 병렬로 처리할 수 있습니다. 통신도 양방향으로 이루어지므로 단일 연결에서 요청과 응답을 동시에 전송할 수 있습니다.

전반적으로 이는 성능을 향상시키고 네트워크 사용량을 줄여 주므로, 트래픽이 많은 마이크로서비스 아키텍처에서 특히 유용할 수 있습니다. 하지만 몇 가지 제한 사항이 있습니다. HTTP/2는 일반적으로 최신 웹 브라우저에서 지원되지 않으므로 애플리케이션을 제공하려면 NGINX와 같은 리버스 프록시를 사용해야 할 수 있습니다.

gRPC와 REST 비교

오늘날 REST는 가장 널리 사용되는 API 설계 방식이므로 gRPC와 비교할 때 유용한 기준이 됩니다. REST와 gRPC는 모두 웹 애플리케이션과 마이크로서비스용 API를 구축하는 데 적합한 접근 방식이며, 어느 한쪽이 반드시 다른 쪽보다 더 낫다고 할 수는 없습니다. 다만 작업에 가장 적합한 도구를 선택하려면 두 방식의 주요 차이점을 이해하는 것이 좋습니다.

gRPC와 REST의 주요 차이점은 다음과 같은 범주로 나눌 수 있습니다:

• 프로토콜
• 데이터 형식
• 스트리밍
• API 설계
• 성능
• 오류 처리
• 언어 지원

프로토콜

REST API도 HTTP/2를 활용할 수 있지만, RESTful 서비스는 전통적으로 텍스트 기반의 HTTP/1.1을 전송 계층으로 사용합니다. gRPC는 더 효율적이며 헤더 압축과 단일 TCP 연결을 통한 멀티플렉싱 같은 기능을 지원하는 바이너리 프로토콜인 HTTP/2만 사용합니다.

데이터 형식

REST API는 일반적으로 데이터를 주고받기 위한 데이터 형식으로 JSON을 사용합니다. JSON은 텍스트 기반이므로 읽고 쓰기 쉬우며 폭넓게 지원됩니다. gRPC API는 바이너리 형식인 Protobuf를 사용하여 페이로드 크기를 줄이고 더 빠르게 통신할 수 있습니다. 하지만 Protobuf 자체는 쉽게 읽을 수 없습니다.

스트리밍

REST API는 스트리밍을 제한적으로 지원하는 요청-응답 모델을 지원합니다. 반면 gRPC API는 HTTP/2를 통해 제공되며 단항(Unary, 요청-응답), 서버 스트리밍, 클라이언트 스트리밍, 양방향 스트리밍을 비롯한 여러 통신 패턴을 지원합니다.

API 설계

REST는 GET, POST, PUT, DELETE와 같은 표준 HTTP 메서드를 지원하는 리소스 중심 모델입니다. 각 요청에는 요청을 처리하는 데 필요한 모든 정보가 포함되어야 합니다. 또한 API 계약은 일반적으로 OpenAPI Specification을 사용해 작성하며, 클라이언트와 서버의 코딩은 별도의 단계로 진행합니다. 반면 gRPC는 메시지와 서비스를 .proto 파일에 정의하는 서비스 중심 모델입니다. 이 파일을 사용해 API 클라이언트와 서버 양쪽의 코드를 생성할 수 있습니다.

성능

REST는 HTTP/1.1을 통해 텍스트 기반으로 데이터를 전송하기 때문에 속도가 느릴 수 있습니다. 각 요청에는 TCP 핸드셰이크가 필요하므로 어느 정도 지연이 발생할 수 있습니다. gRPC는 HTTP/2를 통한 다중 스트림을 지원하므로 여러 클라이언트가 새로운 TCP 연결을 설정하지 않고도 동시에 여러 요청을 보낼 수 있습니다. 또한 헤더 압축과 같은 HTTP/2 기능도 활용합니다.

오류 처리

REST는 오류 처리에 표준 HTTP 상태 코드를 사용합니다. 반면 gRPC는 오류 상태 코드를 정의하고 일관성을 보장할 수 있도록 훨씬 더 세분화된 기능을 제공합니다. 기본적으로 gRPC 모델은 상당히 제한적이지만, 일반적으로 더 풍부한 기능을 갖춘 Google에서 개발한 오류 모델을 사용하여 확장합니다.

언어 지원

REST는 사실상 모든 언어에서 폭넓게 지원되지만, 기본 제공되는 코드 생성 기능은 없습니다. 구현은 전적으로 개발자의 몫입니다. gRPC는 protoc 컴파일러를 통해 여러 프로그래밍 언어에 대한 네이티브 코드 생성을 지원합니다.

REST 대신 gRPC를 사용해야 할까요?

요약하면, gRPC와 REST 중 무엇을 선택할지는 달성하려는 목표에 따라 달라집니다. gRPC는 분산 애플리케이션에서 서비스 간 통신을 위한 효율적인 고성능 방식을 제공합니다. 다만 웹 브라우저나 기타 클라이언트에서 직접 읽을 수 없으므로, 프런트엔드 클라이언트와 상호 작용하려면 API 게이트웨이 또는 NGINX와 같은 리버스 프록시가 필요합니다. 이벤트 기반 마이크로서비스 아키텍처를 구성하는 내부 API에 매우 적합한 선택입니다.

반면 REST는 널리 채택되어 있으며 사실상 모든 언어에서 지원됩니다. JSON 또는 XML을 사용해 데이터를 교환하므로 사람과 기계 모두 읽을 수 있습니다. 또한 입문을 위한 학습 곡선이 훨씬 완만하고 다양한 웹 브라우저에서 지원되므로 외부에 공개되는 API에 적합합니다.

gRPC 마이크로서비스 아키텍처

gRPC는 마이크로서비스 아키텍처에서 통신을 구현하기 위한 최적의 선택지 중 하나입니다. 이는 부분적으로 성능 덕분이기도 하지만, 다양한 언어를 유연하게 지원하기 때문이기도 합니다. 개발자는 선호하는 언어로 실행되는 gRPC 클라이언트와 서버를 손쉽게 구축하고 생성할 수 있습니다. gRPC는 API 계약을 바이너리 형식으로 정의하므로, 마이크로서비스는 어떤 언어로 구축되었는지와 관계없이 서로 통신할 수 있습니다.

가장 일반적인 gRPC 기반 마이크로서비스 아키텍처 중 하나는 마이크로서비스 앞에 API 게이트웨이를 배치하고 모든 내부 통신을 gRPC로 처리하는 방식입니다. API 게이트웨이는 HTTP/1.1을 통해 들어오는 요청을 처리하고, 이를 HTTP/2 기반의 gRPC 요청으로 변환하여 마이크로서비스에 프록시합니다.

gRPC 보안 고려 사항

gRPC 도입이 계속 확대됨에 따라 개발자와 보안 운영 팀은 효과적인 보안 솔루션이 마련되어 있는지 확인해야 합니다. gRPC 메시지는 바이너리 형식이므로 ASCII 기반 통신을 전제로 하는 장치와 도구에서 문제가 발생할 수 있습니다.

gRPC API 역시 여러 가장 일반적인 API 보안 위협에 취약합니다. 액세스 제어, 암호화, 런타임 보호와 같은 표준 API 보안 관행은 gRPC 기반 아키텍처에서도 똑같이 중요합니다.

gRPC 보안 권장 사항

gRPC 애플리케이션과 API의 보안을 위해서는 종합적인 접근 방식이 필요합니다. gRPC 보안을 위한 몇 가지 모범 사례는 다음과 같습니다:

• 스키마 검증 – gRPC 메시지의 각 필드가 올바른 유형과 예상된 콘텐츠를 포함하는지 확인하여 악의적인 공격을 차단합니다.
• 데이터 마스킹 – 신용카드 번호 및 사회보장번호와 같은 민감한 데이터가 시스템 외부로 유출되지 않도록 마스킹하거나 차단합니다.
• 속도 제한 – 리소스 고갈형 DoS 공격을 방지하기 위해 요청의 크기와 횟수를 엄격하게 제한합니다.
• 액세스 제어 – 클라이언트에 서비스 액세스 권한을 부여하기 전에 인증 및 권한 부여를 적용합니다.
• 암호화 – 전송 계층 보안(TLS)을 사용하여 전송 중인 메시지를 보호합니다.

궁극적으로는 API 게이트웨이, 웹 애플리케이션 방화벽 (WAF) 및 기타 API 관리·보안 도구가 프로덕션 환경에서 gRPC 애플리케이션과 API를 충분히 보호할 수 있는지 확인해야 합니다. 이러한 도구는 각 서비스의 .proto 파일을 가져와 gRPC 애플리케이션과 API에 보안 조치를 적용할 수 있어야 합니다.

요약

gRPC는 개발자와 Netflix 및 Lyft 같은 대기업이 마이크로서비스 아키텍처에서 사용하는 인기 있는 대안으로 빠르게 주목받고 있습니다. 그렇다고 해서 gRPC가 REST API를 대체하거나 본질적으로 더 나은 API 구축 방식인 것은 아닙니다. 주로 내부 마이크로서비스 환경을 위한 API를 구축하면서 효율적인 실시간 통신이 필요한 경우 고려할 수 있는 하나의 대안일 뿐입니다.

앞으로 gRPC는 성능상의 이점과 개발 편의성 덕분에 클라우드 네이티브 애플리케이션에서 계속해서 널리 채택될 가능성이 높습니다. 한편, API를 외부에 공개해야 하는 개발자들은 애플리케이션에서 계속 REST를 사용할 것입니다. 또한 REST는 이전 버전과의 호환성이 뛰어나고 기존 API 인프라 및 운영 체계와 긴밀하게 통합되어 있어 클라우드 네이티브 환경에서도 계속 사용될 것입니다.