gRPC를 좀 더 쉽게 정리 해 보자.

개요 : gRPC에 대해서 좀 더 깊이 들어가고 싶었으나, 만약 타인에게 설명을 해 주는 상황이라면 기본 개념이 머리속에 잡혀 있어야 되는데 정리를 하면서도 너무 방대한 양이라 이해하기가 어려웠다. 그래서 간단하게 정리 해 보고 기본적인 개념을 잡아보는게 더 좋을 거 같아서 정리를 해보게 되었다.

 

gRPC

- Google Remote Procedure Call의 약자로, 확장 가능하고 빠른 API를 만드는 데 사용되는 오픈 소스 RPC 프레임워크이다.

Procedure(프로시저)

 

• 특정한 로직을 처리하기만 하고 결과 값을 반환하지 않는 서브 프로그램
• 데이터베이스에 대한 일련의 작업을 정리한 절차를 관계형 데이터베이스 관리 시스템이 저장한 것
• 테이블에서 데이터를 추출, 조작하고 결과를 다른 테이블에 다시 저장하거나 갱신하는 처리를 할 때 프로시저를 사용.

장점

• 하나의 요청으로 여러 SQL문을 실행 가능
• 네트워크 소요 시간을 줄여 성능개선이 가능
• 여러 어플리케이션과 공유 가능
• 기능변경 편리 -> 특정 기능을 변경할 때 프로시저만 변경하면 된다.

단점

• 문자나 숫자열 연산에 사용하면 java보다 느린 성능을 보일 수 있다.
• 프로시저가 앱의 어디에 사용되는지 확인이 어렵다. -> 유지보수가 어려움

프로시저 생성

CREATE OR REPLACE PROCEDURE 프로시져명 
(파라미터1 IN | OUT | IN OUT,파라미터2 IN | OUT | IN OUT...); 

IS[AS]
변수, 상수 등을 선언 

BEGIN로직을 실행할 쿼리문 

[EXCEPTION 예외처리] 

END 프로시져 명;

• IN : 입력 (입력 매개변수)
• IOUT : 출력 (출력 매개변수)
• IN OUT : 입출력을 동시에 한다.
• 기본값은 in
• out 파라미터는 프로시저에서 로직 수행 후, 해당 매개변수에 값을 할당해서 프로시저 호출부분에서 이 값을 참조할 수 있다.
  ->에러코드, 에러메세지를 전달하는 목적으로 사용.

출처: https://scoring.tistory.com/entry/프로시저란 [LightSourceCoder:티스토리]

 

주요 특징

• 다양한 환경에서 실행 가능
• 고성능
• 프로토콜 버퍼를 사용하여 데이터를 효율적으로 교환
  • 프로토콜 버퍼는 작고 빠른 이진 직렬화 형식으로, 사람이 해석하기 어렵지만 인/디코딩 속도가 빠르다.

gRPC를 사용하면 서비스 간에 정의된 인터페이스를 통해 메서드를 호출하고, 강력한 통신 프로토콜을 기반으로 한 서비스 간의 통합이 가능하다.

 

배경

• 마이크로서비스 기반으로 구축되는 시스템은 서비스 간 네트워크 통신 연결이 급증
• 마이크로서비스용 통신을 구축할 때에 주로 사용하는 RESTful 서비스는 프로세스 간 통신을 구축할 때 부피가 크고 비효율적이다.

설명

• Google에서 만든 오픈 소스 원격 프로시저 호출(RPC) 시스템.
• gRPC는 성능이 좋고, 전송 효율이 높은 서비스를 제공하는데 사용
• gRPC는 여러 언어로 구현되어 있으며, 일반적으로 HTTP/2 프로토콜을 기반으로 구현되어 있음.

사용 순서

1. 프로토콜 버퍼를 IDL(Interface Definition Language)로 사용해 서비스 인터페이스 정의 (메서드 종류, 호출 파라미터, 메시지 형식 등)
2. 서비스 정의를 사용해 서버 스켈레톤(Server Skeleton)이라는 서버 측 코드 생성
3. 서비스 정의를 사용해 클라이언트 스텁(Client Stub)이라는 클라이언트 측 코드 생성

 

Productlnfo Service Definition

장점

• 프로세스 간 통신 효율성
  • Json이나 XML과 같은 텍스트 형식을 사용하는 대신 프로토콜 버퍼 기반 바이너리 프로토콜 사용
  • HTTP/2 위에 프로토콜 버퍼로 구현되어 프로세스 간 통신 속도가 빠르고 효율적이다.
• 간단 명확한 서비스 인터페이스와 스키마
  • 서비스 인터페이스를 정의한 후 나중에 세부 사항을 작업함에 따라 안정적이다.
• 플리그랏
  • 여러 프로그래밍 언어로 작동하도록 설계되어, 특정 언어에 구애 받지 않는다.
• 이중 스트리밍 지원
• 유용한 내장 기능 지원
  • 인증, 암호화, 압축, 로드밸런싱 등 기본적으로 지원한다.

---

단점

• 외부 서비스 부적합
  • 계약 기반(Contract-driven) & 강력한 타입 속성을 갖기 떄문에 외부에 노출 되는 서비스에 유연성이 낮음
• 서비스 정의의 급격한 변경에 따른 개발 프로세스 복잡성
  • 변경 발생 시 일반적으로 클라이언트 서버 코드를 모두 생성 해야한다.
• 상대적으로 작은 생태계
  • HTTP 프로토콜 대비 작은 생태계 및 브라우저 & 모바일 & RPC 지원은 초기 단계이다.