코딩관계론

gRPC 개념 본문

개발

gRPC 개념

개발자_티모 2023. 7. 25. 19:11
반응형

등장요인

server-client model

예전에는 프로그램은 하나의 메인 프레임에서 동작하는 모노롤틱 구조로 설계되었습니다. 따라서 모든 기능이 한 공간에서 구동되다 보니 지금처럼 네트워크 통신이 그게 중요하지 않았습니다.

 

 

기술 발전에 따라 소형 컴퓨터 장비들이 등장하게 되고, 기업 입장에선 매우 고가인 메인 프레임워크를 비교적 저가의 서버로 대체하고 싶어했습니다. 하지만 메인 프레임워크의 고사양 서비스를 저사양 서버에서 그대로 제공하기엔 한계가 존재했습니다.

 

이 때문에 메인 프레임워크 기능을 워크스테이션 서버로 분산시키고, 네트워크 연결로 서비스하는 방식을 채택하게 됩니다. 흔히말하는 Server-client model입니다. 이처럼 서버 간 혹은 서버와 개인 PC간 네트워크 연결/통신이 중요해지면서 OS 계층 구조가 정의되고 발전하기 시작합니다.

 

마이크로 구조와 모노롤틱 구조

통신 방식

IPC(Inter Process Communication) 

프로세스들은 기본적으로 상호독립적입니다. 

프로세스들은 기본적으로 상호독립적입니다. 메모리를 공유하지 않기 때문에 각자 자신의 일만 하며 서로 간섭하지 않습니다. 

하지만 필요에 따라 프로세스간 정보를 교환해야하는 경우가 필요합니다. 이 때 별도의 수단을 통해 통신하는 방법론을 IPC라고 부릅니다. 

 

Socket

IPC의 통신 방식 중 대표적인 소캣 통신에 대해서 알아보겠습니다.

소켓은 Application Layer(L7)에서 Transport Port(L4)의 TCP 또는 UDP를 이용하기 위한 수단입니다.  목적지와의 통신이 컴퓨터 내부가 아니라 온라인 범위에서 이루어지기 때문에 네트워크 간 통신이라고 구분됩니다. 

 

Socket의 장점 및 한계점

소캣의 장점은 대부분의 언어에서 API형태로 제공하기 때문에 사용에 이점이 있습니다. 하지만 일련의 통신 과정을 직접 구현하므로 통신 관련 장애를 처리하는 것은 개발자의 몫이 됩니다. 또한 서로 다른 플랫폼이나 버전에서 소켓 프로토콜의 호환성 문제가 발생할 수 있습니다. 특히, 네트워크 통신을 하는 애플리케이션들 간에 일관된 프로토콜을 사용하기 위해서는 추가적인 작업이 필요합니다.

 

RPC (Remote Procedure Call)

이런 소켓의 한계에서 RPC(Remote Procedure Call)라는 기술이 등장합니다. 이름 그대로 네트워크로 연결된 서버 상의 프로시저(함수, 메서드 등)를 원격으로 호출할 수 있는 기능입니다. 네트워크 통신을 위한 작업 하나하나 챙기기 귀찮으니. 통신이나 call 방식에 신경쓰지 않고 원격지의 자원을 내 것처럼 사용할 수 있죠. IDL(Interface Definication Language) 기반으로 다양한 언어를 가진 환경에서도 쉽게 확장이 가능하며, 인터페이스 협업에도 용이하다는 장점이 있습니다.

 

Stub

클라이언트와 서버는 각각 다른 주소 공간에 있으므로, 이러한 주소 공간의 차이를 극복하기 위해 스텁이 사용됩니다. 스텁은 클라이언트와 서버 간의 인터페이스 역할을 하며, RPC 통신을 원활하게 수행할 수 있도록 돕습니다.

 

클라이언트 스텁(Client Stub)

클라이언트가 원격 서버의 함수를 호출할 때, 클라이언트 스텁이 이를 가로채서 호출 파라미터를 변환합니다. 이 과정을 "마샬링(Marshalling)"이라고 합니다.

 

마샬링은 호출 파라미터를 네트워크로 전송 가능한 형태로 직렬화하는 과정을 말합니다. 이는 클라이언트의 메모리에 있는 데이터를 이진 데이터로 변환하여 네트워크를 통해 서버로 전송할 수 있게 해줍니다.

 

서버로부터 받은 결과 데이터 역시 클라이언트 스텁이 역변환을 수행하여 클라이언트가 사용할 수 있도록 변환합니다.

 

서버 스텁(Server Stub)

클라이언트로부터 전달받은 호출 파라미터를 역변환하는 과정을 "언마샬링(Unmarshalling)"이라고 합니다.

언마샬링은 전달받은 이진 데이터를 서버가 사용하는 데이터 형식으로 변환하는 과정을 말합니다.

함수를 실행한 후, 서버 스텁은 결과 데이터를 다시 클라이언트로 보내기 전에 마샬링 과정을 거쳐 이진 데이터로 변환합니다.

 

