gRPC는 언제 써야하는걸까?

 

gRPC 많이 들어본 단어다. 이름에서 보듯 RPC를 이용한 기술이고, REST API 대신 쓸 수 있다고는 대충 들었는데... 대체 언제 쓰고 왜 쓰는 걸까?

 

gRPC에 대해서 자세히 한 번 알아보자

 

Remote Procedure Call (RPC)

---

Remote Procedure Call 한국말로 원격 프로시저 호출로 불리는 RPC는 네트워크 안에 있는 다른 컴퓨터의 함수를 마치 Local 환경에 있는 것처럼 실행하는 통신 기술이다. 이게 대체 무슨 말일까?

 

예를 들어 클라이언트가 서버로 요청을 보낸다고 해보자. REST API를 사용해 타 서버를 호출하려면 어떤 URL로 경로를 잡을지, HTTP Method(GET/POST)는 뭘로 할지, Request/Response 객체는 어떻게 파싱 할지 등 고민해야 할 부분이 꽤 많다.

Mono<AddResponse> response = webClient.post()
    .uri("http://server-b/api/v1/calculator/add") // 1. URL 경로 직접 지정
    .header(HttpHeaders.CONTENT_TYPE, MediaType.APPLICATION_JSON_VALUE) // 2. 헤더 설정
    .bodyValue(new AddRequest(10, 20)) // 3. DTO 객체 전달
    .retrieve()
    .bodyToMono(AddResponse.class);

 

위 코드처럼 REST API는 URI, Header, Body 등 개발자가 직접 챙겨야 할 요소들이 많다. 반면 RPC는 Stub이라는 친구를 통해 이러한 통신 복잡성을 감추고, 훨씬 간결하게 타 서버의 함수를 호출할 수 있게 해준다.

 

Stub은 뭘까?

RPC 통신 구조 (From Reference 2)

 

소프트웨어 테스트를 작성해 본 분들이라면 Stub이라는 개념이 친숙할 것이다. 테스트에서 Stub은 필요한 응답 상태를 미리 만들어 두고 테스트 환경을 구축할 때 사용하는 가짜/더미 코드(Dummy Code)를 말한다.

 

RPC의 Stub도 비슷한 역할을 한다. 개발자가 로컬 함수를 부르는 것처럼 느끼게 하려고, 네트워크 연결부터 데이터 포장/해제 같은 복잡한 작업들을 Stub 내부에서 다 처리해 준다. 덕분에 클라이언트는 그저 stub.add(10, 20)처럼 함수 하나만 가볍게 불러도 알아서 통신이 이뤄진다.

 

하지만 RPC도 만능은 아니다. 가장 대표적인 단점은 서버와 클라이언트 간의 강한 결합도다. REST API는 JSON에 새로운 필드가 추가되어도 클라이언트가 무시하면 그만이지만, RPC는 서버 측 함수 명세(Signature)가 바뀌면 클라이언트의 Stub 코드도 다시 생성해서 재컴파일 및 재배포를 해야 한다. 유연성이 떨어지고 매번 동기화를 맞춰줘야 하는 번거로움이 존재한다.

 

구글인 이런 장점과 단점을 가지고 있는 RPC 시스템을 이용해서 Stubby라는 내부 전용 RPC 시스템을 만들어서 운용했었다. 이 Stubby 아키텍처 위에 HTTP/2와 Protobuf를 결합해서 오픈소스로 공개한 게 gRPC다.

 

gRPC

---

자 그럼 본격적으로 gRPC에 대해서 더 알아보자. 

 

gRPC의 첫 번째 특징으로는 HTTP/2를 기반으로 하는 Protocol을 따른다. 헤더 압축, 멀티플렉싱, 바이너리 프레이밍을 지원하여 기존 HTTP/1.1 대비 지연 시간과 대역폭 효율이 크게 개선되었다. 특히 하나의 TCP 연결 안에서 양쪽이 동시에 데이터를 쏟아낼 수 있는 풀 듀플렉스 덕분에 양방향 스트리밍이 가능해졌다.

 

두 번째 특징은 Protocol Buffers(줄여서 Protobuf)라는 데이터 형식을 사용한다. JSON 같은 텍스트 포맷이 아닌 바이너리(Binary) 형식으로 데이터를 주고받아 속도가 압도적으로 빠르고 용량이 작다. 다만 사람 눈으로 패킷을 바로 읽을 수 없어 디버깅할 때 애를 먹기도 한다. 또한 Protobuf는 RPC의 특성상. proto 파일에 스키마를 항상 명확히 정의해 줘야 한다.

 

 

 

Protobuf는 다양한 역할은 해주는 아주 재미있는 친구다.  Protoc 컴파일러를 통해 Java, Go, Python, C++ 등 다양한 언어의 Stub 코드를 자동으로 생성해 준다. 이 덕분에 서로 다른 언어로 개발된 마이크로서비스끼리도 언어의 장벽 없이 완벽하게 소통할 수 있다.

 

그럼 이 야무진 gRPC를 언제 쓸 수 있을까?

대표적인 예로 내부 마이크로서비스 간에 통신에 사용될 수 있을 것 같다. 마이크로서비스는 필요에 따라서 다른 언어로 만들어지는데, gRPC는 서비스가 각각 다른 언어로 개발되어 있더라도 언어 제약이 없고, JSON 대비 통신 속도가 월등히 빠르기 때문에 백엔드 서비스 간 내부 통신에 최적이다.

 

두 번째로는 High-frequency Trading처럼 속도가 중요한 소프트웨어에서도 효과적으로 쓰일 수 있을 것 같다. 초당 수만 건의 데이터가 왔다 갔다 해야 하는 소프트웨어에서는 REST API 보다 빠른 gRPC가 좀 더 강력하게 사용이 가능할 것 같다.

 

마지막으로는 양방향성을 이용한 서비스 (자율주행, 실시간 대화 서비스 등)에 사용할 수 있을 것 같다. 유저나 센서의 상태/위치 데이터를 실시간으로 서버에 쏘아 올리면서, 동시에 서버의 제어 명령이나 응답을 비동기로 즉시 받아 처리해야 하는 시스템에는 gRPC가 가진 특징이 유용하게 쓰일 수 있을 것 같다.

 

 

 

 

 

Reference

---

https://www.geeksforgeeks.org/operating-systems/remote-procedure-call-rpc-in-operating-system/

Remote Procedure Call (RPC) in Operating System - GeeksforGeeks

 

https://web.mit.edu/6.033/1997/reports/dp1-danlief.html

 

https://www.geeksforgeeks.org/software-engineering/what-is-grpc/

What is gRPC? - GeeksforGeeks

https://www.geeksforgeeks.org/distributed-systems/grpc-communication-in-distributed-systems/

https://www.geeksforgeeks.org/computer-networks/what-is-http-2/