[Server] REST API & gRPC

REST API / gRPC

REST API와 gRPC는 서버와 클라이언트 간의 통신을 위해 사용되는 두 가지 대표적인 프로토콜이다.

REST API를 사용하는 경우 gRPC와 비교 시 좀 더 광범위하게 사용되고 선호되는 것을 볼 수 있다.

반대로 gRPC는 외부 사용자가 액세스 할 수 없는 내부 시스템 또는 구조를 만들 때 주로 사용된다.

 

REST API

REST란 자원을 이름(자원의 표현)으로 구분해 해당 자원의 상태(정보)를 주고받는 모든 것을 의미한다.

기본적으로 웹의 기존 기술과 HTTP 프로토콜을 그대로 활용한 아키텍처 스타일을 따르게 된다.

REST API는 CRUD ( Create, Read, Update, Delete ) 연산을 수행하기 위해 URI로 GET, POST 방식의

Http Method를 사용하여 요청을 보내며, 요청을 위한 자원은 특정한 형태로 표현하게 된다.

URI ( Uniform Resource Identifier ) - 인터넷상의 자원을 식별하기 위한 문자열로 구성
URL ( Uniform Resource Location ) - 인터넷상 자원의 위치를 의미
URI는 URL을 포함하므로, URI가 URL보다 포괄적인 범위 

 

REST의 구성은 자원, 행위, 표현으로 구성된다.

먼저 자원 ( Resource )은 URI로 표현되며, 모든 자원에는 고유한 ID가 존재한다.

자원을 구별하는 아이디는 '/members/:member_id'와 같은 HTTP URI를 통해 나타낼 수 있다.

클라이언트는 URI를 이용하여 자원을 지정하고, 해당 자원의 상태정보에 대한 조작을 서버에 요청한다.

다음으로 행위 ( Verb )는 HTTP Method ( CRUD )로 구성되며,

GET / POST / PUT / PATCH / DELETE 5가지의 Http Method가 존재한다. 

GET - Read / 정보 요청
POST - Create / 정보 입력
PUT - Update / 정보 업데이트 ( 데이터 전체 )
PATCH - Update / 정보 업데이트 ( 데이터 일부 )
DELETE - Delete, 정보 삭제

 

마지막으로 표현 ( Representations) 이다.

이는 클라이언트와 서버가 데이터를 주고받는 형태를 나타내며,

주로 JSON 형태로 클라이언트와 서버가 데이터를 주고받게 된다.

JSON 외에도 XML, TEXT 등이 존재한다.

 

REST의 특징을 살펴보면 다음과 같다.

• 서버 - 클라이언트 구조 
  자원이 있는 쪽이 Server, 자원을 요청하는 쪽이 Client로 역할을 구분하여 상호 의존성을 최소화
• 무상태 ( Stateless )
  Client의 Context를 Server 측에 저장하지 않는다.
  즉 이전 요청이 다음 요청의 처리에 연관되어서는 안 된다.
  요청 간에 상태를 저장하지 않으며, 각 요청은 독립적으로 처리된다.
• 캐싱 ( Cacheable )
  웹 표준 HTTP 프로토콜을 그대로 사용하므로, HTTP 프로토콜의 특징을 그대로 활용한다.
• 계층 구조 ( Layered System )
  Rest Server는 다중 계층으로 구성할 수 있다.
  보안, 로드 밸런싱, 암호화 등을 위한 계층이 추가되어 구조를 변경할 수 있다.
• 인터페이스 일관성 ( Uniform Interface )
  URI로 지정한 Resource에 대한 요청을 통일한고, 모든 요청은 HTTP 프로토콜을 사용한다.
• 자체 표현 ( Self-Descriptiveness )
  요청 메시지 ( URI )만 보고도 쉽게 이해할 수 있는 자체 표현 구조를 가지고 있다.

REST API Architecture

 

다음과 같은 REST의 구성과 특징을 기반으로 서비스 API를 구현한 것이 REST API이다.

이러한 REST API의 장점을 살펴보면 다음과 같다.

