gRPC

팁

이 콘텐츠는 Azure용 클라우드 네이티브 .NET 애플리케이션 설계 eBook 에서 발췌한 것으로, .NET 문서에서 제공되거나 오프라인 상태에서도 읽을 수 있는 PDF(무료 다운로드 가능)로 제공됩니다.

PDF 다운로드

지금까지 이 책에서는 REST 기반 통신에 중점을 두었습니다. REST는 엔터티 리소스에 대해 CRUD 기반 작업을 정의하는 유연한 아키텍처 스타일입니다. 클라이언트는 요청/응답 통신 모델을 사용하여 HTTP를 통해 리소스와 상호 작용합니다. REST가 널리 구현되는 동안 최신 통신 기술인 gRPC는 클라우드 네이티브 커뮤니티에서 엄청난 추진력을 얻었습니다.

gRPC란 무엇인가요?

gRPC는 오래된 RPC(원격 프로시저 호출) 프로토콜을 발전시키는 최신 고성능 프레임워크입니다. 애플리케이션 수준에서 gRPC는 클라이언트와 백 엔드 서비스 간의 메시징을 간소화합니다. Google에서 시작된 gRPC는 오픈 소스이며 클라우드 네이티브 제품의 CNCF(Cloud Native Computing Foundation) 에코시스템의 일부입니다. CNCF는 gRPC를 인큐베이팅 프로젝트로 간주합니다. 인큐베이팅이란 최종 사용자가 프로덕션 애플리케이션에서 기술을 사용하고 있으며 프로젝트에 많은 기여자가 있음을 의미합니다.

일반적인 gRPC 클라이언트 앱은 비즈니스 작업을 구현하는 로컬, In-Process 함수를 노출합니다. 내부적으로는 해당 로컬 함수가 원격 컴퓨터에서 다른 함수를 호출합니다. 로컬 호출로 보이는 것이 본질적으로 원격 서비스에 대한 투명한 out-of-process 호출이 됩니다. RPC 연결은 지점간 네트워킹 통신, 직렬화 및 컴퓨터 간의 실행을 추상화합니다.

클라우드 네이티브 애플리케이션에서 개발자는 프로그래밍 언어, 프레임워크 및 기술 전반에 걸쳐 작업하는 경우가 많습니다. 이 상호 운용성은 메시지 계약과 플랫폼 간 통신에 필요한 연결을 복잡하게 만듭니다. gRPC는 이러한 문제를 추상화하는 "균일한 수평 계층"을 제공합니다. 개발자는 비즈니스 기능에 중점을 둔 네이티브 플랫폼의 코드를 작성하고 gRPC는 통신 연결을 처리합니다.

gRPC는 Java, JavaScript, C#, Go, Swift 및 NodeJS를 포함하여 가장 널리 사용되는 개발 스택 전반에 걸쳐 포괄적인 지원을 제공합니다.

gRPC 혜택

gRPC는 전송 프로토콜에 HTTP/2를 사용합니다. HTTP 1.1과 호환되지만 HTTP/2는 다음과 같은 많은 고급 기능을 제공합니다.

• 텍스트 기반인 HTTP 1.1과 달리 데이터 전송을 위한 이진 프레임 프로토콜.
• 동일한 연결을 통해 여러 병렬 요청을 보내는 멀티플렉싱 지원 - HTTP 1.1은 한 번에 하나의 요청/응답 메시지로 처리를 제한합니다.
• 클라이언트 요청과 서버 응답을 동시에 보내기 위한 양방향 전체 이중 통신.
• 큰 데이터 집합을 비동기적으로 스트리밍하기 위해 요청 및 응답을 설정하는 기본 제공 스트리밍.
• 네트워크 사용량을 줄이는 헤더 압축.

gRPC는 가볍고 고성능입니다. 메시지가 60-80% 더 작은 JSON 직렬화보다 최대 8배 빠를 수 있습니다. Microsoft WCF(Windows Communication Foundation) 구문에서 gRPC 성능은 고도로 최적화된 NetTCP 바인딩의 속도와 효율성을 능가합니다. Microsoft 스택을 선호하는 NetTCP와 달리 gRPC는 플랫폼 간입니다.

