gRPC 대 REST: 차이점, 유사점, 사용 이유

통신을 위한 gRPC와 REST 클라이언트-서버 아키텍처를 비교하고 이들의 장단점을 비교합니다.

널리 사용되는 클라이언트-서버 아키텍처는 통신을 두 부분으로 나눕니다. 하나는 서버라고 하는 무거운 작업을 모두 차지하고 서비스를 제공하는 것이고, 다른 하나는 클라이언트라고 하는 서비스를 즐기는 것입니다.

일반적인 클라이언트-서버 통신에서 클라이언트는 리소스 또는 서비스를 요청하는 요청을 서버로 전송하고 서버는 해당 요청에 응답합니다.

클라이언트-서버 통신을 위해 클라이언트와 서버는 통신하는 프로토콜을 이해할 수 있는 라이브러리가 있어야 합니다. 프로토콜은 인터넷 통신 규칙의 언어 또는 집합입니다. 인터넷을 통해 데이터를 전송하기 위한 몇 가지 지침을 따르는 전송 메커니즘입니다.

클라이언트 통신의 두 번째로 중요한 측면은 클라이언트와 서버 모두가 동의할 수 있는 메시지 형식입니다. 이 메시지 형식은 일부 스키마를 기반으로 하며, 이러한 스키마를 따르지 않으면 의사소통이 이루어지지 않습니다. 메시지 형식은 스키마를 준수하는 XML 또는 특정 키-값 쌍을 포함해야 하는 JSON 파일과 유사할 수 있습니다.

이러한 통신 유형의 또 다른 중요한 측면은 요청 및 응답 메커니즘을 기반으로 한다는 것입니다. 즉, 서버는 클라이언트가 통신을 시작할 때만 통신합니다. REST 및 GraphQL에서는 대부분 단방향입니다. 이것은 gRPC와 같은 기술로 해결될 기본적인 문제입니다.

 

 

gRPC 대 REST: 차이점, 유사점, 사용 이유

 

 

왜 REST가 생겨났을까요?

90년대 초, SOAP라는 인기 있는 클라이언트-서버 프로토콜은 하드 코딩된 스키마를 가진 XML 메시지 형식을 사용했습니다. 메시지 형식의 스키마가 매우 엄격했습니다. 자유의 부족은 SOAP의 포기와 REST의 출현을 초래했습니다.

REST는 JavaScript의 인기가 높아지면서 JSON 파일 형식의 인기가 높아짐에 따라 생겨났습니다. 이해하기 쉽고 편리했습니다. 메시지 형식에 키와 값 쌍이 있습니다.

간단히 말해, Rest는 HTTP를 프로토콜(전송 메커니즘)로 하여 인터넷을 통해 JSON 메시지를 전송하기 위한 지침입니다. Rest를 사용하면 스키마를 만들 걱정을 할 필요가 없습니다.

 

 

REST란?

우리는 REST의 등장에 대해 이야기했습니다. 이제 핵심 기술에 대해 자세히 알아보겠습니다. REST는 대표적인 국가 이전을 의미합니다. Rest는 업계에서 많이 사용되는 API인 표준화된 소프트웨어 아키텍처 스타일입니다.

 

 

REST의 인기와 보급의 이유

REST는 통신 아키텍처를 위해 단순하고 표준화되었습니다. R을 활용하는 동안, 당신은 메시지나 데이터를 포맷하는 것에 대해 걱정할 필요가 없을 것입니다. 메시지 형식은 모두 표준화되고 업계에서 사용되므로 매번 번거롭게 사용할 필요가 없습니다.

REST는 확장 가능합니다. 서비스 규모가 커지고 기능이 더 필요한 경우 서버의 REST 성능에 신경 쓰지 않고 서버를 쉽게 개조할 수 있으며, 데이터가 손상되지 않는 한 완전히 격리된 상태에서 새로운 기능을 생성할 수 있습니다.

REST는 상태 비저장입니다. 즉, 각 요청에는 서버가 이해해야 하는 일부 데이터가 포함됩니다. 서버의 아키텍처는 서버가 이 요청의 정보를 불러오도록 하지만 REST 아키텍처에서는 세션 상태가 클라이언트 측에 저장되어 서버의 효율성을 높이고 서버의 기능 개선을 위한 작업 부하를 최소화합니다.