표준화된 아키텍처 - HTTP 프로토콜을 그대로 사용하여 표준화된 구조를 가진다.
광범위한 자원 - HTTP 프로토콜을 지원하는 모든 플랫폼에서 사용이 가능하다.
쉬운 학습 곡선 - REST API 자체로 의도하는 바를 명확하게 나타내므로 쉽게 이해 가능하다.
확장성 - Stateless 특성으로 각각의 요청이 독립적으로 처리 가능하다. ( 부하 분산, 캐싱 )

 

이처럼 REST API는 배우기 쉽고 이해하기 간단하며, 브라우저 및 웹 기술과 잘 통합되고,

다양한 데이터 포맷 ( JSON, XML, TEXT ) 등을 지원한다.

하지만 물론 단점도 존재한다. REST API의 단점을 살펴보면 다음과 같다.

표준화된 강제 사항 없음 - 개발자마다 구현 방식이 다양하여 상호 보완성이 저해될 수 있다.
데이터 전송 형식의 제한 - HTTP Method 형태가 제한적, 비정형 데이터나 대용량 파일 전송에 비효율
Stateless로 인한 데이터 전송 부담 - 각 요청마다 Client의 상태 정보를 포함해야 하므로, 트래픽 증가
실시간 데이터 전송의 한계 - 실시간 데이터 전송에는 비효율로 다른 대안이 필요

 

REST API는 요청 / 응답 방식으로 실시간 데이터 전송에는 비효율적으로

실시간 양방향 통신에는 Web Socket 등의 대안이 필요하다. 또한 기본적으로 텍스트 기반이므로

데이터 양이 많을 경우 오버헤드가 발생하고, 무상태성으로 인해 클라이언트 정보가 필요할 때는

매 요청마다 클라이언트 정보를 추가해야 하므로 오버헤드가 크게 발생할 수 있다.

 

gRPC

gRPC는 Google에서 개발한 원격 프로시저 호출 ( Remote Procedure Call ) 프레임워크이다.

gRPC는 Protocol Buffers ( Protobuf )를 사용하여 데이터를 직렬화한다.

다양한 프로그래밍 언어와 환경을 지원하며,

REST API는 HTTP/1 위에서 동작하지만, HTTP/2 위에서 동작한다는 차이점이 존재한다.

HTTP/1과 HTTP/2의 차이점을 간단히 살펴보면 다음과 같다.  

HTTP/1.1 vs HTTP/2

 

 

HTTP/1.1은 연결당 하나의 요청과 응답을 처리하는 구조를 기본으로 한다.
즉, 하나의 요청/응답 주기마다 서버와 클라이언트 사이에서 Session 연결이 필요하다.

이 구조에서는 요청/응답 과정에서 동시 전송 문제가 발생할 수 있다.
또한, 다수의 리소스를 처리해야 할 경우에는 여러 개의 연결을 반복적으로 생성/종료해야 하므로

성능 저하와 네트워크 오버헤드가 생길 수 있다. 하지만 HTTP/2는 다음과 같은 개선점을 제공한다.

 

단일 연결로 다중 요청 처리

• HTTP/2는 하나의 연결(Session)에서 여러 요청과 응답을 동시에 처리할 수 있다.
  
• 이로 인해 요청/응답 순서가 서로 독립적이며, 병렬 처리가 가능하다

서버 푸시(Server Push)

• HTTP/2는 클라이언트가 요청하지 않아도 서버가 데이터를 먼저 푸시(push)할 수 있다.
• 이를 통해, 클라이언트가 필요한 리소스를 미리 제공하여 대기 시간을 줄일 수 있다.

헤더 압축

• HTTP/2는 헤더 데이터를 효율적으로 압축하여 전송량을 줄인다.
• 추가 요청에서 중복되는 헤더 정보를 제거하거나 공통된 헤더를 캐싱해 전송 효율성을 높인다.

스트리밍 통신 지원

• HTTP/2는 하나의 연결로 클라이언트와 서버 간에 스트리밍 통신이 가능하다.
• 이를 통해 실시간 데이터 전송이나 대규모 리소스 로드가 더욱 효율적으로 이루어진다.

