이벤트 기반 아키텍처 (Event Driven Architecture)

이벤트 기반 아키텍처 (Event Driven Architecture)

AWS, MicroSoft, 전문가를 위한 파이썬 교재에서는 각각 이벤트 기반 아키텍처에 대해 아래와 같이 설명하고 있습니다.

• 마이크로 서비스가 이벤트라고 하는 상태 변화에 대응하는 소프트웨어 설계 패턴.
• 이벤트 생성 및 감지와 관련된 소프트웨어 아키텍처 패러다임
• 이벤트(메세지)와 서로 다른 소프트웨어 컴포넌트 사이에서 일어나는 이벤트 흐름

그렇다면 이벤트란 무엇일까요?

이벤트

이벤트란 상태의 변화로 정의할 수 있다고 합니다. 이러한 상태를 전달할 수 있으며, 이벤트는 식별자일 수 있습니다.

특성

• 일어날 일의 기록
• 변경하거나 삭제할 수 없는 변경 불가능한 사실을 캡처
• 이벤트 소비 시 서비스가 적용하는 로직에 관계없이 발생
• 무기한 대규모로 유지되면 필요한 만큼 사용
• 메세지 방출을 트리거한 상태 변경인 이벤트 자체는 아니며, 이벤트는 이동하지 않고 발생한다.

Producer, Broker, Consumer, Router

Producer (Publisher)

• 이벤트를 발생하는 주체입니다.

Broker

• Producer, Consumer 서비스에 이벤트를 라우팅합니다.

Consumer (Subscriber, Worker(?))

• 이벤트를 소모하는 주체입니다.

이벤트 기반 아키텍처를 사용한다면?

크고 복잡한 시스템도 쉽게 분리할 수 있고, 독립된 컴포넌트 사이의 명확한 경계를 정의할 수 있습니다. 각 컴포넌트들의 격리 상태 역시 개선할 수 있어요.

좋은 점

서비스를 분리할 수 있기 때문에 독립적으로 확장할 수 있습니다. 장애가 발생하더라도 다른 서비스는 유지될 수 있어요. 이벤트 처리 기반으로 배치 기반에서 벗어날 수 있습니다.

이벤트 라우터등의 도구를 통하여 폴링, 필터링을 사용할 수 있기 때문에 개발자가 코드를 작성할 필요가 없습니다.

기존 마이크로 서비스에 영향을 주지 않고 기능을 확장하고 추가할 수 있습니다.

이벤트가 비동기식으로 생성될 수 있으므로 응답을 기다리지 않고 즉시 발생시킬 수 있습니다

안좋은 점

시스템간의 의존도는 낮아지지만, 메시지 중개인(Broker)에 대한 의존도는 높아져요

이벤트 흐름을 추적하고 관리해야하고, 이벤트 처리와 처리 로직을 분리해야하기 때문에 복잡성이 높아집니다.

다수의 이벤트가 비동기적으로 처리되기 때문에 순서 처리 보장을 하기가 어렵습니다. (불가능하진 않아요!)

데이터가 여러 서비스에 걸쳐 분산되어 있을 수 있기 때문에, 데이터 상태를 유지하기가 어렵습니다.

주의할 점

모든 이벤트 주도 애플리케이션들이 꼭 비동기는 아니에요!

매우 동기적이고 완전히 병행이 아닌 문제들을 분리하는 데에도 이벤트 주도 접근 방식은 유용합니다!

언제 사용해볼까요?

• 시스템이 서로 다른 스택에서 실행중인 경우, 각 스택의 독립성을 유지하면서 여러 기술 스택간의 상호 운용성을 유지하여 시스템 간 정보를 공유할 수 있습니다.
• 여러 리전과 계정에서 운영하고 배포하는 시스템과 팀을 조정하는 경우 시스템을 조율할 수 있어요.
• 스토리지 버킷, 데이터베이스 테이블, 가상 머신 또는 기타 리소스의 이상 수치나 변경사항을 지속적으로 확인하는 것이아니라, 이슈가 발생했을 때 수신할 수 있습니다.

