gRPC란 무엇인가요?

RPC(원격 프로시저 호출)는 원격 호출이 로컬 호출로 표시되고 작동할 수 있도록 하는 클라이언트/서버 상호 작용을 위한 통신 모델입니다. 개념적으로는 1970년대로 거슬러 올라가는 오래된 기술로, ARPANET 및 Xerox PARC와 같은 선구적인 컴퓨팅 프로젝트에서 초기에 적용되었습니다.

RPC에서 클라이언트는 로컬로 보이지만 실제로는 중개자 역할을 하는 서버의 표현과 상호 작용합니다. 이 중개자는 일반적으로 스텁이라고 하며, 데이터 마샬링 및 언마샬링(데이터를 전송에 적합한 형식으로 변환하고 서버에서 받은 결과를 원래 형식으로 다시 변환하는 작업)을 처리합니다. 클라이언트/서버 통신을 위한 아키텍처 스타일이기 때문에 API 설계에 일반적으로 사용됩니다.

XML-RPC 및 JSON-RPC를 포함하여 RPC 프레임워크에는 다양한 구현이 있습니다. 이러한 구현은 HTTP를 전송 프로토콜로 사용하며, 대부분 형식 유형이 다릅니다. 1990년대와 2000년대로 거슬러 올라가는 이러한 구현은 RPC의 강점을 잘 보여줍니다. 즉, 개발을 단순화하고, 네트워크 통신 복잡성을 추상화하고, 가볍고, 비교적 사용하기 쉽고, 사람이 읽을 수 있다는 것입니다.

그러나 많은 최신 환경, 특히 마이크로서비스 아키텍처, 다국어 환경 및 데이터 부하가 많은 시스템을 사용하는 환경에서는 분산된 애플리케이션을 연결하기 위해 더 빠른 고성능 프레임워크가 필요합니다. 이 프레임워크는 서로 다른 환경과 데이터 센터에서 실행되는 서비스 간에 보다 효율적인 실시간 데이터 전송을 가능하게 하는 것이 이상적입니다.

gRPC는 이러한 요구 사항을 충족하기 위해 개발되었으며, 데이터 직렬화 및 HTTP/2 프로토콜 사용, 양방향 스트리밍 능력, 코드 생성 등을 통해 낮은 대기 시간과 높은 처리량을 제공합니다.

gRPC는 HTTP/2가 출시된 해와 같은 해인 2015년에 처음 출시되었습니다. 주로 IDL(인터페이스 정의 언어)인 프로토콜 버퍼 또는 Protobuf를 사용하여 이전 RPC 구현의 제한 사항을 해결합니다. Protobuf는 구조화된 데이터를 직렬화하고 바이너리로 인코딩합니다. 이를 통해 데이터를 더욱 압축하여 더 빠른 전송과 더 높은 성능을 구현할 수 있습니다.

또한 Protobuf를 사용하면 코드 중단 없이 데이터 필드를 변경할 수 있습니다. 이를 통해 오류를 줄이고 실시간 데이터 공유 및 처리를 가능하게 합니다. 이러한 기능 덕분에 gRPC로 구축된 API는 최신 분산 환경, 마이크로서비스 아키텍처, 스트리밍 애플리케이션, 사물인터넷 시스템 및 디바이스 연결을 위한 강력한 옵션이 되었습니다.

gRPC가 'Google 원격 프로시저 호출'의 약자라면 이해가 될 것입니다. 하지만 grpc.io의 gRPC 팀은 'gRPC 원격 프로시저 호출'의 약자라고 건방지게 주장합니다. GitHub에 따르면 'g'는 각 버전마다 다른 것을 의미합니다('gregarious'에서 'goose', 'Guadalupe River Park Conservancy'에 이르기까지). 어쨌든 Google은 gRPC를 개발하여 2015년에 오픈 소스 프로젝트로 출시했습니다.

gRPC는 최신 언어와 추가 기능 및 최적화를 지원하는 최신 업데이트된 버전의 RPC를 제공합니다. 제공되는 특징은 다음과 같습니다.

