gRPC 시리즈에서 다룰 내용
- 왜 gRPC인가?
- gRPC로 unary RPC 구현
- gRPC로 stream RPC 구현
- gRPC로 REST API 구현
서론
전 편에서 프로토콜 버퍼에 대해 언급했었습니다. 프로토콜 버퍼를 사용해 REST 통신을 하던 구글은, '이거, RPC로 구현하면 되게 편하고 효율적이지 않을까?' 생각하게 됩니다.
먼저 우리는 RPC에 대해 알 필요가 있습니다.
RPC는 쉽게 말해서 통신 기술 중 하나로, 로컬 함수를 호출 하듯 다른 프로세스에 있는 내용을 호출 할 수 있도록 하는 기술입니다. 네트워크 간 통신의 추상화가 아름답게 이루어져, 다른 프로세스에 있는 내용을 로컬 함수처럼 호출 할 수 있다는것이죠.
RPC 개념에 대해 익숙치 않아도 괜찮습니다. HTTP 기반의 REST API 가 유행이 되며 RPC는 잊혀져갔기 때문에, 충분히 모를 수 있는것이죠.
그렇다면, 'REST 와 RPC가 사용 용도에 있어 비슷한 역할을 한다' 는 말이 됩니다.
그런데 gRPC가 다시 주목을 받기 시작한다는건, RPC → REST → gRPC 라는 흐름이 이어져 오고 있다는겁니다. 왜 다시 RPC, 그것도 하필 gRPC일까요? 그게 뭐길래?
gRPC, 너 정체가 뭐냐! - 왜 gRPC인가
역시 오늘도 사전적 정의부터 찾아보겠습니다.
gRPC(gRPC Remote Procedure Calls[1])는 구글이 최초로 개발한 오픈 소스 원격 프로시저 호출 (RPC) 시스템이다. 전송을 위해 HTTP/2를, 인터페이스 정의 언어로 프로토콜 버퍼를 사용하며 인증, 양방향 스트리밍 및 흐름 제어, 차단 및 비차단 바인딩, 취소 및 타임아웃 등의 기능을 제공한다. 수많은 언어를 대상으로 크로스 플랫폼 클라이언트 및 서버 바인딩을 생성한다. 가장 흔한 사용 시나리오에는 마이크로서비스 스타일 아키텍처의 서비스 연결, 모바일 장치, 브라우저 클라이언트를 백엔드 서비스에 연결하는 일 등이 포함된다. - 한국어 위키피디아
뭔가 알 수 없는 말이 잔뜩 있다고 생각 할 수 있지만, 그래도 익숙한 용어들이 몇개 보입니다.
- HTTP/2
- 프로토콜 버퍼
이 두개의 키워드는, 다음과 같은 요약을 내릴 수 있게 해줍니다.
HTTP/2를 기반으로, 프로토콜 버퍼를 사용하여 통신하는 RPC 시스템
전 편에서 다루었던 프로토콜 버퍼를 사용하여 통신한다 하니, 둘은 밀접하게 닿아 있다는 생각이 들죠. 실제로도 그렇습니다. 이제 그 내용에 대해서 다뤄보도록 하겠습니다.
그러면 다시 원래 질문으로 돌아오겠습니다.
왜 그냥 RPC도 아니고, HTTP 기반의 REST 통신도 아닌 gRPC일까요?
나중에 네트워킹의 발전사를 언급하며 이 부분을 다시 한번 언급하겠습니다만, 다음과 같은 내용을 봅시다.
gRPC 이전의 통신 구현 환경은 다음과 같았습니다.
- REST 자체는 명확하게 통신 데이터의 모델을 다루는 내용이 없다.
- REST는 표준이나 규약보단 스타일에 가까워서, 명확히 관리되지 않는다.
- 통신 데이터의 모델을 문서화로 진행해야한다는 점은 매우 번거롭다.
- XML은 비효율적이다.
- JSON은 통신 이후 데이터를 처리하는 별도의 과정(Serialization)이 필요하다.
- HTTP/1.1 는 비효율적이고, 느리고, 유연하지 못하다.
- 요청 → 응답의 구조로 인해 매번 새로 connection을 생성해야 한다.
- cookie 같은 메타 데이터가 중복 전달 된다.
그렇다면 gRPC는 이 문제들을 어떻게 해결 했을까요?
- 프로토콜 버퍼 사용
- 전 편에서 프로토콜 버퍼를 보았듯, 통신 데이터의 형식을 지정 할 수 있다.
- HTTP/2 사용
- HTTP/2는 매 요청마다 Connection을 생성하지 않을 수 있다.
- 요청 → 응답의 구조가 아닌 양방향 통신이 가능하다. (스트림 통신이 가능하다)
그래서 gRPC로 뭘 할 수 있는데?
- 높은 성능을 보장하는 인터페이스 파일(stub) 생성
- MSA 서비스 간 통신에서 활용
- 필요시 HTTP/2 기반의 REST API도 같이 사용 가능
그래서 gRPC 사용 시나리오는 다음과 같습니다...
- 전달 할 값(파라미터)의 사양, 실행 될 프로시져(실행 될 내용)을 프로토콜 버퍼 스키마(.proto 파일)로 작성
- 프로토콜 버퍼 컴파일러(protoc)를 통해 언어에 맞는 인터페이스 파일(stub) 생성
- gRPC의 SDK를 활용, 서버 및 클라이언트 작성 - 인터페이스 파일을 사용하여 프로시져 구현 및 전달 할 값 생산
1번과 2번은, 전 편에서 어느정도 다루었습니다. 사용 시나리오를 보니, gRPC와 프로토콜 버퍼가 얼마나 밀접하게 닿아있는지 와닿지않나요?
protoc를 통해 stub을 생성 할 수 있다는 점은, 언어가 다른 경우에도 스키마 문서 없이 컴파일만 진행하면 해당 데이터들을 쉽게 다룰 수 있다는 점에서 매우 매력적으로 들립니다.
다음 편부터, 이렇게 멋진 gRPC를 직접 구현해보도록 하겠습니다!
참고한 링크
https://lejewk.github.io/grpc-go-example/
https://juneyr.dev/2018-07-30/what-is-grpc
https://blog.naver.com/n_cloudplatform/221751268831
https://blog.banksalad.com/tech/production-ready-grpc-in-golang/
'Computer Science' 카테고리의 다른 글
| Nginx 리버스 프록시를 사용하여 배포 할 때 해야 할 것들 (0) | 2021年02月22日 |
|---|---|
| 다크모드 적용시: StatusBar (상단바) 아이콘 색상 바꿀때 유의 할 점 (0) | 2021年01月29日 |
| 프로토콜 버퍼(protocol buffer)란? (0) | 2020年12月14日 |
| SW 마에스트로 11기 후기 (3) | 2020年11月29日 |
| 선린인터넷고등학교 정보보호과 동아리 지원시스템 개발기 (1) | 2020年06月07日 |