지식 줍줍 🐿️

RESTful, 비효율적 텍스트 기반 메세지 프로토콜

RESTful 서비스는 HTTP 1.x 와 같은 텍스트 기반 전송 프로토콜로 구축되고, JSON 처럼 사람이 읽을 수 있는 텍스트 포맷을 활용함.
그런데, 서비스간 통신을 할 경우(common server - user server 이런식?) 사람이 읽을 수 있는 텍스트 기반 포맷을 사용할 필요가 없음!
→ 비효율적이라 판단함. 

클라이언트가 서버로 전송할 바이너리 콘텐츠를 만든 후, 바이너리 구조체를 텍스트로 변환함.
그리고 네트워크를 통해 텍스트로 전송하고 서비스측에서 다시 바이너리 구조로 변환함.
→ 이럴바에 비즈니스 로직으로 바로 매핑될 수 있는 바이너리 형식으로 쉽게 전송하는것이 낫다고 판단!

RPC

설명

클라이언트 - 서비스 애플리케이션을 구축하는 데 널리 사용되는 프로세스간 통신 기술
RPC을 통해 클라이언트는 로컬 메서드를 호출하는 것처럼 원격으로 메서드 기능을 호출할 수 있다.

gRPC

설명

구글에서 만든 오픈소스 원격 프로시저 호출 시스템.

※ 원격 프로시저
별도의 원격 제어를 위한 코딩 없이 다른 주소 공간에서 함수나 프로시저를 실행할 수 있게하는 프로세스 간 통신 기술이다.
다시 말해, 원격 프로시저 호출을 이용하면 프로그래머는 함수가 실행 프로그램에 로컬 위치에 있든 원격 위치에 있든 동일한 코드를 이용할 수 있다.

로컬함수를 호출하는 것 만큼 쉽게 분산된 이기종 애플리케이션을 연결/호출/운영/디버깅 할 수 있는 프로세스 간 통신 기술.
주로 통신에 동기식 요청-응답 스타일을 사용하나, 초기 통신이 설정되면 완전 비동기식이거나 스트리밍 모드에서 작동할 수 있다.
프로토콜 버퍼와 HTTP/2 프로토콜 위에 구축됨.

※ 프로토콜 버퍼
구조화된 데이터를 직렬화하고자 언어에 구애 받지 않고 플랫폼 중립적이며 확장 가능한 메커니즘인 데이터 직렬화 프로토콜.
데이터가 직렬화되면 이 프로토콜은 일반 JSON 페이로드보다 크기가 작고 강력한 형식의 바이너리 페이로드를 생성함.
→ HTTP/2라는 바이너리 전송 프로토콜을 통해 전송!

구성 프로젝트

● 인터페이스 정의
‣ 서비스를 사용하는 방법, 원격으로 호출되는 메서드 종류, 해당 메서드를 호출하기 위한 파라미터, 메세지 형식등을 포함.
‣ *.proto 파일로 정의(=인터페이스 정의 언어), 이는 프로토콜 버퍼 메세지로 RPC 메서드 파라미터 및 반환 타입과 함께 gRPC 서비스를 일반 프로토콜 버퍼 형식으로 정의함.
‣ 프로토 파일에서 코드를 생성하고자 gRPC 플러그인이 사용된다.

※ gRPC 플러그인
gRPC 서버측, 클라이언트측 코드 뿐만이 아니라
정의된 메세지 타입의 데이터 지정, 직렬화, 데이터 취득의 일반 프로토콜 버퍼 코드도 생성할 수 있다.

● 서버
‣ 인터페이스 정의가 완료되면, protoc을 사용해 서버측이나 클라이언트 측 코드를 생성할 수 있다.
‣ 스켈레톤(server skeleton) 이라는 서버측 코드 생성가능. 저수준의 통신 추상화를 통해 서버 측 로직 단순화 가능.
  (gRPC 관련 상위 서비스 클래스를 오버라이드 하여 스켈레톤(server skeleton) 이라는 서버측 코드 구현!)
‣ 로직 구현 후, 서버 실행하여 클라이언트 요청 수신 및 응답!

● 클라이언트
‣ 스텁(client stub) 이라는 코드를 생성할 수 있음. 메소드 함수 호출하는것처럼 쉽게 클라이언트측에서 원격 호출 가능.
‣ 스텁(client stub)은 서버와 동일한 메서드를 제공하는데, 클라이언트 코드에서 메서드들의 호출을 네트워크상 원격 함수 호출로 변환함.

으로 구성.

클라이언트-서버 흐름

▶︎ 네트워크 통신은 HTTP/2를 통해 이루어짐
▶︎ (java 기준) *.proto 파일 생성 후, 빌드하면(물론 관련 패키지 import하고,,) grpc 사용관련 클래스들이 생성되고, 이를 서버와 클라이언트가 사용하는것으로 확인

gRPC 장점

• 프로세스간 통신 효율성이 증대
텍스트 형식 대신 프로토콜 버퍼 기반 바이너리 프로토콜을 사용하여 gRPC 서비스 및 클라이언트와 통신하며,
HTTP/2 프로토콜 버퍼로 구현되기에 프로세스 간 통신 속도가 매우 빨라진다.

• 간단 명확한 서비스 인터페이스 스키마
먼저 서비스 인터페이스를 정의 하고나서 구현 세부 사항을 작업한다. (구현이 간단)

• 엄격한 타입 점검 형식
프로토콜 버퍼를 사용하기에 gRPC 서비스 계약은 애플리케이션간 통신에 사용할 데이터 타입을 명확하게 정의한다.

• 폴리글랏
여러 프로그래밍 언어와 작동하도록 설계됨. 특정언어에 구애 안받음!

• 이중 스트리밍

• 유용한 내장 기능 지원

• 클라우드 네이티브 생태계와 통합
넷플릭스 도커 시스코 등에서 채택

gRPC 단점

• 외부 서비스 부적합
외부 클라이언트에 제공하려는 경우는 적합하지 않을 수 있음.
계약 기반이고, 강력한 타입 속성을 갖기 때문
그래서 gRPC 게이트웨이는 이 문제를 해결책으로 설계됨.

• 서비스 정의의 급격한 변경에 따른 개발 프로세스 복잡성
gRPC 서비스가 재정의되면, 클라이언트 및 서버 코드 모두 변경을 해야함;

• 상대적으로 작은 생태계
브라우저 및 모바일 애플리케이션에서 gRPC 지원은 초기 단계라고함.

..

참고

책: http://www.kyobobook.co.kr/product/detailViewKor.laf?mallGb=KOR&ejkGb=KOR&barcode=9791161754635
링크: https://thenewstack.io/grpc-remote-procedure-calls-in-a-nutshell/

링크: https://grpc.io/

링크: https://ko.wikipedia.org/wiki/%EC%9B%90%EA%B2%A9_%ED%94%84%EB%A1%9C%EC%8B%9C%EC%A0%80_%ED%98%B8%EC%B6%9C