gRPC 핵심 개념, 아키텍처 및 수명 주기(Core concepts, architecture and lifecycle)

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를 사용하면 네 가지 종류의 서비스 메서드를 정의할 수 있습니다.

• 클라이언트가 서버에 단일 요청을 보내고 일반 함수 호출과 마찬가지로 단일 응답을 다시 받는 단항 RPC입니다.

rpc SayHello(HelloRequest) returns (HelloResponse);

• 클라이언트가 서버에 요청을 보내고 메시지 시퀀스를 다시 읽기 위해 스트림을 가져오는 서버 스트리밍 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 인프라는 들어오는 요청을 디코딩하고, 서비스 메서드를 실행하고, 서비스 응답을 인코딩합니다.
• 클라이언트 측에서 클라이언트에는 서비스와 동일한 메서드를 구현하는 stub(일부 언어의 경우 기본 용어는 클라이언트)이라는 로컬 개체가 있습니다. 그런 다음 클라이언트는 로컬 개체에서 해당 메서드를 호출할 수 있으며 메서드는 호출에 대한 매개 변수를 적절한 프로토콜 버퍼 메시지 유형으로 래핑하고 요청을 서버로 보낸 다음 서버의 프로토콜 버퍼 응답을 반환합니다.

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

서버 스트리밍 RPC는 서버가 클라이언트의 요청에 대한 응답으로 메시지 스트림을 반환한다는 점을 제외하면 단항 RPC와 비슷합니다. 모든 메시지를 보낸 후 서버의 상태 세부 정보(상태 코드 및 선택적 상태 메시지) 및 선택적 후행 메타데이터가 클라이언트로 전송됩니다. 이렇게 하면 서버 측에서 처리가 완료됩니다. 클라이언트는 서버의 모든 메시지가 있으면 완료됩니다.

Client streaming RPC

클라이언트 스트리밍 RPC는 클라이언트가 단일 메시지 대신 서버에 메시지 스트림을 보낸다는 점을 제외하면 단항 RPC와 비슷합니다. 서버는 단일 메시지(상태 세부 정보 및 선택적 후행 메타데이터와 함께)로 응답하지만 일반적으로 클라이언트의 모든 메시지를 받은 후에는 그렇지 않습니다.

Bidirectional streaming RPC

양방향 스트리밍 RPC에서 호출은 메서드를 호출하는 클라이언트와 클라이언트 메타데이터, 메서드 이름 및 최종 기한을 수신하는 서버에 의해 시작됩니다. 서버는 초기 메타데이터를 다시 보내거나 클라이언트가 메시지 스트리밍을 시작할 때까지 기다리도록 선택할 수 있습니다.

클라이언트 및 서버 쪽 스트림 처리는 응용 프로그램에 따라 다릅니다. 두 스트림은 독립적이므로 클라이언트와 서버는 순서에 관계없이 메시지를 읽고 쓸 수 있습니다. 예를 들어, 서버는 메시지를 작성하기 전에 클라이언트의 모든 메시지를 받을 때까지 기다릴 수 있으며, 서버와 클라이언트는 "핑퐁"을 할 수 있습니다 – 서버가 요청을 받은 다음 응답을 다시 보낸 다음 클라이언트가 응답을 기반으로 다른 요청을 보내는 식입니다.

Deadlines/Timeouts

gRPC를 사용하면 클라이언트가 RPC가 DEADLINE_EXCEEDED 오류로 종료되기 전에 RPC가 완료될 때까지 대기할 시간을 지정할 수 있습니다. 서버 쪽에서 서버는 특정 RPC가 시간 초과되었는지 또는 RPC를 완료하는 데 남은 시간을 확인하기 위해 쿼리할 수 있습니다.

최종 기한 또는 시간 제한을 지정하는 것은 언어별로 다르며, 일부 언어 API는 시간 제한(기간)을 기준으로 작동하고 일부 언어 API는 최종 기한(고정 시점)을 기준으로 작동하며 기본 최종 기한이 있을 수도 있고 없을 수도 있습니다.

RPC termination

gRPC에서 클라이언트와 서버 모두 호출 성공에 대한 독립적인 로컬 결정을 내리며 결론이 일치하지 않을 수 있습니다. 즉, 예를 들어 서버 측에서는 성공적으로 완료되지만("모든 응답을 보냈습니다!") 클라이언트 측에서는 실패하는 RPC가 있을 수 있습니다("응답이 마감일 이후에 도착했습니다!"). 클라이언트가 모든 요청을 보내기 전에 서버가 완료하기로 결정할 수도 있습니다.

Cancelling an RPC 

클라이언트 또는 서버는 언제든지 RPC를 취소할 수 있습니다. 취소하면 RPC가 즉시 종료되므로 추가 작업이 수행되지 않습니다.

Warning

취소 전에 변경한 내용은 롤백되지 않습니다.

Metadata

메타데이터는 키-값 쌍 목록 형식의 특정 RPC 호출(예: 인증 세부 정보)에 대한 정보로, 키는 문자열이고 값은 일반적으로 문자열이지만 이진 데이터일 수 있습니다.

키는 대/소문자를 구분하지 않으며 ASCII 문자, 숫자 및 특수 문자 -, _, 로 구성됩니다. grpc-(gRPC 자체용으로 예약됨)로 시작해서는 안 됩니다. 이진 값 키는 -bin으로 끝나지만 ASCII 값 키는 그렇지 않습니다.

사용자 정의 메타데이터는 gRPC에서 사용되지 않으므로 클라이언트가 호출과 관련된 정보를 서버에 제공할 수 있으며 그 반대의 경우도 마찬가지입니다.

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

Channels

gRPC 채널은 지정된 호스트 및 포트의 gRPC 서버에 대한 연결을 제공합니다. 클라이언트 스텁을 만들 때 사용됩니다. 클라이언트는 채널 인수를 지정하여 gRPC의 기본 동작(예: 메시지 압축 켜기 또는 끄기)을 수정할 수 있습니다. 채널에는 연결됨 및 유휴 상태를 포함한 상태가 있습니다.

gRPC가 채널 닫기를 처리하는 방법은 언어에 따라 다릅니다. 일부 언어에서는 채널 상태 쿼리도 허용합니다.