요즘 떠오르는 gRPC 톺아보기

gRPC는 왜 실용적일까?

이 글은 gRPC를 접한 지 얼마 안 됐거나 새롭게 알아보고 싶은 사람을 대상으로 go, gRPC 그리고 MSA 환경에서의 실무 경험을 기반하여 작성되었습니다.

저는 gRPC는 인프라 구축에 있어 다소 러닝커브가 있는 편이지만 굉장히 실용적이라고 생각합니다.

오늘은 이에 대한 이야기를 해보려고 해요.

 

먼저, gRPC는 무엇일까요?

gRPC는 한 문장으로 다음과 같이 정의해볼 수 있습니다.

gRPC는 Protocol Buffer를 IDL(Interface Definition Language)로 사용하는
HTTP/2기반의 RPC 프레임워크입니다.

생소한 단어들이 많을 수 있을 것 같은데요! 잠깐 몇 가지 살펴볼까요?

• RPC(Remote Procedure Call)
  • RPC는 말 그대로 원격 프로시저를 호출하는 기술을 의미합니다.
  • 우리가 흔히 알고 있는 RESTful API와 비슷한데, 예전부터 존재하던 개념이에요.
  • 이전에는 RESTful이 좀 더 인기가 많아서 RPC가 묻혀졌다(?)는 이야기가 있어요.
• Protocol Buffer
  • gRPC에서 통신을 위한 interface를 정의하는데 사용하는 문법&형식! 입니다.
  • 간단하게는 json과 같은 데이터 통신 형식으로 볼 수 있습니다!
  • 우리가 API를 개발할 때, interface를 정의할텐데 이를 gRPC에서는 Protocol Buffer 문법을 이용해 정의하게 됩니다.

 

본격적으로 들어가기 전에 gRPC의 특징들을 몇 가지 살펴볼까요?

gRPC의 특징을 나열해보면 다음과 같습니다!

 

1. IDL 기반으로 각 언어별 client 코드와 server 뼈대 코드를 자동 생성(generate)

Protocol Buffer로 작성된 IDL을 기반으로 각 언어별 client 코드&server 뼈대 코드를 간단한 명령으로 자동 생성할 수 있습니다.
여기서 각 언어별로 컴파일러가 존재하고 이는 gRPC에서 제공하고 있어요!
이렇게 하면 다음과 같은 효과를 누릴 수 있습니다!

1. API 작업 시 IDL을 가장 먼저 작성하기에 나름 검증된 API 문서화
   • PR 리뷰에서 협업자와 payload 정의에 의견을 주고받기도 해요(네이밍 등등)
2. IDL을 SSOT(Single Source Of Truth)로 사용
   • IDL은 신뢰할 수 있는 단일 문서를 의미하고 이를 기반으로 소통 비용을 절약합니다.

2. payload 압축률이 높은 Protocol Buffer를 사용

gRPC에서는 압축률이 높은 Protocol Buffer를 IDL(Interface Definition Language)로 사용합니다

Protocol Buffer에는 성능을 위한 고민들이 녹아져습니다. 이는 조금 뒤에 알아보죠!

자 이제 위에 나열한 특징들을 한 번 톺아보도로오오오옥~~ 하겠습니다!!

 

IDL

위에서 계속 이야기했던 IDL에 대해서 좀 더 살펴봅시다.
먼저 gRPC에서 IDL 문법으로 사용하는 Protocol Buffer에 대해 알아보고, 어떻게 작성하고 활용되는지 살펴볼게요!

 

Protocol Buffer와 그의 압축률

MSA 환경에서 네트워크 지연시간을 줄이는 것은 굉장히 중요합니다.
그리고 아시다시피 payload 압축은 네트워크 지연시간을 줄이는 방법 중에는 하나죠.

gRPC의 기반이 되는 Protocol Buffer와 HTTP/2에는 이런 압축과 관련된 고민들이 많이 녹아져 있는데요, 먼저 Protocol Buffer가 payload를 어떻게 압축하는지 살펴보려고 합니다.

 

Protocol Buffer 란 무엇일까요?