프로토콜 버퍼

gRPC는 프로토콜 버퍼라는 오픈 소스 기술을 수용합니다. 서비스가 서로에게 보내는 구조화된 메시지를 직렬화하기 위해 매우 효율적이고 플랫폼 중립적인 직렬화 형식을 제공합니다. 개발자는 플랫폼 간 IDL(인터페이스 정의 언어)을 사용하여 각 마이크로 서비스에 대한 서비스 계약을 정의합니다. 텍스트 기반 .proto 파일로 구현된 계약은 각 서비스에 대한 메서드, 입력 및 출력을 설명합니다. 동일한 계약 파일을 다른 개발 플랫폼에 빌드된 gRPC 클라이언트 및 서비스에 사용할 수 있습니다.

Protobuf 컴파일러 protoc는 proto 파일을 사용하여 대상 플랫폼에 대한 클라이언트 및 서비스 코드를 모두 생성합니다. 코드에는 다음 구성 요소가 포함됩니다.

• 클라이언트와 서비스가 공유하는 강력한 형식의 개체로, 메시지에 대한 서비스 작업 및 데이터 요소를 나타냅니다.
• 원격 gRPC 서비스가 상속 및 확장할 수 있는 필수 네트워크 연결이 있는 강력한 형식의 기본 클래스입니다.
• 원격 gRPC 서비스를 호출하는 데 필요한 연결이 포함된 클라이언트 스텁입니다.

런타임에 각 메시지는 표준 Protobuf 표현으로 직렬화되고 클라이언트와 원격 서비스 간에 교환됩니다. JSON 또는 XML과 달리 Protobuf 메시지는 컴파일된 이진 바이트로 직렬화됩니다.

.NET의 gRPC 지원

gRPC는 .NET Core 3.0 SDK 이상에 통합됩니다. 다음 도구에서 지원됩니다.

• ASP.NET 및 웹 개발 워크로드가 설치된 Visual Studio 2022
• Visual Studio Code
• dotnet CLI

SDK에는 엔드포인트 라우팅, 기본 제공 IoC 및 로깅을 위한 도구가 포함되어 있습니다. 오픈 소스 Kestrel 웹 서버는 HTTP/2 연결을 지원합니다. 그림 4-20은 gRPC 서비스에 대한 골격 프로젝트를 스캐폴드하는 Visual Studio 2022 템플릿을 보여 줍니다. .NET이 어떻게 Windows, Linux 및 macOS를 완벽하게 지원하는지 확인합니다.

그림 4-20. Visual Studio 2022의 gRPC 지원

그림 4-21은 Visual Studio 2022에 포함된 기본 제공 스캐폴딩에서 생성된 골격 gRPC 서비스를 보여 줍니다.

그림 4-21. Visual Studio 2022의 gRPC 프로젝트

이전 그림에서 proto 설명 파일과 서비스 코드를 확인합니다. 곧 보게 되겠지만 Visual Studio는 Startup 클래스와 기본 프로젝트 파일 모두에서 추가 구성을 생성합니다.

gRPC 사용

다음 시나리오에서는 gRPC를 선호합니다.

• 처리를 계속하기 위해 즉각적인 응답이 필요한 동기식 백 엔드 마이크로 서비스 간 통신.
• 혼합 프로그래밍 플랫폼을 지원해야 하는 다중저장소 환경.
• 성능이 중요한 낮은 대기 시간 및 높은 처리량 통신.
• 지점 간 실시간 통신 - gRPC는 폴링 없이 실시간으로 메시지를 푸시할 수 있으며 양방향 스트리밍에 대한 뛰어난 지원을 제공합니다.
• 네트워크 제약이 있는 환경 – 이진 gRPC 메시지는 항상 동등한 텍스트 기반 JSON 메시지보다 작습니다.