마지막으로 Rest는 고성능 아키텍처이며 캐슁을 지원합니다.

 

 

REST 사용 시기

레스토랑을 위한 웹사이트를 만들고 있다고 상상해 보세요. 모든 메뉴가 온라인으로 제공되며, 식품은 세 가지 범주로 나뉩니다:

• 스타터
• 메인 코스
• 음료

 

이제 온라인에서 모든 음료를 보고 싶다고 가정해 보겠습니다. Rest 아키텍처에서는 API 끝점에서 모든 리소스를 쉽고 일관되게 분할할 수 있습니다. 물론 여러 인증을 사용하여 보안을 강화할 수 있습니다.

이런 경우에는 서버에 GET 요청을 엔드포인트로 전송하여 음료 리소스 데이터를 가져올 수 있습니다.

마찬가지로 Rest API에서 모든 CRUD(Create, Read, Update, Delete)를 수행할 수 있으므로 데이터의 슈퍼 전송이 필요 없고 실시간일 필요가 없는 큰 프로젝트에 적합합니다.

Rest는 효율적인 데이터 전송이 중요한 프로젝트에 가장 적합합니다. 캐싱은 음식 예약 앱, 호텔 예약 앱, 블로그 웹 사이트, 온라인 포럼 웹 사이트 등과 같은 표준 응용 프로그램에 유용한 REST의 또 다른 기능입니다.

 

 

REST의 제한 사항 및 문제

REST는 훌륭하지만 경우에 따라 상당히 중요한 단점이 많습니다. 그들에 대해 이야기해 봅시다.

• 양방향 커뮤니케이션의 필요성. 서버가 클라이언트에 일부 데이터를 전송해야 하는 경우에는 어떻게 해야 합니까? 평균 서버가 통신을 시작하려고 합니다. REST 아키텍처에서는 이것이 가능하지 않습니다. 물론, 여러분은 몇 가지 속임수를 사용할 수 있지만, 그것들은 실용적이지 않습니다.
• 라이브 스코어 웹사이트를 만든다고 상상해 보세요. 고객에게 점수 데이터 업데이트 요청을 보내도록 서버를 어떻게 관리하시겠습니까? 우리는 고객들이 10초마다 요청을 보내도록 할 수 있지만, 그것은 전혀 좋은 관행이 아닙니다. 서버에 과부하가 걸려 속도 문제가 발생할 수 있습니다.
• REST 아키텍처는 순수하게 요청되고 응답하며 데이터 스트리밍(연속 이벤트 처리)을 지원하지 않습니다.
• 상태 비저장 REST 속성은 REST 아키텍처의 데이터 상태를 결정할 수 없기 때문에 축복이자 저주로 간주될 수 있습니다.

 

 

gRPC는 왜 생겨났을까요?

양방향 통신의 필요성인 REST의 첫 번째 문제를 해결하기 위해 서버가 통신을 시작할 수 있는 WebSocket이 발명되었지만, 문제는 형식이 없다는 것입니다. 바이트만 보내고 제한은 없습니다.

웹 소켓 자체에는 문제가 없었지만, 실제 문제는 모든 통신 유형에는 프로토콜이 필요하고 각 프로토콜에는 해당 프로토콜을 사용하여 통신할 수 있는 클라이언트 라이브러리가 필요하다는 것입니다.

Rest 아키텍처에서 작동하는 Python 응용프로그램을 만드는 경우 서버와 통신할 수 있는 HTTP 클라이언트가 필요합니다. 대부분의 경우 클라이언트 라이브러리는 주로 독립 개발자인 제3자에 의해 만들어집니다. 타사 라이브러리를 사용하면 보안이 노출될 수 있으며 전체 응용 프로그램은 타사의 통신에 의존합니다.

웹 응용프로그램의 경우 브라우저가 클라이언트 라이브러리처럼 작동하지만 웹 프로젝트가 아닌 경우 타사 클라이언트 라이브러리가 필요합니다. 만약 여러분이 스스로 하나를 만들 생각이라면, 그것이 그렇게 쉽지 않다는 것을 기억하세요, 그리고 여러분은 다른 애플리케이션을 유지하는 것에 부담을 가질 것입니다.

그래서 Rest와 클라이언트 라이브러리의 문제를 해결하기 위해 Google은 2015년에 gRPC를 발명했습니다.

