1. [gRPC] gRPC 소개

안녕하세요. 코딩도치입니다~

 

오늘부터 gRPC라는 것에 대해서 공부해보도록 하겠습니다.

 

마이크로서비스 아키텍처(MSA)는 이제 최신 소프트웨어 애플리케이션에서는 필수라고 할 수 있는데요.

이러한 MSA구조에서 중요한 것은 바로 프로세스간 통신 기술입니다.

 

예를 들어, MSA 구조의 온라인 판매 시스템은 주문 관리, 검색, 결제, 배송 등 서로 연결된 여러 마이크로서비스로 구성될 것입니다.

이러한 시스템 구조는 작은 단위의 서비스들이 서로 통신해야하고, 요청량에 따라 네트워크 통신 연결이 급증할 수밖에 없습니다.

그렇기 때문에, 프로세스 간 통신 기술이 분산 소프트웨어의 가장 중요한 부분이 되는 것이죠.

 

gRPC가 바로 이러한 곳에 사용하는 프로세스 간 통신 기술입니다.

 

프로세스 간의 통신에는 동기식 스타일과 비동기식 스타일이 있는데요.

동기식 스타일의 통신을 구축할 때에는 주로 HTTP 기반의 네트워크 호출을 통하는 RESTful 서비스로 구성을 많이 하였습니다.

 

그러나 많은 경우 RESTful 서비스는 프로세스 간 통신을 구축할 때 부피가 크고 비효율적이었습니다.

좀 더 효율적이고 확장성이 높은, 느슨하게 결합되는 프로세스 간 통신 기술이 요구되었고, 그렇게 등장하게 된 것이 gRPC입니다.

 

gRPC에 대해서 좀 더 이해하기 위해, 프로세스 간 통신 기술의 발전을 개략적으로 아는 것이 좋습니다.

 

RPC(Remote Procedure Calls)라는 것은 기존에도 클라이언트-서버 애플리케이션을 구축하는 데 널리 사용되는 프로세스 통신 기술이었고, RPC를 통해 클라이언트는 로컬 메서드를 호출하는 것처럼 원격으로 메서드의 기능을 호출할 수 있었습니다.

 

대표적으로 CORBA, 자바 RMI와 같은 것들이 있는데요.

이러한 RPC들은 TCP와 같은 통신 프로토콜로 구축되고 과장된 규격에 기반을 두었기 때문에 매우 복잡했습니다.

 

기존 RPC 구현의 한계로 등장한 것이, SOAP(Simple Object Access Protocol)입니다.

SOAP는 서비스 간 XML 기반의 구조화된 데이터 교환용 표준 통신 기술이며, HTTP와 같은 프로토콜을 통해 통신합니다.

하지만 이 SOAP 또한 규격의 복잡성과 메시지 포맷의 복잡성 때문에 분산 애플리케이션 구축에 맞지 않았고, 이제는 대부분 REST 아키텍처 스타일을 사용하게 되었습니다.

 

REST아키텍처 스타일의 애플리케이션 구축은 마이크로서비스를 구축하는 시작점이 됐지만,

마이크로서비스가 많아지고 이들 간의 네트워크 상호작용의 확산으로 RESTful 서비스는 최신 요구사항을 충족하지 못했습니다.

 

RESTful 서비스가 최신 마이크로서비스 기반 애플리케이션의 메시징 프로토콜로 사용할 수 없는 몇 가지 주요한 제한 사항이 있습니다.

 

- 비효율적인 텍스트 기반 메시지 프로토콜

RESTful 서비스는 HTTP1.x와 같은 텍스트 기반 전송 프로토콜로 구축되며 JSON처럼 사람이 읽을 수 있는 텍스트 포맷을 활용합니다.

하지만 서비스간 통신의 경우 사람이 읽을 수 있는 텍스트 기반 포맷을 사용할 필요가 없기 때문에 JSON과 같은 텍스트 포맷을 사용하는 것은 비효율적인 것입니다.

또한 텍스트 기반의 HTTP1을 사용하기 때문에, 바이너리(클라이언트) -> 텍스트 -> 바이너리(서버)와 같은 불필요한 변환 과정이 발생하여 비효율적입니다.

 

- REST아키텍처 스타일 강제의 어려움

구현 단계에서 REST규칙을 적용하는 것이 쉽진 않습니다.

결국 대부분 RESTful 서비스는 실질적으로 REST 스타일의 기본 규칙을 준수하지 못하고, 단순 HTTP서비스로 제공되는 경우가 많습니다.

 

이외에도 엄격한 타입 점검 부족 등의 제한 사항들이 있습니다.

 

반면에 왜 gRPC일까요.

 

- 프로세스 간 통신 효율성

gRPC는 JSON과 같은 텍스트 형식을 사용하는 대신 프로토콜 버퍼 기반 바이너리 프로토콜을 사용해 서비스 및 클라이언트와 통신합니다.

또한 HTTP/2 위에 구현되기에 프로세스 간 통신 속도가 매우 빠릅니다.

 

- 엄격한 타입 점검 형식

이전에 RESTful과 달리, gRPC는 서비스를 정의하는데 프로토콜 버퍼를 사용하기 때문에 애플리케이션 간 통신에 사용할 데이터 타입을 명확하게 정의합니다.

그에 따라 런타임과 상호운용 에러를 극복하는데 많은 도움이 되고, 디버깅이 쉽기 때문에 분산 애플리케이션 개발이 훨씬 안정적으로 이뤄질 수 있습니다.

 

이외에도 폴리글랏, 유용한 내장 기능 지원 등의 다양한 장점이 있습니다.

 

물론 gRPC도 단점이 있는데요.

 

- 외부 서비스 부적합

대부분 외부 사용자는 gRPC가 새롭고, 강력한 타입 속성을 갖기 때문에,

외부 당사자에게 노출되고 유연하게 사용되어야 하는 서비스에서는 유연성을 방해할 수 있습니다.

 

- 서비스 정의의 급격한 변경에 따른 개발 프로세스 복잡성

서비스 개발 중에 스키마 수정은 상당히 흔히 볼 수 있습니다.

gRPC서비스의 경우 정의가 변경되면 일반적으로 클라이언트와 서버 코드 모두 다시 생성해야 하기 때문에,  이러한 경우 개발 프로세스를 복잡하게 만들 수 있습니다.

 

결론적으로

gRPC는 로컬 함수를 호출하는 것만큼 쉽게 분산된 애플리케이션을 연결, 호출, 운영, 디버깅할 수 있는 프로세스 간 통신 기술입니다.

 

이렇게 gRPC에 대해서 알아봤는데요.

 

다음에는 이어서, gRPC 동작 원리에 대해서 알아보도록 하겠습니다.

 

감사합니다.

 

참고자료

gRPC 시작에서 운영까지 - http://www.yes24.com/Product/Goods/94489227

gRPC 시작에서 운영까지 - YES24