📰 이번에 다룬 뉴스:

Yuval Hazaz 의
REST vs. gRPC - What’s the Difference?
✅ 작성자 편한대로, 이해한 대로, 기억하고 싶은 부분만 chat-gpt 와 함께 번역했습니다. 믿지 마시고, 되도록이면 위의 원문을 봐주세요.
⚡️ 해당 이모지가 있는 부분은 원문에 없는 작성자의 사족입니다.

✒️ 느낀 점

여러 서비스를 개발한 우리 개발팀에서는 동일한 하나의 서버를 복수의 서비스에서 사용하고 있다. 새로운 기능이나 변경이 있을 때마다 l2 버전으로 명명해 api 를 새로 뚫고 기능을 구현하고 있었는데 이를 해결하기 위한 방법으로 gRPC 가 스크럼에서 나왔었다. 응애 신입은 gRPC 가 뭔지 몰라 가만히 듣고 있었는데, 이번 기회에 뉴스를 번역하며 알아보았다.

🔤 번역

현대의 대부분의 어플리케이션은 클라이언트와 상호작용하기 위해 APIs에 의존하고 있다. 이 의존성은 효율적이고 확장 가능하며 인관된 API 를 설계하는 것의 중요성을 크게 만들었다. 이를 이루기 위해 API 설계에 구조와 일관성을 도입한 다양한 프레임워크가 나타났다.
REST 는 API 개발과 설계에서 오랜시간 산업의 표준이었다. gRPC는 구글에서 최근 소개한 빠르고, 확장가능한 APIs 프레임워크이다.
이 글에서 위 2가지의 프레임워크에 대해 알아보고 어떤 상황에서 어떤 프레임워크를 선택해야 되는지 알아보도록 하겠다.

REST 가 뭔데?

REST 는 Representational State Transfer 의 줄임말로서 웹 기반 또는 마이크로서비스 기반의 어플리케이션의 API로서 가장 널리 사용되는 아키텍처이다. REST는 표준 HTTP 프로토콜 위에 구축되며, 각 RESTful 웹 서비스는 리소스를 나타낸다. 이러한 리소스는 HTTP 표준 메소드(GET, POST, PUT, DELETE)를 사용하여 공통 인터페이스를 통해 가져오거나 조작할 수 있다.

REST api 는:

• 클라이언트-서버 독립적: 사용자 인터페이스(클라이언트) 관련 문제와 데이터 저장(서버) 관련 문제가 분리된다.
• 무상태(stateless): 클라이언트와 서버 간의 통신에는 요청을 처리하는데 필요한 모든 정보를 가지고 있다.
• 캐시 가능: 클라이언트나 서버 쪽에 캐시되어 더 나은 성능을 달성할 수 있다.

REST api 는 모든 컴포넌트가 통신하는데에 같은 룰을 적용시켜 통일된 인터페이스를 제공하기 위해 설계됐다. 나아가 계층 구조를 가지고 있어 각각의 컴포넌트는 실제 상호작용하고 있는 레이어의 정보만을 볼 수 있다.

gRPC는 뭔데?

goole remote precedure call 이라고도 불린다. RPC 프로토콜에 기반해 만들어졌다. RPC 프로토콜은 오픈 소스, 크로스 플랫폼, 고속 통신 프로토콜로, HTTP 2.0을 사용하는 분산 애플리케이션에서 서비스 간 통신에 널리 사용된다.

gRPC는 RPC의 확장된 형태이며 원격 서버에서 호출된 함수를 동일한 서버에서 호스팅되지 않은 다른 서버와 기계에서 호출할 수 있게 해준다. HTTP 2.0 프로토콜을 통해, gRPC는 양방향 스트리밍을 할 수 있으며, 내장된 통신 계층 보안을 제공하고 개발자로 하여금 다양한 언어로 프로그래밍된 서비스를 통합할 수 있도록 해준다.

gRPC는 HTTP를 전송 계층으로 사용해 개발자가 미리 정해진 옵션이 아닌 원하는 함수를 호출할 수 있도록 해준다. 또한 서버와 클라이언트간의 느슨한 결합을 제공을 제공하는데, 이는 서버와 클라이언트간의 오래 지속되는 연결이 만들어지기 때문이며 각 RPC 호출마다 새로운 HTTP 2.0 스트림이 열리기 때문이다.

REST와 gRPC에 대한 비교

작동 모델
REST는 HTTP 1.1 프로토콜에 기반해 만들어졌으며 요청-응답 모델에 따라 api 를 설계하도록 한다. gRPC는 반대로, HTTP 2.0 프로토콜에 기반해 만들어졌으며 양방향 통신 기능과 전통적인 요청-응답 모델을 사용한다. 이것은 RESP api 에서는 다양한 클라이언트로부터의 다양한 요청이 순차적으로 처리되는 반면, gRPC 는 여러 요청을 동시에 처리할 수 있다는 것을 의미한다. (HTTP 2.0 이 다중화 기능을 제공하기 때문)

REST의 작동 모델은 api 를 정의할 때 내장된 코드와 표준 규칙을 필요로 한다. gRPC 는 .proto 파일에 미리 정의된 모델을 따른다. 이 파일에서는 서버와 클라이언트가 따라야할 표준 데이터 교환 가이드라인을 포함하고 있다.