• 프로토콜 버퍼라고 하는 인터페이스 디자인 언어(IDL)
• 데이터 전송을 위한 HTTP/2 사용
• 양방향 스트리밍
• 코드 생성
• 4가지 방법 유형
• TLS 기반 보안과 통합
• 로깅, 추적, 인증 등을 위한 인터셉터 지원

일반적으로 Protobuf로 알려진 프로토콜 버퍼는 Google에서 개발한 크로스 플랫폼 데이터 형식으로, 구조화된 데이터를 직렬화하는 데 사용됩니다. 사실상 클라이언트와 서버 사이에서 요청을 바이너리 코드로 직렬화하여 전송하는 강력한 중개자 역할을 합니다.

이 메커니즘은 유연하고 효율적이어서 프로그래밍 언어 불가지론, 메시지 크기 감소, 빠른 구문 분석 및 전송을 동시에 지원합니다. Java를 사용하는 애플리케이션은 요청이 바이너리 언어인 바이너리로 변환되므로 Python을 사용하는 애플리케이션과 통신할 수 있습니다. 바이너리는 사람이 읽을 수는 없지만 JSON과 같은 텍스트 기반 형식보다 컴퓨터로 전송하고 해독하는 속도가 빠릅니다.

기본적으로 개발자는 ".proto" 접미사가 붙은 텍스트 파일을 만듭니다. 데이터 구조에 대한 모든 정보를 담고 있습니다. 이 정보는 스키마 기반 정보로, 데이터 구조에 대한 설명인 매개변수, 방법 및 가능한 아웃풋을 정의합니다. 예를 들어 "사용자"에 대한 항목이 있을 수 있으며, 이 데이터에는 "이름", "이메일 주소", "좋아하는 피자 토핑"이 포함됩니다.

Protobuf 문서에 따르면, 이것은 XML과 비슷하지만 "더 작고, 더 빠르고, 더 간단합니다. 데이터를 어떻게 구조화할지 한 번 정의하면 특별히 생성된 소스 코드를 사용하여 다양한 데이터 스트림과 다양한 언어를 사용하여 구조화된 데이터를 쉽게 쓰고 읽을 수 있습니다." Protobuf는 중개자로서 다양한 인증 및 보안 조치도 설치할 수 있습니다.

개발자는 Protoc이라는 컴파일러를 사용하여 C#, C++, Dart, Go, Java, Kotlin, Node.js, Objective-C, PHP, Python 및 Ruby 등 여러 지원 언어 중 하나로 코드를 생성할 수 있습니다. 이 코드는 일반적으로 클래스 또는 모듈을 포함하고, 바이너리로 직렬화 및 바이너리로부터 역직렬화를 처리하며, 데이터 교환의 복잡성을 추상화하는 등 다양한 기능을 수행합니다. 개발자는 네트워크 패키징, 마샬링, 호환성 및 구현을 위한 업데이트에 대해 걱정할 필요가 없으며, Protobuf가 모든 것을 처리합니다.

Protobuf의 스키마 기반 설계를 통해 개발자는 전체 시스템을 중단하지 않고도 기존 구조에 새 데이터 필드를 추가할 수 있습니다. 또한 새 데이터 필드를 추가한 후 이전 코드를 조정하는 등 지루한 API 관련 작업을 업데이트, 유지 관리 및 처리하는 데 필요한 수고를 크게 줄여줍니다. 즉, .proto 파일은 처음에 설정하는 데 시간과 노력이 다소 걸릴 수 있습니다.

