gRPC란? gRPC vs REST / Protobuf, Profo file

이번 글은 gRPC란 무엇인지, REST와 어떤 차이점이 있는지에 대한 내용입니다.

📌왜 gRPC를 써야 할까? (gRPC vs REST)

• REST API는 payload가 크고 , 주고 받는 Message format이 고정되어 있지 않다.
  • Server-Client간 상호 협의가 자주 필요하며, 규격이 바뀔 때 마다 협의를 해야 한다.
• REST API(HTTP 1.1)는 모든 Request마다 TCP 연결을 해야 하지만, HTTP 2를 기반으로 하는 gRPC는 한번의 연결로 여러 요청을 처리 할 수 있다.

✔️HTTP 1.1 vs HTTP 2

• HTTP/1.1은 클라이언트의 요청이 올 때 마다 서버가 응답을 하는 구조로, 매 요청마다 connection을 생성해야 한다.
• HTTP2는 한 connection으로 동시에 여러 메시지를 주고 받을 수 있고, header를 압축해서 중복 제거 후 전달하기 때문에 효율적이다.

 

📌REST(REpresential State Transfer)

• HTTP/1.1을 기반으로 URI를 통해 모든 자원(Resource)를 명시하고 HTTP Method를 통해 처리하는 아키텍처이다.
• 장점
  • 자원을 표현하기 직관적이다.
  • HTTP를 그대로 계승하였기 때문에 별도 작업 없이도 쉽게 사용할 수 있다.
• 단점
  • parameter와 응답 값이 명시적이지 않다.
  • HTTP 메소드의 형태가 제한적이기 때문에 세부 기능 구현에 제약이 있다.
  • JSON을 추가 파싱하고 형변환하는 작업이 필요하다.

📌gRPC(google Remote Procedure Call)란?

• google에서 개발한 오픈소스 RPC(Remote Procedure Call) 프레임워크이다.
• PB(protocol Buffer) 기반 Serizlaizer에 HTTP/2를 결합해 RPC 프레임워크를 만들었다.
• HTTP/2를 사용하는것과 프로토콜 버퍼로 데이터를 전달한다는 특징이 있다.
• Proto File만 배포하면 환경과 프로그래밍 언어에 구애받지 않고 데이터 통신이 가능하다.

📍RPC(Remote Procedure Call)란

• 네트워크로 연결된 서버 상의 프로시저(함수, 메서드 등)을 원격으로 호출할 수 있는 기능이다.
• 통신이나 call 방식에 신경쓰지 않고 원격지의 자원을 내것 처럼 사용할 수 있다.
• C++, Java, Pytho, Go, PHP .. 등의 많은 언어를 지원한다.
• Stub : 서버와 클라이언트가 서로 다른 주소 공간을 사용하기 때문에, 함수 호출에 사용된 매개변수를 꼭 변환해주어야 한다. 이 변환을 담당하는 것이 Stub이다.

📍ProtoBuf(Protocl Buffer, 프로토콜 버퍼)

• Protocol Buffer는 google에서 개발한 구조화된 데이터를 직렬화 하는 기법이다.
• ⚠️직렬화란?
  • 데이터 표현을 바이트 단위로 작업하는 기법
• JSON의 경우 모든 정보를 text로 저장하기 때문에 용량이 많이 소요되는데에 비해, protocol buffer는 필드 번호, 필드 유형 등을 1byte로 받아서 식별하고, 주어진 Length만큼만 읽도록 하기 때문에 더 적은 용량으로 통신이 가능하다.

 

📍Proto File

[프로토 파일의 구성 요소]

✔️Message and Field

• 주고 받을 data를 message라는 것으로 정의한다.

syntax = "proto3";

message SearchRequest{
	string query = 1;
	int32 page_number = 2;
	int32 result_per_page = 3;
	repeated int32 result_per_page_2 = 4 [packed=true];
}

• Naming : message이름을 CamelCase, field 이름은 under_bar 형태로 작성하는 것이 권장된다.
• Field Tag(=Field Number) : 필드들이 가지고 있는 고유한 번호로서, Encoding 이후 Binary Data에서 필드를 식별하는데 사용된다.
  • 필드 번호가 1~15번일 때는 1byte, 16~2047일 때는 2byte를 Tag로 가져가기 때문에, 자주 호출되는 필드에 대해서는 1~15로 저장해두는 것이 좋다.
• Field Rule
  • repeated : 임의 반복 가능한 필드 (번호 및 값의 순서는 보존)
  • [packed = true] 옵션 : key-value 쌍 형태에서 value만 반복

✔️Package

• message type 이름을 구분하기 위해 사용한다.
• package를 명시함으로써 필드와 명확히 구분이 가능해진다.

package foo.bar;
message Open{
	//...
}
message Foo{
	foo.bar.Open open = 1;
}

✔️Service

• RPC를 통해 서버가 클라이언트에게 제공할 함수의 형태를 정의한다.
• stream option을 줘서 양방향 Streaming RPC를 구현할 수 있다.

service SearchService{
	rpc Search(stream SearchRequest) returns(stream SearchResponse);
}

📌gRPC의 장점

📍성능

• Protobuf를 이용하기 때문에 서버와 클라이언트에서 매우 빠르게 직렬화한다.
• gRPC는 HTTP2로 설계되었기 때문에 훨씬 빠르다.
  • HTTP2는 HTTP1과 달리 한 connection에서 여러 요청을 처리할 수 있고, header의 중복 값을 제거해 Payload를 줄였다.

📍코드 생성

• gRPC 개발의 핵심 파일은 gRPC 서비스 및 메시지의 계약을 정의하는 .proto 파일이다.
• 서버와 클라이언트 간에 .proto 파일을 공유해 사용할 수 있기 때문에 프로그램 개발 시간이 절약된다.

📍엄격한 사양

• JSON을 사용하는 HTTP API는 공식 사양이 없기 때문에 형식을 논의하며 사용해야 한다.
• gRPC는 플랫폼 및 구현에 상관 없이 따라야 하는 서비스 형식에 대한 지침이 정해져있어 논쟁이 불필요하다.
  • https://github.com/grpc/grpc/blob/master/doc/PROTOCOL-HTTP2.md

📍스트리밍

• gRPC 서비스는 모든 스트리밍 조합을 지원한다.
  • 단항(스트리밍 없음)
  • 서버-클라이언트 스트리밍
  • 클라이언트-서버 스트리밍
  • 양방향 스트리밍

📌gRPC의 약점

📍제한된 브라우저 지원

• 현재 브라우저 API가 HTTP/2 엑세스를 지원하지 않기 때문에 gRPC-WEB을 사용하여 브라우저에서 서버로 직접 통신을 할 수는 다.
• 하지만 응답 변환 Proxy 서버를 통해 요청 및 응답을 브라우저가 처리할 수 있도록 변환 할 수 있습니다.

📍사람이 읽을 수 없다.

• HTTP API 요청은 텍스트로 전송되며, 사람이 읽고 만들 수 있다.
• gRPC 메시지는 protobuf로 인코딩되기 때문에 사람이 읽을 수 없다. → 네트워크에서 Protobuf를 분석하려면 추가적인 도구가 필요하다.

[Reference]

gRPC

gRPC 서비스와 HTTP API 비교

[NBP 기술&경험] 시대의 흐름, gRPC 깊게 파고들기 #1