MSA 개발 방식이 주목받으면서 gRPC도 같이 부상중에 있다. 이번 포스팅에서는 gRPC의 기본 개념을 초급 개발자도 이해할 수 있도록 쉽게 풀어서 적어볼까 한다. (내가 초급개발자니까..)
우선 gRPC를 이해하기 위해서는 몇 가지 개념을 이해해야한다.
1. RPC (Remote Procedure Call)
2. protocol buffer
3. HTTP2.0
왜냐하면 gRPC는 protocol buffer를 사용해서 HTTP2.0 규격으로 다른 프로시저를 호출하는 RPC 통신 기술이기 때문이다.
그럼 RPC가 무엇인지부터 알아보겠다.
1. RPC
: 한 프로그램이 네트워크의 세부 정보를 이해하지 않고도 네트워크 안의 다른 컴퓨터에 있는 프로그램에서 서비스를 요청할 수 있게 하는 통신 기술이다.
위 그림처럼 RPC는 Client-Server 모델을 사용하는데, client 쪽에서 서비스 요청을 하면 server에서 응답을 하는 방식으로 통신을 한다.
네트워크로 연결된 서버 상의 프로시저(함수, 메소드 등)를 원격으로 호출하기 때문에
통신이나 call 방식에 신경쓰지 않고 원격지의 프로시저에 접근이 가능하다.
gRPC는 구글에서 개발한 RPC 통신 규격이라고 이해하면 된다.
2. protocol buffer
: IDL (Interface Definition Language)의 한 종류로, 같은 언어를 사용하지 않는 소프트웨어 컴포넌트 사이의 통신을 가능하게 하는 인터페이스 정의 언어이다.
대표적으로 많이 사용되는 IDL에는 XML, JSON 등이 있다.
각 언의 특징은 스킵하고, protocol buffer가 기존 IDL과는 다른 점을 알아보겠다.
① 데이터 직렬화 (data serialization)
- 메모리를 디스크에 저장하거나 네트워크 통신에 사용하기 위한 형식으로 변환하는 것
proto buffer의 경우 여러 언어에서 호환가능한 인터페이스 정의 언어이기 때문에, 각 언어마다 다른 데이터 규격을 맞춰주기 위해 데이터를 binary stream 형식으로 변환하여 사용하고 있다.
또 참조형 데이터의 경우 각 pc마다 저장하고 있는 메모리 주소가 다르기 때문에 직렬화 하여 값 형식 데이터로 변환이 필수이다.
② 저용량 고성능
- 데이터를 binary 형식으로 변환하기 때문에 다른 IDL 언어에 비해 가볍고 오류가 적다.
XML 대비 속도는 20~100배 빠르고, 파일 크기는 3~10배 작다고 한다.
③ 높은 가독성
.proto 파일은 proto syntax 로 작성하기 때문에 일반 프로그래밍 언어로 작성하는 것과 비슷하게 인터페이스를 정의할 수 있다. 자세한 문법은 공식문서를 통해 확인 가능하다.
https://developers.google.com/protocol-buffers/docs/proto3
Language Guide (proto3) | Protocol Buffers | Google Developers
Language Guide (proto3) This guide describes how to use the protocol buffer language to structure your protocol buffer data, including .proto file syntax and how to generate data access classes from your .proto files. It covers the proto3 version of the pr
developers.google.com
3. HTTP2.0
gRPC가 HTTP2.0 규격으로 데이터를 주고 받고 있기 때문에 그 특징을 이해할 필요가 있다. HTTP2.0은 기존 HTTP1.0, HTTP1.1 의 단점을 개선하고 성능향상에 맞춘 프로토콜이다.
기존 HTTP1.0은 하나의 connection당 하나의 Request, Response를 처리했는데 여기서 속도 문제가 발생하게 됐다.
그 단점을 개선하고자 나온 것이 HTTP1.1 이다.
HTTP1.1은 개선 방안으로 pipelining을 적용했는데, 하나의 connection을 통해 다수의 파일을 Request/Response로 받을 수 있는 기법이다.
하지만 pipelining 기법은 첫번째 파일에 대한 처리가 늦어지면 같은 connection 내에 있는 다음 번째 request에 대한 처리도 늦어지는 지연현상을 발생하게 했다.
이 단점을 개선시킨것이 HTTP2.0 이다.
Message 단위가 아닌 frame 단위로 데이터를 나누어서 처리가 빠르도록 개선했다.
또 Multiplexed Stream 방식을 사용해서 한 connection으로 여러개의 메세지를 주고 받을 수 있고, 순서에 상관없이 response를 stream으로 처리할 수 있게 했다.
나머지 HTTP2.0 특징은 역시 공식문서에서 확인 가능하다.
HTTP/2
This is the home page for HTTP/2, a major revision of the Web's protocol. It is maintained by the IETF HTTP Working Group. What is HTTP/2? HTTP/2 is a replacement for how HTTP is expressed “on the wire.” It is not a ground-up rewrite of the protocol; H
http2.github.io
여기까지 선행지식이었고, 본격적으로 gRPC가 무엇인지 알아보도록 하겠다.
gRPC는 위의 요소를 갖추고 있는 RPC 프레임워크이다.
- proto buffer를 사용해서 언어제약없이 구현 가능
- 클라이언트, 서버 및 양방향 호출 지원
- 이진 직렬화 사용 -> 네트워크 사용량감소
- 분산 프로그래밍(MSA)에 큰 이점
사실상 MSA 때문에 gRPC가 각광받게 됐기 때문에 MSA에서 gRPC가 어떻게 활용될 수 있는지 간단히 적어보겠다.
MSA는 여러개의 작은 프로시저들이 모여 하나의 큰 프로그램을 이룬다는 특징을 갖는다.
하나의 서비스 안에 각 서비스들이 세부적으로 나눠져 있다고 가정해보겠다. 같은 서비스 회사에서 다른 언어로 여러 프로세스가 개발되어 있는 경우에 각 프로세스간 통신이 힘들다는 문제점이 있다.
그때 이 문제를 gRPC를 통해 해결할 수 있다. proto 파일에 미리 통신 규격을 정해두면 언어의 충돌 없이 프로시저 호출이 가능해지기 때문이다.
- Stub : 함수 호출에 사용된 매개 변수를 변환
서버, 클라이언트 서로 다른 주소 공간 사용
- Client Stub :
함수 호출에 사용된 파라미터 unmarshalling 및
함수 실행 후 서버에서 전달 된 결과 변환
- Server Stub :
클라이언트가 전달한 매개 변수의 역변환 및
함수 실행 결과 변환 담당
(혹은 스켈레톤이라고 명명하기도 하는듯)
Client는 원격지(Server)의 프로시저를 끌어다 로컬처럼 사용가능
-> 확장성 ↑, 분산 프로그래밍 환경에 이점을 갖는다.
이런 원리로 작동하는 gRPC는 현재 이미 많은 서비스 회사에서 사용하고 있다고 한다. 다만 내가 이 세미나를 준비하게 된 이유가 Server-Front 사이의 통신을 대체할 수 있을지 없을지를 논의하기 위해서 였기 때문에 REST API 통신과의 차이점도 정리해보려고 한다.
대체로 속도와 호환성면에서 gRPC가 우수하나, gRPC는 브라우저 지원을 하지 않기 때문에 아직 front와의 통신을 대체하기에는 무리가 있다고 결론을 내렸다.
그리고 회사에서 사용하는 주 개발 언어가 GO 이기 때문에, GO를 사용해서 예제를 만들어보았다.
https://github.com/csohb/probufExample
GitHub - csohb/probufExample
Contribute to csohb/probufExample development by creating an account on GitHub.
github.com
질문이 있으시면 되도록 구글링을 추천하지만... 그래도 혹여나 있다면 댓글 남겨주세요
'Golang' 카테고리의 다른 글
| Golang Docker-Kafka 프로그램 2 (0) | 2022.04.05 |
|---|---|
| Golang Docker Kafka 프로그램 (0) | 2022.04.05 |
