study/devops

마이크로서비스 간의 통신(2) - REST, 메세지 플랫폼

FYE 2023. 2. 1. 15:35

REST

REST는 HTTP로 소통하는 프로세스 간 통신 규약입니다. REST API는 웹에서 사용되는 데이터나 자원(Resource)을 HTTP URI로 표현하고, HTTP 프로토콜을 통해 요청과 응답을 정의하는 방식입니다.

 

REST의 가장 중요한 특성은 각 요청이 어떤 정보나 동작을 위한 것인지 그 모습 자체만으로 추론 가능함.

문서, 그림, 데이터등의 자원을 이름으로 구분해서 해당 자원에 대한 상태, 정보를 주고받는 것을 의미

 

 

- HTTP method를 활용해서 CRUD를 적용하는 것을 의미함

  • get
  • post
  • delete
  • patch
  • put

http요청을 할 때 어떤 url에 어떤 메소드를 사용할 지에 대한 약속 

 

 

REST API

API : 응용 프로그램에서 사용할 수 있도록, 운영체제나 프로그래밍 언어에서 제공하는 기능을 제어할 수 있게 해주는 인터페이스

애플리케이션 프로그래밍 인터페이스(API)는 다른 소프트웨어 시스템과 통신하기 위해 따라야 하는 규칙을 정의합니다. 개발자는 다른 애플리케이션이 프로그래밍 방식으로 애플리케이션과 통신할 수 있도록 API를 표시하거나 생성합니다. 예를 들어, 근무 시간 기록 애플리케이션은 직원의 전체 이름과 날짜 범위를 요청하는 API를 표시합니다. 이 정보가 수신되면 내부적으로 직원의 근무 시간 기록을 처리하고 해당 날짜 범위에서 근무한 시간을 반환합니다.

 

* 인터페이스 : 인터페이스는 서로 다른 두 개의 시스템, 장치 사이에서 정보나 신호를 주고받는 경우의 접점이나 경계면이다. 즉, 사용자가 기기를 쉽게 동작시키는데 도움을 주는 시스템을 의미한다.

사람과 사람, 사람과 기기따위를 연결하는것

요청과 응답을 할 수 있도록 연결하는 것

 

RESTful API는 두 컴퓨터 시스템이 인터넷을 통해 정보를 안전하게 교환하기 위해 사용하는 인터페이스입니다. 대부분의 비즈니스 애플리케이션은 다양한 태스크를 수행하기 위해 다른 내부 애플리케이션 및 서드 파티 애플리케이션과 통신해야 합니다. 예를 들어 월간 급여 명세서를 생성하려면 인보이스 발행을 자동화하고 내부의 근무 시간 기록 애플리케이션과 통신하기 위해 내부 계정 시스템이 데이터를 고객의 뱅킹 시스템과 공유해야 합니다. RESTful API는 안전하고 신뢰할 수 있으며 효율적인 소프트웨어 통신 표준을 따르므로 이러한 정보 교환을 지원합니다.

 

 

 

 

메세지플랫폼

 

메세지 브로커

  • 많은 기업들에서 대규모 메세지 기반 미들웨어 아키텍처에서 사용되어 왔음
  • 메시지 브로커는 애플리케이션, 시스템 및 서비스가 서로 간에 통신하고 정보를 교환할 수 있도록 해주는 소프트웨어
  • 메시지 브로커는 메시징 미들웨어 또는 메시지 지향 미들웨어(MOM) 솔루션 내의 소프트웨어 모듈
  • 이러한 유형의 미들웨어는 자체 코어 논리에만 집중할 수 있도록 애플리케이션의 컴포넌트 간에 데이터의 플로우를 처리하는 표준화된 수단을 개발자에게 제공
  • 이는 다수의 플랫폼을 아우르는 애플리케이션이 내부적으로 통신할 수 있도록 허용하는 분산 통신 계층의 역할을 수행할 수 있음
  • Publisher(송신자)로부터 전달받은 메세지를 Subscriber(수신자)로 전달해주는 중간 역할이며 응용 소프트웨어 간에 메시지를 교환할 수 있게 함
  • 메세지가 적재되는 공간을 Message Queue(메세지 큐)라고 하며 메시지 그룹을 Topic(토픽)이라고 함

