gRPC
  1. [WEB] gRPC 란
목록보기

0. gRPC 개념

0.1 RPC 란

RPC 란 Remote Procedure Calls의 약자로 다른 프로세스와 통신할때 인터페이스를 사용해서 통신하는 방법입니다. Client와 Server에 존재하는 각각의 Stub 이 serialize and deserialize 역할을 수행합니다.

0.0.1 rpc 아키텍처

img.png

RPC 아키텍처는 주로 5가지 프로그램 구성요소로 구성됩니다.

  1. Client
  2. 클라이언트 스텁
  3. RPC 런타임
  4. 서버 스텁
  5. 서버

RPC 프로세스는 아래 단계로 진행됩니다.

단계 1) 클라이언트, 클라이언트 스텁 및 RPC 런타임 인스턴스 하나가 클라이언트 시스템에서 실행됩니다.

단계 2) 클라이언트는 일반적인 방법으로 매개변수를 전달하여 클라이언트 스텁 프로세스를 시작합니다. 클라이언트 스텁은 클라이언트 자체 주소 공간 내에 저장됩니다. 또한 로컬 RPC 런타임에 서버 스텁으로 다시 보내도록 요청합니다.

단계 3) 이 단계에서는 사용자가 정기적인 로컬 절차적 Cal을 만들어 액세스하는 RPC입니다. RPC 런타임은 클라이언트와 서버를 통한 네트워크 간 메시지 전송을 관리합니다. 또한 재전송, 확인, 라우팅 및 암호화 작업도 수행합니다.

단계 4) 서버 프로시저를 완료한 후 서버 스텁으로 돌아가서 반환 값을 메시지로 압축(마샬링)합니다. 그런 다음 서버 스텁은 메시지를 전송 계층으로 다시 보냅니다.

단계 5) 이 단계에서 전송 계층은 결과 메시지를 클라이언트 전송 계층으로 다시 보내고, 클라이언트 전송 계층은 메시지를 클라이언트 스텁으로 다시 반환합니다.

단계 6) 이 단계에서 클라이언트 스텁은 결과 패킷의 반환 매개변수를 디마샬링(압축해제)하고 실행 프로세스가 호출자에게 반환됩니다.

0.2 gRPC

gRPC는 구글에서 개발한 RPC(RPC, Remote Procedure Call) 시스템이며 모든 환경에서 실행할 수 있는 오픈 소스 고성능 RPC 프레임워크입니다. HTTP/2기반으로 다양한 언어에서 사용이 가능하며 스텁, 프로토콜버퍼 등의 특징이 있으며 서비스들을 효율적으로 연결할 수 있는 강점을 가집니다.

1. gRPC 특징

  1. HTTP/2 기반
    • gRPC는 HTTP/2 프로토콜을 사용하여 데이터 전송을 수행합니다. 이를 통해 멀티플렉싱, 흐름 제어, 헤더 압축 등의 기능을 지원하며 효율적인 네트워크 사용을 제공합니다.
  2. 프로토콜 버퍼(Protobuf) 사용
    • gRPC는 기본적으로 Google의 Protocol Buffers(프로토콜 버퍼)로 메시지를 직렬화/역직렬화합니다. Protobuf는 JSON이나 XML보다 빠르고 데이터 크기가 작아 성능이 뛰어납니다.
    • 이를 통해 API 인터페이스 정의와 메시지 구조를 명확하게 지정할 수 있습니다.
  3. 다양한 언어 지원
    • gRPC는 C++, Java, Python, Go, C#, JavaScript, PHP 등 다양한 언어에서 클라이언트 및 서버를 구현할 수 있도록 지원합니다.
  4. 양방향 스트리밍 지원
    • 단순 요청-응답 방식뿐만 아니라, 다음과 같은 통신 방식도 지원합니다:
      • 단방향 스트리밍: 클라이언트 또는 서버가 연속된 데이터를 보냄.
      • 양방향 스트리밍: 클라이언트와 서버가 동시에 데이터를 주고받음.
  5. 자동 코드 생성
    • 프로토콜 버퍼 파일(.proto)을 작성하면 gRPC 툴체인을 통해 서버와 클라이언트 코드가 자동으로 생성됩니다.

1.1 프로토콜 버퍼

프로토콜 버퍼(Protocol Buffers, Protobuf)는 IDL(Interface Definition Language)로, Google에서 설계한 효율적이고 플랫폼 독립적인 데이터 직렬화(Serialization) 및 역직렬화(Deserialization) 형식입니다.

