IDL(Interface Definition Language)
- 명세 정의 언어
- 서버와 클라이언트가 정보를 주고 받는 규칙이 프로토콜(HTTP)이라면,
IDL은 정보를 저장하는 규칙이다. - 대표적인 IDL의 예 : XML, JSON, Protocol buffers(proto)
Protocol buffers(proto)
- XML의 문제점을 개선하기 위해 제안된 IDL이며, XML보다 월등한 성능을 지닙니다.
Protocol buffers는 구조화(structured)된 데이터를 직렬화(serialization)하기 위한 프로토콜로 XML보다 작고 빠르고 간단합니다. XML 스키마처럼 .proto 파일에 protocol buffer 메세지 타입을 정의합니다.
Protocol buffers는 구조화된 데이터를 직렬화하는데 있어서 XML보다 많은 장점들을 가지고 있습니다. 대표적인 장점은 다음과 같습니다.
- 간단하다
- 파일 크기가 3에서 10배 정도 작다
- 속도가 20에서 100배 정도 빠르다
- XML보다 가독성이 좋고 명시적이다
protobuf 예시
3개 방식 비교
gRPC
- 구글에서 개발한 RPC(Remote Procedure Call) 시스템
- 전송을 위해 TCP/IP 프로토콜과 HTTP2.0 프로토콜을 사용하고 IDL로 protocol buffer를 사용합니다.
RPC(Remote Communication Mechanism)
-
원격 프로시저 호출
-
한 프로그램이 네트워크의 세부 정보를 이해하지 않고도 네트워크 안의 다른 컴퓨터에 있는 프로그램에서 서비스를 요청하느 프로토콜
-
client - server 모델을 사용
-
client에서 서비스를 요청(function call)하면, server에서 서비스를 제공
(이렇게 보면 기존 방식하고 똑같은거 아닌가?)
RPC vs REST vs GraphQL
그 동안 API 개발자들은 RESTful API만을 알고 개발을 해왔다.
그러나 최근 RPC나 GraphQL과 같은 다양한 프로토콜도 관심을 받고 있다.
많은 큰 규모의 테크회사들이 RPC를 이용하는 이유는 PRC통신이 굉장히 쉽고 high performance를 제공하기 때문이에요. 특히 내부적으로 복잡한 마이크로 서비스를 가진 회사들은 마이크로 서비스간에 수억, 수조의 통신이 발생하기 때문에 이걸 전부 http를 거쳐서 RESTful API로 통신하는것보다 군더더기 없는 RPC의 메세지가 훨씬 작아 더 경제적이고 성능면에서도 좋기때문에 최근들어 대규모시스템을 가진 회사들이 특히 RPC를 선호하는 경향이 있습니다
하지만 RPC라고 전부 좋은것만은 아니에요. 일단 어떤 서비스에서 제공하는 함수를 가지고 외부서비스가 API를 만들기때문에 시스템간에 연결관계가 너무 돈독해집니다. 그러면 독립적으로 움질일때보다 변경이나 삭제등이 필요할때 신속하게 움직일수 없겠죠. 그리고 함수명이 그대로 드러나는 형태라서 각 마이크로서비스의 내부 시스템 디자인과 구현방식이 그대로 노출된다는 단점이 있습니다.
-
각 API 방식이 주는 장단점
참고
