개발자 / 애플리케이션

“REST의 현실적인 대안” gRPC 프로토콜의 이해

Matthew Tyson | InfoWorld 2023.08.29
gRPC는 구글이 오픈소스로 공개한 원격 프로시저 호출을 위한 바이너리 프로토콜이다. 성능과 간편함으로 인기를 얻은 REST의 대안이다. gRPC는 HTTP/2에 대한 전이중(full duplex) 연결을 제공한다. 현재 브라우저에서 사용할 때는 어댑터가 필요하며, 백엔드 서비스로 가장 인기가 높다. gRPC는 특히 강력한 API 계약과 메서드 추상화가 복잡성을 낮추는 데 도움이 되는 마이크로서비스에서 많이 사용된다. gRPC는 일반적인 REST 스택에 비해 사전 작업이 더 많이 필요하지만 더 구조적인 접근 방식이 유리한 조직과 규모가 큰 프로젝트에 매력적일 수 있다.
 
ⓒ Getty Image Bank
 

REST의 현실성 있는 대안, gRPC

gRPC는 REST의 현실성 있는 대안으로, 원격 프로시저 호출에 있어 최신 기술이다. 여러 언어를 지원하며 모든 주요 백엔드 언어와 플랫폼에서 서버 및 클라이언트용 키트를 제공한다. 브라우저에서 사용하기 위한 gRPC 웹 프로젝트도 있다. 

여기서는 바로 코드로 들어가 Node.js 서비스와 통신하는 Node.js 클라이언트를 만들어본다. 이를 통해 커뮤니케이션 채널의 양측을 모두 볼 수 있을 것이다. gRPC는 HTTP/2에서 실행되며 여러 차단 및 스트리밍 요청의 조합(요청/응답, 클라이언트 스트리밍, 서버 스트리밍, 전체 스트리밍 이중)을 지원하는 바이너리 프로토콜을 사용한다. 여기서 살펴볼 간단한 예제는 요청/응답 상호작용이다. gRPC에서는 이를 스트리밍과 구분하여 “단항(unary)” 상호작용이라고 한다. 
 

노드 서비스 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를 사용한다. 
 

노드 프로젝트 설정 

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

<예시 2> 새 gRPC 노드 프로젝트 시작
$ cd iw-grpc
$ npm init -y
$ npm install @grpc/proto-loader async google-protobuf @grpc/grpc-js
 

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

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

<예시 3> 노드 gRPC 서버 
const grpc = require('@grpc/grpc-js');
const protoLoader = require('@grpc/proto-loader');

// Load the protobuf definition dynamically
const packageDefinition = protoLoader.loadSync('service.proto');
const { myservice } = grpc.loadPackageDefinition(packageDefinition);

// Implement the NumberSquarer service
const server = new grpc.Server();

function squareNumber(call, callback) {
  const number = call.request.value;
  const squaredValue = number * number;

  callback(null, { value: squaredValue });
}

server.addService(myservice.NumberSquarer.service, {
  SquareNumber: squareNumber,
});

// Start the gRPC server
const port = 50051;
server.bindAsync(`0.0.0.0:${port}`, grpc.ServerCredentials.createInsecure(), (err, port) => {
  if (err) {
    console.error(`Failed to bind gRPC server: ${err}`);
    return;
  }
  console.log(`gRPC server is listening on port ${port}`);
  server.start();
});

<예시 3>은 (가져오기 이후) 크게 서비스 정의 로드, 엔드포인트 로직 구현, 서버 시작의 세 부분으로 구성된다. 패키지 내에 서비스를 정의했으므로 패키지를 로드한 다음 여기서 서비스를 가져온다.
 
const { myservice } = grpc.loadPackageDefinition(packageDefinition);

그다음 새 gRPC 서버를 만들고 제곱 메서드를 정의하고 서버 객체를 사용해서 새 메서드를 SquareNumber 엔드포인트에 바인딩한다. 마지막으로, 포트 50051에서 수신 대기하는 서버를 시작한다. createInsecure 메서드를 사용하는데, 이는 HTTPS가 아닌 HTTP를 사용한다는 것을 의미한다. 이제 $ node server.js를 입력해서 이 서버를 시작할 수 있다. 
 