고려할 점

• 모든 단일 이벤트를 처리해야 하는 경우 이벤트 소스가 전송을 보장할 수 있나요?
• 애플리케이션에서 여러 비동기식 요청을 처리할 수 있어요?
• 이벤트 흐름을 어떻게 추적하고 싶으신가요?
• 이벤트 소스의 데이터를 사용하여 상태를 다시 빌드할 건가요?

데이터를 가져가는 방식

pulling

• 정해진 시간마다 새 메지가 있는지 확인합니다.

push

• 새로운 이벤트가 발생하면 브로커가 알려줍니다.
  • 예를 들어 50ms 최대 값이므로, 이에 해당하는 49ms 레이턴시를 아낄 수 있습니다.
  • RabbitMQ, SNS

실습

Celery

파이썬에서 제공하는 오픈소스입니다. 분산 메세지 전달에 기반을 둔 비동기 태스크 큐(스케쥴링), 잡 큐입니다.

방대한 양의 메세지를 처리할 수 있는 간단하고, 유연하며, 안정적인 분산 시스템이며, 이러한 시스템을 유지하는 데 필요한 도구를 운영에 제공합니다.

SQS

SQS는 AWS에서 제공하는 분산된 애플리케이션의 구성 요소 간의 비동기 메세지 기반 통신을 가능하게 하는 매우 안정적이고 확장 가능한 메제시 큐 서비스 입니다.

사용한 수만큼의 메세지를 언제든지 Amazon SQS 대기열로 보낼 수 있고, 메세지는 동일한 구성 요소 또는 다른 구성요소에서 검색할 수 있습니다.

각 메세지는 고가용성, 고신뢰성 대기열에 영구적으로 저장됩니다.

여러 프로세스가 SQS를 읽고 쓸 수 있으며, 서로 간섭하지 않고 동시에 대기열에서 읽고 쓸 수 있습니다.

대기열 유형

표준

• 메시지는 최소 한 번 전송되지만 간혹 두 개 이상의 메시지 사본이 전송된다.
• 표준 대기열은 최적의 순서를 제공하며, 경우에 따라 메시지가 전송된 순서와 다르게 전송될 수 있다.
• 표준 대기열은 매우 높은 처리량이 중요한 경우에 유용하다.

FIFO

• 메시지는 정확히 한 번 전송되며, 메시지 순서가 보존됩니다.
• FIFO 대기열은 작업과 이벤트 순서가 중요하거나 중복을 허용할 수 없을 때 애플리케이션 간 메시지 전송을 강화하도록 설계되다.
  • 사용자가 입력한 명령이 올바른 순서로 실행되도록 보장합니다.
  • 가격 수정을 올바른 순서로 전송하여 올바른 제품 가격을 표시합니다.
  • FIFO 대기열의 이름은 .fifo 접미사로 끝나야 합니다.

 

---

출처

• EDA
  • https://cloud.google.com/eventarc/docs/event-driven-architectures?hl=ko
  • https://en.wikipedia.org/wiki/Event-driven_architecture
  • https://aws.amazon.com/ko/what-is/eda/
  • https://f-lab.kr/insight/understanding-event-driven-architecture?gad_source=1&gclid=CjwKCAjw4f6zBhBVEiwATEHFVgR62eYVMfCzZtuB_mqSe1T3SOkG_CENMbDYE51EKBPrarVtfZR0NBoCpCAQAvD_BwE
  • https://com789.tistory.com/38
  • 전문가를 위한 파이썬
  • https://jimmydqv.com/serverless-event-routers/
• Celery, SQS
  • https://docs.celeryq.dev/en/stable/index.html
  • https://aws.amazon.com/ko/sqs/
  • https://celery.school/amazon-sqs-celery-broker
  • https://medium.com/@kasperjuunge/how-to-use-celery-c34310e6bcba
  • https://stackoverflow.com/questions/8048556/celery-with-amazon-sqs
  • https://derlin.github.io/introduction-to-fastapi-and-celery/03-celery/

---