“Rest의 현실적인 대안” Grpc 프로토콜의 이해: 새로운 통신 방식의 등장

gRPC는 구글이 개방형 소스로 공개한 바이너리 프로토콜로, 원격 프로시저 호출을 위해 사용된다. 이 프로토콜은 REST와 비교하여 성능과 간편성 측면에서 대안으로 인기를 얻고 있다. gRPC는 HTTP/2를 이용하여 전이중(full duplex) 연결을 제공한다. 현재 브라우저에서 사용하기 위해서는 어댑터가 필요하지만, 백엔드 서비스에서는 가장 인기가 있다. gRPC는 특히 마이크로서비스에서 사용되며, 강력한 API 계약과 메서드 추상화를 통해 복잡성을 낮추는 데 도움이 된다. gRPC는 사전 작업이 더 필요하지만, 더 구조적인 접근 방식이 유리한 조직과 규모가 큰 프로젝트에 매력적일 수 있다. REST의 현실성 있는 대안으로서, gRPC는 최신 기술이고 원격 프로시저 호출에 사용된다. gRPC는 모든 주요 백엔드 언어와 플랫폼에서 서버 및 클라이언트용 키트를 제공하며, 여러 언어를 지원한다. 또한 gRPC 웹 프로젝트는 브라우저에서 사용할 수 있다. 이번에는 Node.js 서비스와 통신하는 Node.js 클라이언트를 만들어볼 것이다. 이를 통해 커뮤니케이션 채널의 양측을 모두 볼 수 있을 것이다. gRPC는 바이너리 프로토콜을 사용하며 HTTP/2에서 실행되며, 다양한 조합의 차단 및 스트리밍 요청을 지원한다. 예를 들면 요청/응답, 클라이언트 스트리밍, 서버 스트리밍, 그리고 전체 스트리밍 등이 있다. 이번 예제에서는 단일 상호작용인 요청/응답 상호작용을 살펴볼 것이다. gRPC는 이를 스트리밍과 구분하여 “단항(unary)” 상호작용이라고 한다.

노드 서비스 API 정의 만들기

API를 정의하기 위한 노드 서비스 API 정의 만들기
gRPC는 일반 텍스트로 서비스 정의를 만든 다음 이를 “스텁(stub)”으로 컴파일한다. 스텁은 애플리케이션에서 가져와서 서버와 클라이언트를 정의하는 데 사용하는 코드 라이브러리다. 기본적으로, 텍스트 정의는 엔드포인트와 해당 커뮤니케이션을 손쉽게, 사람이 읽을 수 있는 형식으로 정의한 다음 이를 애플리케이션 내에서 엔드포인트와 상호작용하는 데 사용하는 코드 라이브러리로 컴파일할 수 있게 해준다. 실제 I/O 작업은 모두 스텁이 하고, 코드는 API 정의에 대한 액세스 권한을 획득해 비즈니스 로직을 추가한다.

전체적인 이 흐름은 다른 RPC 프레임워크와 비슷하다. 학습을 위해 알아야 할 중요한 점은 모든 클라이언트와 서비스 사이의 동작이 이 서비스 정의를 중심으로 이뤄진다는 것이다. 이는 API 표면이며, 코드 내 서버와 클라이언트는 이 정의의 컴파일된 버전에서 실행된다. 서비스 정의를 유지관리하고 코드 변경과 함께 마이그레이션하기 위한 부가적인 단계에는 이론적으로 오버헤드가 따르고, 실제로도 그렇다. 다만 정의를 IDE의 빌드 프로세스 및 지원에 통합하면 프로세스의 부담을 줄일 수 있다.

먼저 <예시 1>과 같이 노드 기반 숫자 제곱 서비스를 위한 API 정의를 만들어 보자.

<예시 1> 노드 서비스를 위한 API 정의

syntax = “proto3”;
package myservice;

