구글의 HTTP 기반의 RPC 프로토콜 GRPC

간단한 GRPC 소개

어제 오늘 약간 커뮤니티를 달군 내용 중의 하나가 구글에서 새롭게 발표한 GRPC라는 개념이다.

GRPC는 한마디로 이야기하자면, 예전 자바 RMI나, CORBA의 웹 버전 정도?

RPC란, Remote Procedure Call의 약자로, 원격에 있는 함수를 호출해주는 기능을 이야기 한다.

RPC는 일반적으로, request parameter와 response parameter를 알아야 하기 때문에, 양쪽의 인터페이스 규약을 IDL 등의 언어로 정의한후, 해당 프로그래밍 언어가 부를 수 있는 형태의 코드로 생성을 해줘야 하는데, 이를 Skeleton과 Stub코드라고 한다.

HTTP 기반의 REST가 유행하면서 RPC는 많이 사라 졌는데, 반대로 REST의 경우, 호출 하는 parameter와 응답 값이 명시적이지 않기 때문에, 오류의 여지가 많고 (API 스펙만을 의존, 형 체크등을 안함) JSON을 HTTP를 통해서 쏘기 때문에, 다소 속도가 떨어진다는 단점을 가지고 있다.

그래서 근래에 RPC 개념이 다시 유행하기 시작했는데, 페이스북의 경우에는 Thrift라는 바이너리기반의 RPC 프레임웍을 발표했다. 구글은 RPC 자체는 지원하지 않고, 메세지(JSON등)을 Serialize할 수 있는 프레임웍으로 PB (Protocol Buffer)를 제공해왔는데, GRPC라는 개념으로, PB를 기본으로한 Serizlaizer에 HTTP2를 붙여서 RPC 프레임웍을 릴리즈 하였다.

http://www.grpc.io/

GRPC의 특징 중의 하나는 C/C++  뿐 아니라 자바나 Ruby,node.js,python과 같은 대부분의 모던 프로그래밍 언어를 지원하며, 또한, 요즘 유행하는 MSA (마이크로 서비스 아키텍쳐)와 물려서, RPC를 하나의 서비스로 하여 배포할 수 있는 개념을 가지고 왔다고 해야 할까? MSA와 모던 프로그래밍 언어의 조합은 상당히 매력적이다. 서비스의 개념을 가지고 있는 것만으로도, 잘 서비스화된 서버 시스템을 만들어 낼 수 있으니까는.

이러한 서비스 컨셉은 TP 모니터로 유명한 Tuxedo에 널리 사용되었는데, (그러고보면 10년이 훨 지난 이 제품이 아직도 현대의 많은 개념을 리드하는게 존경 스러울 뿐이다.) 잘 정의된 서비스 정의 프레임웍은 깔끔한 서비스 개발을 보장해주기 때문에, 훨씬 정리된 형태의 MSA 구현이 가능하지 않을까 싶다.

또한 서버 구현체 역시 자바의 경우 Netty를 이용하여, 몇줄 안되는 코드로 고 성능 서버에 서비스를 많지 않은 코딩양으로 구현이 가능하다. 

얼마나 확산이 될지는 지켜봐야 하겠지만, REST의 단방향의 한계를 극복하고, HTTP2 기반의 Streaming을 지원하며, REST대비 빠른 성능을 지원하기 때문에, 충분히 검토해볼만한 가치는 있는 것으로 보인다.

또한 코딩양 역시 Spring Boot 만큼이나 적고 간단해서 경쟁력이 있고, 무엇보다 여러 언어를 동시 지원함으로써 폴리그랏 형태의 개발이 가능하다는 장점은 있지만, 반대로, 네이티브 프로토콜의 한계상, 데이타 포맷 변환이 런타임시 자유롭지 못하고, 중간에 메세지를 열어서 라우팅이나 메디에이션을 하는 API GATEWAY 도입이 어려운 구조이기 때문에, 분명히 한계는 있다.

시간이 될때, 몇가지 샘플을 가지고 테스트 좀 해봐야 할듯

거의 예전 코바 + 턱시도와 컨셉이 같은듯... 장점만 따왔으니 괜찮지 않을까?