RPC : Remote Procedure Calls

= 다른 컴퓨터의 프로그램의 프로시저를 실행하는 프로그램을 허용하는 프로토콜

개발자가 원격 상호 작용에 대한 세부 정보를 명시적으로 코딩하지 않아도 됨

프레임워크가 자동 핸들링

클라이언트 코드에서는 직접 서버 코드의 함수를 호출하는 것처럼 보임

클라이언트 코드 언어 ≠ 서버 코드 언어 : 다른 언어로 쓰일 수 있음




gRPC = Communication 프레임워크

마이크로서비스는 여러 PL들로 만들어짐 (ex : back-end = Go, front-end = java)

이 서비스들 간의 소통 필요

마이크로서비스 간의 교환되는 메시지 수 = 엄청나게 많음 >>> 빠른 소통이 좋음

개발자는 핵심 로직구현만 집중하도록 하고 소통은 프레임워크에게 맡기기

gRPC = High-performance Open-source Feature-rich Framework

  • originally developed by Google
  • 지금은 Cloud Native Computing Foundation 파트 (CNCF - like 쿠버네티스)
  • gRPC 메시지는 기본적으로 Protobuf (이진형식)로 인코딩 됨 > 송수신 효율적 but 사람이 못읽음


gRPC는 Protocol Buffers를 통해 클라이언트 코드와 서버 인터페이스 코드를 생성.
옵션에 따라 생성하는 언어 변경 가능
>>> 하나의 proto 파일을 사용해서 go, python, java, swift 등 다양한 언어의 서버/클라이언트 코드를 생성할 수 있음

'g'는 gPRC 릴리스마다 다름 (https://github.com/grpc/grpc/blob/master/doc/g_stands_for.md)




gRPC 작동원리

  1. 클라이언트는 stub 생성 (서버랑 같은 메소드 제공)
  2. stub는 gRPC 프레임워크를 호출 (내부 네트워크를 통해서 호출)
  3. 클라이언트와 서버는 서로 상호작용을 위해 stubs 사용 >>> 서로의 코어 서비스 로직의 권한만 필요)



gRPC - HTTP API 비교

기능 gRPC JSON을 사용하는 HTTP API
계약 필수( .proto) 선택 사항(OpenAPI)
프로토콜 HTTP/2 (빠름!) HTTP
Payload Protobuf(소형, 이진메시지 형식) JSON(대형, 사람이 읽을 수 있음)
규범 엄격한 사양 느슨함. 모든 HTTP가 유효합니다.
스트리밍 클라이언트, 서버, 양방향 클라이언트, 서버
브라우저 지원 아니요(gRPC-웹 필요)
보안 전송(TLS) 전송(TLS)
클라이언트 코드 생성 OpenAPI + 타사 도구

.proto 파일 : gRPC서비스/ 메시지 계약 정의



gRPC 한계

브라우저에서 gRPC 서비스 직접 호출 불가능

> gRPC-Web 사용 (양방향 스트리밍 불가, 서버 스트리밍 제한적)

> RESTful JSON Web API 에서 HTTP 메타데이터로 .proto 파일에 주석으로 gRPC 서비스 사용

(애플리케이션= json Web API, gRPC 둘다 지원)




Reference

유튜브 TECH SCHOOL 의 [gRPC #1~3] 강의

gRPC 서비스와 HTTP API 비교

gRPC와 HTTP API를 비교한 방법과 권장 시나리오를 알아봅니다.

docs.microsoft.com

[버즈빌의 누구나 궁금해하는 개발 이야기] gRPC를 쓰면 REST가 공짜!? - 모비인사이드 MOBIINSIDE

[버즈빌의 누구나 궁금해하는 개발 이야기] gRPC를 쓰면 REST가 공짜!? - 마케팅 모비인사이드 MOBIINSIDE

www.mobiinside.co.kr

반응형

+ Recent posts