HTTP/2는 컴퓨터와 서버가 정보를 교환하는 데 사용하는 전송 프로토콜로, 바이너리 형식을 사용하여 메시지를 전송하고, TCP 연결을 줄이며, 헤더 압축을 사용하는 등 이전 버전(HTTP/1.1)보다 빠르고 효율적입니다. 또한 멀티플렉싱, 즉 단일 연결에서 여러 개의 동시 스트림을 전송할 수 있는 기능도 지원합니다. gRPC는 채널이라는 것을 사용하여 이러한 여러 연결을 통해 여러 개의 스트림을 사용할 수 있도록 합니다. 메시지는 HTTP/2 데이터 프레임으로 전송되며, 각 프레임에는 여러 개의 gRPC 메시지가 포함될 수 있습니다.

gRPC는 클라이언트와 서버가 읽기/쓰기 스트림에서 독립적으로 메시지를 보낼 수 있는 양방향 스트리밍을 제공합니다. 이 방법은 서버와 클라이언트가 순차적으로 응답을 교환하거나 서버가 모든 클라이언트의 메시지가 수신될 때까지 기다렸다가 응답할 수 있는 등 모든 종류의 유연성을 허용합니다. 이 기능은 특정 애플리케이션에 따라 조정할 수 있습니다.

gRPC는 protoc이라는 컴파일러 도구를 사용하여 .proto 파일에 정의된 서비스 정의와 메시지 구조를 기반으로 다양한 언어로 클라이언트 및 서버 코드를 자동으로 생성합니다. 플러그인을 사용하여 더 많은 언어로 지원을 확장할 수 있습니다.

Protoc은 proto 정의에 정의된 언어로 데이터 접근 클래스를 생성합니다. 이러한 클래스는 [name]과 같은 필드에 대한 간단한 접근자와 구조를 원시 바이트로 직렬화 및 구문 분석하는 방법을 제공합니다^.1

gRPC는 데이터 전송을 위해 단항, 클라이언트 측 스트리밍, 서버 측 스트리밍 및 양방향 스트리밍의 4가지 방법 유형을 지원합니다.

gRPC에는 클라이언트와 서버 간의 데이터 교환을 암호화하고 사용자가 연결을 보호할 수 있도록 하는 TLS(전송 계층 보안)와의 통합 기능이 내장되어 있습니다.

gRPC는 플러그형 인증, 추적, 로깅, 지표, 로드 밸런싱, 상황 확인 등을 지원합니다. 

gRPC에는 4가지 유형의 방법이 있으며, 이는 gRPC 클라이언트와 gRPC 서버가 메시지를 주고받는 방식을 나타냅니다. 이러한 유형은 다음과 같습니다.

단항: 클라이언트가 단일 요청을 보내고 서버가 단일 응답으로 응답하는 간단한 호출입니다.

서버 측 스트리밍: 클라이언트가 하나의 요청을 보내면 서버가 여러 개의 응답으로 응답하는 호출입니다.

클라이언트 측 스트리밍: 클라이언트가 여러 요청을 보내고 서버가 단일 응답으로 응답하는 호출입니다. 서버는 처리 및 응답하기 전에 클라이언트 요청의 전체 스트림이 중지될 때까지 기다리도록 선택할 수 있습니다.

양방향 스트리밍: 클라이언트와 서버는 동시에 여러 통화를 주고받아 실시간 통신을 가능하게 합니다.

gRPC와 REST는 모두 API 설계에 일반적으로 사용되는 아키텍처 스타일입니다. 둘 다 클라이언트/서버 아키텍처를 따르고, HTTP 기반 통신에 의존하며, 상태 저장소가 없고 언어에 구애받지 않는 등 많은 유사점을 가지고 있습니다. 그러나 주요 측면도 다르기 때문에 각각 다른 사용 사례에 적합합니다.

데이터 형식: REST API는 JSON 및 XML과 같은 일반 텍스트 형식을 사용합니다. gRPC는 Protobuf를 사용하여 데이터를 바이너리로 인코딩합니다.

통신 패턴: gRPC는 단방향, 서버 스트리밍, 클라이언트 스트리밍, 양방향 스트리밍의 4가지 방법을 지원합니다. REST는 요청 및 응답의 단항 시스템을 사용합니다.

