이벤트 기반 마이크로서비스 아키텍처

먼저 이벤트 기반 마이크로서비스 아키텍처 에서 서비스는 이벤트 메시지 를 통해 서로 통신합니다. 비즈니스 이벤트가 발생하면 생산자는 메시지와 함께 이를 게시합니다. 동시에 다른 서비스는 이벤트 리스너를 통해 이를 사용합니다.

따라서 이벤트 구동 시스템의 주요 이점은 비동기 동작과 느슨하게 결합된 구조입니다. 예를 들어 앱은 필요할 때 데이터를 요청하는 대신 필요하기 전에 이벤트를 통해 데이터를 소비합니다. 따라서 전반적인 앱 성능이 향상됩니다. 반면에 커플링을 느슨하게 유지하는 것은 마이크로 서비스 환경의 주요 핵심 사항 중 하나입니다.

솔루션으로서의 이벤트 기반 아키텍처

이벤트 기반 구조로 시스템을 구축할 수 있을 뿐만 아니라 이미 구축된 고도로 결합된 환경에 대한 솔루션으로 사용할 수도 있습니다. 이벤트 기반 접근 방식을 솔루션으로 적용하는 방법에 대해 논의해 보겠습니다.

기본 REST 기반 접근 방식

REST(동기) API 호출

응용 프로그램이 제대로 작동하더라도 다음과 같은 단점이 있습니다.

모듈 1은 응답을 기다립니다.
모듈 2는 다운될 수 있습니다.
네트워크 지연으로 성능 저하
데이터가 크면 페이지가 매겨집니다. 이는 더 많은 REST 호출을 의미합니다.
모듈 2는 부하가 높을 수 있으며 매우 늦게 응답할 수 있습니다.

동기화된 연결로 인해 시스템 효율성이 저하되면 이벤트 기반 솔루션을 적용할 수 있습니다.

실제 시나리오: 우리 팀이 적용한 방법

Trendyol/Marketplace 팀에는 보고 애플리케이션(GIB API)이 있습니다. 모든 판매 보고서를 정부에 전송합니다. 따라서 이 앱은 다른 API에서 모든 판매 데이터를 가져와야 합니다. 초기에는 거래량이 매우 적었습니다. 따라서 REST 방식으로 API를 빠르게 구축했습니다.

보고서 생성 타이밍 다이어그램

처음에는 적은 양의 데이터에도 불구하고 갑자기 증가했습니다. Trendyol은 빠르게 성장하는 회사이기 때문에 종종 이러한 문제에 직면합니다. 반면에 솔루션은 간단합니다. 이벤트 메시징으로 변환하는 것입니다.

솔루션 1: 이벤트 메시징으로 변환

보고서가 효율적으로 생성되지 않는다는 사실을 깨닫는 즉시 이벤트 기반 솔루션을 적용했습니다.

무엇보다 우리의 계획은 간단했습니다.

트랜잭션 항목 생성 시 이벤트 게시
이벤트 수신 시 관련 데이터 가져오기
보고서 문자열로 변환
RDBMS(PostgreSQL)에서 지속
보고서 생성 시 데이터 쿼리
문자열 데이터를 연결하고 디스크에 파일로 유지

비동기 이벤트 메시징을 통한 데이터 수집

그 결과 필요한 트랜잭션 항목이 보고 API에 유지됩니다. 보고서 생성이 시작되자마자 RDBMS에서 보고서 데이터를 쿼리하고 연결합니다.

거래 보고서 생성

성공은 쉽게 오지 않는다

동기화 프로세스를 비동기 아키텍처로 변환하는 동안 트랜잭션 API는 또 다른 성능 문제에 직면했습니다. 보고(GIB) API는 트랜잭션 항목이 생성될 때마다 세부 정보를 요청하기 때문에 트랜잭션 API에 과부하가 걸렸습니다. 그 이유는 Trendyol에서 판매되는 모든 품목에 대해 거래 기록이 생성되기 때문입니다. 따라서 엄청난 수의 거래 항목 세부 정보 요청이 API를 질식시켰습니다.

솔루션 2: 팻 이벤트

설명하기,ㅏ뚱뚱한 사건메시지에 엔터티 식별자가 포함된 세부 정보가 포함되어 있음을 의미합니다.

Fat 이벤트 메시지 샘플

메시지를 팻 이벤트로 변환한 후에는 추가 REST 호출이 필요하지 않았습니다. 그 결과 우리 아키텍처는 완전한 비동기식 이벤트 중심 시스템이 되었습니다.

완전한 짝수 기반 아키텍처

해결 방법 3: 보낼 편지함 패턴

판매 거래에 대해 이야기하는 동안 이러한 데이터가 얼마나 중요한지 이미 분명합니다. 그들은 금융 사업에 관한 것이기 때문입니다. 따라서 계산은 100% 정확해야 합니다.

이 정확도에 액세스하려면 시스템에서 이벤트 메시지가 손실되지 않는지 확인해야 합니다. 이에 발신함 패턴을 적용하였습니다.