// Define the service
service NumberSquarer {
// Unary RPC method for squaring a number
rpc SquareNumber(Number) returns (Number) {}
}

// Define the message types
message Number {
int32 value = 1;
}

<예시 1>은 먼저 gRPC에 사용할 Protocol Buffers 프로토콜의 버전을 알려준다. 현재 최신 버전은 proto3이다. 이제 myservice라는 패키지를 정의한다. 그다음에는 두 개의 블록이 있는데 하나는 서비스이며 다른 하나에는 데이터 구조가 있다. 서비스의 이름은 NumberSquarer이고 SquareNumber라는 하나의 원격 프로시저가 있고 이 프로시저는 Number 형식을 받는다. 이 형식은 <예시 1>에 정의돼 있으며 SquareNumber도 반환 형식으로 Number를 사용한다. .

[B4] 프런트엔드를 위한 API 프로토콜, REST만이 답은 아니다. (with. gRPC, GraphQL)

노드 프로젝트 설정

새로운 노드 프로젝트를 시작하기 위해서는 <예시 2>의 단계를 따라야 한다. 이 단계에는 필요한 종속 항목이 포함되어 있다. 참고로 이 단계를 따르기 전에 노드/NPM을 설치해야 한다.

<예시 2> 새로운 gRPC 노드 프로젝트 시작

$ cd iw-grpc
$ npm init -y
$ npm install @grpc/proto-loader async google-protobuf @grpc/grpc-js.

REST API가 뭔가요?

정의를 사용해서 서버 만들기

정의를 사용하여 서버를 만드는 방법은 다음과 같습니다. 자바와 같은 몇 가지 플랫폼에서는 컴파일 과정이 빌드 프로세스에 필요하지만 자바스크립트에서는 런타임에 컴파일할 수 있습니다. /iw-grpc 디렉터리에서 예시 1에서 본 내용과 같은 service.proto 파일을 생성하십시오. 그런 다음 다음과 같이 이 정의를 사용하여 제곱 엔드포인트를 노출하는 노드 gRPC 서버를 시작하십시오.

– 예시 1에는 <예시 1에 대한 내용>이 들어가야 합니다.
– 예시 3에는 노드 gRPC 서버를 시작할 때 필요한 코드와 설정이 들어가야 합니다.

gRPC 사용, protocol buffers

노드 클라이언트

노드 클라이언트는 노드 서버가 실행되면 `<예시 4>`와 같이 서비스 정의를 사용하여 클라이언트를 빌드할 수 있습니다.

“`javascript
const grpc = require(‘@grpc/grpc-js’);
const protoLoader = require(‘@grpc/proto-loader’);

// 프로토버프 정의를 동적으로 로드합니다.
const packageDefinition = protoLoader.loadSync(‘service.proto’);
const { myservice } = grpc.loadPackageDefinition(packageDefinition);

// gRPC 클라이언트를 생성합니다.
const client = new myservice.NumberSquarer(‘localhost:50051’, grpc.credentials.createInsecure());

// 명령줄 인수에서 숫자를 읽어옵니다.
const number = parseInt(process.argv[2]);

// 요청 메시지를 생성합니다.
const request = { value: number };

// gRPC 단일 RPC 호출을 수행합니다.
client.SquareNumber(request, (err, response) => {
if (err) {
console.error(`에러 발생: ${err.message}`);
return;
}
console.log(`제곱된 숫자: ${response.value}`);
});
“`

클라이언트는 한 개의 숫자를 받고 (`process.argv[2]`) 서버를 사용하여 제곱한 값을 출력합니다. 클라이언트는 서버와 동일한 프로세스에서 서비스 정의를 로드합니다. 서버를 생성하는 대신 위 코드를 실행 중인 서버에 대한 참조를 통해 클라이언트 서비스를 생성합니다.

“`javascript
const client = new myservice.NumberSquarer(‘localhost:50051’, grpc.credentials.createInsecure());
“`

