GRPC
구글에서 개발한 대표적인 RPC 프레임워크 , 일반적으로 Internal API는 RPC API, External (Web) API는 HTTP API로 구축
API : 두 소프트웨어가 서로 Communicate할 방법을 설명해 놓은 것
REST API : 대부분 HTTP API가 따르는 아키텍처 스타일(제약조건)을 만족하는 API
프레임워크가 아닌 REST Design Principles 을 따르는 API 로 높은 자유도 보장 -> 여러 Component 연결, MicroServices architecture에서 많이 사용
클라이언트. 서버. 리소스, 표현 (Representation) 으로 구성
예) 내 브라우저 (클라이언트) 가 기상청 API 를 통해 날씨 (리소스) 정보를 요청하면 기상청 서버가 날씨 정보를 JSON (표현) 형태로 제공
REST Design Priciples
Client-server decoupling. 클라이언트와 서버 어플리케이션이 완벽히 decouple 되어 있어야함. 클라이언트가 알아야 할 유일한 정보는 필요한 리소스의 URI 임. 마찬가지로 서버도 클라이언트가 보낸 Request에 Response만 보낼 수 있음.
Statelessness. REST APIs 는 stateless 해야함. 각각의 Request가 그 Request를 처리하는데 필요한 모든 정보를 가지고 있어야 함. 서버 사이드 세션이 필요없음. 서버는 클라이언트 Request에 관련된 정보를 저장할 수 없음 - 예) Statelessness : 햄버거 주문할 떄 "햄버거 주세요"하면 어떻게 대응할지 필요한 정보가 다 있음 , 기존의 정보 필요 없음 , Stateful한 API : 어제 주문했던 햄버거 동일한 거 주세요 , 내가 누군지 알아야 되고 기록해야함 - Statelessness하기 떄문에 Request 올 떄마다 다른 서버가 다운 되지 않도록 핸들링 가능하기에 유지보수에 용이 , 또한 해당 API만 원인을 파악하면 되므로 디버깅에도 용이
Uniform Interface. 같은 리소스에 대한 리퀘스트는 항상 같아야함. 한 리소스에 대한 데이터는 모두 같은 Uniform Resource Identifier (URI) 에 있어야 함. 리소스는 클라이언트가 필요한 최소한의 데이터만 가지고 있어야함
Cacheability. 가능한 경우 클라이언트나 서버 측에서 자원을 캐시할 수 있도록 해야함. 또한 서비 응답에는 전송된 자원에 대해 캐싱이 허용되는지 여부에 대한 정보가 포함되어야 함. 이를 통해 클라이언트 측 성능을 개선하고 서버 측 확장성을 높이는 것이 목표
Layered system architecture. REST API 에서 호출 및 응답은 서로 다른 계층을 통해 이루어짐. 원칙적으로 클라이언트와 서버 애플리케이션이 직접 연결된다고 가정해서는 안 됨. 통신 루프에는 다양한 중간 매개체가 있을 수 있음. REST API 는 클라이언트나 서버가 최종 애플리케이션 또는 중간 매개체와 통신하는지 구분할 수 없도록 설계되어야 함.
Code on demand (optional). REST API는 일반적으로 정적인 자원을 보내지만. 특정 경우에는 응답에 실행할 수 있는 코드 (예: Java 애플릿) 도 포함 가능. 이러한 경우 코드는 요청 시에만 실행되어야 함
gRPC와 JSON을 사용하는 HTTP API 비교
gRPC가 나오게 된 배경
구글의 내부 서비스 통신 문제 구글은 다양한 서비스들이 서로 통신해야 하는 환경을 가지고 있었으며, 각 서비스가 다양한 언어와 플랫폼으로 개발되어 효율적이고 표준화된 통신 방법이 필요함. 이러한 요구를 해결하기 위해 Stubby라는 자체 RPC(Remote Procedure Call) 시스템을 도입하여, 내부 서비스 간 효율적인 통신을 지원하고자 함.
기존 방식의 한계 기존 REST API 방식은 HTTP/1.1과 JSON, XML 같은 포맷을 사용했으나, 데이터 전송 속도가 느리고 대용량 데이터 처리나 실시간 양방향 통신에 한계가 있었음. 또한, 다양한 언어와 플랫폼에서 일관성 있게 적용하기 어렵다는 점이 있어, 보다 일관적이고 효율적인 통신 방식을 제공하고자 함.
새로운 기술의 등장 HTTP/2와 Protocol Buffers(프로토콜 버퍼) 같은 새로운 기술이 등장하면서, 데이터 전송 속도를 높이고 다양한 언어와 플랫폼에서 쉽게 사용할 수 있는 환경을 제공하고자 함.
오픈소스와 표준화 필요성 구글은 Stubby의 장점과 최신 기술을 결합해 외부 개발자들도 사용할 수 있는 오픈소스 RPC 프레임워크를 만들기로 하였으며, 누구나 쉽게 사용할 수 있는 표준화된 통신 방법을 제공하고자 함.
마이크로서비스와 클라우드 환경의 확산 최근 마이크로서비스 아키텍처와 클라우드 환경이 널리 사용되면서, 서비스 간 빠르고 효율적인 통신의 중요성이 커짐. 이러한 환경에 최적화된 통신 방식을 지원하고자 gRPC가 등장하게 됨.
https://learn.microsoft.com/ko-kr/aspnet/core/grpc/comparison?view=aspnetcore-9.0
Last updated