gRPC

해당 글은 gRPC - 알고 나면 쉬움 - https://www.youtube.com/watch?v=uwrR5e5_FH8 를 보고 정리한 글 입니다.

gRPC

• 구글에서 만든 RPC 프레임워크.

RPC

• remote procedure call의 약자.
• 다른 컴퓨터에 있는 어떤 기능을 자기 기능인 것처럼 실행할 수 있도록 하는 프로토콜.

gRPC

• 여러 RPC 프레임워크 중 하나.
• 높은 성능.
• 강력한 개발자 커뮤니티.
• 풍부한 도구, 라이브러리.
• 최근에 가장 널리 사용되는 RPC.

REST API vs gRPC

예시)
도서 대여 서비스의 서버에서 마이크로서비스로 도서 관리, 대여 및 반납, 리뷰 관리, 검색, 알림 등으로 구성됩니다.
이런 마이크로서비스들 사이에서도 요청과 응답을 통한 지속적인 소통이 필요합니다. REST API 에서는 보통 JSON 데이터로 통신합니다.

{
	"available": true,
    "location": "Main Library, Aisle 4",
    "rentalPrice": 2.99,
    "rentalDays": 14,
    "additionInfo": "Last Copy available!"
}

JSON은 SOAP에서 사용하는 XML 보다는 훨씬 간결하지만 같은 종류 요청이 자주 반복된다면 key 값이 반복되어 중복에 대한 낭비가 생기게 됩니다.

{
	"available": true,
    "location": "Main Library, Aisle 4",
    "rentalPrice": 2.99,
    "rentalDays": 14,
    "additionInfo": "Last Copy available!"
},
{
	"available": true,
    "location": "Main Library, Aisle 4",
    "rentalPrice": 2.99,
    "rentalDays": 14,
    "additionInfo": "Last Copy available!"
},
{
	"available": true,
    "location": "Main Library, Aisle 4",
    "rentalPrice": 2.99,
    "rentalDays": 14,
    "additionInfo": "Last Copy available!"
},
{
	"available": true,
    "location": "Main Library, Aisle 4",
    "rentalPrice": 2.99,
    "rentalDays": 14,
    "additionInfo": "Last Copy available!"
},

하지만 JSON에서 key를 없앤다면 해당 값이 무엇을 나타내느지 구분하기 어렵습니다.

gPRC는 이를 위해 protocol buffer라는 것을 사용합니다.

*.proto

syntax = "proto3";

pacage loan;

service LoanService {
	rpc CheckBookAvaliability(BookRequest) returns (BookResponse) {}
}

message BookRequest {
	string book_id = 1;
    int32 quantity = 2;
}

message BookResponse {
	bool available = 1;
    string location = 2;
    float rentalPrice = 3;
    int32 rentalDays = 4;
    string additionInfo = 5;
}

.proto 파일은 각 메시지가 어떻게 작성될지에 관한 약속으로, 서버와 클라이언트 모두에게 공유됩니다. 이를 기준으로 클라이언트와 서버는 서로 주고받는 메시지를 작성하고 해독합니다.

이처럼 프로토콜 버퍼를 사용해서 합의된 사양을 기준으로, 언어와 환경이 다른 주체들끼리도 매끄럽게 소통할 수 있습니다.

프로토콜 버퍼는 단지 메시지의 키만 간소화하는게 아니라 이를 바이너리 형태로 직렬화해서 전송합니다. 이는 JSON과 같은 텍스트 기반 방식에 비해 용량이 작으므로 훨씬 빠르게 전송할 수 있습니다. 때문에 gRPC는 REST API와 같은 다른 방식들에 비해 효율적으로 요청과 응답을 주고 받을 수 있습니다.

HTTP/2 기반

gRPC의 또 다른 강점은 HTTP/2 기반이라는 점입니다.
RESTful API에서 주로 사용되는 HTTP/1.1는 편지로 요청과 응답을 주고 받는 것과 같습니다.

클라이언트가 편지들을 적어보내면 서버는 이를 하나씩 받아서 순서대로 답장을 돌려보내는 식으로만 소통이 이루어집니다. 만약 먼저 보낸 편지의 처리가 늦어지면, 그 뒤의 편지들은 앞의 편지가 처리될 때까지 기다리게 됩니다.

반면, HTTP/2는 전화로 대화를 주고 받는 것과 같습니다. 한번 통화가 연결되면 서버와 클라이언트는 양방향에서 동시에 대화를 주고 받을 수 있습니다. 여러 메시지를 한 번에 보낼 수도 있고 이를 순서와 상관없이 빠르게 처리해서 답을 보낼 수도 있습니다.
서로 동시에 메시지를 보낼 수도 있고, 서버가 클라이언트에게 능동적으로 메시지를 보낼 수도 있습니다.
gRPC에서 주고 받아지는 바이너리 데이터도 HTTP/2에서 효율적으로 처리됩니다.

TLS를 통해 데이터 암호화

다른 누군가가 메시지를 훔쳐보거나, 내용을 변경하거나 클라이언트 또는 서버를 사칭하지 못하도록 합니다. TLS를 통해 중요한 데이터가 오고 가는 곳에서 gRPC는 안전한 통신을 보장합니다.

아래 링크에서 grpc에 대해 더 알아볼 수 있습니다.
https://grpc.io