[Full-Stack Network] 7. gRPC

Cherish·2023년 11월 2일

풀스택서비스네트워킹

Full-Stack Service Networking

목록 보기

7/10

🍏 함수 호출 방법

✅ 정적 링킹 (Static Linking)

실행 파일 생성 시 필요한 라이브러리를 포함하여 생성
내가 만든 기계어 파일과 남이 만든(이미 만들어진) 기계어 파일들이 합쳐진다 -> exe 파일

✅ 동적 링킹 (Static Linking)

실행 파일에 라이브러리 코드를 포함하지 않고, 하나의 메모리 공간에 매핑하여 여러 프로그램이 공유하여 사용된다.
실행 파일에는 모든 기능이 100% 있는 것이 아니다. 반드시 돌아가야 할 애들만 실행파일에 넣고, 나머지 기능은 필요할 때만 불러서 사용.
필요한 동적 라이브러리가 없으면 실행이 불가능 하다.
동적 링킹을 통해 메모리를 줄일 수 있다.

✅ 원격 함수 호출 (RPC)

RPC = Remote Procedure Call
분산 네트워크 환경에서 원격지 컴퓨터의 함수를 호출한다.
호출 된 함수의 실행이 내 컴퓨터가 아니라 원격 컴퓨터에서 실행된다.
통신을 통해 parameter 전달, 결과 전달 등을 함.
IDL(Interface Definition Language)
복잡한 과정을 자동화 해준다.

🍏 gRPC 개요

= 기존의 RPC를 기반으로 구글이 만든 기술 (오픈소스)

RPC는 client들이 호출할 때 stub을 호출한다.
호출되는 쪽, 호출하는 쪽 언어가 달라도 된다. -> 인기있는 이유 중 하나

✅ 목적

moder / open souce / high performance / 다양한 언어에서 제공을 한다 / 성능 좋고 stable / data center에서 쓰일 수 있다.

http2의 막강한 장점 : 보안

✅ gRPC vs REST API (HTTP + JSON)

Protocol

gRPC = http2에서만 돌아간다 / 보안 때문 + binary이기 때문에 통신의 대역폭이 줄어든다 (대역폭이 작다 = 메세지가 작다 = 지연이 줄어든다)
REST API = http면 된다.

Payload

REST : 간단하면 url에 값 집어놓고 컨텐츠를 통해 주고 받고, 내용이 많으면 JSON으로 하면된다.
gRPC는 무조건 입출력 parameter로 받는다(Protobuf 이용) / binary기 때문에 보내는 정보의 크기가 매우 줄어든다. gRPC는 프로그래밍 언어의 일환으로, 굉장히 호출하고 결과를 받아오는 규칙이 strict 하다. 반면 REST는 loose.

Streaming

REST : 계속 정보를 보내는 것 X / 함수 호출로 값을 하나 받아 옴 = req/res
gRPC : 끊임없이 정보를 보낼 수 있다. Streaming 처럼 느껴진다. ( Client / Server / Bi-directional )

Browser Support

gRPC : 아직 java에서 호출하는 게 안돼서 브라우저에서 지원이 안된다. 웹 말고 어플리케이션 레벨에서 정보를 주고 받는다.
REST : 브라우저 지원 O

Client Code-Generation

gRPC : 샘플이 자동으로 만들어지기 때문에, 이해해야 할 내용은 많지만 실제로 짜는 것은 적다 -> 최신 language 특징

🍏 gRPC Example (4 Type)

✅ 1. Unary RPC

함수를 호출하면서 입력 parameter를 주고 간단한 결과를 가져오는 것
가장 간단
서버 입장에서 client를 어떻게 받을 것인가.

✅ 1-1 Unary RPC - Proto File

Proto file ( .proto )
client는 호출하고 server는 호출당할 함수를 위한 문법을 저장하는 확장자 파일
- Protocol Buffers 언어 표준을 따른다.
- proto : proto buffer에서 따온 것.
File 정의 예제
- RpcFunc : 호출될 함수이름
- (request) : 입력 parameter
- (response) : return 값

