gRPC와 REST의 차이점은 무엇인가요?
gRPC와 REST는 API 설계에 사용되는 2가지 방법입니다. API는 정의 및 프로토콜 세트를 사용하여 두 소프트웨어 구성 요소가 서로 통신할 수 있게 하는 메커니즘입니다. gRPC에서는 한 구성 요소(해당 클라이언트)가 다른 소프트웨어 구성 요소(해당 서버)의 특정 함수를 직접 또는 간접적으로 호출합니다. REST에서는 함수를 직접적으로 호출하는 대신 클라이언트가 서버의 데이터를 요청하거나 업데이트합니다.
gRPC란 무엇인가요?
RPC란 무엇인가요?
RPC에서 클라이언트-서버 통신은 클라이언트 API 요청이 로컬 작업이거나 요청이 내부 서버 코드인 것처럼 작동합니다.
RPC에서 클라이언트는 서버의 프로세스로 요청을 전송합니다. 이 프로세스는 항상 원격 호출을 수신 대기 중인 상태로 유지됩니다. 요청에는 직접적으로 호출할 서버 함수와 전달할 파라미터가 포함됩니다. RPC API는 HTTP, TCP 또는 UDP와 같은 프로토콜을 기본 데이터 교환 메커니즘으로 사용합니다.
gRPC는 RPC와 어떻게 다른가요?
gRPC는 몇 가지 최적화와 함께 기존 RPC를 구현하는 시스템입니다. 예를 들어 gRPC는 데이터 전송에 Protocol Buffer와 HTTP 2를 사용합니다.
또한 개발자의 데이터 교환 메커니즘을 추상화합니다. 예를 들어 널리 사용되는 또 다른 RPC API 구현인 OpenAPI를 사용할 때는 개발자가 RPC 개념을 HTTP 프로토콜에 매핑해야 합니다. 하지만 gRPC는 기본 HTTP 통신을 추상화합니다. 이러한 최적화 덕에 gRPC는 다른 RPC 구현보다 더 빠르고 쉽게 구현할 수 있으며 웹 친화적입니다.
REST란 무엇인가요?
REST는 소프트웨어 구성 요소 간 데이터 교환을 위한 일련의 규칙을 정의하는 소프트웨어 아키텍처 접근 방식입니다. REST는 웹의 표준 통신 프로토콜인 HTTP를 기반으로 합니다. RESTful API는 생성, 읽기, 업데이트 및 삭제 작업에 POST, GET, PUT, DELETE와 같은 HTTP 동사를 사용하여 클라이언트와 서버 간의 통신을 관리합니다. 서버 측 리소스는 엔드포인트라고 하는 URL로 식별됩니다.
REST는 다음과 같이 작동합니다.
- 클라이언트가 서버에 리소스의 생성, 수정 또는 삭제를 요청합니다.
- 요청에는 리소스 엔드포인트가 포함되며 추가 파라미터도 포함될 수 있습니다.
- 서버가 응답하여 작업이 완료되면 전체 리소스를 클라이언트에 반환합니다.
- 응답에는 JSON 형식 및 상태 코드의 데이터가 포함됩니다.
REST 지침을 사용하여 구축된 API를 RESTful API 또는 REST API라고 합니다.
조직에서 gRPC와 REST를 사용하는 이유는 무엇인가요?
gRPC와 REST는 API 개발에 대한 2가지 다른 접근 방식입니다.
API의 작동 방식은 레스토랑에서 메뉴를 보고 음식을 주문하는 것과 유사합니다. 어떤 식당에서든 고객(클라이언트)은 정해진 요리 세트가 있는 메뉴(API)에서 음식을 주문할 수 있습니다. 주방(서버)에 이를 전달하면 주방에서는 요청된 요리를 준비하고 고객에게 전달합니다. 고객은 주방에서 어떻게 주문을 요리하는지 알 필요가 없으며 무엇이 나올지만 알면 됩니다. 메뉴 형식의 표준화는 고객과 주방에서 메뉴 형식을 사용하는 방법을 알 수 있다는 것을 의미합니다.
API가 없다면 서로 다른 애플리케이션이나 소프트웨어 서비스가 통신하는 방식에 대한 공동의 합의가 이루어지지 않습니다. 서로 다른 두 애플리케이션을 사용하는 프로그래머는 매번 데이터 교환을 구축하는 방법을 결정하기 위해 서로 이야기해야 합니다.
API 아키텍처에는 gRPC 및 REST 같은 다양한 유형이 있습니다. 조직 내 다양한 사용 사례에 따라 적절한 아키텍처가 다를 수 있기 때문입니다. API 설계자는 시스템 요구 사항에 따라 선호하는 클라이언트-서버 아키텍처를 선택해야 합니다.
gRPC와 REST의 유사점은 무엇인가요?
REST와 gRPC는 API 아키텍처 접근 방식으로서 몇 가지 근본적인 특성이 유사합니다.
데이터 교환 메커니즘
클라이언트와 서버라는 두 소프트웨어 구성 요소는 두 API 모두에서 공유 규칙 세트에 따라 통신하고 데이터를 교환할 수 있습니다. 이러한 규칙은 각 소프트웨어 구성 요소가 내부적으로 작동하는 방식에 관계없이 적용됩니다.
HTTP 기반 통신
둘 다 웹에서 선호되는 효율적인 통신 프로토콜인 HTTP 요청-응답 메커니즘을 통해 데이터를 전달합니다. 그러나 gRPC에서는 이 메커니즘이 개발자에게 보이지 않지만 REST에서는 더 명확합니다.
구현 유연성
REST와 gRPC 모두 다양한 프로그래밍 언어로 구현할 수 있습니다. 이러한 특징 덕에 프로그래밍 환경 전반에 걸쳐 이동성이 매우 높습니다. 이 특징은 거의 보편적인 지원을 통한 최적의 상호 운용성으로 연결됩니다.
확장 가능한 분산 시스템에 대한 적합성
gRPC와 REST 모두 다음을 사용합니다.
- 비동기식 통신 - 클라이언트와 서버에서 작업을 중단하지 않고 통신할 수 있음
- 무상태 설계 - 서버에서 클라이언트 상태를 기억할 필요가 없음
즉, 개발자는 gRPC 및 REST를 사용하여 동시 요청 수가 많은 내결함성 시스템을 구축할 수 있습니다. 여러 클라이언트가 있는 확장 가능한 분산 시스템을 구축할 수 있습니다.
아키텍처 원칙: gRPC와 REST
REST와 gRPC는 비슷한 기능을 제공하지만 기본 모델은 아키텍처에서 크게 다릅니다.
통신 모델
REST API를 사용할 때 클라이언트는 단일 REST API 요청을 서버에 전송합니다. 서버는 이에 대한 응답으로 단일 응답을 보냅니다. 클라이언트에서는 작업을 계속하기 전에 서버가 응답할 때까지 기다려야 합니다. 이 메커니즘은 요청-응답 모델이며 단방향 데이터 연결(일대일)입니다.
반대로 gRPC를 사용하면 클라이언트가 하나 또는 여러 개의 API 요청을 서버에 보낼 수 있습니다. 따라서 서버에서 하나 또는 여러 개의 응답이 발생할 수 있습니다. 데이터 연결은 단방향(일대일), 서버 스트리밍(일대다), 클라이언트 스트리밍(다대일) 또는 양방향 스트리밍(다대다)일 수 있습니다. 이 메커니즘은 클라이언트-응답 통신 모델이며 gRPC가 HTTP 2를 기반으로 하기 때문에 가능합니다.
서버에서 직접적으로 호출 가능한 작업
gRPC API에서 직접적으로 호출 가능한 서버 작업은 함수 또는 프로시저라고도 하는 서비스에 의해 정의됩니다. gRPC 클라이언트는 애플리케이션 내에서 내부에서 함수를 직접적으로 호출하는 것처럼 이러한 함수를 간접적으로 호출합니다. 이를 서비스 지향 설계라고 합니다. 예를 들면 다음과 같습니다.
createNewOrder(customer_id, item_id, item_quantity) -> order_id
REST에는 URL로 정의된 서버 리소스에 대해 클라이언트에서 사용할 수 있는 제한된 HTTP 요청 동사 세트가 있습니다. 클라이언트는 리소스 자체를 직접적으로 호출합니다. 이를 엔터티 지향 설계라고 합니다. 엔터티 지향 설계는 객체 지향 프로그래밍 방법과 잘 맞습니다. 예를 들면 다음과 같습니다.
POST /orders <headers> (customer_id, item_id, item_quantity) -> order_id
gRPC API를 엔터티 지향 접근 방식으로 설계할 수 있지만 이것이 시스템 자체의 제약은 아닙니다.
데이터 교환 형식
REST API를 사용할 때는 소프트웨어 구성 요소 간에 전달되는 데이터 구조가 일반적으로 JSON 데이터 교환 형식으로 표현됩니다. XML 및 HTML과 같은 다른 데이터 형식을 전달하는 것도 가능합니다. JSON은 읽기 쉽고 유연하지만 직렬화해야 하고 프로그래밍 언어로 번역해야 합니다.
반대로 gRPC는 기본적으로 Protocol Buffer(Protobuf) 형식을 사용하지만 기본 JSON 지원도 제공합니다. 서버는 프로토타입 사양 파일에서 Protocol Buffer 인터페이스 설명 언어(IDL)를 사용하여 데이터 구조를 정의합니다. gRPC는 구조를 바이너리 형식으로 직렬화한 다음 지정된 프로그래밍 언어로 역직렬화합니다. 이 메커니즘은 전송 중에 압축되지 않는 JSON을 사용하는 것보다 더 빠릅니다. Protocol Buffer는 JSON과 함께 사용되는 REST API와 달리 사람이 읽을 수 없습니다.
기타 주요 차이점: gRPC와 REST
기타 주요 차이점: gRPC와 REST
아키텍처 스타일 외에도 gRPC와 REST에는 다른 고유한 차이점이 있습니다.
클라이언트-서버 커플링
REST는 느슨하게 결합되기 때문에 클라이언트와 서버가 상대의 구현에 대해 전혀 알 필요가 없습니다. 이 느슨한 결합으로 인해 시간이 지남에 따라 API가 더 쉽게 발전할 수 있습니다. 서버 정의를 변경한다고 해서 반드시 클라이언트에서 코드를 변경해야 하는 것은 아니기 때문입니다.
gRPC는 긴밀하게 결합되기 때문에 클라이언트와 서버에서 동일한 proto 파일에 액세스할 수 있어야 합니다. 파일을 업데이트하려면 서버와 클라이언트 모두에서 업데이트가 필요합니다.
코드 생성
gRPC에는 다양한 클라이언트 측 및 서버 측 네이티브 코드 생성 기능이 내장되어 있습니다. Protocol Buffer 컴파일러인 protoc 덕에 여러 언어로 사용할 수 있습니다. proto 파일에서 구조를 정의하면 gRPC가 클라이언트 측 및 서버 측 코드를 생성합니다. 코드가 생성되기 때문에 API 개발에 소요되는 시간이 줄어듭니다.
반면 REST는 내장된 코드 생성 메커니즘을 제공하지 않으므로 이 기능이 필요한 경우 서드 파티 도구를 추가로 사용해야 합니다. 코드 생성에 대해 자세히 알아보세요.
양방향 스트리밍
gRPC는 양방향 스트리밍 통신을 제공합니다. 즉, 클라이언트와 서버 모두 단일 연결에서 여러 요청과 응답을 동시에 보내고 받을 수 있습니다.
REST는 이 기능을 제공하지 않습니다.
사용 시기: gRPC와 REST
REST는 현재 웹 서비스 및 마이크로서비스 아키텍처에 가장 많이 사용되는 API 아키텍처입니다. REST는 간단한 구현과 데이터 구조 매핑, 가독성 및 유연성 때문에 인기가 많습니다. 초보 프로그래머는 웹 서비스 개발용이든 내부 마이크로서비스용이든 관계없이 애플리케이션을 위한 RESTful API 개발을 쉽게 시작할 수 있습니다.
REST API의 사용 사례는 다음과 같습니다.
- 웹 기반 아키텍처
- 외부 사용자가 쉽게 이해할 수 있는 공개 API
- 간단한 데이터 통신
REST와 달리 gRPC는 분산된 데이터 센터에서 마이크로서비스 아키텍처를 위한 고성능 API를 생성할 수 있도록 특별히 설계되었습니다. 실시간 스트리밍과 대규모 데이터 로드가 필요한 내부 시스템에 더 적합한 gRPC는 시간이 지나도 API가 변경될 가능성이 낮은, 여러 프로그래밍 언어로 구성된 마이크로서비스 아키텍처에도 적합합니다.
gRPC API는 다음과 같은 사용 사례에 더 적합합니다.
- 고성능 시스템
- 많은 양의 데이터 로드
- 실시간 또는 스트리밍 애플리케이션
웹 소프트웨어 개발에 대한 참고 사항
HTTP는 핵심 웹 프로토콜이긴 하지만, 다양한 버전의 HTTP가 존재하며 웹 브라우저와 웹 서버에 걸쳐 채택 정도가 다릅니다.
gRPC API는 항상 HTTP 2를 사용하고, REST API는 일반적으로 동일한 HTTP 프로토콜이 아닌 HTTP 1.1을 사용합니다. HTTP 2는 이제 일반적인 웹 프로토콜이지만 HTTP 1.1과 달리 범용 브라우저를 지원하지 않습니다. 이 제한된 브라우저 지원으로 인해 웹 애플리케이션을 지원하려는 개발자에게 gRPC는 그다지 매력적이지 않을 수 있습니다.
차이점 요약: gRPC와 REST
| gRPC API |
REST API |
|
| 무엇인가요? |
원격 프로시저 호출(RPC) 클라이언트-서버 통신 모델을 기반으로 API를 만들고 사용하는 시스템입니다. |
클라이언트와 서버 간의 정형 데이터 교환을 정의하는 일련의 규칙입니다. |
| 설계 접근 방식 |
서비스 지향 설계. 클라이언트는 서버에 서버 리소스에 영향을 줄 수도 있고 아닐 수도 있는 서비스 또는 기능을 수행해 줄 것을 요청합니다. |
엔터티 지향 설계. 클라이언트에서 서버에 리소스의 생성, 공유 또는 수정을 요청합니다. |
| 통신 모델 |
단방향, 단일 서버-다중 클라이언트, 단일 클라이언트-다중 서버, 다중 클라이언트-다중 서버 등 다양한 옵션이 있습니다. |
단방향. 단일 클라이언트가 단일 서버와 통신합니다. |
| 구현 |
작동하려면 클라이언트 측과 서버 측 모두에 gRPC 소프트웨어가 필요합니다. |
공통 소프트웨어 없이 클라이언트 측과 서버 측에서 다양한 형식으로 구현할 수 있습니다. |
| 데이터 액세스 |
서비스(기능) 직접 호출 |
리소스를 정의하는 URL 형태의 여러 엔드포인트 |
| 반환된 데이터 |
Protocol Buffer 파일에 정의된 서비스의 고정된 반환 유형으로 반환됩니다. |
서버에서 정의하는 고정 구조(일반적으로 JSON)로 반환됩니다. |
| 클라이언트-서버 커플링 |
긴밀하게 결합됩니다. 클라이언트와 서버 모두에 데이터 형식을 정의하는 동일한 Protocol Buffer 파일이 필요합니다. |
느슨하게 결합됩니다. 클라이언트와 서버는 내부 세부 정보를 인식하지 못합니다. |
| 자동 코드 생성 |
기본 제공 기능 |
서드 파티 도구가 필요합니다. |
| 양방향 스트리밍 |
있음 |
없음 |
| 가장 적합한 용도 |
고성능 또는 데이터 사용량이 많은 마이크로서비스 아키텍처 |
리소스가 잘 정의되어 있는 단순한 데이터 소스 |
AWS는 gRPC 및 REST 요구 사항을 어떻게 지원하나요?
Amazon Web Services(AWS)는 API를 설계할 때 API 기반의 최신 애플리케이션 및 서비스를 구축, 실행 및 관리하는 데 도움이 되는 다양한 서비스와 도구를 제공합니다. 자세한 내용은 AWS에서 현대적 애플리케이션을 구축하는 방법에 대한 글을 읽어 보세요.
API 요구 사항을 지원할 수 있는 AWS 제품 및 서비스의 예는 다음과 같습니다.
- Amazon API Gateway는 API를 대규모로 생성, 게시 및 관리하는 데 사용됩니다. API Gateway를 사용하면 컨테이너식 마이크로서비스 아키텍처 및 웹 애플리케이션에 최적화된 RESTful API를 구축할 수 있습니다.
- Elastic Load Balancing(ELB)은 네트워크 트래픽을 분산하여 애플리케이션 확장성을 개선합니다. 마이크로서비스 간 또는 gRPC 지원 클라이언트와 서비스 간에 gRPC 트래픽을 라우팅하고 로드 밸런싱할 수 있습니다. 따라서 고객 클라이언트 또는 서비스의 기본 인프라를 변경하지 않고도 아키텍처에 gRPC 트래픽 관리를 원활하게 도입할 수 있습니다.
- Amazon Virtual Private Cloud(VPC) Lattice는 서비스 간의 통신을 지속적으로 연결, 모니터링 및 보호하는 애플리케이션 네트워킹 서비스입니다. 컴퓨팅 및 네트워크 리소스 규모를 자동으로 조정하여 고대역폭 HTTP, HTTPS 및 gRPC 워크로드를 지원합니다.
지금 계정을 만들어 AWS에서 gRPC와 REST를 시작해 보세요.
