programming/grpc

gRPC 그리고 RPC, 정의 및 역사

jamie91 2023. 6. 26. 21:01

1. gRPC란 무엇일까?

gRPC는 구글이 최초로 개발한 오픈 소스 원격 프로시저 호출 시스템이다. 전송을 위해 HTTP/2를, 인터페이스 정의 언어로 프로토콜 버퍼를 사용하며 인증, 양방향 스트리밍 및 흐름 제어, 차단 및 비차단 바인딩, 취소 및 타임아웃 등의 기능을 제공한다.
출처: 위키백과(링크)
여기서 구글이 최초 개발했다고 하는 기술은 RPC 기술이 아닌 protocol buffer를 통한 RPC 기술을 말합니다.
Protocol buffer는 google 사에서 개발한 구조화된 데이터를 직렬화(Serialization)하는 기법입니다.
이전까지는 RPC 기능은 지원하지 않고, 메세지(JSON 등)를 Serialize 할 수 있는 프레임워크인 PB(Protocol Buffer, 프로토콜 버퍼)만을 제공해 왔는데, PB 기반 Serizlaizer에 HTTP/2를 결합하여 RPC 프레임워크를 탄생시키게 되었습니다.

 

 

 

 

2. 그렇다면 RPC 란 무엇일까?

원격 프로시저 호출(영어: remote procedure call, 리모트 프로시저 콜, RPC)은 별도의 원격 제어를 위한 코딩 없이 다른 주소 공간에서 함수나 프로시저를 실행할 수 있게 하는 프로세스 간 통신 기술입니다. 다시 말해, 원격 프로시저 호출을 이용하면 프로그래머는 함수가 실행 프로그램에 로컬 위치에 있든 원격 위치에 있든 동일한 코드를 이용할 수 있습니다.

MSA(Micro Service Architecture) 구조로 서비스를 만들다 보면, 다양한 언어와 프레임워크로 개발되는 경우가 잦습니다. 이런 Polyglot 한 구조에서는 프로토콜을 맞춰서 통신해야 하는 비용이 발생합니다.
이 경우에 RPC를 이용하여 언어에 구애받지 않고, 원격에 있는 프로시저를 호출하여 조금 더 비즈니스 로직에 집중하는 개발을 할 수 있습니다.

 

 

 

 

3. RPC의 궁극적인 목표

1. 클라이언트-서버 간의 커뮤니케이션에 필요한 상세정보는 최대한 감춥니다.
2. 클라이언트는 일반 메소드를 호출하는 것처럼 원격지의 프로지서를 호출할 수 있습니다.
3. 서버도 마찬가지로 일반 메서드를 다루는 것처럼 원격 메서드를 다룰 수 있습니다.

 

 

 

 

4. RPC의 흐름

  1. 클라이언트 프로세스는 생성된 스텁에 있는 getProduct 함수를 호출합니다.
  2. 클라이언트 스텁은 인코딩 메시지로 HTTP POST 요청을 생성합니다. gRPC에서는 모든 요청이 application/grpc 접두어가 붙는 콘텐츠 타(content-type)을 가진 HTTP POST 요청입니다. 호출하는 원격 함수(/ProductInfo/getProduct)는 별도의 HTTP 헤더로 전송됩니다.
  3. HTTP 요청 메시지는 네트워크를 통해 서버 머신으로 전송됩니다.
  4. 서버에 메시지가 소신되면 서버는 메시지 헤더를 검사해 어떤 서비스 함수를 호출해야 하는지 확인하고 메시지를 서비스 스텁에 넘깁니다.
  5. 서비스 스텁은 메시지 바이트를 언어별 데이터 구조로 파싱 합니다.
  6. 그런 다음 파싱된 메시지를 사용해 서비스는 getProduct 함수를 로컬로 호출합니다.
  7. 서비스 함수의 응답이 인코딩 돼 클라이언트로 다시 전송됩니다. 응답 메시지는 클라이언트에서와 동일한 절차를 따릅니다.
    (응답 -> 인코딩 -> HTTP 응답) 메시지가 복원돼 해당 값이 대기 중인 클라이언트 프로세스로 반환됩니다.

 

 

 

 

 

5. Stub (스텁)

“RPC의 핵심 개념은 ‘Stub(스텁)’ 의 역할입니다.”

서버와 클라이언트는 서로 다른 주소 공간을 사용하므로, 함수 호출에 사용된 매개 변수를 꼭 변환해줘야 합니다. 안 그러면 메모리에 매개 변수에 대한 포인터가 다른 데이터를 가리키게 됩니다. 이 변환을 담당하는 게 스텁입니다.

 

client stub은 함수 호출에 사용된 파라미터의 변환(Marshalling, 마샬링) 및 함수 실행 후 서버에서 전달된 결과의 변환을, server stub은 클라이언트가 전달한 매개 변수의 역변환(Unmarshalling, 언마샬링) 및 함수 실행 결과 변환을 담당하게 됩니다.

 

 

 

 

6. gRPC의 장단점