이 글을 쓰는 시점에서 gRPC는 주로 백 엔드 서비스와 함께 사용됩니다. 최신 브라우저는 프런트 엔드 gRPC 클라이언트를 지원하는 데 필요한 HTTP/2 제어 수준을 제공할 수 없습니다. 즉, JavaScript 또는 Blazor WebAssembly 기술로 빌드된 브라우저 기반 앱에서 gRPC 통신을 가능하게 하는 .NET을 사용한 gRPC-Web을 지원합니다. gRPC-Web을 사용하면 ASP.NET Core gRPC 앱이 브라우저 앱에서 gRPC 기능을 지원할 수 있습니다.

• 강력한 형식의 코드 생성 클라이언트
• 컴팩트 Protobuf 메시지
• 서버 스트리밍

gRPC 구현

Microsoft의 마이크로 서비스 참조 아키텍처인 eShop on Containers는 .NET 애플리케이션에서 gRPC 서비스를 구현하는 방법을 보여 줍니다. 그림 4-22는 백 엔드 아키텍처를 나타냅니다.

그림 4-22. eShop on Containers에 대한 백 엔드 아키텍처

이전 그림에서 eShop이 여러 API 게이트웨이를 노출하여 BFF(프런트 엔드용 백 엔드) 패턴을 어떻게 수용하는지 확인합니다. 이 장의 앞부분에서 BFF 패턴에 대해 설명했습니다. Web-Shopping API 게이트웨이와 백 엔드 쇼핑 마이크로 서비스 사이에 있는 Aggregator 마이크로 서비스(회색)에 세심한 주의를 기울이세요. Aggregator는 클라이언트로부터 단일 요청을 수신하고 이를 다양한 마이크로 서비스에 발송하고 결과를 집계하고 요청 클라이언트로 다시 보냅니다. 이러한 작업은 일반적으로 즉각적인 응답을 생성하기 위해 동기 통신이 필요합니다. eShop에서 Aggregator의 백 엔드 호출은 그림 4-23과 같이 gRPC를 사용하여 수행됩니다.

그림 4-23 eShop on Containers의 gRPC

gRPC 통신에는 클라이언트 및 서버 구성 요소가 모두 필요합니다. 이전 그림에서 Shopping Aggregator가 gRPC 클라이언트를 구현하는 방법을 확인합니다. 클라이언트는 각각 gRPC 서버를 구현하는 백 엔드 마이크로 서비스에 대한 동기 gRPC 호출(빨간색)을 수행합니다. 클라이언트와 서버 모두 .NET SDK의 기본 제공 gRPC 연결을 활용합니다. 클라이언트 쪽 스텁은 원격 gRPC 호출을 호출하기 위한 연결을 제공합니다. 서버 쪽 구성 요소는 사용자 지정 서비스 클래스가 상속하고 사용할 수 있는 gRPC 연결을 제공합니다.

RESTful API와 gRPC 통신을 모두 노출하는 마이크로 서비스에는 트래픽을 관리하기 위해 여러 엔드포인트가 필요합니다. RESTful 호출에 대해 HTTP 트래픽을 수신하는 엔드포인트와 gRPC 호출에 대해 다른 엔드포인트를 수신하는 엔드포인트를 엽니다. gRPC 통신에 필요한 HTTP/2 프로토콜에 대해 gRPC 엔드포인트를 구성해야 합니다.

마이크로 서비스를 비동기 통신 패턴과 분리하기 위해 노력하고 있지만 일부 작업에는 직접 호출이 필요합니다. gRPC는 마이크로 서비스 간의 직접적인 동기 통신을 위한 기본 선택이어야 합니다. HTTP/2 및 프로토콜 버퍼를 기반으로 하는 고성능 통신 프로토콜은 완벽한 선택입니다.

향후 전망

앞으로 gRPC는 클라우드 네이티브 시스템에 대한 견인력을 계속 얻을 것입니다. 성능 이점과 개발 용이성은 매력적입니다. 하지만 REST는 오랫동안 계속 사용될 것입니다. 공개적으로 노출된 API 및 이전 버전과의 호환성에는 REST가 탁월합니다.

이전다음