gRPC(Google 원격 프로시저 호출)는 HTTP/2를 통해 API를 구현하기 위한 고성능 오픈소스 프레임워크입니다. 개발자가 특히, 코드가 여러 컴퓨터에서 실행될 수 있는 경우 분산 애플리케이션을 보다 쉽게 구축할 수 있도록 설계되었습니다.
gRPC는 처음에 원격 프로시저 호출(RPC)을 구현하기 위한 기술로 Google에서 개발되었습니다. 현재 gRPC는 Cloud Native Computing Foundation의 인큐베이션 프로젝트로, 프로덕션에서 사용되고 있으며 건전한 기여자 풀의 지원을 받고 있습니다.
Google이 gRPC를 개발한 이유를 이해하기 위해 API 설계의 타임라인을 간략히 살펴보겠습니다.
RPC는 API를 설계하고 구축하는 가장 오래된 방법 중 하나입니다. RPC를 사용하면 실제로는 다른 컴퓨터(일반적으로 로컬 네트워크상에 위치)에서 실행되는 서비스를 호출하더라도 로컬 컴퓨터에서 실행되는 것처럼 코드를 작성할 수 있습니다.
실제로 개발자는 이를 통해 네트워크 세부 정보를 고려할 필요 없이 직접 동작(예: SendUserMessages, addEntry 등)을 사용할 수 있습니다. RPC 메시지는 가볍고 효율적이지만 기본 시스템과 긴밀하게 결합되어 있으므로 통합, 변경이 어렵고 시스템에 대한 세부 정보가 유출될 가능성이 높습니다.
REST API 아키텍처가 도입되었을 때 GET, POST, PUT, DELETE와 같은 일반적인 HTTP 메서드를 사용하여 데이터와 리소스에 액세스하는 통일된 방법을 제공함으로써 이러한 문제를 일부 해결했습니다. REST는 데이터 액세스를 단순화하지만 API는 종종 필요한 것보다 많은 메타데이터를 반환합니다. 또한 REST API는 네트워크에 대한 자세한 정보(요청을 보낼 위치 등)가 필요하므로 RPC만큼 가볍고 효율적이지 못합니다.
gRPC는 최신 기술을 채택함으로써 구형 RPC 메서드를 업데이트하여 상호 운용성과 효율성을 높였습니다. 오늘날 마이크로서비스 아키텍처용 API를 개발할 때 이것은 매력적인 선택이 됩니다.
gRPC의 몇 가지 장점은 다음과 같습니다.
전반적으로 gRPC는 고도로 분산된 마이크로서비스 아키텍처에서 서비스 간 통신에 적합한 고성능의 유연한 프레임워크를 제공합니다.
gRPC의 장점과 이점은 크게 두 가지 기술의 도입으로부터 비롯됩니다.
gRPC는 프로토콜 버퍼(또는 Protobufs)를 사용하여 XML 또는 JSON 대신 서비스와 메시지를 정의합니다. 이 메커니즘은 서비스가 상호간에 보낼 구조화된 메시지를 직렬화하기 위한 언어 중립적인 메커니즘입니다.
REST API용 OpenAPI 사양의 개념과 유사하게, gRPC의 API 계약은 개발자가 데이터 구조화 방식을 정의하는 .proto 텍스트 파일로 구현됩니다. 그러면 protoc 컴파일러가 .proto 텍스트 파일을 지원되는 모든 언어로 자동 컴파일합니다. 런타임 시에는 메시지가 압축되어 바이너리 형식으로 전송됩니다.
이 방식은 두 가지 주요 장점을 제공합니다.
전통적으로 REST API는 전송 레이어로 HTTP/1.1을 사용했습니다. REST API는 HTTP/2를 통해서도 전송할 수 있지만, gRPC는 HTTP/2를 단독 사용함으로써 몇 가지 주요 장점을 제공합니다. 이러한 장점 중 하나는 바이너리를 사용하여 통신을 전송하는 기능입니다. 또한 HTTP/2는 한 번에 하나의 요청을 처리하는 대신 여러 병렬 요청을 처리하는 기능을 지원합니다. 또한 양방향으로 통신이 이루어지므로 단일 연결에서 요청과 응답을 동시에 보낼 수 있습니다.
이를 통해 전반적으로 성능이 향상되고 네트워크 사용률이 감소하므로 사용량이 많은 마이크로서비스 아키텍처에서 특히 유용할 수 있습니다. 하지만 몇 가지 제한 사항이 있습니다. HTTP/2는 일반적으로 최신 웹 브라우저에서 지원되지 않으므로 애플리케이션을 제공하려면 NGINX와 같은 역방향 프록시를 사용해야 할 수 있습니다.
오늘날 REST는 가장 지배적인 API 설계 스타일이므로 gRPC와 비교하여 유용한 참조점을 제공합니다. REST와 gRPC는 모두 웹 애플리케이션 및 마이크로서비스용 API를 구축하는 데 유효한 접근 방식이며, 하나가 반드시 다른 하나보다 나은 것은 아닙니다. 그렇지만 작업에 가장 적합한 도구를 선택하려면 주요 차이점을 알고 있는 것이 좋습니다.
gRPC와 REST의 주요 차이점 중 일부는 다음과 같은 범주에 속합니다.
REST API는 HTTP/2를 활용할 수 있지만, RESTful 서비스는 전통적으로 텍스트 기반 HTTP/1.1을 전송 레이어로 사용합니다. gRPC는 더 효율적이며 단일 TCP 연결을 통해 헤더 압축 및 멀티플렉싱 같은 기능을 지원하는 바이너리 프로토콜인 HTTP/2를 단독으로 사용합니다.
REST API는 일반적으로 데이터를 송수신하기 위한 데이터 형식으로 JSON을 사용합니다. JSON은 텍스트 기반으로 쉽게 읽고 쓸 수 있으며 널리 지원됩니다. gRPC API는 더 작은 페이로드와 빠른 상호 작용을 제공하는 바이너리 형식의 Protobufs를 사용합니다. 하지만 Protobufs는 그 자체로는 쉽게 읽을 수 없습니다.
REST API는 스트리밍을 제한적으로 지원하는 요청-응답 모델을 지원합니다. 반면에 gRPC API는 HTTP/2를 통해 전달되며 단일 요소(요청-응답), 서버 스트리밍, 클라이언트 스트리밍 및 양방향 스트리밍을 포함한 여러 통신 패턴을 지원합니다.
REST는 GET, POST, PUT, DELETE와 같은 표준 HTTP 메서드를 지원하는 리소스 중심 모델입니다. 모든 요청에는 처리에 필요한 모든 정보가 포함되어야 합니다. 또한 API 계약은 일반적으로 클라이언트 및 서버의 코딩이 별도의 단계로 처리되는 OpenAPI 사양을 사용하여 작성됩니다. 반면, gRPC는 서비스 중심 모델로, 메시지와 서비스가 .proto 파일에 정의되며 이 파일을 사용하여 API 클라이언트 및 서버용 코드를 모두 생성할 수 있습니다.
REST는 HTTP/1.1을 통한 텍스트 기반 데이터 전송으로 인해 속도가 느릴 수 있습니다. 각 요청에는 TCP 핸드셰이크가 필요하므로 약간의 지연 시간이 발생할 수 있습니다. gRPC는 HTTP/2를 통한 다중 스트림을 지원하므로 여러 클라이언트가 새로운 TCP 연결을 설정하지 않고도 동시에 여러 요청을 보낼 수 있습니다. 또한 헤더 압축 같은 HTTP/2 기능을 활용할 수도 있습니다.
REST는 오류 처리를 위해 표준 HTTP 상태 코드를 사용합니다. 이에 비해 gRPC는 오류 상태 코드를 정의하고 일관성을 유지하기 위해 훨씬 더 세분화된 기능을 제공합니다. 기본적으로 gRPC 모델은 매우 제한적이지만 Google에서 개발한 더 풍부한 오류 모델을 사용하여 확장하는 것이 가장 일반적입니다.
REST는 거의 모든 언어에서 널리 지원되지만 내장된 코드 생성 기능은 제공하지 않습니다. 구현은 전적으로 개발자에게 맡겨집니다. gRPC는 protoc 컴파일러를 통해 여러 프로그래밍 언어를 위한 네이티브 코드 생성 기능을 제공합니다.
요컨대 gRPC와 REST 중 어떤 것을 선택할지는 달성하고자 하는 목표에 따라 달라집니다. gRPC는 분산 애플리케이션에서 서비스가 통신할 수 있는 효율적인 고성능 메서드를 제공합니다. 즉, 웹 브라우저 및 기타 클라이언트에서 직접 읽을 수 없으며 프론트엔드 클라이언트와 상호 작용하려면 API 게이트웨이 또는 NGINX 같은 역방향 프록시가 필요합니다. 이벤트 중심 마이크로서비스 아키텍처의 일부인 내부 API에 탁월한 옵션입니다.
반면 REST는 거의 모든 언어에서 널리 채택되고 지원되며, JSON 또는 XML을 사용하여 데이터를 교환하므로 사람과 기계가 모두 읽을 수 있습니다. 또한 시작하기 위한 학습 곡선이 훨씬 낮고 많은 웹 브라우저에서 지원되므로 공개적으로 노출되는 API에 적합합니다.
gRPC는 마이크로서비스 아키텍처에서 통신하기 위한 최고의 옵션 중 하나입니다. 이는 부분적으로는 성능 때문이기도 하지만 언어 지원의 유연성 때문이기도 합니다. 개발자는 선호하는 언어로 실행되는 gRPC 클라이언트와 서버를 쉽게 구축하고 생성할 수 있습니다. gRPC는 API 계약을 바이너리 형식으로 설명하므로 마이크로서비스는 구축에 사용된 언어와 관계없이 통신할 수 있습니다.
가장 일반적인 gRPC 기반 마이크로서비스 아키텍처 중 하나는 마이크로서비스 전면에 API 게이트웨이를 배치한 다음, 모든 내부 통신을 gRPC를 통해 처리하는 것입니다. API 게이트웨이는 HTTP/1.1에서 들어오는 요청을 처리하고 이를 HTTP/2를 통해 마이크로서비스에 gRPC 요청으로 프록시 처리합니다.
gRPC 채택이 계속 증가하면서 개발자와 보안 운영팀은 효과적인 보안 솔루션을 마련해야 합니다. gRPC 메시지는 바이너리 형식이므로 ASCII 기반 통신을 기대하는 디바이스 및 도구에서 문제가 발생할 수 있습니다.
또한 gRPC API는 여러 가지 가장 일반적인 API 보안 위협에 취약합니다. 액세스 제어, 암호화 및 런타임 보호와 같은 표준 API 보안 관행은 gRPC 기반 아키텍처에서도 똑같이 중요합니다.
gRPC 애플리케이션 및 API에는 보안에 대한 포괄적인 접근 방식이 필요합니다. gRPC 보안을 위한 몇 가지 모범 사례는 다음과 같습니다.
궁극적으로 API 게이트웨이, 웹 애플리케이션 방화벽(WAF), 기타 API 관리 및 보안 도구가 프로덕션 시 gRPC 애플리케이션과 API를 보호할 수 있는지 확인해야 합니다. 각 서비스에 대한 .proto 파일을 가져와 이를 사용하여 gRPC 애플리케이션과 API에 보안 보호 기능을 적용할 수 있어야 합니다.
gRPC는 Netflix 및 Lyft와 같은 대기업과 개발자들에게 마이크로서비스 아키텍처에서 사용하기 위한 대안으로 많은 관심을 받고 있습니다. 하지만 gRPC는 REST API를 대체하는 것도 아니고 본질적으로 API 구축하기 위한 더 나은 방법도 아닙니다. gRPC는 내부 마이크로서비스 환경을 위한 API를 주로 구축하며 효율적인 실시간 통신이 필요한 경우에 고려할 수 있는 대안일 뿐입니다.
앞으로 gRPC는 성능상의 이점과 개발의 용이성으로 인해 클라우드 네이티브 애플리케이션에서 계속 주목받을 가능성이 높습니다. 한편, API를 공개적으로 노출해야 하는 개발자는 애플리케이션에서 REST를 계속 사용할 것입니다. REST는 이전 버전과의 호환성, 기존 API 인프라 및 운영과의 긴밀한 통합 기능 덕분에 클라우드 네이티브 환경에서도 계속 존재하게 될 것입니다.
NGINX는 gRPC 여정의 어느 시점에서든 만족할 수 있는 다양한 무료 리소스를 제공합니다.