gRPC 동기 부여 및 디자인 원칙(Motivation and Design Principles)

Motivation

Google은 Stubby라는 단일 범용 RPC 인프라를 사용하여 10년 넘게 데이터 센터 내부 및 전체에서 실행되는 수많은 마이크로서비스를 연결해 왔습니다. 우리의 내부 시스템은 오늘날 인기를 얻고 있는 마이크로서비스 아키텍처를 오랫동안 수용해 왔습니다. 균일한 크로스 플랫폼 RPC 인프라를 통해 효율성, 보안, 신뢰성 및 행동 분석에서 플릿 전반의 개선을 롤아웃할 수 있었습니다.

Stubby에는 많은 훌륭한 기능이 있지만 표준을 기반으로하지 않으며 내부 인프라와 너무 밀접하게 결합되어 공개 릴리스에 적합한 것으로 간주되지 않습니다. SPDY, HTTP/2 및 QUIC의 출현으로 Stubby가 제공하지 않는 다른 기능과 함께 이러한 동일한 기능 중 많은 부분이 공개 표준에 등장했습니다. 이 표준화를 활용하고 모바일, IoT 및 클라우드 사용 사례로 적용 가능성을 확장하기 위해 Stubby를 재작업해야 할 때라는 것이 분명해졌습니다.

Principles & Requirements

개체가 아닌 서비스, 참조가 아닌 메시지

시스템 간의 세분화된 메시지 교환이라는 마이크로 서비스 디자인 철학을 홍보하는 동시에 분산 개체의 위험과 네트워크 무시의 오류를 방지합니다.

Coverage & Simplicity

스택은 널리 사용되는 모든 개발 플랫폼에서 사용할 수 있어야 하며 누군가가 선택한 플랫폼에 맞게 쉽게 빌드할 수 있어야 합니다. CPU 및 메모리 제한 장치에서 실행 가능해야 합니다.

Free & Open

모든 사람이 기본 기능을 무료로 사용할 수 있도록 합니다. 모든 아티팩트를 채택을 촉진하고 방해하지 않아야 하는 라이선스가 있는 오픈 소스 노력으로 릴리스합니다.

Interoperability & Reach

유선 프로토콜은 공통 인터넷 인프라를 통한 통과에서 살아남을 수 있어야 합니다.

General Purpose & Performant

스택은 광범위한 사용 사례 클래스에 적용할 수 있어야 하며 사용 사례별 스택과 비교할 때 성능 저하가 거의 없어야 합니다.

Layered

스택의 주요 측면은 독립적으로 발전할 수 있어야 합니다. 유선 형식의 개정은 응용 프로그램 계층 바인딩을 중단하지 않아야 합니다.

Payload Agnostic

다른 서비스는 프로토콜 버퍼, JSON, XML 및 Thrift와 같은 다른 메시지 유형 및 인코딩을 사용해야합니다. 프로토콜과 구현은 이를 허용해야 합니다. 마찬가지로 페이로드 압축의 필요성은 사용 사례 및 페이로드 유형에 따라 다릅니다: 프로토콜은 플러그형 압축 메커니즘을 허용해야 합니다.

Streaming

스토리지 시스템은 스트리밍 및 흐름 제어에 의존하여 대규모 데이터 세트를 표현합니다. 음성 텍스트 변환 또는 주식 시세 표시기와 같은 다른 서비스는 스트리밍을 사용하여 일시적으로 관련된 메시지 시퀀스를 나타냅니다.

Blocking & Non-Blocking

클라이언트와 서버가 교환하는 메시지 시퀀스의 비동기 및 동기 처리를 모두 지원합니다. 이는 특정 플랫폼에서 스트림을 확장하고 처리하는 데 중요합니다.

Cancellation & Timeout

작업은 비용이 많이 들고 수명이 길어질 수 있습니다 - 취소를 사용하면 클라이언트가 제대로 작동할 때 서버가 리소스를 회수할 수 있습니다. 인과 관계 체인을 추적하면 취소가 연속적으로 발생할 수 있습니다. 클라이언트는 호출에 대한 시간 제한을 나타낼 수 있으며, 이를 통해 서비스는 클라이언트의 요구에 맞게 동작을 조정할 수 있습니다.

Lameducking 

서버는 진행 중인 요청을 계속 처리하는 동안 새 요청을 거부하여 정상적으로 종료되도록 허용되어야 합니다.

Flow Control

컴퓨팅 성능과 네트워크 용량은 종종 클라이언트와 서버 간에 불균형합니다. 흐름 제어를 통해 버퍼 관리를 개선할 뿐만 아니라 지나치게 활동적인 피어에 의한 DOS로부터 보호할 수 있습니다.

Pluggable

유선 프로토콜은 작동하는 API 인프라의 일부일 뿐입니다. 대규모 분산 시스템에는 보안, 상태 확인, 부하 분산 및 장애 조치, 모니터링, 추적, 로깅 등이 필요합니다. 구현은 이러한 기능을 플러그 인할 수 있도록 확장 지점을 제공해야 하며 유용한 경우 기본 구현을 제공해야 합니다.

Extensions as APIs

서비스 간의 공동 작업이 필요한 확장은 가능한 경우 프로토콜 확장보다 API를 사용하는 것이 좋습니다. 이 유형의 확장에는 상태 확인, 서비스 자체 검사, 부하 모니터링 및 부하 분산 할당이 포함될 수 있습니다.

Metadata Exchange

인증 또는 추적과 같은 일반적인 교차 문제는 서비스의 선언된 인터페이스에 속하지 않는 데이터 교환에 의존합니다. 배포는 서비스에서 노출하는 개별 API와 다른 속도로 이러한 기능을 발전시키는 기능에 의존합니다.

Standardized Status Codes

클라이언트는 일반적으로 제한된 수의 방법으로 API 호출에서 반환된 오류에 응답합니다. 상태 코드 네임스페이스는 이러한 오류 처리 결정을 보다 명확하게 하기 위해 제한되어야 합니다. 더 풍부한 도메인별 상태가 필요한 경우 메타데이터 교환 메커니즘을 사용하여 이를 제공할 수 있습니다.