*미들웨어

미들웨어는 컴퓨터 제작 회사가 사용자의 특정한 요구대로 만들어 제공하는 프로그램으로, 운영 체제와 응용 소프트웨어의 중간에서 조정과 중개의 역할을 수행하는 소프트웨어이다.

 

특징

  • 메시지를 받아서 처리하고 나면 즉시 또는 짧은 시간 내에 삭제되는 구조
  • 데이터를 보내고 처리하고 삭제한다

ex) 레디스큐 레빗엠큐

 

 

이벤트브로커

  • 업무상 필요한 시간동안 이벤트를 보존할 수 있음
  • 메시지 브로커랑 결이 다르지만 이벤트 브로커 또한 기본적으로 메시지 브로커의 큐 기능들을 가지고 있어 메시지 브로커의 역할도 할 수 있음
  • 데이터를 처리하지만 삭제하지 않음 → ‘이벤트’
  • 서비스에서 나오는 이벤트를 마치 데이터베이스에 저장하듯이 큐에 저장한다.

 

 

특징

  • 장애가 일어났을 때 장애가 일어난 지점부터 재처리 할 수 있음
  • 많은 양의 실시간 스트림서비스를 처리할 수 있음
  • 이벤트 브로커로 클러스터를 구축하면 이벤트 기반 마이크로 서비스 아키텍처로 발전하는데 아주 중요한 역할을 할 뿐만아니라 메시지 브로커로서도 사용할 수 있음

ex) 카프카,aws 키네시스

 

 

 

메시지 브로커를 이용한 비동기식 통신

 

메시지 브로커를 이용한 비동기 통신은 응용 프로그램에서 서로 다른 시스템이나 구성 요소 간에 메시지를 교환하는 방법을 말하며, 여기서 발신자와 수신자는 실시간으로 서로 통신할 필요가 없다. 대신 메시지는 중간 역할을 하는 메시지 브로커로 보내지며 수신자가 메시지를 처리할 수 있을 때까지 저장된다.

메시지 브로커는 일반적으로 게시/구독, 요청/응답 및 메시지 대기열과 같은 여러 메시징 패턴을 지원한다.

게시/구독에서 발신인은 주제에 대한 메시지를 게시하며, 메시지의 복사본을 수신할 수 있는 구독자 수는 제한된다.

요청/응답에서 보낸 사람은 메시지를 보내고 받는 사람의 응답을 기다리며 메시지 대기열에서 메시지는 대기열에 저장되고 수신된 순서대로 처리된다

메시지 브로커를 사용하는 비동기 통신은 향상된 확장성, 신뢰성 및 성능과 같은 동기 통신에 비해 몇 가지 이점이 있다.

예를 들어, 발신자와 수신자를 분리함으로써, 수신자는 발신자를 사용할 수 없는 경우에도 자신의 속도로 메시지를 처리할 수 있습니다.

이는 한 구성 요소가 중단되거나 사용할 수 없는 경우에도 구성 요소가 계속 작동할 수 있기 때문에 보다 강력하고 확장 가능한 시스템으로 이어질 수 있습니다.

전반적으로 메시지 브로커를 사용한 비동기 통신은 특히 구성 요소 간의 통신이 어려울 수 있는 분산 환경에서 확장 가능하고 신뢰할 수 있는 시스템을 구축하기 위해 널리 사용되는 기술이다.

 

 

  • 요청을 보내는 즉시 수신자로부터 응답이 오길 기대하는 "동기적 방법"
    • 클라이언트-서버 아키텍처의 REST(HTTP)가 대표적
  • 요청을 일단 보내놓고 수신자가 받을때까지 보관했다가 처리하는 "비동기적 방법"
    • 수신자가 받기 전에 누군가는 메시지를 보관해놓아야 한다 → 메시지 브로커 (메시지 큐)