원격 프로시저 호출(RPC)은 간단하며, 클라이언트 객체에서 비동기 메서드를 호출하는 것처럼 보입니다. RPC는 요청, 응답 콜백 핸들러, 두 개의 인수를 받습니다. 클라이언트를 실행하려면 `$ node client.js 7`을 입력하면 됩니다. 다음과 같은 응답을 받게 됩니다.

“`
제곱된 숫자: 49 (서버가 실행 중인지 확인하세요!)
“`

이 예시의 코드는 서버에서 볼 수 있습니다.

What is RPC? gRPC Introduction.

다른 플랫폼

다른 플랫폼에서는 서비스 컴파일을 빌드 프로세스의 일부로 포함한 다음 컴파일된 인터페이스를 사용해서 엔드포인트 구현을 작성한다. 깃허브의 gRPC 리포지토리에 있는 예제를 클론하면 이 방식이 어떻게 작동하는지 살펴볼 수 있다. 예를 들어 자바 예제 중 하나를 보자. 서 지원되는 모든 플랫폼에 대해 이와 비슷한 예제와 퀵스타트를 찾을 수 있다. 브라우저 gRPC에 관심이 있는 사람에게는 grpc-web 프로젝트도 좋고, gRPC 안드로이드 프로젝트도 있다. 예시 5에서 gRPC 컴파일 단계를 자바용 그래들 빌드에 통합하는 방법을 볼 수 있다.

<예시 5> 자바 그래들 gRPC 빌드 샘플

protobuf {
protoc {
artifact = “com.google.protobuf:protoc:${protocVersion}”
}
plugins {
grpc {
artifact = “io.grpc:protoc-gen-grpc-java:${grpcVersion}”
}
}
generateProtoTasks {
all()*.plugins {
grpc {}
}
}
}

기본적으로 빌드에 generateProtoTasks 타겟을 추가하기만 하면 된다.

이 방식은 다른 플랫폼에서도 동일하게 적용될 수 있는데, 예제와 퀵스타트는 깃허브의 gRPC 리포지토리에서 찾을 수 있다. 브라우저에서 사용하려는 경우 grpc-web 프로젝트를 사용할 수 있으며, 안드로이드에서 사용하려는 경우 gRPC 안드로이드 프로젝트를 사용할 수 있다. 예시 5에서는 gRPC를 자바용 그래들 빌드에 통합하는 방법을 자세히 설명하고 있다.

Top 6 Most Popular API Architecture Styles

다른 플랫폼

여기서 살펴본 내용은 gRPC 사용의 맛보기 정도다. gRPC는 REST 공식과는 다르게 사용되며, 부가적인 컴파일 단계를 고려해야 한다는 점이 가장 큰 변화이다. 예를 들어, 노드 사례에서는 컴파일 추가가 간단하다. 그러나 보편적이고 익숙한 REST 대신 gRPC로 마이그레이션할 가치가 있는지 의문이 들 수 있다. 그러나 gRPC의 진정한 가치는 다양한 서비스가 대규모로 상호작용하는 고밀도 마이크로서비스 환경에서 잘 드러난다. 이 경우 대규모 조직은 명시적 RPC 계약이 제공하는 추가적인 엄격성의 이점을 얻게 되며, 바이너리 데이터 프로토콜의 성능 혜택은 마이크로서비스 아키텍처 전체에 영향을 미친다. 빠르게 움직이는 스타트업이라고 해서 gRPC가 적합하지 않은 것은 아니다. 다만, 부가적인 구성을 채택할 의지가 있는지, 성능상의 이득이 필요한지, 개발자 채용과 교육에 필요한 추가적인 노력을 이해하고 있는지 스스로 확인해야 한다. 물론, gRPC 방식이 마음에 든다면 당장 실험을 시작하기에 충분히 합당한 이유가 된다.

REST API 란 무엇입니까?