• JSON/XML과 같이 데이터를 표현하는 형식이며
• .proto 확장자를 가진 파일에 기록되고
• binary format(이진 포맷)으로 저장되어 사람이 읽을 수 없고
  (사실 이를 역직렬화(Unmarshaling)하면 읽을 수 있긴 합니다.)
• 압축률이 높아 JSON/XML에 비해 데이터 크기를 크게 절약합니다.

Protocol Buffer에서는 payload를 message 라는 키워드로 다음과 같이 정의할 수 있는데요, 다음과 같이 Person이라는 message를 정의해볼 수 있습니다.

(네이밍 관련한 컨벤션은 여기서 다루지 않습니다)

그리고 위 Person 메시지를 Protocol Buffer 형식으로 나타내면 다음과 같이 나타낼 수 있습니다.

그림이 조금 복잡한데.. 눈치채신 분들도 있겠지만 위에서 message를 정의할 때 각 필드의 옆에 숫자들이 보이시나요?

위 이미지의 좌측을 살펴보면, field tag와 type을 미리 지정해둔 이진 포맷으로 변경하여 인코딩하는 것을 볼 수 있습니다.

이는 곧 payload key값의 압축을 의미하는데요! 다음 json형식과 비교하며 이해해보죠

위 protocol buffer로 표현한 데이터를 똑같이 json으로 표현해보았습니다.

// 82bytes
{
    "userName": "Martin",
    "favouriteNumber": 1337,
    "interests": ["daydreaming", "hacking"]
}

이 데이터의 크기를 살펴보면 82bytes입니다
그리고 위 protocol buffer로 표현된 것은 이미지의 우측 하단 보면 33bytes라는 걸 알 수 있어요.

바로 “userName”, “favouriteNumber”, “interests” 이런 key 값들이 압축된 것이죠

조금 과장 보태서 무려 248% 압축률을 자랑합니다..! (82Bytes → 33Bytes)

RESTful에서도 gzip과 같은 압축을 이용하면 되는 거 아닌가? 하는 생각이 들지만
gRPC도 gzip과 같은 압축을 활용할 수도 있고 개인적으로 gRPC를 기술적으로 선택하는 이유는 이런 압축률보다 IDL을 활용한 실용성에 있다고 생각합니다!

이에 대한 내용은 아래에서 좀 더 알아보겠습니다.

 

IDL 기반의 Client-Server 코드 자동 생성

gPRC는 각 언어별로 Client-Server 코드를 자동 생성해주는 protoc라는 컴파일러가 존재합니다.
그리고 이렇게 자동 생성한 Client-Server를 기반으로 개발하게 됩니다.

이런 구조가 무엇을 의미하고 어떤 게 효율적인 걸까요? 🤔

제 생각은 이렇습니다.

1. protoc를 이용한 코드 자동 생성으로 기존 Client 코드를 작성하는 시간을 절약해줍니다.
   이는 해당 api를 사용하는 client service가 많을수록 더 많은 시간을 절약하게 됩니다. 소위 말하는 N배의 효율을 낼 수 있는 것이죠.

2. IDL을 기반으로 Server-Client 코드를 생성하기 때문에 IDL이 SSOT(Single Source Of Truth)가 되어 커뮤니케이션 비용을 절약합니다.
   개발하다 보면 항상 API 문서화는 API를 개발한 이후에 진행하게 되지만,
   gRPC는 구조적으로 IDL을 먼저 작성하게 함으로써 어느 정도 검증된 API 문서화를 강제합니다.
   저는 이런 구조적 개선을 좋아하는데요, 이런 면에서 gRPC는 굉장히 긍정적입니다.

 

golang 기준으로 protoc 컴파일러를 통해 어떤 코드들이 생성되는지 잠깐 살펴볼까요?
여기 예시로 content service를 정의한 content.proto파일이 있습니다.

 

이 content.proto 파일을 가지고 아래와 같은 protoc 명령어를 실행하면

아래와 같이 content.pb.go , content_grpc.pb.go 파일이 자동 생성됩니다.

 

이제 이 파일들에는 어떤 코드들이 들어있는지 확인해보면..?

이렇게 위 content.proto 파일에서 정의한 내용 기반으로 message의 struct와 ListContents rpc interface가 만들어진 것을 확인해볼 수 있습니다!

 

