![[gRPC] gRPC 개요, MSA 서비스간 통신, gRPC vs REST](https://img1.daumcdn.net/thumb/R750x0/?scode=mtistory2&fname=https%3A%2F%2Fblog.kakaocdn.net%2Fdn%2FCIt7c%2FbtssOuykPHw%2FspwWCCnYtnjHBNsWSlaHi0%2Fimg.png)
마이크로 서비스간 통신 이슈
MSA에서는 여러 모듈로 분리되어있고 동일 머신에 존재하지 않을 수 있습니다. 따라서 일반적으로는 보편화된 방식인 REST 통신을 통해 메시지를 주고 받습니다. TTP 1.0은 요청/응답을 하기에 앞서 매번 Connection을 맺고 끊어야했기 때문에 연결 요청/해제 비용이 상당히 높았습니다.
RPC
- Remote Procedure Calls
- 다른 컴퓨터의 프로그램의 프로시저를 실행하는 프로그램을 허용하는 프로토콜
- 개발자가 원격 상호 작용에 대한 세부 정보를 명시적으로 코딩하지 않아도 됨
- 프레임워크가 자동 핸들링
- 클라이언트 코드에서는 직접 서버 코드의 함수를 호출하는 것처럼 보임
gRPC
- google Remote Procedure Call
- 구글에서 만든 원격 프로시저 호출 프레임워크
- 프로토콜 버퍼(바이너리 형식)를 이용하여 서비스를 정의 (송수신 효율적이나 사람이 못읽음)
- 간결하게 런타임 및 개발 환경을 설치하고 프레임워크를 사용하여 초당 수백만 개의 RPC로 확장할 수 있는 스케일링 기능을 제공
- 다양한 언어 및 플랫폼에 대해 클라이언트 및 서버 스텁을 자동 생성
- 양방향 스트리밍 및 완전한 통합 인증을 HTTP/2 기반 전송을 통해 제공
gRPC 작동 원리
- 클라이언트는 stub 생성 (서버랑 같은 메소드 제공)
- stub는 gRPC 프레임워크를 호출 (내부 네트워크를 통해서 호출)
- 클라이언트와 서버는 서로 상호작용을 위해 stubs 사용
gRPC 한계
- 브라우저에서 gRPC 서비스 직접 호출 불가능
- gRPC-Web 사용 (양방향 스트리밍 불가, 서버 스트리밍 제한적)
- RESTful JSON Web API 에서 HTTP 메타데이터로 .proto 파일에 주석으로 gRPC 서비스 사용
gRPC vs REST
작동 모델
REST는 HTTP 1.1 프로토콜에 기반해 만들어졌으며 요청-응답 모델에 따라 api 를 설계하도록 한다. 다양한 클라이언트로부터의 다양한 요청이 순차적으로 처리된다. gRPC는 HTTP 2.0 프로토콜에 기반해 만들어졌으며 양방향 통신 기능과 전통적인 요청-응답 모델을 사용한다. 여러 요청을 동시에 처리할 수 있다는 것을 의미한다. (HTTP 2.0 이 다중화 기능을 제공하기 때문)
통신 모델
REST API는 일반적으로 서버와 클라이언트 간에 메시지를 주고받을 때 JSON으로 구현한다. JSON은 텍스트 기반이며 사람이 읽을 수 있기 때문에 다른 메시징 형식보다 효율적이고 플랫폼에 독립적이기 때문이다. gRPC는 프로토콜 버퍼를 마치 REST가 JSON을 사용하듯이, 직렬화 및 통신에 사용한다. 프로토콜 버퍼는 데이터를 직렬화할 때 매우 효율적이고 밀집된 메세징 형태이기에 신속한 응답 전달이 가능하다. 나아가 프로토콜 버퍼는 시스템간 메세지 전송에서 빠른 속도를 보여주는데 왜냐하면 메세지 패킷을 marshaling (매개변수와 원격 함수를 이진 메시지 패킷으로 묶는) 을 네트워크에 보내기 전에 처리하기 때문이다.
지원하는 브라우저와 레이턴시
HTTP 1.0은 모든 브라우저에서 지원되므로, REST는 어떤한 사전 조건없이 사용된다. REST 는 모든 종류의 브라우저를 지원한다. 뛰어난 브라우저 지원능력으로 인해, REST는 지연시간이 길어진다. HTTP 2.0 은 제한된 브라우저 지원으로 인해, gRPC가 어느 브라우저에서는 호환되지 않을 수 있다. gRPC는 제한된 브라우저만을 지원하지만 레이턴시 자체가 이슈가 되지는 않는다. gRPC는 가벼운 마이크로 서비스 어플리케이션을 개발할 될 때 그 빠른 데이터 통신속도와 짧은 레이턴시로 인해 선호된다.
데이터 형식과 직렬화
REST는 JSON, XML과 같은 다양한 데이터 형식을 사용한다. JSON이 가장 널리 사용되는데, 이해하기 쉬우며 유연하기 때문이다. 반면에 gRPC는 데이터를 더 안정적으로 전송하기 위해 프로토콜 버퍼 메시지 형식만을 지원한다.
개발자는 실시간 데이터 통신이 필요한 마이크로서비스에서 gRPC를 사용하는 경우가 많은데, 왜냐하면 고수준의 메세지 직렬화를 제공하는 기능 때문이다. 가벼운 메시징, 저전력 네트워크 및 높은 효율성이 필요한 시스템을 연결하는 데 특히 좋다. 또한, gRPC는 네이티브 코드 생성을 제공하여 개발자가 다국어 또는 언어에 독립적인 환경에서 애플리케이션을 개발할 수 있도록 지원한다.