gRPC 공식 문서 (2) - Core concepts

JinWooHyun·2021년 1월 22일
grpc
0

Core concepts, architecture and lifecycle

An introduction to key gRPC concepts, with an overview of gRPC architecture and RPC life cycle.

gRPC에 익숙하지 않습니까? 먼저 gRPC 소개를 읽어보세요.

언어 별 세부 사항은 선택한 언어에 대한 빠른 시작, 튜토리얼 및 참조 문서를 참조하십시오.

Overview

Service definition

많은 RPC 시스템과 마찬가지로 gRPC는 서비스 정의 개념을 기반으로하며 매개 변수 및 반환 유형을 사용하여 원격으로 호출 할 수있는 메서드를 지정합니다.

기본적으로 gRPC는 서비스 인터페이스와 페이로드 메시지의 구조를 모두 설명하기위한 인터페이스 정의 언어 (IDL)로 프로토콜 버퍼를 사용합니다.

원하는 경우 다른 대안을 사용할 수 있습니다.

service HelloService {
  rpc SayHello (HelloRequest) returns (HelloResponse);
}

message HelloRequest {
  string greeting = 1;
}

message HelloResponse {
  string reply = 1;
}

gRPC를 사용하면 4가지 종류의 서비스 방법을 정의 할 수 있습니다.

  • 클라이언트가 서버에 단일 요청을 보내고 일반 함수 호출처럼 단일 응답을받는 Unary RPC입니다.
rpc SayHello(HelloRequest) returns (HelloResponse);
  • 클라이언트가 서버에 요청을 보내고 메시지 시퀀스를 다시 읽기위한 스트림을 가져 오는 Server Streaming RPC입니다.
  • 클라이언트는 더 이상 메시지가 없을 때까지 반환 된 스트림에서 읽습니다.
  • gRPC는 개별 RPC 호출 내에서 메시지 순서를 보장합니다.
rpc LotsOfReplies(HelloRequest) returns (stream HelloResponse);
  • 클라이언트가 일련의 메시지를 작성하고 제공된 스트림을 사용하여 서버로 보내는 클라이언트 스트리밍 RPC입니다.
  • 클라이언트가 메시지 쓰기를 마치면 서버가 메시지를 읽고 응답을 반환 할 때까지 기다립니다.
  • gRPC는 개별 RPC 호출 내에서 메시지 순서를 보장합니다.
rpc LotsOfGreetings(stream HelloRequest) returns (HelloResponse);
  • 양방향 스트리밍 RPC는 양쪽에서 읽기-쓰기 스트림을 사용하여 일련의 메시지를 전송합니다.
  • 두 스트림은 독립적으로 작동하므로 클라이언트와 서버는 원하는 순서대로 읽고 쓸 수 있습니다.
  • 예를 들어, 서버는 응답을 쓰기 전에 모든 클라이언트 메시지를 수신 할 때까지 기다리거나, 교대로 메시지를 읽은 다음 메시지를 쓰거나, 다른 읽기 및 쓰기 조합을 사용할 수 있습니다.
    각 스트림의 메시지 순서는 유지됩니다.
rpc BidiHello(stream HelloRequest) returns (stream HelloResponse);

아래의 RPC 수명주기 섹션에서 다양한 유형의 RPC에 대해 자세히 알아볼 수 있습니다.

Using the API

.proto 파일의 서비스 정의에서 시작하여 gRPC는 클라이언트 및 서버 측 코드를 생성하는 프로토콜 버퍼 컴파일러 플러그인을 제공합니다.

gRPC 사용자는 일반적으로 클라이언트 측에서 이러한 API를 호출하고 서버 측에서 해당 API를 구현합니다.

  • 서버는 서비스에서 선언 한 메소드를 구현하고 gRPC 서버를 실행하여 클라이언트 호출을 처리합니다.
  • gRPC 인프라는 수신 요청을 디코딩하고, 서비스 메서드를 실행하고, 서비스 응답을 인코딩합니다.
  • 클라이언트에는 서비스와 동일한 메소드를 구현하는 스텁 (일부 언어의 경우 선호되는 용어는 클라이언트)이라는 로컬 오브젝트가 있습니다.
  • 클라이언트는 로컬 객체에서 해당 메서드를 호출하여 적절한 프로토콜 버퍼 메시지 유형으로 호출 매개 변수를 래핑 할 수 있습니다.
  • gRPC는 요청을 서버로 보내고 서버의 프로토콜 버퍼 응답을 반환합니다.

Synchronous vs. asynchronous

서버에서 응답이 도착할 때까지 차단하는 동기식 RPC 호출은 RPC가 추구하는 프로 시저 호출의 개념에 가장 근접해 있습니다.

반면에 네트워크는 본질적으로 비동기적이며 많은 시나리오에서 현재 스레드를 차단하지 않고 RPC를 시작할 수있는 것이 유용합니다.

대부분의 언어에서 gRPC 프로그래밍 API는 동기 및 비동기 버전으로 제공됩니다.

각 언어의 자습서 및 참조 문서에서 자세한 내용을 확인할 수 있습니다 (전체 참조 문서는 곧 제공 될 예정입니다).

RPC life cycle

이 섹션에서는 gRPC 클라이언트가 gRPC 서버 메서드를 호출 할 때 어떤 일이 발생하는지 자세히 살펴 보겠습니다.

전체 구현 세부 사항은 언어 별 페이지를 참조하십시오.

Unary RPC

