인기 있는 클라이언트-서버 아키텍처는 통신을 두 부분으로 나눕니다: 모든 무거운 작업을 처리하고 서비스를 제공하는 부분인 서버와, 그 서비스를 享하는 부분인 클라이언트.
일반적인 클라이언트-서버 통신에서 클라이언트는 단순히 리소스나 서비스를 요청하는 요청을 서버에 보내고, 서버는 그 요청에 응답합니다.
클라이언트-서버 통신을 위해서는 클라이언트와 서버가 그들이 통신하는 프로토콜을 이해할 수 있는 라이브러리가 필요합니다. 프로토콜은 인터넷 통신 규칙의 언어나 세트입니다. 이들은 인터넷을 통해 데이터를 전송하기 위한 몇 가지 지침을 따르는 전송 메커니즘입니다.
클라이언트 통신의 두 번째로 중요한 측면은 클라이언트와 서버가 동의할 수 있는 메시지 형식입니다. 이 메시지 형식은 일부 스키마를 기반으로 하며, 이러한 스키마를 따르지 않으면 통신이 이루어지지 않습니다. 메시지 형식은 스키마에 따르는 XML과 유사하거나, 특정 키-값 쌍을 포함해야 하는 JSON 파일일 수 있습니다.
이러한 유형의 통신에 대해 이해해야 하는 또 다른 중요한 측면은 요청 및 응답 메커니즘을 기반으로 하며, 이는 클라이언트가 통신을 시작할 때만 서버가 통신한다는 것을 의미합니다. REST와 GraphQL로는 대부분 단방향입니다. 이것은 gRPC와 같은 기술로 해결될 기본적인 문제입니다.
REST가 왜 존재하게 되었나요?
90년대 초반, 인기 있는 클라이언트-서버 프로토콜인 SOAP는 하드코딩된 스키마를 가진 XML 메시지 형식을 사용했습니다. 메시지 형식의 스키마는 매우 강결합이었습니다. 자유의 부족이 SOAP의 폐기와 REST의 등장으로 이어졌습니다.
REST는 JavaScript의 인기 증가로 JSON 파일 형식의 인기가 커지면서 생겨났습니다. 이해하기 쉽고 편리했습니다. 메시지 형식에는 키와 값 쌍만 있었습니다.
간단히 말해, Rest는 HTTP를 프로토콜(전송 메커니즘)로 사용하여 인터넷을 통해 JSON 메시지를 전송하는 지침입니다. Rest를 사용하면 스키마를 만들 필요가 없습니다.
REST란 무엇인가?
REST의 등장에 대해 이야기했으니, 이제 핵심 기술로 깊이 들어가 봅시다. REST는 Representational State Transfer의 약자임을 알려드립니다. Rest는 표준화된 소프트웨어 아키텍처 스타일로, 업계에서 많이 사용되는 API입니다.
REST의 인기와 널리 사용되는 이유
- REST는 통신 아키텍처를 위한 간단하고 표준화된 방식입니다. R을 활용하면 메시지나 데이터의 형식을 신경 쓸 필요가 없습니다. 메시지 형식을 매번 신경 쓸 필요가 없으며, 모두 표준화되어 업계에서 사용됩니다.
- REST는 확장 가능합니다. 서비스가 커져 더 많은 기능이 필요해지면 REST의 서버 성능에 신경 쓰지 않고 서버를 쉽게 개조할 수 있으며, 데이터를 망치지 않는 한 완전히 고립된 상태에서 새 기능을 생성할 수 있습니다.
- REST는 무상태입니다. 이는 각 요청이 서버에서 이해해야 할 일부 데이터를 가지고 있다는 것을 의미합니다. 서버의 아키텍처는 이 요청의 정보를 기억하게 만들지만, REST 아키텍처에서는 세션 상태가 클라이언트 측에 저장되어 서버를 보다 효율적으로 만들고 서버에 미세한 기능을 위한 부담을 최소화합니다.
- 마지막으로, REST는 고성능 아키텍처이며 캐싱을 지원합니다.
REST를 사용할 경우
레스토랑을 위한 웹사이트를 만든다고 상상해보십시오. 모든 메뉴가 온라인에 있고, 음식 아이템은 세 가지 범주로 나뉩니다:
- 시차
- 메인 요리
- 음료
이제 온라인에서 모든 음료를 보고 싶다고 가정해 보겠습니다. REST 아키텍처에서는 API 엔드포인트에서 리소스를 쉽게 일관되게 분할할 수 있습니다. 물론 이를 보안하기 위해 다양한 인증을 사용할 수 있습니다.
이러한 경우에는 음료 리소스 데이터를 얻을 수 있는 엔드포인트로 서버에 GET 요청을 보냅니다.
마찬가지로 REST API에서 CRUD(생성, 읽기, 업데이트, 삭제)를 모두 수행할 수 있으므로 데이터 전송이 매우 필요하지 않고 실시간이 될 필요가 없는 대규모 프로젝트에 적합합니다.
데이터 전송의 효율성이 중요한 요소인 프로젝트에서 REST가 가장 잘 작동합니다. 캐싱은 음식 예약 애플리케이션, 호텔 예약 애플리케이션, 블로그 웹사이트, 온라인 포럼 웹사이트 등과 같은 표준 애플리케이션에 유용한 REST의 또 다른 기능입니다.
REST의 한계 및 문제점
REST는 훌륭하지만, 어떤 경우에는 매우 중요한 여러 단점이 있습니다. 이야기해보죠.
- 양방향 통신의 필요성.
서버가 클라이언트에 데이터를 보내야 한다면 어떨까요? 서버가 통신을 시작하고 싶어합니다. REST 아키텍처에서는 이것이 불가능합니다. 물론 몇 가지 요령을 사용할 수는 있지만, 실용적이지 않습니다. - 라이브 점수 웹사이트를 만든다고 상상해보세요. 서버가 클라이언트에 점수 데이터를 업데이트하라는 요청을 어떻게 관리할까요? 클라이언트가 10초마다 요청을 보낼 수는 있지만, 전혀 좋은 방법이 아닙니다. 서버에 과부하가 걸릴 수 있으며, 이로 인해 속도 문제가 발생할 수 있습니다.
- REST 아키텍처는 순수하게 요청과 응답으로만 이루어져 있으며, 데이터 스트리밍(지속적인 이벤트 처리)을 지원하지 않습니다.
- REST의 무상태 특성은 축복일 수도 있고 저주일 수도 있습니다. 왜냐하면 REST 아키텍처에서 데이터의 상태를 결정할 수 없기 때문입니다.
gRPC가 존재하게 된 이유는 무엇일까요?
REST의 첫 번째 문제인 양방향 통신의 필요성을 해결하기 위해 WebSocket이 발명되었습니다. 이는 서버가 통신을 시작할 수 있게 해주지만, 문제는 포맷이 없다는 것입니다. 그것은 단순히 바이트를 보내며 제한이 없습니다.
Websockets 자체에는 문제가 없지만, 실제 문제는 어떤 유형의 통신이라도 프로토콜이 필요하고, 각 프로토콜은 해당 프로토콜을 사용하여 통신할 수 있는 클라이언트 라이브러리를 요구한다는 것입니다.
파이썬 애플리케이션을 개발하고 있으며, Rest 아키텍처를 사용한다면, 서버와 통신할 수 있는 HTTP 클라이언트가 필요합니다. 대부분의 경우, 클라이언트 라이브러리는 독립 개발자 등 제3자에 의해 제작됩니다. 제3자 라이브러리를 사용하면 보안에 취약해질 수 있으며, 전체 애플리케이션의 통신이 제3자에 의존하게 됩니다.
웹 애플리케이션의 경우 브라우저가 클라이언트 라이브러리 역할을 하지만, 웹이 아닌 프로젝트의 경우 제3자 클라이언트 라이브러리가 필요합니다. 직접 만들고자 한다면, 그것이 쉽지 않으며 또 다른 애플리케이션을 유지 관리하는 부담이 생깁니다.
따라서, Rest와 클라이언트 라이브러리의 문제점을 해결하기 위해 구글은 2015년에 gRPC를 발明月했습니다.
gRPC의 경우, 거의 모든 인기 있는 언어에 대해 구글이 유지 관리하는 하나의 클라이언트 라이브러리가 있습니다. HTTP 2 프로토콜을 기반으로 사용하며, 메시지 형식으로 프로토콜 버퍼(protobuf)를 사용합니다.
클라이언트 라이브러리에 대해 걱정할 필요가 없습니다. 구글이 거의 모든 프로그래밍 언어에 대해 유지 관리하고 있기 때문입니다. 단일이고 중앙집중식인 클라이언트 라이브러리는 gRPC의 주요 강점 중 하나입니다.
gRPC의 또 다른 이점은 사용하는 메시지 형식입니다. 프로토콜 버퍼는 언어에 독립적이므로, Python으로 클라이언트를 만들고 Go로 서버를 만들어도 문제 없이 통신할 수 있습니다.
gRPC는 근본적으로 모든 기기에서 사용할 수 있는 하나의 클라이언트 라이브러리와 프로토콜입니다.
gRPC란 무엇인가?
gRPC는 protobuf를 사용하여 통신합니다. 이는 proto 파일을 이진 형식으로 직렬화하여 서버에 전송하고, 서버 측에서는 원래 형식으로 역직렬화합니다. 이것이 protobuf와 함께 gRPC가 작동하는 방식입니다.
gRPC는 다양한 형태의 통신을 가지고 있습니다. 이들을 gRPC의 특징으로 생각할 수 있습니다.
gRPC의 특징
- 단일 요청:클라이언트가 proto 요청을 보내고, 서버가 이를 받으면 어떤 프로세스를 수행하기 위해 일정 시간 동안 대기한 후 응답을 반환하는 요청-응답 통신의 간단한 유형입니다.
- 서버 스트리밍:단일 요청을 보내면 서버로부터 데이터의 홍수가 응답으로 옵니다. 예를 들어, 비디오를 클릭할 때 서버 측에서 많은 비디오 관련 데이터가 몰려오는 것이 이에 해당합니다.
- 클라이언트 스트리밍:서버 스트리밍과 반대로, 클라이언트가 한 번에 많은 양의 데이터를 서버에 보냅니다. 인터넷에서 큰 파일을 공유하거나 이미지나 비디오를 업로드할 때 이런 일이 발생합니다. 클라이언트는 서버 측으로 데이터를 지속적으로 보냅니다.
- 양방향 스트리밍:이런 유형의 통신에서는 클라이언트와 서버가 여러 메시지를 주고받습니다. 채팅은 이것의 좋은 예입니다.
이들은 gRPC의 네 가지 인기 있는 특징으로서 gRPC를 강력하게 만듭니다.
gRPC 사용 시기
gRPC의 특징에 대해 살펴보았고, gRPC의 일부 사용 사례를 살펴보았습니다. 채팅 애플리케이션을 만들고 싶다고 상상해 보세요. 이중 방향 통신의 빠른 스트리밍을 허용하지 않기 때문에 Rest API를 사용하지 않을 것입니다. 이를 위해 gRPC 스트림을 사용할 것입니다. 이는 속도 이상으로 몇 가지 더 많은 이점을 제공합니다.
첫째, 언어 중립적 동작은 서버 또는 다른 클라이언트가 어떤 프로그래밍 언어로 작성되었는지와 관계없이 메시지 형식이 수락되는 한 통신을 설정할 수 있습니다.
따라서 이 기능으로 인해 채팅 앱의 Android 버전은 iOS 버전과 통신하고 그 반대도 가능합니다.
gRPC의 문제점
모든 것에는 문제가 있으며 gRPC도 예외는 아닙니다.
- 브라우저 지원 제한:gRPC는 HTTP 2를 사용하기 때문에 브라우저에서 gRPC 서비스를 직접 호출하기가 어렵습니다. 때로는 프록시를 설정해야 합니다.
- 읽기 불가능한 형식:우리 모두 알다시피 gRPC는 인간이 읽을 수 없는 바이너리 형식을 사용합니다. 이는 일부 경우 단점이 될 수 있습니다.
- 성숙도 부족:gRPC는 2015년에 개발되었으므로 REST에 비해 아직 약간 미숙하며 많은 버그와 문제가 해결되어야 합니다.
- 학습 문제:Rest와 GraphQL은 더 쉬운 학습을 위해 JSON을 사용합니다. 대부분의 사람들은 여전히 새롭고 복잡한 주제인 protobuf에 대해 잘 알지 못하기 때문에 gRPC 전문가를 찾기가 어려울 것입니다.
REST와 gRPC의 비교:
이제 REST와 gRPC의 기술적 차이점에 대해 논의해 보겠습니다.
메시지 형식:
REST가 사용하는 메시지 형식은 대부분 JSON(때론 XML 형식)으로, 이는 더 읽기 쉽고 처리하기 쉬운 형태입니다. REST에서는 스키마에 대해 걱정할 필요가 없습니다. 반면에, gRPC는 데이터를 직렬화하는 데 프로토콜 버퍼를 사용합니다. 압축된 형태는 가볍고 이동하기 빠릅니다. 이는 이진 형식으로, 데이터를 전송하기 위해 직렬화 및 역직렬화합니다.
HTTP 1.1 vs. HTTP 2:
REST API는 일반적으로 HTTP 1.1을 프로토콜로 사용하는 반면, gRPC는 하부에서 HTTP 2를 사용합니다. REST API는 HTTP 2를 사용할 수 있지만 여전히 요청-응답 메커니즘 때문에 제한됩니다. gRPC는 HTTP 2를 사용하고, HTTP 2가 클라이언트-응답 및 양방향 통신을 모두 지원하는 이점을 활용합니다. 이는 gRPC가 REST보다 성능이 뛰어난 또 다른 측면입니다. HTTP 1.1과 같은 단방향 요청 및 HTTP 2와 같은 동시에 양방향 요청을 관리할 수 있습니다.
레이턴시:
gRPC의 낮은 레이턴시와 높은 속도는 가볍고 미세한 마이크로서비스 아키텍처로 구성된 시스템에 연결하는 데 유용합니다. 이는 메시지 전송 효율성을 높입니다. 대부분의 네트워크 상황에서 REST는 25ms의 레이턴시를 가지고 있지만, gRPC의 레이턴시는 REST보다 훨씬 낮습니다.
페이로드 제한:
REST는 외부 메시지를 보낼 때 최대 페이로드 제한이 45MB인 반면, gRPC는 제한이 없으므로 외부 메시지의 크기를 원하는 만큼 크게 만들 수 있습니다.
보안:
보안 측면에서 Rest는 HTTP 1.1과 JSON 형식을 사용하기 때문에 해독 및 접근이 용이하여 속도가 느릴 수 있습니다. 반면에, gRPC는 훨씬 안전한 HTTP 2를 사용하고 이진 형식으로 해독하기 어려운 protobuf를 사용합니다.
속도:
여기서도 gRPC가 이긴다. HTTP 2를 프로토콜로 사용하고 protobuf를 메시지 형식으로 사용하여 Rest보다 10배 더 빠르기 때문입니다.
코드 생성 기능
Rest는 내장된 코드 생성 기능을 제공하지 않으므로 개발자는 API 코드를 생성하기 위해 타사 애플리케이션을 필요로 합니다. 반면 gRPC는 여러 프로그래밍 언어와 호환되는 protobuf 컴파일러 덕분에 기본 코드 생성 기능을 가지고 있습니다. 이는 특히 마이크로서비스 아키텍처에 대한 또 다른 이점입니다.
멤피스 리스트 게이트웨이
다양한 사용 사례를 위해 HTTP 호출을 통한 메시지 생성 및 사용의 용이성을 위해 멤피스는 필요한 스테이션으로 메시지를 생성하기 위해 REST 기반 요청(=메시지)을 수신하는 HTTP 게이트웨이를 추가했습니다.
REST 게이트웨이의 일반적인 사용 사례는 다음과 같습니다:
- 프론트엔드에서 직접 이벤트 생성
- Debezium을 사용하여 HTTP 서버 연결
- ArgoCD 웹훅
- PostHog 통합
- Fivetran/Rivery/또는 다른 ETL 플랫폼에서 HTTP 호출을 통해 데이터 수신
멤피스 리스트 게이트웨이 + JSON 스키마는 애플리케이션 또는 서비스 간의 데이터 품질을 높이고 건강한 통신을 보장하는 강력한 조합이 될 수 있습니다.
멤피스는 곧 gRPC도 지원할 예정입니다.
결론
궁극적으로, REST는 여전히 가장 많이 사용되고 인기있는 아키텍처라고 말씀드리고 싶습니다. 이를 포기하는 것은 불가능합니다. REST는 데이터 스트리밍 부족, 양방향 통신 부재, 속도 저하 등과 같은 많은 단점이 있지만, 일상 생활에서 볼 수 있는 표준 애플리케이션에 가장 적합합니다.
반면에, gRPC는 젊고 배우기 어렵지만, 클라이언트와 서버 측 모두 높은 데이터 스트리밍, 양방향 데이터 스트리밍, 빠르고 간결하며 HTTP 2를 사용한다는 많은 장점을 제공합니다. 빠른 성능 덕분에 gRPC는 동영상 스트리밍, 노래 스트리밍, 온라인 게임, 파일 공유, 채팅 애플리케이션과 같은 고부하 애플리케이션에 가장 적합합니다.