REST API는 HTTP/1.1의 제한 사항으로 인해 세션 관리 및 네트워크 오버헤드 문제가 존재할 수 있다.
하지만, HTTP/2 위에서 작동하는 경우 단일 연결로 다중 요청을 처리하고

헤더 압축 및 스트리밍 통신과 같은 이점을 활용할 수 있다.

이처럼 HTTP/2의 멀티플렉싱과 서버 푸시 기능은 리소스 로드 최적화와 대기 시간 감소에 기여한다. 

 

위의 그림은 gRPC의 동작 과정을 나타낸 다이어그램으로,

각 단계에서의 역할과 데이터 흐름은 다음과 같다.

 

Service Interface 정의

• 개발자는 Service.proto라는 Protocol Buffers ( proto ) 파일에서
  gRPC 서비스의 인터페이스를 정의한다. 이 파일에 서비스 메서드와 데이터 구조를 정의한다.

코드 생성

• .proto 파일을 바탕으로 gRPC는 클라이언트 Stub와 서버 Skeleton을 자동으로 생성한다.
  • Stub : 클라이언트가 원격 서버와 통신하기 위한 메서드를 제공.
  • Skeleton : 서버가 클라이언트 요청을 처리하기 위한 메서드를 구현.
• 언어별 플러그인을 사용하여 자동으로 gRPC 코드를 생성할 수 있다.
  예를 들어, Java, Python, Go 등 다양한 언어에서 proto 파일을 컴파일하여 사용 가능하다.

클라이언트

• 클라이언트 애플리케이션에서 Stub을 통해 원격 gRPC 서비스를 호출한다.
• 클라이언트는 로직과 데이터를 Stub에 전달하고,
  Stub은 이를 Protocol Buffers 형식으로 직렬화한 후 HTTP/2로 서버에 요청한다.

서버

• 서버는 요청을 수신한 후 gRPC Skeleton을 통해 데이터를 역직렬화한다.
• Skeleton은 클라이언트 요청에 따라 서버의 비즈니스 로직을 실행하고 결과를 반환한다.

응답 전달

• 서버는 결과 데이터를 Protocol Buffers 형식으로 직렬화하여
  HTTP/2를 통해 클라이언트로 반환한다.
• 클라이언트 Stub은 응답 데이터를 역직렬화하여 클라이언트 로직으로 전달한다.

 

여기서 Protocol buffer란 무엇일까?

Protocol Buffers는 Google에서 개발한 효율적인 직렬화 및 역직렬화 프레임워크이다.

이에 대한 주요 특징을 살펴보면 다음과 같다.

직렬화와 역직렬화
데이터를 네트워크로 전송하거나 파일에 저장할 때,
Protocol Buffers는 데이터를 바이너리 형식으로 변환하여 크기를 최소화
수신 측에서는 이 바이너리 데이터를 역직렬화하여 원래의 데이터 구조로 복원

빠른 속도
JSON이나 XML보다 더 작고 빠르다. 데이터 크기를 줄이고,
직렬화/역직렬화 성능을 향상해 네트워크 및 스토리지 효율성을 극대화한다.

언어 독립성
프로토콜 정의(proto 파일)를 사용하여 다양한 프로그래밍 언어로 코드를 생성할 수 있다.
(Java, Python, C++, Go...)

버전 관리 용이
필드에 번호를 붙여 메시지를 정의하므로,
새로운 필드를 추가하거나 제거할 때도 하위 호환성을 유지할 수 있다.

 

Protocol Buffers의 메시지 예시를 살펴보면 다음과 같다.

message Member {
    string name = 1;  // 필드 번호 1
    int32 age = 2;    // 필드 번호 2
    string email = 3; // 필드 번호 3
}

 

위와 같은 메시지 정의를 통해 데이터를 바이너리 형식으로 압축 전송하며,

JSON보다 빠르고 네트워크 비용이 적게 든다는 장점이 존재한다.

 

Stream

4 Types of gRPC

 

gRPC는 4가지의 통신 방식이 존재하며, 각각의 특징을 살펴보면 다음과 같다.