이렇듯 IDL을 SSOT로 Server-Client 코드를 생성하는 것을 살펴보았습니다.
이렇게 코드를 자동 생성하는 것은 golang 외에도 다양한 언어들을 지원하고 있어요.
(go, java, kotlin, python, swagger, swift, typescript…)

 

 

SSOT인 IDL 그리고 MSA

소위 말하는 MSA 환경에서 IDL을 SSOT로 사용할 때의 장점은 극대화됩니다.

모든 서비스가 SSOT인 IDL을 바라보기만 하면 되니

• 정말로 다른 서비스 컴포넌트의 구현은 신경 쓰지 않아도 되고
• 각 컴포넌트에서 최신화를 어떻게 할 것인지를 고민하지 않아도 됩니다.
  이건 최신화된 IDL을 generate하는 것만으로 해결될 테니까요.

이렇게 IDL이라는 규칙을 만들어서 구조적으로 고민거리를 줄이는 것 또한 제가 생각하는 실용적 요소 중 하나입니다.

 

서드파티 API와 IDL

서드파티 API(외부 API)를 이용할 때도 IDL을 이용하면 문서화를 챙겨볼 수 있습니다.

IDL option 중에서 [json_name] option을 이용하면 서드파티 API의 필드명을 원하는 대로 커스텀해서 사용해볼 수 있는데요!

다음과 같이 사업자등록번호와 국문명을 알 수 있는 서드파티 API의 Company message를 정의하고 적절하게 팀 내 컨벤션에 맞게 네이밍을 변경해볼 수 있습니다.

 

HTTP/2의 실용성

여기서 자세히 다루진 않을 것이지만,
HTTP/2에도 네트워크 비용을 줄이기 위한 아래와 같은 다양한 고민들이 녹아져 있습니다.

관심 있는 분들은 찾아보면 좋을 것 같아 키워드들 몇 개를 남겨둡니다!

• 바이너리 프레이밍
• 헤더 압축
• 멀티플렉싱(Multiplexing)
• TLS 위에서 동작
• 등등..

Summary

여기까지 gRPC는 왜 실용적일까?에 대해서 짧게 알아봤는데요 정리해보면 다음과 같습니다.

1. IDL(Protocol Buffer)을 이용해 나름 검증된 API와 문서화를 강제
   IDL정의 → 개발 의 과정으로 이루어지기에 API 요청-응답이 검증되어 있고
   API 문서화가 구조적으로 강제됨.
   SSOT(Single Source Of Truth)로 이용하여 소통 비용 절약

2. Client-Server 코드 자동 생성으로 생산성 향상
   각 코드를 자동 생성해주는 컴파일러 protoc!! 이건 히트다..
   golang은 gomock을 이용하면 mock code까지 자동 생성이 가능해요!

3. 고성능 통신으로 네트워크 비용 절약
   실전 경험상 client 통신이 많아 이건 좀 느린 것 같은데? 싶은 것도 빠르고
   여기서 자세히 다루지 않았지만 HTTP/2에 녹아져 있는 성능 최적화 고민들도 한몫합니다
   (+ golang의 goroutine을 이용한 고성능 동시성 처리는 덤!)

마치며

여러분들은 이 글을 읽고 gRPC에 흥미가 생기셨나요?

이 글에 담고 있는 내용들을 보면 MSA 환경에서 gRPC의 효율이 극대화되는 것을 알 수 있습니다.

아 물론 MSA 환경이라면 gRPC를 무조건 사용해라! 라는 건 아닙니다.
gRPC를 도입하기 위한 인프라 등 풀어야 할 문제들이 몇 가지 존재하고, 아직 레퍼런스가 많이 없는 것이 사실입니다.
하지만 그럼에도 gRPC를 도입할 준비가 되어있는 환경이라면 저의 대답은 Wht Not? 입니다.

그리고 무엇보다 운영에서 각 상황에 맞는 트레이드오프는 항상 필요하기에
엔지니어로서 적절한 선택을 그리고, 자주 선택하셨으면 좋겠습니다.

긴 글 읽어주셔서 감사합니다 🙏