분산 애플리케이션에서 프로세스 간의 느슨한 결합(loosely coupled)을 제공하는 것이 가장 큰 장점입니다. 그렇다면 강하게 결합된 시스템에서의 단점은 무엇일까요? 서로 연결되어 있는 시스템 중 한 곳에서 장애가 발생했을 때 그 장애가 연결된 다른 시스템들에 영향이 갑니다.

 

 

 

Action Items

  • 메시지 서비스로는 대표적으로 Apache Kafka와 Amazon SQS, Amazon Kinesis가 있습니다. 각각은 어떤 차이가 있나요?

 

아파치 카프카(Apache Kafka)는 아파치 소프트웨어 재단이 스칼라로 개발한 오픈 소스 메시지 브로커 프로젝트이다.

이 프로젝트는 실시간 데이터 피드를 관리하기 위해 통일된, 높은 처리량, 낮은 지연시간을 지닌 플랫폼을 제공하는 것이 목표이다.

요컨대 분산 트랜잭션 로그로 구성된, 상당히 확장 가능한 pub/sub 메시지 큐로 정의할 수 있으며, 스트리밍 데이터를 처리하기 위한 기업 인프라를 위한 고부가 가치 기능이다.

특징은 대용량 실시간 로그처리에 특화되어 설계된 메시징 시스템으로 TPS가 매우 우수하고 메시지를 파일에 저장하기에 재시작을 해도 메시지 유실 우려가 덜하다. 

 

장: 빠르고 강력하고 확장성이 좋음

단: 관리가 어려움

 

 

아마존 심플 큐 서비스(Amazon Simple Queue Service) 또는 아마존 SQS(Amazon SQS)는 아마존닷컴이 2004년 말 베타 서비스로 선보인 분산 메시지 큐 서비스이다. 2006년 중순 정식 공개했다. 인터넷을 경유하여 통신하기 위한 한 수단으로서 웹 서비스 애플리케이션을 통해 메시지를 프로그래밍적으로 보내는 것을 지원한다. SQS는 공통 생산자-소비자 문제나 생산자-소비자 간 연결에서 발생하는 문제들을 해결하는 큰 규모의 호스팅 메시지 큐를 제공하기 위해 고안되었다.

Queue 서비스, 메시지를 Pull형으로 처리하며 standard 방식과 fifo 방식이 있다.

standard 방식은 scale out이 무한대로 가능한 대신, 메시지의 전달이 exactly once가 아닌 at least once 까지만 보장 된다.

또한 메시지의 순서도 best effort로, 보장되지는 않는다.

fifo 방식은 TPS 제한이 있는 대신, 메시지 전달이 exactly once로 보장되며 메시지의 순서가 보장된다.
SQS는 애플리케이션 통합, 분산 시스템 연계에 적합하다.

 

 

아마존 키네시스(Amazon Kinesis)는 실시간 스트리밍 데이터를 손쉽게 수집, 처리 및 분석할 수 있으므로 적시에 통찰력을 확보하고 새로운 정보에 신속하게 대응할 수 있습니다. Amazon Kinesis는 모든 규모의 스트리밍 데이터를 비용 효율적으로 처리할 수 있는 핵심 기능과 더불어 애플리케이션 요구 사항에 가장 적합한 도구를 선택할 수 있는 유연성을 제공합니다. Amazon Kinesis에서는 기계 학습, 분석 및 기타 애플리케이션을 위해 비디오, 오디오, 애플리케이션 로그, 웹 사이트 클릭스트림 및 IoT 텔레메트리 데이터와 같은 실시간 데이터를 수집할 수 있습니다. Amazon Kinesis를 사용하면 모든 데이터가 수집된 후에야 처리를 시작할 수 있는 것이 아니라 데이터가 수신되는 대로 처리 및 분석하여 즉시 대응할 수 있습니다.

특징: 실시간, 완전관리형, 확장성

 

 

 

 

 

참고 레퍼런스

https://aws.amazon.com/ko/what-is/restful-api/

https://www.ibm.com/kr-ko/cloud/learn/message-brokers

https://aws.amazon.com/ko/sqs/

https://aws.amazon.com/ko/kinesis/

 

 

 

 

저작자표시 비영리 동일조건 (새창열림)