보낼 편지함 패턴은 무엇입니까? 간단히 말해서 API가 이벤트 메시지를 게시할 때 직접 보내지는 않습니다. 대신 메시지가 DB 테이블에 유지됩니다. 작업은 미리 정의된 시간 간격으로 누적 메시지를 보냅니다.

보낼 편지함 패턴

그림을 설명하려면:

비즈니스 모듈은 이벤트를 게시합니다.
이벤트 서비스는 RDBMS에서 메시지를 유지합니다.
스케줄러 서비스는 "이벤트 메시지 보내기" 작업을 트리거합니다.
이벤트 서비스는 누적 이벤트 메시지를 쿼리합니다.
이벤트 서비스는 RabbitMQ를 통해 메시지를 게시합니다.

보낼 편지함 패턴의 장단점을 나열해 보겠습니다.

장점:

이벤트 메시지는 먼저 RDBMS에서 지속됩니다. 트랜잭션의 ACID 속성은 지속성을 보장합니다.
이벤트가 유실된 경우 DB에서 메시지를 확인할 수 있습니다.
손실된 이벤트는 RDBMS에서 효율적으로 복구할 수 있습니다.

단점:

복잡성 증가.
게시 이벤트 지연.
기본 이벤트를 게시하려면 스토리지 시스템과 메시지 큐 프로토콜의 두 가지 기술이 필요합니다.

이벤트 기반 마이크로서비스 아키텍처의 이점

느슨하게 결합된 구조
마이크로서비스의 완전한 격리
동기 REST 호출 없음
비동기식 이벤트 기반 기능
성능 향상

그 중 가장 중요한 혜택은 첫 번째 혜택입니다. 마이크로 서비스 아키텍처로 구성 요소를 분리하기를 원하기 때문에 모든 단위가 충분히 분리(느슨하게 결합)되어야 합니다. 그렇지 않으면 마이크로서비스 아키텍처가 작동하지 않고 시스템이 분산 모놀리스로 바뀝니다.

단점

단일 실패 지점 : RabbitMQ 가 생산 프로세스 중에 문제에 직면하면 전체 시스템도 실패합니다.

실패를 극복하려면:

RabbitMQ를 클러스터로 구성
내구성 있는 대기열 만들기
지속되는 메시지 게시

결과적으로 모든 장애를 신속하게 복구할 수 있습니다. 오류가 발생하면 클러스터의 다른 인스턴스가 작업을 인계받아 지속형 대기열을 다시 생성합니다. 또한 지속된 메시지는 디스크에서 복구됩니다.

중복된 이벤트 메시지: 이벤트 게시자 API는 문제에 직면하여 동일한 메시지를 다시 보낼 수 있습니다. 시스템의 중복을 해결하려면 모든 소비자 엔드포인트가 멱등적 이어야 합니다. API가 이전에 이벤트를 획득했는지 항상 먼저 확인하는 것을 고려하십시오.

TL;DR

마이크로서비스 아키텍처 환경 에서는 결합을 낮게 유지 해야 합니다 . 커플링을 낮게 유지하려면 모듈 간의 연결에 집중 해야 합니다 . 이를 수행하는 한 가지 방법은 이벤트 기반 접근 방식 을 사용하는 것 입니다.

한편 직접 REST 호출은 비용이 많이 듭니다 . 대상 API가 서비스되지 않을 수 있습니다. 또한 소스 API는 응답이 수신될 때까지 기다려야 합니다.

이벤트 기반 마이크로서비스 구조를 생성하기 위해 지속형 메시지가 있는 RabbitMQ 클러스터 를 생성할 수 있습니다. 필요한 모든 이벤트는 책임자를 통해 게시할 수 있습니다. 또한 다른 모든 서비스는 이벤트 메시지를 보낼 때 소비자를 바인딩하고 작업을 처리할 수 있습니다.

이벤트 기반 시스템을 구축하는 동안 팻 이벤트 를 고려할 수 있습니다 . Fat 이벤트는 이벤트가 발생할 때 필요한 모든 데이터를 제공합니다. 그 결과 API는 추가 외부 호출이 필요하지 않습니다 .

반면에 시스템 장애 또는 네트워크 중단으로 인해 손실 이벤트가 발생할 수 있습니다 . 모든 이벤트가 성공적으로 게시되고 사용되도록 하려면 보낼 편지함 패턴 을 적용할 수 있습니다. 간단히 말해서 이벤트는 직접 게시하는 대신 스토리지 시스템에 저장됩니다. 그 후 구성된 작업은 일정한 시간 간격으로 이벤트를 보냅니다. 손실된 메시지는 스토리지 시스템을 통해 쉽게 복구할 수 있습니다.

결론

요약하자면, 마이크로서비스 아키텍처는 매우 새롭고 우리, 모든 개발자는 매일 더 잘 배우고 있습니다. 우리가 조심하지 않을 때마다 우리 시스템은 분산형 단일체로 변할 수 있으며 이것은 최악의 경우입니다. 어떤 이점도 얻을 수 없고 복잡성을 처리해야 하기 때문입니다. 무엇보다 이벤트 기반 아키텍처와의 결합을 느슨하게 유지하는 것이 가장 중요한 것 중 하나입니다.

https://medium.com/trendyol-tech/event-driven-microservice-architecture-91f80ceaa21e