대부분의 소프트웨어 응용 프로그램은 여러 가지 이유로 다른 코드에 연결할 수 있어야 합니다. 이것은 통합에서 새로운 기능 추가에 이르기까지 무엇이든 될 수 있습니다. 소프트웨어가 다른 응용 프로그램과 연결되고 다른 프로그램과의 통합을 보장하기 위해 개발자는 API를 사용합니다. 이것이 대부분의 소프트웨어에 응용 프로그래밍 인터페이스가 필요한 이유입니다. API는 시스템 간의 브리지 역할을 통해 개인이 다양한 웹 서비스에 액세스할 수 있도록 합니다. 따라서 프로젝트에 API를 제공할 적절한 기술을 선택하는 것이 중요합니다.
사용자와 애플리케이션 또는 플랫폼을 공유하려는 조직은 API를 사용해야 합니다. API를 개발하고 미세 조정하여 애플리케이션에 완벽하게 맞추는 방법에는 여러 가지가 있습니다. 프로그래머가 API를 설계하는 데 사용하는 최신 방법 중 하나는 gRPC 입니다. gRPC 가 무엇이며 장단점을 살펴보겠습니다.
gRPC 란 무엇입니까?
gRPC 는 Google Remote Procedure Call 을 나타냅니다. gRPC 는 확장 가능하고 빠른 API를 만드는 데 사용되는 오픈 소스 RPC 프레임워크입니다. 네트워크로 연결된 시스템의 개발과 gRPC 클라이언트와 서버 애플리케이션 간의 개방형 통신을 가능하게 합니다. gRPC 는 Google, IBM, Netflix 등을 비롯한 여러 최고의 기술 회사에서 채택했습니다. gRPC 프레임워크는 최적의 API 보호, 고성능 원격 프로시저 호출 및 확장성을 위해 HTTP/2, 프로토콜 버퍼 등과 같은 최첨단 기술 스택에 의존합니다.
RPC 란 무엇입니까?
RPC 및 REST( Representational State Transfer)는 역사적으로 API를 구축하는 두 가지 별도의 접근 방식이었습니다. 또한 SOAP 및 GraphQL 과 같은 프로토콜도 이러한 목적으로 사용됩니다. 원격 프로시저 호출을 사용하면 다른 장치에서 실행될 수 있지만 로컬에서 실행되는 것처럼 소프트웨어를 작성할 수 있습니다.
API를 설계하는 데 가장 일반적으로 사용되는 프레임워크입니다. 일반적인 HTTP 프로토콜 호출과 달리 RPC는 클라이언트-서버 상호 작용의 기본 방법으로 함수 호출을 사용합니다. RPC 는 교환이 간단하고 내용이 가볍기 때문에 API를 생성하는 생산적인 기술입니다. gRPC 서비스도 이 통신 아키텍처를 모방합니다. RPC 는 IDL ( Interface Definition Language)을 사용하여 호출될 데이터 유형과 메서드를 축소합니다. RPC에서 채택한 gRPC 서비스는 최근 몇 년 동안 매우 인기를 얻었습니다.
gRPC 서비스가 개발된 이유는 무엇입니까?
더 많은 기업이 통합 채널을 열면서 그러한 소프트웨어를 연결하는 것이 점점 더 어려워지고 있습니다. RPC API는 내부 세부 사항을 공개할 수 있기 때문에 통합하기 어렵고 배포하기가 위험합니다. 그들은 많은 프로그래밍 언어로 개발되었으며 기본 프레임워크와 밀접하게 연결되어 있습니다.
이 문제가 해결되었고 2000년 REST API 가 출시되었을 때 API 접근성이 향상되었습니다. 특히 GET, PUT, POST 등과 같은 표준 HTTP 기술을 사용하여 자산을 통해 간접적으로 정보를 검색할 수 있는 일관된 방법을 사용자에게 제공했습니다. REST API 와 RPC 의 주요 차이점은 RPC 를 사용하면 프로세스가 처리되지만 다양한 시스템의 프로세스가 무엇인지 예측하기가 쉽지 않다는 것입니다.
REST API 는 많은 응용 프로그램을 처리하기 위한 향상된 형식을 제공했음에도 불구하고 많은 양의 메타데이터를 생성했기 때문에 간단하고 가벼운 RPC 를 완전히 대체할 수 없었습니다. 결과적으로 Facebook의 GraphQL 과 Google의 gRPC 서비스가 등장했습니다.
Google은 2015년에 RPC 프레임워크에 추가하여 gRPC 를 구축하여 다양한 기술로 만들어진 수많은 마이크로서비스 아키텍처를 연결합니다. gRPC 는 원래 Google의 핵심 인프라와 밀접하게 관련되어 있었지만 결국 공개 소스가 되어 일반 대중이 사용할 수 있도록 표준화되었습니다.
gRPC 개념 개요
JSON 및 XML에 비해 성능이 높고 API 무결성이 더 뛰어난 첨단 기술의 활용은 gRPC 의 생성과 인기를 책임지고 있습니다. 알아야 할 몇 가지 gRPC 개념은 다음과 같습니다.
프로토콜 버퍼
Protobuf 라고도 하는 프로토콜 버퍼는 애플리케이션을 간단하게 정의하고 클라이언트 라이브러리의 코드 생성을 자동으로 수행하는 직렬화 또는 역직렬화 표준입니다. 최신 버전인 proto3 는 사용이 더 간편하고 gRPC 에 대한 최신 기능을 제공합니다.
.Proto 파일은 gRPC 클라이언트와 서버 메시지 간의 gRPC 서비스 및 통신을 가능하게 합니다. .proto 파일은 Protobuf 컴파일러 protoc 에 의해 실행될 때 메모리에 로드됩니다. 이 컴파일러는 메모리 내 구조를 사용하여 바이너리 데이터를 직렬화 및 역직렬화하는 gRPC 클라이언트 및 gRPC 서버 애플리케이션을 빌드합니다. 각 통신은 gRPC 에서 코드 생성 후 사용자와 원격 서비스 간에 송수신됩니다.
데이터가 이진 형식으로 변환되고 암호화된 신호가 더 작기 때문에 Protobuf 를 사용한 구문 분석은 gRPC 에 대해 더 적은 CPU 전력을 사용합니다. 따라서 휴대폰과 같이 CPU 가 약한 컴퓨터에서도 gRPC 를 사용하면 메시지가 더 빨리 전송됩니다.
HTTP/2
gRPC 서비스는 제한 사항이 적은 HTTP/1.1 버전인 HTTP/2를 기반으로 합니다. 이전 HTTP 프로토콜과 함께 작동하지만 HTTP/2에는 gRPC 에 대한 몇 가지 정교한 기능이 있습니다. 여기에는 각 HTTP/2 쿼리와 응답을 더 작은 메시지로 나누고 이진 형식으로 프레임하여 메시지 전달을 개선하는 이진 프레이밍 계층이 포함됩니다. 또한 gRPC 는 양방향 전이중 스트리밍에서 클라이언트 및 gRPC 서버의 여러 요청 및 응답을 지원합니다.
HTTP/2에는 진행 중인 패킷을 버퍼링하는 데 필요한 RAM 을 정밀하게 제어할 수 있는 흐름 제어 방법이 있습니다. 또한 gRPC 서비스에 대한 헤더 압축을 제공합니다. HTTP/2의 모든 것은 전송 전에 암호화되어 고성능 원격 프로시저 호출을 제공하는 헤더를 포함합니다. gRPC 는 HTTP/2를 사용하여 비동기 및 동기 처리를 모두 제공하여 다양한 대화형 및 스트리밍 RPC 유형을 실행할 수 있습니다.
HTTP/2의 이러한 모든 특성 덕분에 gRPC 서비스는 더 적은 리소스를 사용할 수 있으므로 클라우드 기반 애플리케이션과 gRPC 서비스 간의 응답 시간이 빨라지고 모바일 장치에서 작동하는 gRPC 클라이언트의 배터리 수명이 늘어납니다.
스트리밍
gRPC 가 지원하는 중요한 아이디어는 단일 요청 내에서 여러 프로세스의 실행을 허용하는 스트리밍입니다. gRPC 는 하나의 TCP ( Transmission Control Protocol) 연결을 통해 여러 응답 또는 요청을 동시에 보내거나 받을 수 있는 HTTP/2의 다중화 기능을 통해 이를 가능하게 합니다. 기본 스트리밍 형식은 서버 스트리밍 RPC, 클라이언트 스트리밍 RPC 및 양방향 스트리밍 RPC 입니다.
채널
단일 요청 연결에서 수많은 동시 스트림을 허용하는 HTTP/2 스트림과 gRPC 가 있는 채널은 여러 요청에서 여러 연속 스트림을 지원합니다. 클라이언트 스텁을 구축하고 특정 IP 및 포트의 gRPC 서버에 연결하는 메커니즘을 제공하는 데 사용됩니다.
gRPC 아키텍처
gRPC 아키텍처는 gRPC 클라이언트와 gRPC 서버로 구성됩니다. 모든 gRPC 클라이언트 서비스에는 활성 원격 프로세스가 포함된 인터페이스와 유사한 자동 생성 파일 또는 스텁이 포함되어 있습니다. gRPC 클라이언트는 gRPC 서버 메시지에 전달할 인수가 포함된 스텁에 대한 로컬 프로시저 호출을 시작합니다. 그런 다음 gRPC 클라이언트 스텁은 Protobuf 마샬링 절차를 사용하여 인수를 직렬화한 후 로컬 컴퓨터의 로컬 클라이언트 시간 단위로 쿼리를 보냅니다.
운영 체제는 HTTP/2 프로토콜을 사용하여 원격 서버 컴퓨터와 통신합니다. 서버의 OS는 메시지를 수락하고 들어오는 매개변수를 디코딩한 후 Protobuf 를 사용하여 적절한 작업을 호출하는 서버 스텁 프로세스를 호출합니다. 그런 다음 클라이언트 전송 계층은 서버 스텁에서 암호화된 응답을 수신합니다. gRPC 클라이언트 스텁이 응답 메시지를 수신하고 제공된 인수를 래핑 해제한 후 실행이 호출자에게 다시 전달됩니다.
gRPC 의 장점
gRPC 는 다른 API 설계 메커니즘에 비해 몇 가지 장점이 있습니다. gRPC 는 또한 RPC 구조를 개선합니다. 다음은 gRPC 서비스의 가장 두드러진 이점입니다.
- 고성능 원격 프로시저 호출
Protobuf 및 HTTP/2를 사용하는 gRPC 서비스는 REST+JSON 상호 작용보다 최대 10배 높은 성능과 API 보호를 제공합니다. 서버 푸시, 다중화 및 헤더 압축을 사용하여 HTTP/2는 gRPC 서비스에 대한 고성능 순위를 제공합니다. 멀티플렉싱이 HOL(head-of-line) 지연을 없애는 반면, 서버 푸시를 사용하면 HTTP/2가 필요하기 전에 자료를 서버에서 클라이언트로 푸시할 수 있습니다. 메시지는 HTTP/2를 사용하여 더 효과적으로 압축되어 gRPC 서비스로 더 빠르게 로드됩니다.
- 스트리밍
스트리밍 gRPC 서비스에 대한 서비스 설명에는 이미 클라이언트 또는 서버 엔드 스트리밍 원칙이 포함되어 있습니다. 결과적으로 gRPC 클라이언트 및 스트리밍 서비스 구축이 훨씬 쉬워졌습니다.
- 코드 생성
gRPC 클라이언트 및 gRPC 서버 프로그램에 대한 코드 생성은 gRPC 웹 접근 방식의 핵심 구성 요소입니다. .proto 파일에서 코드 생성을 위해 gRPC 모듈은 .protoc 컴파일러를 사용합니다. Protobuf 형식은 데이터 형식과 애플리케이션 끝점을 모두 정의하는 데 사용되는 gRPC 의 코드 생성을 통해 제어됩니다. 클라이언트 측 네트워크 스텁과 서버 측 스켈레톤을 생성할 수 있어 gRPC 서비스에서 다양한 서비스로 프로그램을 설계하는 데 필요한 시간을 줄일 수 있습니다.
- 상호 운용성
Java, Ruby, Go, C# 등과 같은 수많은 시스템 및 프로그래밍 언어가 gRPC 리소스 및 라이브러리에서 지원됩니다. 이러한 프로그래밍 언어를 사용하여 개발자는 gRPC 와의 완전한 플랫폼 간 호환성을 활용하면서 성능이 뛰어난 앱을 만들 수 있습니다. 이는 Protobuf 바이너리 배선 형식과 거의 모든 시스템에 대한 효과적인 코드 생성 덕분입니다.
- 보안
API 보안은 TLS 종단 간 암호화 세션을 통해 HTTP/2를 사용하는 gRPC 에서 보장됩니다. gRPC 는 서버와 gRPC 클라이언트 간의 데이터 암호화 및 인증을 위해 SSL/TLS 채택을 촉진합니다.
- 생산성 및 사용성
gRPC 는 완전한 RPC 대안이므로 광범위한 시스템 및 언어에서 문제 없이 작동합니다. gRPC 는 또한 수동으로 생성되는 많은 필수 상용구 코드와 함께 훌륭한 도구를 가지고 있습니다. 엔지니어는 이제 gRPC 로 시간을 크게 절약할 수 있으므로 핵심 기능에 더 집중할 수 있습니다.
gRPC 의 단점
gRPC 단점이 결국 해결되기를 바랄 수 있지만, 현재 사용에 몇 가지 문제가 있습니다. 알아야 할 gRPC 의 몇 가지 단점은 다음과 같습니다.
- 성숙의 부족
기술의 발전은 채택에 상당한 장벽이 될 수 있습니다. 이는 gRPC 를 사용하는 동안에도 명확합니다. GraphQL 의 피어 중 하나인 GraphQL은 StackOverflow 에 대해 14k 이상의 쿼리를 가지고 있는 반면 gRPC 는 현재 4k 미만입니다. gRPC 커뮤니티는 HTTP/2 및 Google 외부의 프로토콜 버퍼에 대한 프로그래머 지원이 많지 않기 때문에 모범 사례, 솔루션 및 성공에 대한 지식이 부족합니다. 그러나 gRPC 커뮤니티가 확장되고 새로운 개발자가 유입됨에 따라 이는 결국 진화할 것입니다.
- 제한된 브라우저 지원
현재 gRPC 웹 브라우저는 HTTP/2 프레임을 처리할 수 없으므로 gRPC 웹은 주로 HTTP/2에 의존하기 때문에 브라우저에서 gRPC 서비스를 효과적으로 호출할 수 없습니다. 결과적으로 몇 가지 단점이 있는 gRPC 와 함께 프록시를 사용해야 합니다.
- 사람이 읽을 수 없음
XML 및 JSON과 달리 Protobuf 파일은 데이터가 바이너리 형식으로 압축되기 때문에 사람이 읽을 수 없습니다. 개발자는 페이로드를 평가하고, 문제 해결을 수행하고, 수동 쿼리를 생성하기 위해 서버 반사 프로토콜 및 gRPC 명령 프롬프트와 같은 추가 도구를 사용해야 합니다.
- 가파른 학습 곡선
JSON을 주로 사용하는 REST 및 GraphQL과 달리 프로토콜 버퍼에 익숙해지고 HTTP/2 마찰에 대처하는 방법을 찾는 데 시간이 걸립니다.
AppMaster 는 어떻게 도움이 되나요?
No-code 생성은 사람들이 프로그래밍을 보는 방식을 바꾸고 있습니다. No-code 생성 없이 사람들이 코드 생성을 통해 소프트웨어를 더 빨리 배우고 만들 수 있습니다. AppMaster 와 같은 no-code 생성 플랫폼을 사용하면 애플리케이션에 대한 코드 생성이 더 간단해집니다. 코드 생성이 보호되고 생성한 코드가 전적으로 귀하에게 속하기 때문에 소유권 문제도 없습니다. AppMaster 를 사용하면 클라이언트 및 서버 응용 프로그램을 더 빠르고 쉽게 만들 수 있습니다.
AppMaster의 no-code 생성 플랫폼을 통해 개발자는 gRPC 프로토콜을 사용하여 백엔드 마이크로서비스 아키텍처 간에 요청할 수 있습니다. 내년에 우리는 API를 gRPC 웹 및 gRPC 모바일 애플리케이션 모두에 포함하여 gRPC 지원을 확장할 것입니다.
결론
gRPC 서비스에는 비즈니스와 개발자에게 매력적인 몇 가지 이점이 있지만 마지막으로 REST 또는 SOAP와 같은 다른 서비스보다 gRPC 서비스를 사용할지 여부는 애플리케이션에 따라 다릅니다. 일부 소프트웨어는 gRPC 와 함께 고성능 이점을 가지지만 다른 소프트웨어는 대안에 더 적합할 수 있습니다. gRPC 서비스의 단점과 장점을 이해하고 작동 여부를 결정해야 합니다.