Unary

• 가장 기본적인 요청-응답 방식
  클라이언트가 서버에 하나의 요청을 보내고, 서버가 하나의 응답을 반환하는 구조
• 특징
  • HTTP/REST 방식과 유사한 동작
  • 요청과 응답은 모두 단일 메시지로 구성
  • 가장 간단하고 일반적으로 사용되는 방식

Client Streaming

• 클라이언트가 서버로 여러 개의 요청을 스트리밍 방식으로 보낸 뒤,
  서버가 이를 처리하고 단일 응답을 반환하는 구조
• 특징
  • 클라이언트가 다수의 데이터를 연속적으로 전송
  • 서버는 모든 요청을 처리한 후 최종적으로 응답을 반환
  • 대용량 데이터를 처리하거나 여러 요청을 묶어서 처리하는 데 적합

Server Streaming

• 클라이언트가 단일 요청을 보내면,
  서버가 여러 개의 응답을 스트리밍 방식으로 반환하는 구조
• 특징
  • 클라이언트는 한 번 요청 후 서버의 응답을 지속적으로 받음
  • 서버는 클라이언트의 요청에 대한 응답을 순차적으로 스트리밍
  • 데이터 스트림을 클라이언트가 처리할 수 있는 경우 유용

Bidirectional Streaming

• 클라이언트와 서버가 서로 독립적으로 여러 개의 메시지를 스트리밍 방식으로 주고받는 구조
• 특징
  • 양방향 통신을 통해 실시간 데이터를 교환.
  • 클라이언트와 서버는 서로 데이터를 보낼 때 독립적인 순서를 유지
  • 실시간 채팅, 주식 가격 업데이트 등과 같은 실시간 애플리케이션에 적합

이 네 가지 방식은 gRPC가 제공하는 성능과 유연성을 극대화하며,

각각의 사용 사례에 맞게 적합하게 선택할 수 있다는 장점이 존재한다. 

이를 통해 REST처럼 하나의 요청 / 응답만 주고받는 것이 아닌

여러 개의 메시지를 스트리밍으로 주고받는 형태의 구현을 손쉽게 할 수 있다.

 

REST API vs gRPC

REST API와 gRPC의 개괄적인 비교를 하면 다음과 같다.

기능	gRPC	JSON을 사용하는 HTTP API
계약	필수(.proto)	선택 사항 ( Open API )
프로토콜	HTTP/2	HTTP
데이터 포맷	Protobuf(소형, 이진)	JSON(대형)
규범	엄격한 사항	느슨함 / 모든 HTTP가 유효
스트리밍	클라이언트-서버 / 양방향	클라이언트-서버
호환성	추가 설정 필요 ( 브라우저 제외 )	브라우저
성능	빠르고 효율적	상대적으로 낮음

 

REST API는 gRPC와 비교 시 좀 더 광범위하게 사용되고 선호된다.

이는 빠른 반복 및 HTTP 프로토콜 표준이 필요한 시스템에 적합하다.

따라서 웹 서비스 개발, 마이크로 서비스 및 앱 인터페이스 개발 시 유용하다.

 

반대로 gRPC는 외부 사용자가 액세스 할 수 없는 내부 시스템  또는 구조를 만들 때 주로 사용한다.

짧은 대시 시간과 빠른 대역폭 통신 등 메시지 전달의 효율성이 중요한 경우에 유용하게 사용할 수 있다.

또한 실시간 통신이나, 양방향 스트리밍이 필요한 경우에 유용하며,

제한된 네트워크 환경에서 경량 메시지 형식이 필요한 경우에 유용하게 사용가능하다.

이처럼 gRPC는 REST API처럼 광범위하게 사용되지는 않지만,

HTTP/2 위에서 동작하는 구조로  여러 가지 장점을 가지고 있다.

따라서 시스템 구조 혹은 상황에 따라 REST API 대신 gRPC를 선택하는 것이 좋을 수 있다.

 

 

참고자료

https://abdullah-jan-khan.medium.com/realtime-communication-using-grpc-pt-1-5c2466811232