프로토콜 버퍼로 작업할 때는 proto file에서 직렬화하려는 데이터 구조를 정의합니다. 프로토콜 버퍼는 하나의 프로그래밍 언어가 아니라 여러 프로그래밍 언어를 지원하기 때문에, 특정 언어에 종속성이 없는 형태로 데이터 타입을 정의하게 되는데, 이 파일을 proto file이라고 합니다.

syntax = "proto3";

message Person {
    string name = 1;  // 필드 번호 1
    int32 id = 2;     // 필드 번호 2
    string email = 3; // 필드 번호 3
}

이 코드를 컴파일러(protoc)를 사용해 다양한 언어로 코드 생성할 수 있습니다. (protoc --java_out=. person.proto)

2. 장단점

장점

  • 높은 생산성을 가지고, 프로토콜 버퍼의 IDL 만 정의하면 서비스와 메세지에 대한 소스코드가 자동으로 생성되고 데이터를 주고 받을 수 있습니다.
  • HTTP/2 기반으로 통신하여 양방향 스트리밍이 가능하며 프로토콜 버퍼를 사용하여 ‘‘직렬화된 바이트 스트림’‘으로 통신하여 JSON 기반의 통신보다 더 가볍고 통신속도가 빠릅니다.
  • 다양한 언어를 기반으로 만들 수 있습니다.

단점

  • HTTP/2를 지원하지 않는 네트워크 환경에서는 사용이 제한될 수 있습니다. 주로 브라우저와 서버간의 gRPC 통신이 지원되지 않는데 이를 해결하려면 grpc-gateway를 통해 protobuf 형식으로 데이터를 변환 후 사용해야 합니다.
  • JSON보다 사람이 읽기 어려운 Protobuf 포맷으로 테스트가 어렵고 네트워크 단에서 데이터를 보고 싶으면 추가적인 작업이 필요합니다.

2.1 http 1.1 vs 2.0

멀티플렉싱: HTTP/1.1은 리소스를 차례로 로드하므로 한 리소스를 로드할 수 없는 경우 그 뒤에 있는 다른 모든 리소스가 차단됩니다.이와는 대조적으로, HTP/2는 단일 TCP 연결을 사용하여 한 번에 여러 데이터 스트림을 보낼 수 있으므로 한 리소스 때문에 다른 리소스가 차단되지 않습니다.HTTP/2는 데이터를 이진 코드 메시지로 분할하고 클라이언트가 각 이진 메시지가 속한 스트림을 알 수 있도록 이러한 메시지에 번호를 매겨 이를 수행합니다.

서버 푸시: 일반적으로 서버는 클라이언트가 요청하는 경우에만 클라이언트 장치에 콘텐츠를 제공합니다.그러나 이 접근 방식은 클라이언트가 요청해야 하는 수십 개의 개별 리소스를 포함하는 최신 웹 페이지에서는 항상 실용적인 것은 아닙니다.HTTP/2는 클라이언트가 요청하기 전에 서버가 클라이언트에 콘텐츠를 “푸시”할 수 있도록 하여 이 문제를 해결합니다.서버는 또한 Bob이 모든 것을 보내기 전에 Alice에게 소설의 목차를 보낸 경우와 같이, 예상되는 콘텐츠를 푸시한 내용을 클라이언트에게 알려주는 메시지를 보냅니다.

헤더 압축: 작은 파일은 큰 파일보다 더 빨리 로드됩니다.웹 성능 속도를 높이기 위해 HTTP/1.1 및 HTTP/2는 모두 HTTP 메시지를 압축하여 더 작게 만듭니다.그러나 HTTP/2는 HTTP 헤더 패킷에서 중복 정보를 제거하는 HPACK이라는 고급 압축 방법을 사용합니다.이렇게 하면 모든 HTTP 패킷에서 몇 바이트가 제거됩니다.단일 웹 페이지를 로드하는 데 관련되는 HTTP 패킷의 양을 고려할 때, 이러한 바이트는 빠르게 합산되어 로드 속도가 빨라집니다.

cloudflare 참고 -> https://www.cloudflare.com/ko-kr/learning/performance/http2-vs-http1.1/

Ref.

  1. https://aws.amazon.com/ko/compare/the-difference-between-grpc-and-rest/

태그: ,

카테고리:

업데이트:

댓글남기기

참고