노드 클라이언트 

일단 노드 서버가 실행되면 <예시 4>와 같이 서비스 정의를 사용해서 클라이언트를 빌드할 수 있다. 

<예시 4> 노드 클라이언트 
const grpc = require('@grpc/grpc-js');
const protoLoader = require('@grpc/proto-loader');

// Load the protobuf definition dynamically
const packageDefinition = protoLoader.loadSync('service.proto');
const { myservice } = grpc.loadPackageDefinition(packageDefinition);

// Create a gRPC client
const client = new myservice.NumberSquarer('localhost:50051', grpc.credentials.createInsecure());

// Read the number from the command line argument
const number = parseInt(process.argv[2]);

// Create the request message
const request = { value: number };

// Make the gRPC unary RPC call
client.SquareNumber(request, (err, response) => {
  if (err) {
    console.error(`Error: ${err.message}`);
    return;
  }
  console.log(`Squared number: ${response.value}`);
});
  
하나의 숫자에 대한 클라이언트는 명령줄 인수를 받고(process.argv[2]) 서버를 사용해서 제곱을 출력한다. 서버와 동일한 프로세스에 따라 서비스 정의를 로드한다. 서버를 만드는 대신 다음을 통해 실행 중인 서버를 참조해 클라이언트 서비스를 생성한다. 
 
const client = new myservice.NumberSquarer('localhost:50051', grpc.credentials.createInsecure());.

원격 프로시저 호출은 간단해서, 클라이언트 객체에서 비동기 메서드를 호출하는 것처럼 보인다. RPC는 요청, 응답 콜백 핸들러, 두 개의 인수를 받는다. 클라이언트를 실행하려면 $ node client.js 7을 입력하면 된다. 다음과 같은 응답을 받는다. 
 
Squared number: 49. (Make sure the server is running!)
  
이 예시의 코드는 여기서 볼 수 있다. 
 

다른 플랫폼 

다른 플랫폼에서는 서비스 컴파일을 빌드 프로세스의 일부로 포함한 다음 컴파일된 인터페이스를 사용해서 엔드포인트 구현을 작성한다. 깃허브의 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 사용의 맛보기 정도다. 광범위하게 사용되는 REST 공식과는 다르지만 생각의 회로를 바꾸기가 그렇게 어렵지는 않다. 가장 큰 변화는 부가적인 컴파일 단계를 고려해야 한다는 점이다. 노드 사례에서 살펴본 바와 같이 컴파일 추가는 간단하다. 

보편적이고 개발자에게 익숙한 REST를 두고 굳이 gRPC로 마이그레이션할 가치가 있냐는 의문을 당연히 품을 수 있다. 하지만 gRPC의 진정한 가치는 다양한 서비스가 대규모로 상호작용하는 고밀도 마이크로서비스 환경에서 사용될 때 잘 드러난다. 이 경우 대규모 조직은 명시적 RPC 계약이 제공하는 부가적인 엄격성의 이점을 얻게 되고, 바이너리 데이터 프로토콜이 얻는 성능 혜택은 마이크로서비스 아키텍처 전체에 걸쳐 확대된다. 

그렇다고 빠르게 움직이는 스타트업 등에는 gRPC가 적합하지 않다는 말은 아니다. 다만 부가적인 구성을 채택할 의지가 있는지, 성능상의 이득이 필요한지, 그리고 개발자 채용과 교육에 필요한 부가적인 노력을 이해하고 있는지를 스스로 확인해야 한다. 물론 gRPC 방식이 그냥 마음에 든다면, 그것만으로도 당장 실험을 시작하기에 충분히 합당한 이유가 된다.
editor@itworld.co.kr
 Tags gRPC REST
Sponsored

회사명 : 한국IDG | 제호: ITWorld | 주소 : 서울시 중구 세종대로 23, 4층 우)04512
| 등록번호 : 서울 아00743 등록발행일자 : 2009년 01월 19일

발행인 : 박형미 | 편집인 : 박재곤 | 청소년보호책임자 : 한정규
| 사업자 등록번호 : 214-87-22467 Tel : 02-558-6950

Copyright © 2024 International Data Group. All rights reserved.