gRPC와 Protocol Buffers에 대해 알아보자 (1)

현회사는 gRPC를 통해 내부 마이크로 서비스 간의 통신을 하고 있다. gRPC라는 것을 처음 들어본 나에게는 굉장히 생소한 개념이라 나와 같이 처음 접하는 사람들에게 도움이 되었으면 하는 바람에 이 글을 작성하고자 한다. 이 글에서는 gRPC에 대해 자세히 알아보고, 이후 Protocol Buffer에 대해 알아볼 것이다. 

gRPC란 무엇인가? 를 알기 전에 🚥🖐️

구글에서 개발한 오픈소스 RPC이다. 여기서 잠깐, RPC란 무엇인지 짚고 넘어가자. 많이들 알 수 있지만 RPC가 무엇을 하는지 알아야 gRPC에 대해서도 이해하기 수월할 것이다. 나처럼 RPC를 모르는 사람에게 아래 내용을 바친다. 

 

RPC란?

RPC는 Remote Procedure Call로 원격 프로시저 호출을 말한다. 네트워크를 통해 다른 컴퓨터나 서버에 있는 함수나 프로시저를 호출하는 방법이다. 실제 원격 호스트의 프로시저를 로컬에서 호출하는 것처럼 사용하는 것이다. 

자, 이제 개념은 알았다. 도대체 이건 어디에 쓰이는 걸까? 필자는 보통 예시가 있으면 이해하기가 쉽기에 예를 하나 들어보겠다. 

우리가 주문, 재고 관리를 포함한 여러 도메인이 각각 독립된 서비스로 구현된 온라인 커머스를 개발 및 운영하고 있으며 RPC를 사용하지 않고 있다고 가정해보자. RPC를 사용하지 않을 경우, 내가 생각한 문제점은 아래 2개이다. 

1. 서비스 간에 강한 결합이 일어난다. 
   주문 시에 상품 재고를 확인하기 위해 주문팀에서 직접 재고 관리팀 관할의 DB와 직접 통신해야 한다. 이는 주문팀에서 재고 관리 테이블의 구조를 명확하게 알아야 하고, 테이블이 변경된다면 주문 코드도 변경되어야 할 수 있다. 각 서비스 간의 독립성이 사라지고, 유지보수가 어려워지게 된다. 
2. 복잡한 예외 처리를 해야 한다.
   만약, 데이터베이스 연결, 쿼리 오류 등의 문제로 처리에 실패한다면 주문팀에서 재고 관리 테이블을 위한 예외 상황에 대한 코드를 추가해야 할 것이다. 주문 처리에 집중하는 것이 아닌 관련 없는 재고 관리 테이블의 예외 상황마다 코드를 추가하면 재고 관리와 관련된 상황에 대한 책임이 모호해지고 복잡도가 점점 높아지게 된다. 

 

RPC를 사용하게 되면 위와 같은 문제를 해결할 수 있다. 재고 서비스에 재고 확인을 위임하여 주문팀에서는 직접 데이터베이스를 호출하지 않고, 재고 서비스를 호출해서 필요한 정보를 가져올 수 있게 된다. 이로 인해 주문팀에서는 재고 관리 데이터베이스 구조를 정확하게 알지 않아도 된다. 또한, 주문 서비스는 간단하게 재고 관리 서비스에 요청 하나만 보내면, 데이터베이스 연결, 쿼리 오류 등의 모든 예외 상황은 재고 관리 서비스 내부에서 처리하게 되므로, 주문 서비스 본래의 책임에 집중할 수 있게 된다. 이처럼, 각 서비스가 서로 독립적으로 동작하면서도 서로에게 필요한 것들에 대한 통신은 간단하게 이루어져 서비스 간 결합도를 낮추고 확장성을 높일 수 있게 된다. 

 

우리는 네트워크 통신을 할 때, 아래와 같은 문제들을 해결해야 한다. 

1. 어떻게 데이터를 보낼지?
2. 어떻게 서로 통신할지?
3. 요청과 응답 제어는 어떻게 할지?

RPC는 네트워크를 통해 원격 프로시저 호출을 가능하게 하여, 위 문제들을 해결한다. 데이터를 포맷팅해서 네트워크로 전송하는 기능을 갖고 있으며, 클라이언트와 서버 간의 프로토콜을 정의하면 서로 다른 언어로 구현된 시스템도 통신 가능하다. 또한, 요청과 응답의 흐름을 정의하여 네트워크 통신을 처리할 수 있게 된다. 

 

gRPC란 무엇인가? 🏃‍♀️💨💨

다시 돌아와 gRPC에 대해 이야기해보겠다. 분산 시스템에서 서로 다른 서비스들이 네트워크를 통해 통신할 때, 마치 같은 컴퓨터 안에서 실행되는 함수처럼 간단하게 호출할 수 있도록 만들어주는 도구이다. RPC의 기능을 기반으로 좀 더 효율적인 방식으로 최적화되었다. 

• 좀 더 빠르고 효율적인 데이터 전송
  
  • 기존 RPC는 데이터를 JSON, XML 같은 텍스트 기반 포맷으로 직렬화를 해서 전송한다. 이와 같은 형식은 사람이 읽기에는 쉬우나 데이터가 크고 느리다. 하지만, gRPC는 다음에 다룰 Protocol Buffer를 사용하여 바이너리 포맷으로 데이터를 직렬화해서 훨씬 작고 빠르게 보낼 수 있다. 
• 다양한 언어 지원
  • 기존에는 언어 간 데이터 호환성이 있긴 했지만, JSON, XML 같은 포맷들은 처리 비용이 굉장히 컸다. 반면, gRPC의 Protocol Buffer는 여러 언어에서 바로 사용 가능하고, 자동 코드 생성 도구를 제공하여 개발 효율성을 높일 수 있다. 
• HTTP/2 기반 통신
  
  • 이전엔 HTTP/1.1이나 TCP를 사용하여 기본적으로 요청-응답 방식에 초점을 맞추었다. gRPC는 HTTP/2를 기반으로 동작하며 양방향 스트리밍, 하나의 연결로 여러 요청 처리를 동시에 가능하게 하고, 헤더 압축을 통해 네트워크 사용량을 줄였다.
• 생산성 향상
  • gRPC는 .proto 파일을 만들면 각 언어에 맞는 클라이언트/서버 코드를 자동으로 생성해준다. 기존은 자동화 도구가 부족하여 언어마다 인터페이스를 수동으로 작성해야 하는 경우가 많았다.

마이크로서비스 아키텍처에서 서비스 간 통신이 필요하거나 빠르고 효율적인 네트워크 통신이 중요한 실시간 애플리케이션, 언어와 플랫폼에 구애받지 않는 통신을 원한다면 위와 같은 장점을 갖고 있는 gRPC가 굉장히 유용하게 사용될 것이다.

 

마무리하며

ㅍ1✌드백 혼ㅏ영❢

지금까지 RPC와 gRPC의 개념, 그 둘의 차이에 대해 알아보았다. 다음에는 gRPC에서 사용하는 Proto Buffer 에 대해 알아볼 것이다. 이 글이 RPC 혹은 gRPC에 대해 처음 들어본 사람들에게 도움이 되었으면 한다. 피드백은 언제나 환영이다.