gRPC (1) - gRPC의 특징 및 성능확인

Problem statement

논리적으로는 분리되어 있지만 Monolitic하게 설계된 애플리케이션이 있다고 가정하자.

• 내부 모듈 간 통신 속도가 빠르다는 장점
• 하나의 모듈에 문제가 생길 경우 애플리케이션 전체가 영향을 받음 (특정 모듈이 메모리를 과도하게 점유할 경우 시스템 전체가 죽는다던가)

그렇다보니 애플리케이션의 구조를 MicroService로 변경하려는 추세.

따라서 각각의 business / subdomain별로 별도의 시스템을 생성한 뒤 Http, Json으로 통신하는 형태의 아키텍처.

Http + Json 기반 MicroService의 단점으로 생각할 수 있는 점

1. 요청 / 응답에 걸리는 시간.
   • 오른쪽 그림처럼, TCP 커넥션을 맺은 후에야 Request / Response를 받아올 수 있는 구조.
   • Request를 보내면 Response를 받기까지 기다려야만 한다.
   • 연결 자체에 시간이 걸리는 경우도 왕왕 있음

2. Stateless한 Http 특성
   • headers / cookies 등의 값이 매번 필요하며,
   • 이 값은 plain text. 크기도 크고 압축할 수도 없음

3. Serialize - Deserialize를 매번 해줘야 함.
   • 텍스트는 CPU가 작업하기에는 상대적으로 불편한 데이터 형식. binary 형태로 변환하기 위한 절차를 매번 진행해야 한다.

4. Type Constraint의 부재
   • Json 데이터 형식 자체에는 아무런 데이터 제약조건이 없다. 필드명이나 필드값 자체에 제약조건을 설정할 수가 없음

5. Client SDK 통일성
   • 4번의 문제는 '개발자끼리 해당 필드명을 통일하도록 한다' 라거나 '통일성 이슈를 처리할 수 있는 라이브러리를 개발해 dependency로 사용한다'는 해결책이 있긴 하다.
   • 만약 개발 언어나 프레임워크가 다양하다면? 모든 언어별로 라이브러리를 사용할 수는 없다.

구글에서는 이런 이슈 때문에 내부적으로 Stubby라는 RPC 프레임워크를 사용했다.

• 10 billions Request / sec.
• Cross - platform
• Tightly Coupled with infrastructure.

• tightly coupled with infrastructure 문제를 해결하기 위해 구글에서 개발한 Remote Procedure Call.
• Inter MicroService 통신에 적합.

HTTP/2 vs HTTP/1.1

HTTP/1.1

• 1997년 등장
• TCP Connection (3 way handshake)로 connection 생성 뒤 데이터 전송 / 응답.
• static한 데이터 처리하던 시기에 사용되었으며, 데이터 전송까지의 시간이 오래 걸리는 편 (connection establish)
• 수많은 Javascript를 사용해 동적으로 웹페이지 로딩하는 현재 상황에는 그다지 적절하지 못한 편.

실제 작동방식은

브라우저에서 한 번에 맺을 수 있는 최대 커넥션 개수는 6개. 따라서 처음에 웹서버와 통신할 때 6개의 커넥션을 만들어놓고, 이 커넥션을 계속 재사용하는 구조.

HTTP/2

Multiplexing 개념의 등장

• TCP Connection 여러 개 생성하지 말고, 한 번의 Connection을 맺은 뒤 필요한 데이터 요청을 동시다발적으로 할 수 있게끔 변경됨.

기타 특장점

1. Plain text가 아니라 Binary
2. Header 값 압축 가능. 이전에 보냈던 값과 달라진 것만 전송할 수 있다 (Method, host, path 등등.. 이전 연결 시 보냈던 값과 중복될 경우 보내지 않는다.)
3. Flow Control. Streaming Request / Response 형태.

gRPC의 장점.

• Http/2 기반 동작이므로 http2의 장점을 그대로 계승
• Json 대신 Protobuf 사용.
• 대부분의 프로그래밍 언어에서 라이브러리로 형태로 제공된다.

gRPC vs REST

사실, 직접비교가 가능한 대상은 아니다. 통신 프로토콜 vs 데이터 송수신 아키텍처라는 점에서..

grpc에는 unary / stream (bidirectional) 두 가지 형태로 요청이 가능함.

REST로 100개의 concurrent Request + 리턴값 Aggregate

총 86초, 11.51 Request / sec. Max Response Time으로는 최대 9.4초까지 소요된다.

gRPC Unary로 100개의 concurrent Request + Aggregate

총 36초. 27.6 Request / sec. MAx Response Time은 최대 4.1초.

gRPC stream으로 100개의 concurrent Request + Aggregate

총 8초, 121.16 Request / sec. Max Response Time은 0.9초.