client stub은 함수 호출에 사용된 파라미터의 변환(Marshalling, 마샬링) 및 함수 실행 후 서버에서 전달 된 결과의 변환을, server stub은 클라이언트가 전달한 매개 변수의 역변환(Unmarshalling, 언마샬링) 및 함수 실행 결과 변환을 담당하게 됩니다. 이런 Stub을 이용한 기본적인 RPC 통신 과정을 살펴보겠습니다.

 

이렇게 클라이언트 스텁과 서버 스텁이 호출 파라미터와 결과 데이터를 변환함으로써, 클라이언트와 서버가 서로 다른 주소 공간에 있더라도 원격 함수 호출이 가능해집니다. 스텁을 통해 원격 서버의 함수를 마치 로컬에서 호출하는 것처럼 편리하게 사용할 수 있습니다.

 

일반적으로, RPC 프레임워크나 라이브러리가 스텁을 자동으로 생성해주고, 개발자는 스텁의 존재를 잘 모르고도 RPC를 사용할 수 있습니다. 이를 통해 원격 서버와의 통신을 추상화하여 개발자가 더 쉽게 원격 함수 호출을 수행할 수 있습니다.

스텁

 

gRPC란 무엇인가

gRPC는 Google에서 개발한 오픈소스 RPC(Remote Procedure Call) 프레임워크로, 다양한 언어와 플랫폼 간에 원격 서비스 호출을 지원하는 기술입니다. 이전까지 Google은 Protocol Buffer(PB)라는 메시지 직렬화 프레임워크를 사용하여 데이터를 교환하였으나, RPC 기능은 지원하지 않았습니다. 그러나 gRPC는 PB를 기반으로 하여 RPC 기능을 추가하여 탄생하였습니다. 즉, PB를 사용하여 데이터를 직렬화하고, 이를 HTTP/2 프로토콜을 이용하여 원격 서비스 호출을 가능하게 하는 것이 gRPC의 주요 특징입니다.

 

gRPC vs REST

  • 프로토콜: gRPC는 HTTP/2 프로토콜을 사용하여 통신합니다. HTTP/2는 한 번의 연결로 여러 개의 메시지를 동시에 주고받을 수 있으며, 헤더 압축 기능 등으로 효율적인 통신을 지원합니다. 반면에 REST는 보통 HTTP/1.1을 사용하며, 요청마다 새로운 연결을 생성해야 하기 때문에 비교적 오버헤드가 큽니다.
  • 데이터 전달 방식: gRPC는 Protocol Buffer를 사용하여 데이터를 직렬화하고 전송합니다. Protocol Buffer는 이진 형식으로 데이터를 효율적으로 표현할 수 있으며, 데이터 크기가 작아 네트워크 부하를 줄일 수 있습니다. REST는 주로 JSON과 같은 텍스트 기반 데이터 포맷을 사용하는데, 이는 데이터 크기가 상대적으로 크고 직렬화/역직렬화 과정에서 오버헤드가 발생할 수 있습니다.
  • 인터페이스 정의: gRPC는 서비스와 메소드를 Protocol Buffer를 사용한 인터페이스 정의 언어(IDL, Interface Definition Language)로 정의합니다. 이러한 IDL 기반으로 서버와 클라이언트 간의 인터페이스를 명확히 정의할 수 있습니다. REST는 주로 HTTP 메소드(GET, POST, PUT, DELETE 등)를 이용하여 리소스를 다루기 때문에 인터페이스 정의가 상대적으로 자유롭습니다.
  • 확장성: gRPC는 Protocol Buffer를 기반으로 하기 때문에, 다양한 언어와 플랫폼에서 이용할 수 있습니다. 이러한 특성으로 인해 클라이언트와 서버가 서로 다른 언어로 개발되더라도 상호간에 통신이 가능합니다. REST 역시 언어나 플랫폼에 구애받지 않고 사용할 수는 있지만, 표준이 없기 때문에 프로토콜과 데이터 포맷 등을 일일이 정의해야 할 수도 있습니다.

요약하자면, gRPC는 HTTP/2를 기반으로 하고 Protocol Buffer를 사용하여 데이터를 효율적으로 직렬화하여 원격 서비스 호출을 지원하는 RPC 프레임워크입니다. 이를 통해 클라이언트와 서버 간의 통신을 더욱 빠르고 효율적으로 처리할 수 있습니다.

 

 

해당 글은 네이버의 gRPC 깊게 파고들기#1 글을 참고해서 작성했습니다.

https://medium.com/naver-cloud-platform/nbp-%EA%B8%B0%EC%88%A0-%EA%B2%BD%ED%97%98-%EC%8B%9C%EB%8C%80%EC%9D%98-%ED%9D%90%EB%A6%84-grpc-%EA%B9%8A%EA%B2%8C-%ED%8C%8C%EA%B3%A0%EB%93%A4%EA%B8%B0-1-39e97cb3460

반응형

'개발' 카테고리의 다른 글

타임딜 서비스 개발기  (2) 2024.07.25
최적의 PK를 찾아서  (0) 2024.07.25
Git Branch 관리 전략  (0) 2024.07.17
객체지향이란 무엇인가  (0) 2024.06.01
ProtoBuf (Protocol Buffer, 프로토콜 버퍼)  (0) 2023.07.27