Google 원격 프로시저 호출(gRPC)은 HTTP/2를 통해 API를 구현하기 위한 고성능 오픈 소스 프레임워크입니다. 특히 코드가 여러 컴퓨터에서 실행될 수 있는 경우 개발자가 분산 애플리케이션을 더 쉽게 빌드할 수 있도록 설계되었습니다.
gRPC는 원래 Google에서 원격 프로시저 호출(RPC)을 구현하기 위한 기술로 개발되었습니다. 오늘날 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는 XML이나 JSON 대신 Protocol Buffers (또는 Protobufs )를 사용하여 서비스와 메시지를 정의합니다. 이는 서비스가 서로에게 보내는 구조화된 메시지를 직렬화하기 위한 언어 중립적인 메커니즘입니다.
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는 바이너리 프로토콜인 HTTP/2를 독점적으로 사용하는데, 이 프로토콜은 더 효율적이고 헤더 압축, 단일 TCP 연결을 통한 멀티플렉싱과 같은 기능을 지원합니다.
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 여정의 모든 지점에서 활용할 수 있는 다양한 무료 리소스를 제공합니다.