먼저 클라이언트가 단일 요청을 보내고 단일 응답을받는 가장 간단한 유형의 RPC를 생각해보면,

  1. 클라이언트가 스텁 메서드를 호출하면 이 호출에 대한 클라이언트의 메타 데이터, 메서드 이름 및 지정된 기한 (해당하는 경우)을 사용하여 RPC가 호출되었음을 서버에 알립니다.

  2. 그런 다음 서버는 자체 초기 메타 데이터 (응답 전에 전송되어야 함)를 즉시 다시 보내거나 클라이언트의 요청 메시지를 기다릴 수 있습니다. 먼저 발생하는 것은 애플리케이션에 따라 다릅니다.

  3. 서버에 클라이언트의 요청 메시지가 있으면 응답을 만들고 채우는 데 필요한 모든 작업을 수행합니다. 그런 다음 응답은 상태 세부 정보 (상태 코드 및 선택적 상태 메시지) 및 선택적 후행 메타 데이터와 함께 클라이언트에 반환됩니다 (성공한 경우).

  4. 응답 상태가 OK이면 클라이언트가 응답을 받고 클라이언트 측에서 호출을 완료합니다.

Server Streaming RPC

Server Streaming RPC는 서버가 클라이언트의 요청에 대한 응답으로 메시지 스트림을 반환한다는 점을 제외하면 Unary RPC와 유사합니다.

모든 메시지를 보낸 후 서버의 상태 세부 정보 (상태 코드 및 선택적 상태 메시지)와 선택적 후행 메타 데이터가 클라이언트로 전송됩니다.

이 것으로 서버 측에서 처리가 완료됩니다.

클라이언트는 서버의 모든 메시지를 받으면 완료됩니다.

Client Streaming RPC

Client Streaming RPC는 클라이언트가 단일 메시지 대신 서버로 메시지 스트림을 보내는 것을 제외하고는 Unary RPC와 유사합니다.

서버는 일반적으로 모든 클라이언트의 메시지를 수신 한 후에 (반드시 그런 것은 아니지만) 상태 세부 정보 및 선택적 후행 메타 데이터와 함께 단일 메시지로 응답합니다.

Bidirectional Streaming RPC

Bidirectional Streaming RPC에서 호출은 메서드를 호출하는 클라이언트와 클라이언트 메타 데이터, 메서드 이름 및 기한을 수신하는 서버에 의해 시작됩니다.

서버는 초기 메타 데이터를 다시 보내거나 클라이언트가 메시지 스트리밍을 시작할 때까지 기다릴 수 있습니다.

클라이언트 측 및 서버 측 스트림 처리는 애플리케이션에 따라 다릅니다.

두 스트림이 독립적이므로 클라이언트와 서버는 순서에 관계없이 메시지를 읽고 쓸 수 있습니다.

예를 들어, 서버는 메시지를 쓰기 전에 클라이언트의 모든 메시지를 수신 할 때까지 기다리거나 서버와 클라이언트가 "ping-pong"(서버가 요청을 받은 다음 응답을 보낸 다음 클라이언트가 응답을 기반으로하는 또 다른 요청 등)을 할 수 있습니다.

Deadlines/Timeouts

gRPC를 사용하면 클라이언트가 DEADLINE_EXCEEDED 오류와 함께 RPC가 종료되기 전에 RPC가 완료 될 때까지 기다릴 시간을 지정할 수 있습니다.

서버 측에서 서버는 특정 RPC가 Timeout 되었는지 또는 RPC를 완료하는 데 남은 시간을 확인하기 위해 쿼리를 보낼 수 있습니다.

Deadline 또는 Timeout 지정은 언어별로 다릅니다.

일부 언어 API는 Timeout (시간 지속) 측면에서 작동하고 일부 언어 API는 Deadline (고정 시점) 측면에서 작동하며 기본 기한이 있을 수도 있고 없을 수도 있습니다.

RPC termination

gRPC에서 클라이언트와 서버는 호출의 성공 여부를 로컬에서 독립적으로 결정하며 결론이 일치하지 않을 수 있습니다.

예를 들어 서버 측에서는 성공적으로 완료되지만 ("내 모든 응답을 보냈습니다!") 클라이언트 측에서는 실패 ("응답이 마감일 이후에 도착했습니다!")하는 RPC가있을 수 있음을 의미합니다.

클라이언트가 모든 요청을 보내기 전에 서버가 완료를 결정할 수도 있습니다.

Cancelling an RPC

클라이언트나 서버는 언제든지 RPC를 취소 할 수 있습니다.

취소하면 RPC가 즉시 종료되므로 더 이상 작업이 수행되지 않습니다.

WARNING
취소하기 전에 변경 한 사항은 롤백되지 않습니다.

Metadata

메타 데이터는 키-값 쌍 목록 형식의 특정 RPC 호출 (예 : 인증 세부 정보)에 대한 정보입니다.

여기서 키는 문자열이고 값은 일반적으로 문자열이지만 binary 데이터 일 수 있습니다.

메타 데이터는 gRPC 자체에는 불투명합니다.

이를 통해 클라이언트가 서버 호출과 관련된 정보를 제공 할 수 있으며 그 반대의 경우도 마찬가지입니다.

메타 데이터에 대한 액세스는 언어에 따라 다릅니다.

Channels

gRPC 채널은 지정된 호스트 및 포트에서 gRPC 서버에 대한 연결을 제공합니다.

클라이언트 스텁을 만들 때 사용됩니다. 클라이언트는 채널 인수를 지정하여 메시지 압축 켜기 또는 끄기와 같은 gRPC의 기본 동작을 수정할 수 있습니다.

채널에는 연결됨 및 유휴 상태를 포함한 상태가 있습니다.

gRPC가 채널 폐쇄를 처리하는 방법은 언어에 따라 다릅니다.

일부 언어는 채널 상태 쿼리도 허용합니다.

profile
JinWooHyun
Unicorn Developer
이전 포스트

gRPC 공식문서 (1) - Introduction

다음 포스트

gRPC 공식 문서 (3) - Python

0개의 댓글