코드 생성: gRPC는 기본적으로 코드 생성 기능을 제공하지만, REST는 그렇지 않습니다. 다만 플러그인을 통해 생성은 가능합니다.

디자인 패턴: gRPC에는 호출 가능한 서버 작업이 서비스 또는 함수로 정의되는 서비스 지향 디자인이 있습니다. REST에서 디자인은 HTTP 방법을 사용하여 URL로 정의된 엔드포인트를 통해 서버 리소스에 액세스하는 리소스를 중심으로 합니다.

프로토콜: gRPC는 HTTP/2를 사용하는 반면 REST는 HTTP/1.1을 사용합니다.

결합: gRPC의 클라이언트와 서버는 긴밀하게 결합되어 있으므로 클라이언트와 서버 모두 동일한 미들웨어 프로토 파일에 액세스할 수 있어야 하며, 하나가 변경되면 다른 하나도 변경되어야 합니다. 반면 REST는 느슨하게 결합되어 있습니다. 이러한 독립성은 한 구성 요소의 변경 사항이 다른 구성 요소에 영향을 미치지 않음을 의미합니다.

gRPC는 분산 환경에서 여러 서비스를 연결하는 복잡한 API에 자주 사용됩니다. gRPC의 실시간 스트리밍 기능과 고성능 덕분에 gRPC는 마이크로서비스, 스트리밍 및 사물인터넷 클라이언트 연결을 비롯한 여러 사용 사례에 적합합니다.

gRPC는 고성능, 짧은 대기 시간, 대용량 데이터 처리 능력 및 실시간 양방향 스트리밍 능력으로 인해 마이크로서비스용 API를 만드는 데 자주 사용됩니다.

gRPC는 언어에 구애받지 않기 때문에 서로 다른 프로그래밍 언어로 작성된 서비스 간의 통신을 가능하게 합니다. 또한 Protobuf 정의는 마이크로서비스 데이터 무결성을 보호하는 데 도움이 되는 강력한 형식의 스키마를 제공합니다.

gRPC의 양방향 스트리밍 능력은 단일 네트워크 연결을 통해 클라이언트와 서버 간에 양방향으로 데이터를 동시에 스트리밍할 수 있다는 것을 의미합니다. 이 기능을 통해 gRPC는 화상 회의와 같은 진행 중인 프로세스 또는 사용자가 다른 데이터가 전송되는 동안 데이터 세트의 일부를 사용하려는 경우에 이상적입니다.

사물인터넷은 연결된 디바이스 또는 클라이언트의 네트워크를 의미합니다. IoT 기기(스마트 객체라고도 함)에는 스마트 온도 조절기와 같은 간단한 "스마트 홈" 디바이스, 스마트워치 및 RFID 지원 의류와 같은 웨어러블 기기, 복잡한 산업 기계 및 운송 시스템이 포함될 수 있습니다.² gRPC API는 이러한 기기 간의 일관된 데이터 교환을 용이하게 하는 데 자주 사용됩니다.

gRPC는 양방향 스트리밍 지원과 마이크로서비스 친화적 능력(그리고 CNCF 프로젝트로서의 지위) 덕분에 클라우드 기반 API에 점점 더 많이 사용되고 있습니다.

gRPC는 다양한 프로그래밍 언어로 클라이언트 라이브러리를 생성하는 데 사용됩니다. 이러한 라이브러리는 .proto 파일에 제공된 서비스 정의에 따라 생성되며, 서비스가 정의되면 gRPC는 선택한 프로그래밍 언어로 클라이언트 코드를 자동으로 생성합니다.

이 기능은 개발자의 작업을 간소화하여 개발자가 하위 수준 통신 코드가 아닌 애플리케이션 논리에 집중할 수 있도록 합니다.

gRPC는 고성능 요구 사항을 가진 API를 구축하는 조직과 개발자에게 많은 이점을 제공합니다. 다음과 같은 이점이 있습니다.

