[WIL] gRPC - 1

yoonn·2024년 2월 8일
grpc

gRPC

목록 보기
1/3
post-thumbnail

gRPC

  • 구조화된 데이터 직렬화를 위해 Google이 제공하는 다목적 오픈 소스 도구인 프로토콜 버퍼를 사용
  • 주로 Protobuf를 사용하지만 JSON과 같은 다른 데이터 형식도 지원.
  • 기본적으로 원격으로 호출할 수 있는 특정 메서드로 서비스를 정의하는 RPC 패러다임을 따른다.

프로토콜 버퍼?

  • 구조화된 데이터를 효율적으로 직렬화하기 위한 다양한 언어 간 플랫폼 독립적 솔루션 역할을 한다.
  • 데이터를 어떻게 구조화할지 한 번 정의. 정의 언어는 .proto 파일로 생성
  • proto compiler가 데이터와 인터페이스하기 위해 생성하는 코드

프로토콜 버퍼의 장점

  • 컴팩트한 데이터 저장
  • 빠른 구문 분석
  • 자동 생성되는 클래스를 통한 최적화된 기능
  • 언어 간 호환성
  • 확장성을 제공. 기존 서비스와의 호환성을 손상시키지 않고 데이터 구조를 조정하고 업데이트 가능.

프로토콜 버퍼의 한계

  • 대용량 데이터: 수 메가가 넘어가는 대용량 데이터로 작업할 때는 직렬화된 복사본으로 인해 사실상 여러 개의 데이터 복사본을 갖게 되어 메모리 사용량이 급격히 증가할 수 있음.
  • 직렬화 복잡성: 프로토콜 버퍼가 직렬화될 때 동일한 데이터는 다양한 바이너리 직렬화를 가질 수 있습니다. 두 메시지를 완전히 구문 분석하지 않고는 두 메시지의 동일성을 비교할 수 없음.
  • 압축 미지원: 프로토콜 버퍼에는 압축 기능이 내장되어 있지 않음.
  • 비객체 지향 언어: 프로토콜 버퍼는 포트란이나 IDL과 같이 과학 컴퓨팅에서 널리 사용되는 비객체 지향 언어에서는 잘 지원되지 않음.
  • 메시지 해석 및 스키마 종속성: 프로토콜 버퍼 메시지에는 고유한 데이터 설명이 부족하며 리플렉션 스키마에 의존하기 때문에 전체 해석을 위해 해당 .proto 파일에 액세스해야 한다.
  • 공식 표준화 부족: 어떤 조직의 공식 표준도 아니므로 법적 또는 표준화 요구 사항이 있는 환경에는 적합하지 않음.

프로토콜 버퍼 작동

Protocol Buffers Work
1. .proto 파일 작성 (인터페이스 정의)
2. 프로토콜 버퍼 컴파일러 protoc을 사용해 프로토 정의에서 원하는 언어로 데이터 액세스 클래스를 생성
3. 각 필드에 대한 간단한 접근자와 전체 구조를 원시 바이트로 직렬화/구문 분석하는 메서드가 제공됨.

grpc 서비스 정의

productinfo service definition

서비스 ProductInfo는 네트워크를 통해 gRPC 서비스로 노출되는 방식으로 모델링

1. ProductInfo.proto

  • 프로토콜 버퍼를 IDL로 사용하여 서비스 인터페이스 정의 (.proto 파일)
  • 서비스 정의는 프로토콜 버퍼 사양의 확장이므로 .proto 파일에서 코드를 생성하는 데 특수 gRPC 플러그인이 사용된다.
    • 프로토콜 버퍼용 gRPC 플러그인을 사용하면 gRPC 서버 측 및 클라이언트 측 코드는, 메시지 유형 채우기, 직렬화를 위한 일반 프로토콜 버퍼 코드 생성 가능.
  • 서비스 정의는 gRPC 애플리케이션의 서버 및 클라이언트 측을 구축하는 데 사용됨.
  • 서비스 정의 구성
    • 원격 메소드
    • 입력 및 출력 매개변수
    • 해당 매개변수의 유형 정의(또는 메시지 형식)를 지정하는 서비스 인터페이스 정의

2. gRPC Server

  • 서비스 기본 클래스를 재정의하여 생성된 서비스 스켈레톤의 서비스 로직을 구현
  • gRPC 서버를 실행(클라이언트의 요청 수신 및 반환)

3. gRPC Client

  • 서비스 정의를 사용하여 클라이언트 측 Stub을 생성
  • Client Stub은 클라이언트 코드가 호출할 수 있는 서버와 동일한 메소드를 제공하고, 이를 서버 측으로 이동하는 원격 네트워크 호출로 변환한다.

Server ↔ Client 메시지 흐름

client가 server를 호출

Client

  • gRPC 라이브러리는 프로토콜 버퍼를 사용해 원격 프로시저 호출 프로토콜 버퍼 형식을 마샬링하여 HTTP/2를 통해 전송.

Server

요청 받은 메시지를 언마샬링. 해당 프로시저 호출은 프로토콜 버퍼를 사용하여 실행됩니다.

server에서 client로 응답하는 것 역시 유사하게 동작한다.

다른 통신 기술들과의 비교

RPC

  • RPC를 사용하면 클라이언트는 로컬 메서드를 호출하는 것처럼 원격으로 메서드 기능을 호출할 수 있음.
  • RPC 구현의 대부분이 TCP 통신 프로토콜 위에 구축되어 상호 운용성을 방해하고 복잡도가 높아진다.

REST

  • REST는 주로 동기식 요청-응답 스타일 통신을 구축할 때 일반적으로 사용됨. gRPC도 주로 동기식 요청-응답 스타일로 통신하지만, 초기 통신 설정되면 비동기식 스트리밍 모드로 작동 가능.
  • REST는 HTTP/1.x와 같은 텍스트 기반 전송 프로토콜 기반으로 구축. gRPC는 HTTP/2.0 기반
  • REST는 JSON(대부분)과 같은 텍스트 형식으로 직렬화되어 전송하므로 텍스트 변환 작업이 필요함. gRPC는 바이너리 직렬화 형식 프로토콜 버퍼를 활용하므로 텍스트 변환 과정이 필요 없음.

Usecase

기업 사용 사례

넷플릭스

  • 기존: HTTP/1.1의 RESTful로 서비스 간 통신을 위한 자체 기술 스택을 개발(거의 98%)
  • 현재: gRPC로 전환
  • 장점: 클라이언트 제작 시간이 줄어듦. 전체적인 지연 시간 감소.

드롭박스

  • 초당 수백만 건의 요청을 주고받는 수백 개의 다국어 마이크로서비스를 실행
  • 기존: 자체 개발 RPC 프레임워크 및 HTTP1.1 기반의 RPC 프레임워크 등
  • 현재: gRPC 기반의 RPC 프레임워크 사용

reference

profile
yoonn
1
다음 포스트

[WIL] gRPC - 2

0개의 댓글