통신 모델
REST와 gRPC는 요청을 보내고 응답을 받는 데 다른 메시징 형식을 사용한다.
REST API는 일반적으로 서버와 클라이언트 간에 메시지를 주고받을 때 JSON으로 구현한다. JSON은 텍스트 기반이며 사람이 읽을 수 있기 때문에 다른 메시징 형식보다 효율적이고 플랫폼에 독립적이기 때문이다.

gRPC는 프로토콜 버퍼를 마치 REST가 JSON을 사용하듯이, 직렬화 및 통신에 사용한다. 프로토콜 버퍼는 데이터를 직렬화할 때 매우 효율적이고 밀집된 메세징 형태이기에 신속한 응답 전달이 가능하다. 나아가 프로토콜 버퍼는 시스템간 메세지 전송에서 빠른 속도를 보여주는데 왜냐하면 메세지 패킷을 marshaling (매개변수와 원격 함수를 이진 메시지 패킷으로 묶는) 을 네트워크에 보내기 전에 처리하기 때문이다.

지원하는 브라우저와 레이턴시
HTTP 1.0은 모든 브라우저에서 지원되므로, REST는 어떤한 사전 조건없이 사용된다. 하지만 HTTP 2.0 은 제한된 브라우저 지원으로 인해, gRPC가 어느 브라우저에서는 호환되지 않을 수 있다. (특히 예전버전) 아래는 HTTP2 2.0과 gRPC를 지원하는 브라우저와 그 버전이다.

• 크롬: 40+ 버전
• 파이어폭스: 36 이상의 버전
• 사파리: 9이상의 버전
• 엣지: 14 이상의 버전
• 오페라: 27 이상의 버전

※ 이는 일부 브라우저의 지원에 대한 예시일뿐이므로 정확한 정보는 공식 문저와 업데이트를 통해 살펴보기를 권합니다.

데이터 형식과 직렬화
REST는 JSON, XML과 같은 다양한 데이터 형식을 사용한다. JSON이 가장 널리 사용되는데, 이해하기 쉬우며 유연하기 때문이다. 하지만 REST가 일반적으로 엄격한 데이터 구조를 요구하지는 않는다. 이와 같은 유연성은 중요하지 않은 데이터의 전송에서 이상적일 수 있다. 반면에 gRPC는 데이터를 더 안정적으로 전송하기 위해 프로토콜 버퍼 메시지 형식만을 지원한다.

위에서 언급한대로 프로토콜 버퍼는 빠른 전송을 위해 데이터를 압축한다. gRPC의 이러한 프로토콜 버퍼의 사용은 중립적인 직렬화를 가능케하며 반면에 REST는 데이터를 XML 및 JSON이 지원하는 Python 기본 데이터로 형태로 변환하여 직렬화를 제공한다.

gRPC를 REST 대신 써야하는 경우

gRPC가 선호되는 상황에 대해서 다루기 전에 REST에 대해서 간단히 정리를 하겠다. REST는 어플리케이션이 다양한 써드파티간의 통합이 필요한 경우에 유용하다. 또한 클라우드 기반의 어플리케이션을 개발할 때도 적합한데, REST는 무상태의 호출을 만들기 때문에 기술적 실패가 발생하더라고 클라우드 어플리케이션에 쉽게 통합될 수 있기 때문이다. REST 는 모든 종류의 브라우저를 지원한다는 장점도 있다. 하지만 여전히 단점이 존재한다.

뛰어난 브라우저 지원능력으로 인해, REST는 지연시간이 길어진다. gRPC는 제한된 브라우저만을 지원하지만 레이턴시 자체가 이슈가 되지는 않는다. gRPC는 가벼운 마이크로 서비스 어플리케이션을 개발할 될 때 그 빠른 데이터 통신속도와 짧은 레이턴시로 인해 선호된다. 개발자는 실시간 데이터 통신이 필요한 마이크로서비스에서 gRPC를 사용하는 경우가 많은데, 왜냐하면 고수준의 메세지 직렬화를 제공하는 기능 때문이다. 가벼운 메시징, 저전력 네트워크 및 높은 효율성이 필요한 시스템을 연결하는 데 특히 좋다.

또한, gRPC는 네이티브 코드 생성을 제공하여 개발자가 다국어 또는 언어에 독립적인 환경에서 애플리케이션을 개발할 수 있도록 지원한다.

종합적으로, gRPC는 다중화된 스트림이 필요한 애플리케이션이나 브라우저 지원이 제한된 모바일 애플리케이션에서 사용된다.

결론

gRPC 와 REST 중 어는 것이 더 나은지 말하기는 어렵다. 하지만 gRPC는 대규모 분산 어플리케이션에 가장 유용하다고 말할 수 있을 것 같다. 하지만 gRPC는 충분히 유명하지가 않은 기술이며 제한된 브라우저 지원이라는 단점을 가지고 있다. 이러한 단점으로 인해 gRPC 서버로의 요청을 처리하기 위해 프록시 도구가 필요할 수 있다.

단어

agonostic: 불가지론, 중립적인
solely: 단독으로
whereas: 반면
incorporated: 통합된, 합병한