✅ 1-2 Unary RPC - Steps

[Step1] Server에 의해 호출당할 함수 작성
[Step2] Proto 파일 작성
- Protocol Buffer : 내가 하고자 하는 서비스와 주고 받을 메세지에 대한 정의를 한 것
- 실질적으로 하는 행위는 숨김
  개발자가 작성하는 주요 두가지 항목
  - Service(Function) / Message(Parameter)
    - Server는 MyService를 서비스한다. MyFunction 기능을 rpc를 통해서 Service하는 것. Function들이 Service에 들어가는 거져.
    - 통신에서 주고받는 것 = Message = Parameter
[Step3] gRPC 클래스 자동 생성
- grpc_tools.protoc를 통해서 클래스 파일들을 생성
  - Protobuf compiler 실행
  - Proto file을 기반으로 Message 부분과 Service 부분을 읽어서 각각 소스 코드를 만든다.
- grpc_tools.protoc 프로그램은 다음 출력 파일을 생성
  - message class : Message 부분을 읽어서 만들어진 파일 = 코드들
  - client/server class : Service 부분을 읽어서 만들어진 파일 = sample 예제
[Step4] gRPC Server 작성
[Step5] gRPC Client 작성
[Step6] gRPC Server&Client 실행 결과 확인
[Step7] 개발 파일확인

✅ 2. Bidirectional Streaming gRPC

양뱡향 streaming
client/server 사이에 정보를 끊임없이 주고받는다 = Streaming
list를 모아서 보내는 것이 아니라 element를 따로따로 여러번 보내는 것.
Streaming : 복수의 data set (collection datatype)를 한꺼번에 모아서 보내는 것이 아니라 조금씩 끊임 없이 보내는 것.
client가 서버로 보내는 것과 그 반대가 독립적으로 동작. 여러 가지 타입의 조합이 가능하다. client가 server에게 계속 보내면서 server가 client에게 보낼 수도 있고, 다 받고 보낼 수도 있고.. 등등

✅ 2-1 Bidirectional Streaming gRPC - Proto File

입출력을 stream으로 계속해서 받고 줄 수 있다.

Proto Buffer 구성
- client가 list를 서버에게 전달. 완성된 list가 아니라 작업이 완료된 element를 보내고, 보내면서 다음 element만들고, 만들어진거 보내고,... 이걸 반복

✅ 3. Client Streaming gRPC

not bidirectional
client가 server에게 보내는 입력 parameter가 stream
Server는 이것을 다 받은 다음 처리하거나, 받으면서 처리하거나 선택 가능.

Proto File
Proto Buffer

✅ 4. Server Streaming gRPC

이번엔 Server가 줄줄이 보내는 것.
Client는 명확히 하나만 전달
예를들어 5를 보내면 서버에서 5개를 만들어 보내는 프로그램

Proto File

Proto Buffer

🍏 Protocol Buffer

= 컴퓨터 A의 정보를 컴퓨터 B에 전달하는 역할

A,B의 언어,OS와 같은 환경에 독립적으로 동작한다
= language-neutral, platform-neutral
Serializing Structured data
Protocol Buffer를 programmer가 쉽게 사용한것이 Proto File과 Proto Compiler
- 이 기술을 통해서 언어와 OS 상관없이 함수, method, 입출력 Parameter들을 편하게 주고받을 수 있다.

✅ ProtoBuf 기능

open source / cross-platform
Serializing Structured data
정보를 저장하고 읽을 때, 언어와 OS에 독립적으로 가능.
Data를 표현하기 위한 언어를 사용한 것. 확장자 proto에 정의된 규칠들을 따른다.
Compiler : 규칙에 맞게 언어를 해석하고 파일을 생성

✅ ProtoBuf 동작 원리

Binary Encoding
- Byte 단위의 원초적인 형태로 data를 표현한 것. HW dependent한 모든 부분들을 표현한 것.