gRPC의 경우, 하나의 클라이언트 라이브러리는 거의 모든 인기 있는 언어에 대해 Google에 의해 유지 관리됩니다. 후드 아래의 HTTP 2 프로토콜과 메시지 형식으로 프로토콜 버퍼(protobf)를 사용합니다.

Google은 사용자와 거의 모든 프로그래밍 언어를 위해 라이브러리를 관리하고 있으므로 클라이언트 라이브러리에 대해 걱정할 필요가 없습니다. 단일 중앙 집중식 클라이언트 라이브러리는 gRPC의 주요 장점 중 하나입니다.

gRPC의 또 다른 이점은 사용하는 메시지 형식입니다. 프로토콜 버퍼는 언어에 구애받지 않기 때문에 Python에서는 클라이언트를, Go에서는 서버를 만들 수 있으며 여전히 소란을 피우지 않고 통신할 수 있습니다.

gRPC는 기본적으로 모든 장치에서 사용할 수 있는 하나의 클라이언트 라이브러리와 하나의 프로토콜입니다.

 

 

gRPC란?

gRPC는 프로토콜을 사용하여 통신합니다. 프로토 파일을 이진 형식으로 직렬화하여 서버로 보내고, 서버 측에서는 원래 형식으로 역직렬화합니다. 이것이 프로토오프와 함께 작동하는 방식입니다.

gRPC는 다양한 형태의 통신을 가지고 있습니다. gRPC의 기능이라고 생각하시면 됩니다.

 

 

gRPC의 특징

• 단일 요청: 이것은 클라이언트가 프로토 요청을 보내고, 이를 수신하면 서버가 프로세스를 수행하기 위해 일정 시간을 기다린 후 일부 응답을 반환하는 간단한 요청-응답 통신 유형입니다.
• 서버 스트리밍: 단일 요청을 할 때 서버에서 응답으로 데이터가 쇄도합니다. 예를 들어, 비디오를 클릭하면 서버 측에서 많은 비디오 관련 데이터가 범람합니다.
• 클라이언트 스트리밍: 서버 스트리밍의 경우 그 반대입니다. 여기서 클라이언트는 한 번에 많은 데이터를 서버로 보냅니다. 예를 들어, 인터넷에서 대용량 파일을 공유하거나 이미지 또는 비디오를 인터넷에 업로드할 때 발생합니다. 클라이언트는 서버 측에 지속적으로 데이터를 전송합니다.
• 양방향 스트리밍: 이런 종류의 통신에서는 클라이언트와 서버가 여러 개의 메시지를 보냅니다. 채팅은 그것의 좋은 예입니다.

다음은 gRPC를 강력하게 만드는 4가지 주요 기능입니다.

 

 

gRPC를 사용해야 하는 경우

gRPC의 기능에 대해서는 gRPC의 몇 가지 사용 사례를 보았습니다. 채팅 응용 프로그램을 만들고 싶다고 가정해 보겠습니다. Rest API는 양방향 통신의 빠른 스트리밍을 허용하지 않기 때문에 사용하지 않을 것입니다. 이를 위해 속도 이외의 몇 가지 이점을 제공하는 gRPC 스트림을 사용할 것입니다.

첫째, 서버나 다른 클라이언트가 어떤 프로그래밍 언어를 쓰는지 언어 중립적인 동작은 중요하지 않습니다. 메시지 형식이 승인될 때까지 통신을 설정할 수 있습니다.

따라서 이 기능을 통해 안드로이드 버전의 채팅 앱은 iOS 버전과 통신할 수 있고 그 반대도 가능합니다.

 

 

gRPC 관련 문제

gRPC를 포함한 모든 것에 문제가 있습니다.

• 제한된 브라우저 지원: gRPC는 HTTP 2를 사용하므로 브라우저에서 직접 gRPC 서비스를 호출하기 어렵습니다. 프록시를 설정해야 하는 경우도 있습니다.
• 읽을 수 없는 형식: 우리 모두가 알다시피 gRPC는 인간이 읽을 수 없는 이진 형식을 사용합니다. 그것은 어떤 경우에는 불리합니다.
• 성숙도 부족 : gRPC는 2015년에 개발되어 REST에 비해 아직 다소 미숙하며, 많은 버그와 문제점을 해결해야 합니다.
• 학습 문제: Rest와 GraphQL은 배우기 쉬운 JSON을 사용합니다. 프로토브가 아직 새롭고 복잡한 주제이기 때문에 대부분의 사람들은 그것들을 고수하려고 할 것이고, 그래서 gRPC 전문가를 찾기 어려울 것입니다.

 

 