6.1. gRPC의 장점

  1. 프로세스 간 통신 효율성
    • gRPC는 JSON이나 XML과 같은 텍스트 형식을 사용하는 대신 프로토콜 버퍼 기반 바이너리 프로토콜을 사용해 gRPC 서비스 및 클라이언트와 통신합니다.
    • 또한 HTTP/2 위에 프로토콜 버퍼로 구현되기에 프로세스 간 통신 속도가 매우 빨라지며, 가장 효율적인 프로세스 간 통신 기술 중 하나가 됩니다.
  2. 간단 명확한 서비스 인터페이스와 스키마
    • gRPC는 애플리케이션 개발용 계약 우선(contract-first) 접근 방식을 권장합니다.
    • 먼저 서비스 인터페이스를 정의한 후 나중에 구현 세부 사항을 작업하며, gRPC에서는 RESTful의 OpenAPI/Swagger나 SOAP의 WSDL과 달리 간단하지만 일관되고 안정적인 확장 가능한 애플리케이션 개발 경험을 제공합니다.
  3. 엄격한 타입 점검 형식
    • gRPC 서비스를 정의하고자 프로토콜 버퍼를 사용하기 때문에 gRPC 서비스 계약은 애플리케이션 간 통신에 사용할 데이터 타입을 명확하게 정의합니다.
    • 정적타이핑(static typing)은 여러 팀과 기술에 걸친 클라우드 네이티브 애플리케이션을 구축할 때 발생할 수 있는 대부분의 런타임과 상호운용 에러를 극복하는 데 도움이 되므로 분산 애플리케이션 개발이 훨씬 안정적으로 이뤄집니다.
  4. 폴리글랏
    • gRPC는 여러 프로그래밍 언어와 작동하도록 설계 됐고, 프로토콜 버퍼 기반의 gRPC 서비스 정의는 특정 언어에 구애받지 않습니다.
    • 따라서 기존 gRPC 서비스나 클라이언트와 상호 연결하고자 여러 프로그래밍 언어를 선택할 수 있습니다.
  5. 이중 스트리밍(duplex streaming)
    • gRPC는 클라이언트나 서버 측 스트리밍을 기본적으로 지원하며 서비스 정의 자체에 포함되기 때문에 스트리밍 서비스나 스트리밍 클라이언트를 훨씬 쉽게 개발할 수 있습니다.
    • 아울러 기존의 요청-응답(request-response) 스타일 메시징 방식이나 클라이언트 및 서버 측 스트리밍을 구축하는 기능은 기존 RESTful 메시징 스타일에 비해 주요 장점이 됩니다.
  6. 유용한 내장 기능 지원
    • gRPC는 인증, 암호화, 복원력(데드라인과 타임아웃), 메타데이터 교환, 압축, 로드밸런싱, 서비스 검색 등과 같은 필수 기능을 기본적으로 지원합니다.
  7. 클라우드 네이티브 생태계와 통합
    • gRPC는 CNCF의 일부며 대부분의 최신 프레임워크와 기술은 gRPC를 기본적으로 지원합니다.
    • 예를 들어 엔보이(Envoy)와 같은 많은 CNCF 프로젝트는 gRPC를 통신 프로토콜로 지원하며, 메트릭스(metrics) 및 모니터링과 같은 횡단 관심(cross-cutting) 기능을 위해 gRPC는 대부분 도구에서 지원됩니다.
      • 예를 들어, 프로메테우스(Prometheus)
  8. 성숙하고 널리 채택됨
    • gRPC는 구글의 강력한 테스트를 통해 완성됐으며 스퀘어, 리프트, 넷플릭스, 도커, 시스코, CoreOS와 같은 주요 기술 회사에 채택됐습니다.

 

6.2. gRPC의 단점

  1. 외부 서비스 부적합
    • 인터넷을 통해 애플리케이션이나 서비스를 외부 클라이언트에 제공하려는 경우 대부분 외부 사용자는 gRPC가 새롭기 때문에 적합하지 않을 수 있습니다.
    • 계약 기반(contract-driven)이면서 강력한 타입 속성을 갖는 gRPC 서비스는 외부 당사자에게 노출되는 서비스의 유연성을 방해할 수 있으며 사용자는 훨씬 적은 제어권을 갖습니다.
    • gRPC 게이트웨이(gateway)는 이 문제의 해결책으로 설계되었습니다.
  2. 서비스 정의의 급격한 변경에 따른 개발 프로세스 복잡성
    • gRPC 생태계는 여전히 기존 REST나 HTTP 프로토콜에 비해 상대적으로 작습니다.
    • 브라우저와 모바일 애플리케이션에서 gRPC의 지원도 여전히 추기 단계입니다.
  3. 상대적으로 작은 생태계
    • 스키마 수정은 최신 서비스 간 통신 유스케이스에서 상당히 흔히 볼 수 있습니다.
    • gRPC 서비스 정의가 급격히 변경되면 일반적으로 클라이언트와 서버 코드 모두 다시 생성해야 합니다.
    • 이는 기존의 지속적인 통합(CI, Continuous Integration) 프로세스에 통합돼야 하며 전체 개발 수명 주기를 복잡하게 할 수 있습니다.
    • 그러나 대부분의 gRPC 서비스 정의 변경은 서비스 계약을 위반하지 않게 수용될 수 있고,
    • gRPC는 주요 변경 사항이 없는 한 다른 버전의 프로토(proto)를 사용해 클라이언트 및 서버와 문제없이 상호운용할 수 있습니다.
    • 즉, 대부분의 경우 코드 재생성은 필요하지 않습니다.
728x90
반응형