빨라진 유선 통신에서 HTTP 1.1을 쓸 때 우리가 이렇게 비트를 아껴야하나? 라는 생각이 들게 됨. 이동통신은 절대로 급속도로 빨라질 수 없기 때문에 구글이 속도를 올리기 위해 비트 처리를 한다. HTTP2 에서도 비트 처리를 하고 + 압축까지 함. 즉, 프로그램이 복잡해짐. 하지만 이정도의 프로그램은 CPU 성능이 올라와서 충분히 처리 가능해짐

gRPC에서는 Protobuf를 통신할 때 사용
- 주고받는 부분은 Protobuf에게 맡기고 그 위에서 gRPC가 편안하게 동작
- 작고 빠르고 간단~

🍏 gRPC 장점 & 단점

✅ gRPC 장점

성능

Protobuf = 최소한의 byte로 정보(binary)를 표현할 수 있는 방법 -> 성능 좋음
Small Message = 지연시간 단축 = Mobile Communication 용이

중간 예상 문제 : TCP/HTTP1.1/HTTP2?/gRPC의 정보를 실어나르는 방법, 표현하는 방법의 차이점_
- HTML/HTTP : 알파벳으로 써있어서 사람은 읽기 쉽지만 / 주고받는 정보가 너무 많다
- gRPC : binary라 사람은 못읽지만 작은 메세지로 빠르게 전달 가능하다. 유선보다 무선이 중요해졌기 때문. 작고 빠른게 중요하다!

HTTP/2 based

HTTP 1.x와 차이점
- Binary framing and compression(압축)
- Multiplexing = Client가 Server에게 요구한 req의 순서대로 Server가 응답할 필요 X / req는 독립적이며 순서가 의미 X
HTTP2 -> 주고받는 정보를 최소화해서 지연을 줄이자! = gRPC의 가장 큰 목적 / 대신 압축하거나 푸는 데 CPU가 좀 더 필요하다.
http2에 특화된 상위계층? 아직 gRPC밖에 없음
HTTP/2 is not exclusive to gRPC

Code generation

Proto Buf 사용하기 때뭄ㄴ에
Proto File을 만들고 Proto Compiler를 사용하면 class, message들을 자동으로 만들어줬다.
Server/Client가 Proto File만 공유하면 메세지나 함수들이 언어 별로 만들어졌기 때문에 별도로 맞춰야하는 작업을 할 필요가 없었따 -> 개발 시간 감소 / 생산성 향상

Strict specification

gRPC는 철학을 통일했기 때문에 개발 시간을 줄일 수 있다.

Streaming

TCP/Restful 등등 다 전부 rep/req개념인데
streaming 개념이 도입된 건 grpc가 처음.
실시간으로 주고받은 streaming service 개발 가능.

Deadline/Timeouts & Cancellation

이 기능은 예제로 보여주지 않아쓴데
client에서 rpc에 요청하면서 초가적으로 요청을 하는 거야. deadline을 주고 넘어가면 취소해버려! 하는 것.

✅ gRPC 단점

Limited browser support

브라우저가 http1.1의 웬만한 기능을 다 담고 있어요. gRPC는 아님.. 자바를 호출해서 웹브라우저 창에서 gRPC를 호출하는 것이 지원되지 않음.

Not human readable

인간이 읽을 수 없다.
읽고싶으면 1.1을 쓰는거고 읽지 않고 성능을 올리려면 grpc를 쓰는거지

Right tool for Right problem

x축 : 초당 들어오는 request 수 or 사용자 수
y축 : 처리한 용량

초록색 : zmq의 router
파란색 : zmq의 req/rep
grpc

성능이 좀 떠러지더라도 필요한 기능을 사용할 수 있다면 고르면 됨. CPU를 무조건 아껴야되는 것이 아니야. CPU를 좀 쓰더라도 안되던게 되면 획기적인 거임!

통신 프로그램은 그 분야에 맞춰서 고를 수 있어야 하는 거!
무조건 새로운 게 좋은 것이 아님.

Cherish

다음 포스트