더 빠르고 효율적인 전송: gRPC의 고성능에 기여하는 몇 가지 요인이 있습니다. 우선 Protobuf 직렬화를 사용하면 메시지 크기가 줄어들고 더 작은 패키지를 더 빠르게 전송할 수 있습니다. 또한 바이너리는 JSON이나 XML과 같은 일반 텍스트 형식보다 더 효율적으로 구문 분석됩니다.

또한 gRPC는 HTTP/1.1보다 빠르고 효율적인 HTTP/2를 사용하므로 지연 시간과 대역폭 사용량이 더욱 줄어듭니다.

이식성 향상: gRPC는 프로토콜 버퍼(언어 및 플랫폼에 구애받지 않는 직렬화 메커니즘)를 사용하여 데이터 구조 및 RPC 인터페이스를 설명하므로 서로 다른 플랫폼에서 다양한 언어로 작성된 서비스 간의 통신을 사용하도록 설정하는 데 사용할 수 있습니다.

런타임 오류 감소: Protobuf는 강력한 타이핑을 제공하므로 확고하고 명시적으로 정의된 데이터 구조를 적용합니다. 강력한 타이핑은 일관성과 조기 오류 감지를 촉진하여 런타임 시 오류 발생 가능성을 줄입니다.

유연한 사용자 지정: 미들웨어에 대한 기본 지원으로 보안 및 인증 조치나 분석 도구와 같은 기능을 사용자 지정하고 추가할 수 있습니다.

gRPC에는 많은 장점이 있지만, 해결해야 할 과제도 있습니다. 예를 들어, 사용 편의성이 주요 고려 사항인 간단한 데이터 소스가 포함된 공개 API의 경우 gRPC로 인한 복잡성이 불필요할 수 있습니다. gRPC의 과제는 다음과 같습니다.

복잡성: gRPC에서 요구하는 대로 .proto 파일로 메시지 구조와 서비스를 정의하는 것은 XML 및 JSON과 같은 텍스트 기반 형식으로 작업하는 것보다 더 어려울 수 있습니다.

사용 편의성: gRPC, 프로토콜 버퍼, HTTP/2는 REST 작업에 익숙한 개발자에게는 가파른 학습 곡선을 제시할 수 있습니다.

디버깅: 바이너리 형식은 사람이 읽을 수 없기 때문에 gRPC 애플리케이션을 검사, 디버깅 및 기록하기 어려울 수 있습니다. 바이너리를 변환할 수 있는 도구가 있지만 XML이나 JSON에 비해 추가 단계가 필요합니다.

최신성 및 지원: gRPC는 REST와 같은 다른 인기 아키텍처 스타일만큼 오래되지 않았으며 커뮤니티 규모나 플러그인 및 문서 지원이 많지 않습니다. 새로운 프레임워크인 gRPC는 기존 스타일에 비해 사용할 수 있는 도구(예: 보안 스캐너 도구)가 더 적습니다.

브라우저 제한: 웹 브라우저는 기본적으로 gRPC 프로토콜을 지원하지 않으므로 브라우저 기반 애플리케이션에서 gRPC 서비스를 직접 호출할 수 없습니다. 이 문제를 해결하는 한 가지 방법은 gRPC-Web과 같은 프록시를 사용하는 것입니다. gRPC-Web은 기본적으로 브라우저의 HTTP와 gRPC 프로토콜 간의 변환 계층 역할을 합니다.

웹 애플리케이션은 브라우저 호환성에 맞게 조정된 gRPC 요청을 보내기 위해 gRPC-Web JavaScript 클라이언트 라이브러리를 사용하여 gRPC 호출을 시작합니다. 요청은 프록시 서버로 전송되며, 프록시 서버는 요청을 표준 gRPC 요청으로 변환하여 gRPC 백엔드 서버로 전달합니다. gRPC 서버는 요청을 처리하고 프록시 서버로 응답을 다시 보내고, 프록시는 클라이언트로 다시 전달하기 전에 응답을 다시 한 번 gRPC-Web 형식으로 변환합니다.