gRPC (google Remote Procedure Call)
이번 포스트에서는 내가 외주 프로젝트에서 gRPC를 사용하면서 느낀 점을 포함해서 간단하게 gRPC에 대해 소개를 해보겠다.
인터페이스
우선 gRPC는 http/2 통신을 기반으로 한 프로토콜 프레임워크다. 특징으로는 양방향 스트리밍, 통신을 위한 인터페이스를 정의할 수 있다는 것이다.
인터페이스를 정의할 때 Protobuf라는 구조화된 데이터 형식을 사용하는데 이 형식을 코드로 라이브러리를 지원하는 언어가 매우 많기 때문에 .proto 파일만 짜고 protoc를 이용해 컴파일하면 클라이언트 / 서버 사이드 구현체가 뚝딱하고 만들어 지는 것이다.
예시를 한번 보자
syntax = "proto3";
package example
service Example {
rpc ExampleEx (ExampleRequest) returns (ExampleResponse);
}
message ExampleRequest {
string name = 1;
int32 age = 2;
}
message CreateUserReply {
int64 id = 1;
}이런 .proto 파일을 만들고, protoc를 이용해서 컴파일 시켜주면 구현체가 만들어진다. 물론 언어마다 옵션을 넣어야할 게 다르다. Go는 go_package 옵션을 넣어야한다던가..
당연하지만 protoc에 종속적이기 때문에 빌드 타임 때 필요하다.
통신 종류
통신 종류도 생각보다 꽤 많다. 단순 요청, 서버 사이드 스트리밍, 클라이언트 사이드 스트리밍, 양방향 스트리밍이 있다.
직렬화 / 역직렬화
gRPC의 장점이라고 할 수 있는데 직렬화 / 역직렬화를 구현체 단에서 해준다. REST처럼 우리가 직접 json xml 같은 스펙을 정의할 필요가 없다는 것이다. 그리고 그냥 구현 단계에서 사용하면 된다. 또한 직렬화된 구조가 바이너리라서 텍스트보다 훨씬 빠르다.
다만 통신 속도 자체를 중요시하면 꽤 생각할 필요가 있다. json 같은 스펙을 사용할 경우 단순히 텍스트 형식으로만 보내서 빠르다. gRPC같은 경우에 직접 모두 직렬화를 다 수행한다. 이 말은 json 등 스펙으로 통신을 하는 것보다 느리다는 것을 의미한다. 이 글을 보면 이해가 빠르다. 예를 들어 배열같은 경우는 모두 인덱싱을 수행해야 하기에 오버헤드가 매우 크게 발생한다.
이게 내가 프로젝트를 진행하면서 굉장히 곤혹스러웠던 점이다.. 분명 빠르다고 했는데..?
REST와의 차이점
gRPC는 마이크로서비스 간의 통신, 실시간 데이터 스트리밍, 효율적인 네트워크 대역폭 사용이 필요한 경우에 적합하다. 반면, REST는 웹 애플리케이션, 브라우저와의 통신, 간단한 HTTP 요청/응답 패턴에 더 적합하다.
- 참조
♥️