gRPC란?

회사 기술지원팀에서 갑자기 통신 방식을 gRPC로 바꿀 예정이기 때문에

앞으로 개발할 프로젝트는 서버와 통신을 하려면 전부 gRPC를 적용해야 한다는 지침이 내려왔다.

그 당시 우리 프로젝트는 막 개발 초기 셋팅 단계였고

당연히 우리 프로젝트도 대상이었다.

쿠궁

서버와의 통신 프레임워크 구축은 내 담당이었고,,,

서버에서 제공하는 API를 붙여야 했다.

서버도 처음 붙여보는데 다른 프로젝트 코드를 참고도 할 수 없는 상황이라니 (gRPC 사용중인 프로젝트 없었음)

그러나 어쩌겠는가... 해야지..

어떻게든 해야만 했다

그 당시 gRPC적용을 위해 공부 했던 것을 간단히 정리하고 적어보려한다.

gRPC

Google에서 개발한 RPC(Remote Procedure Call) 프레임 워크
전송을 위해 TCP / IP 프로토콜과 HTTP 2.0 프로토콜을 사용하며, IDL(Interface Definition language) 로
protocol buffer를 사용

RPC(Remote Procedure Call) : 원격 프로시저 호출

RPC(원격 프로시저 호출)는 한 프로그램이 네트워크의 세부 정보를 이해하지 않고도
네트워크 안의 다른 컴퓨터에 있는 프로그램에서 서비스를 요청하는 프로토콜.
client-server 모델을 사용함. (리소스를 사용하는 앱과 (클라이언트) 존재하는 곳 (서버)을 분리시키는 모델)

이게 무슨 뜻인가 하면..

클라이언트가 원격 서버에서 실행 중인 프로시저를 로컬에서 호출하듯 사용할 수 있게 해준다는 뜻이다.

client - server 모델을 2 tier Architecture라고 하는데,

3-tier 구조도 존재한다.

(클라 <----> 서버 <----> DB)

gRPC의 장점?

1. 빠르고 가볍다

gRPC는 HTTP의 개정판인 HTTP/2로 설계

- HTTP/2는 단일 TCP 연결 내에서 여러 스트림을 동시에 주고받을 수 있음 (HTTP에 비해 효율적인 통신 방식)

ProtoBuf를 사용한 직렬화

- protoBuf는 데이터리를 바이너리 포맷으로 직렬화.

=> JSON과 같은 텍스트 기반 포맷에 비해 더 효율적이며 가볍다.

하지만 역시 그렇대~~ 라고만 믿고 쓰면

개발자라고 할 수 없지...

사내 기술지원팀 서버분께 굳이굳이

데이터 사이즈 비교해주세요!!@!@!@!@ 빼앸!@!!!!!@@! 해서 비교를 부탁드렸다...ㅋㅋㅋ

(번거롭게 해서 죄송해요)

JSON vs ProtoBuf

아래왜 같이 proto 형식의 데이터와 JSON 형식의 데이터가 있다.

// .proto

syntax = "proto3";

package test;

message Message 
{
  int32 id = 1;
  string body = 2;
  string name = 3;
  int32 age = 4;
  int32 buyCount = 5;
  double value = 6;
  bool payUser = 7;
  float fvalue = 8;	
}

{
	"id": 123,
	"body": "test",
	"name": "test_name",
	"age": 19,
	"buyCount": 100,
	"value": 123.11212323,
	"payUser": true,
	"fvalue": 22.2124405
}

JSON 대비 약 30%의 용량의 결과가 나왔다.

+ 추가로 들은 말은.. 기술지원팀 서버 개발자분께 들은 지식은...

1. string타입 이외의 데이터 타입은 바이너리로 저장되고,

2. json property의 string값이 정수타입의 인덱싱으로 관리되어 용량 절약에 용이하다고,,,

예... 감사합니다...

2. JSON에 비해 보안에 더 용이

protobuf의 바이너리 기반의 포맷

- 사람이 읽을 수 있는 Text 기반의 JSON 포맷과는 달리 바이너리 기반이기에 사람이 읽을 수 없음

=> 이는 변조 시 사람이 읽을 수 없기에 보안에 더 용이함

해당 proto파일이 바이너리로 변환된 파일이다.

string 값은 그대로 저장되었지만 나머지는 전부 바이너리로 변환되어

위조 및 변조가 쉽지 않을 것으로 보인다

호기심 해결하려고 질문하면 눈 반짝이면서

한 시간 씩 열정적으로 강의해주시는 기술 지원팀 개발자분들...

사실 완전히 이해 하고 있지는 않은데요...

항상 감사합니다 허헣

3. 코드 생성

.proto 파일을 기반으로 한 코드 자동 생성

- 서버와 클라이언트 간에 .proto 파일을 공유하여 생성된 코드의 호환을 보장해 줌.

- 기존 문서로 전달하던 API 적용의 휴먼 에러를 방지할 수 있음.

결론은,

1. 기존 Json을 사용하는 HTTP API에 대비하여 작은 패킷 사이즈
2. JSON보다 빠름
3. 바이너리 기반이기에 보안에 용이함. (사람이 읽기가 힘듦)
4. .proto 파일을 기반으로 코드를 자동으로 생성해 줌.

- c++ / c# / js 등 여러 환경에서 개발 가능
- 서버 / 클라이언트 모두 생성된 코드 호환 보장
- API 문서에 비해 휴먼 에러 방지 가능

등등..

정도로 요약될 수 있겠다.

이러한 이유로 회사에서는 gRPC를 채택하게 되었고

나는 눈물을 찔끔 흘리면서 통신을 붙였다.

왜냐하면 현재 로컬에 저장하던 데이터 구조는 상속을 이용하여

데이터가 설계된 클래스가 많았는데,

gRPC는 인터페이스를 제외하고 상속을 통한 확장을 금지하고 있기 때문이다.

이는 사실 gRPC가 상속을 금지 한다기 보다는,

gRPC가 사용하고 있는 프로토콜 버퍼가

상속을 이용할 경우 역직렬화 하는 과정에서 문제가 발생할 수 있기 때문이다.

대신 인터페이스를 사용한 확장은 가능해서

모든 UserDataContainer가 공통적으로 상속 받는 인터페이스 하나를 정의하여 관리하는 방식으로 설계했다.

+ Protocol Buffer에 대한 것은 이어서 후술해보겠음...

저작자표시 (새창열림)

'Etc.' 카테고리의 다른 글

Protocol Buffer (0)	2024.08.19

devOat

gRPC란?