[Network] gRPC: MSA에서 서비스 간 저용량 고성능으로 통신하기

최근 MSA(Micro Servie Architecture)가 다양한 서비스에 적용됨에 따라 각각의 마이크로 서비스들이 통신하는 네트워크 비용이 자연스레 상승하게 되었습니다. 그런데 시스템들 간 모듈들이 언어가 다양하다 보니 데이터를 주고받는 게 쉽지 않았고, REST API로 개발하여 통신을 주고받으려고 하니, 각 모듈별로 서버를 띄우는 것도 부담스러운 환경이 되었습니다.

 

이에 따라 좀 더 가볍고 빠르며, 언어에 종속적이지 않게 메세지를 주고받을 수 있는 방법을 고민하던 중 나온 것이 바로 gRPC입니다. gRPC란 google에서 만든 RPC라는 뜻으로 프로세스간 통신을 위한 기법 중 하나입니다.

 

특징적으로는 다른 서버에 있는 함수를 호출할 때 마치 같은 서버에 있는 함수를 호출하듯 간편하게 호출할 수 있다는 구조를 가지고 있습니다. 예를 들면 다른 서버에 rest api로 통신하여 가져와야 했던 모듈에 관한 데이터를 단순히 import <모듈 이름> 형식과 같이 간편하게 호출할 수 있습니다.

 

특별히 구글에서 만든 RPC Framework인 gRPC는 저용량 메시지와 고성능 RPC를 지향합니다. gRPC가 저용량의 고성능 RPC가 되는데에 큰 기여를 한 데이터 타입이 있는데 바로 protocol buffer입니다. 프로토콜 버퍼는 구글에서 만든 데이터 구조로 json 형식과 다르게 데이터 자체가 바이너리 형태입니다. 따라서 컴퓨터에서 일련의 변환 가정 없이 (바이너리 자체이기 때문에) 빠르게 처리할 수 있으며, Json과 xml과 다르게 데이터의 용량도 줄어들게 됩니다. (이 역시 바이너리이기 때문에) 뿐만 아니라, json과 같은 사람이 알아보기 쉬운 Text타입보다 표현할 수 있는 데이터 구조가 많은데, 이 구조 중에는 클래스와 메서드도 포함이 되기 때문에 다양하게 확장이 가능하다는 장점이 있습니다.

 

※ 프로토콜 버퍼의 더 자세한 내용은 아래의 포스팅을 참조해주세요.

 

[Tech] Serialization에 관하여, 모두가 JSON을 쓴다고 하여 JSON만이 정답일까?

또한 HTTP/2를 기본적용하여 사용하고, 양방향 통신이 가능하기 때문에 다양하게 활용이 가능합니다. 아래의 표는 프로토콜 버퍼의 개괄적인 비교입니다.

 

기능	gRPC	JSON을 사용하는 HTTP API
계약	필수(.proto)	선택 사항(OpenAPI)
프로토콜	HTTP/2	HTTP
Payload	Protobuf(소형, 이진)	JSON(대형, 사람이 읽을 수 있음)
규범	엄격한 사양	느슨함. 모든 HTTP가 유효함.
스트리밍	클라이언트, 서버, 양방향	클라이언트, 서버
브라우저 지원	지원하지 않음(gRPC-웹 필요)	지원
보안	TLS	TLS
클라이언트 코드 생성	예	OpenAPI + 타사 도구

모든 기술에 장단점이 있듯 프토콜 버퍼 역시 약점이 있는데, 일단 제한된 브라우저의 지원을 꼽을 수 있습니다. 또한 이진 바이너리 형태이기 때문에 사람이 읽을 수 없다는 것 역시 약점입니다.

 

 

---

[참고 URL] https://docs.microsoft.com/ko-kr/aspnet/core/grpc/comparison?view=aspnetcore-3.1

gRPC 서비스와 HTTP API 비교

[참고 URL] https://blog.banksalad.com/tech/production-ready-grpc-in-golang/?gclid=EAIaIQobChMIqcSimObf6gIVEnZgCh1H3gdPEAAYASAAEgKQ0vD_BwE#%EC%99%9C-grpc%EB%A5%BC-%EC%82%AC%EC%9A%A9%ED%95%98%EB%8A%94%EA%B0%80

프로덕션 환경에서 사용하는 golang과 gRPC | 뱅크샐러드