Rest 대 gRPC

이제 REST와 gRPC의 기술적 차이에 대해 논의하겠습니다.

 

메시지 형식

REST에서 사용하는 메시지 형식은 대부분 JSON(때로는 XML 형식)으로, 보다 읽기 쉽고 다루기 쉽습니다. Rest에서 스키마에 대해 걱정할 필요가 없습니다. 반면에 gRPC는 프로토콜 버퍼를 사용하여 데이터를 직렬화합니다. 압축된 형태가 더 가볍고 이동 속도가 빠릅니다. 이진 형식이므로 데이터를 직렬화하고 역직렬화하여 전송합니다.

 

HTTP 1.1 대 HTTP 2

Rest API는 일반적으로 HTTP 1.1을 프로토콜로 사용하는 반면, gRPC는 HTTP 2를 프로토콜 기반으로 사용합니다. Rest API는 여전히 HTTP 2를 사용할 수 있지만 요청-응답 메커니즘 때문에 여전히 제한되어 있습니다. gRPC는 HTTP 2를 사용하며 클라이언트-응답 및 양방향 통신 모두에 대해 HTTP 2 지원을 활용합니다. 이는 REST보다 gRPC 성능을 향상시키는 또 다른 측면입니다. HTTP 1.1과 같은 단방향 요청과 HTTP 2와 같은 양방향 요청을 동시에 관리할 수 있습니다.

 

대기 시간

gRPC는 대기 시간이 짧고 통신 속도가 빠르기 때문에 경량 마이크로서비스 아키텍처로 구성된 시스템에 연결하는 데 유용하므로 메시지 전송 효율성이 향상됩니다. 대부분의 네트워크에서 대기 시간 REST는 25ms가 소요되는 반면, gRPC 대기 시간은 REST보다 훨씬 적습니다.

 

페이로드 제한

rest는 발신 메시지를 보낼 때 최대 페이로드 제한이 45MB인 반면 gRPC는 제한이 없습니다. 즉, 발신 메시지가 원하는 만큼 무거울 수 있습니다.

 

보안

보안 측면에서 Rest는 암호 해독 및 액세스가 용이한 HTTP 1.1 및 JSON 형식을 사용하기 때문에 지연됩니다. 반면에 gRPC는 훨씬 더 안전한 HTTP 2를 사용하고 이진 형식이며 암호 해독이 어려운 protobf를 사용합니다.

 

속도

여기서도 gRPC는 Rest보다 10배 빠른 속도를 제공하기 때문에 승리하며, HTTP 2를 프로토콜로 사용하고 protof를 메시지 형식으로 사용합니다.

 

코드 생성 기능

Rest는 내장된 코드 생성 기능을 제공하지 않습니다. 즉, 개발자는 API 코드를 생성하기 위해 타사 앱이 필요한 반면, gRPC는 여러 프로그래밍 언어와 호환되는 컴파일러 프로토콜로 인해 네이티브 코드 생성 기능을 가지고 있습니다. 이는 특히 마이크로서비스 아키텍처의 또 다른 이점입니다.

 

 

결론

궁극적으로, 저는 REST가 여전히 가장 많이 사용되고 대중적인 건축물이며, 포기할 수 없다고 말하고 싶습니다. REST는 데이터 스트리밍 부족, 양방향 통신 없음, 느린 속도 등 많은 단점이 있지만 일상에서 볼 수 있는 표준 애플리케이션에 가장 적합합니다.

반면에 gRPC는 젊고 배우기가 어려우며 클라이언트와 서버 모두에서 높은 데이터 스트리밍, 좋은 양방향 데이터 스트리밍, 빠르고 소형이며 HTTP 2를 사용합니다. 빠른 성능으로 인해 gRPC는 비디오 스트리밍, 노래 스트리밍, 온라인 게임, 온라인 게임 등과 같은 고부하 애플리케이션에 가장 적합합니다, 파일 공유 및 채팅 응용 프로그램을 사용할 수 있습니다.