[레포트] 이벤트 드리븐 아키텍처 구축을 위한 적절한 어플리케이션 통합 서비스 선택 및 사용 방법 #AWSSummitOnlineKorea

안녕하세요! Classmethod 주식회사 신입 엔지니어 이병현이라고 합니다!

이번 AWS Summit Online Korea 2020의 세션을 들으면서 내용을 정리해보았습니다.

제가 정리한 세션은 김성진님 (솔루션즈 아키텍트, AWS) 의 이벤트 드리븐 아키텍처 구축을 위한 적절한 어플리케이션 통합 서비스 선택 및 사용 방법 입니다.

어떤 세션인지

• 이벤트 드리븐 아키텍처를 위한 어플리케이션 통합서비스 소개입니다.
• 어플리케이션 통합방법에 대해 알아봅니다.

이벤트 드리븐 아키텍처

동기적 처리

• 하나의 서비스 장애가 더 많은 서비스로 전파됩니다.
• 동기적으로 처리할 경우 커플링이 높아집니다.
• 관련 서비스가 추가되고 변경될 때마다 어플리케이션을 변경해야 합니다.

이벤트 기반 처리

• 고가용성 서비스 스트림에 이벤트를 전달 후 고객에게는 주문완료를 응답합니다.
• 이벤트 처리를 희망하는 서비스는 구독하고 전달받은 이벤트를 소비하게 됩니다.
• 이벤트를 생성한 서비스는 어떤 서비스가 이벤트를 소비할지에 대한 신경 쓰지 않아도 됩니다.
• 시스템의 수정 없이 서비스의 추가, 삭제가 가능합니다.

'이벤트'란?

이벤트는 '명령'이 아닌 '관찰'을 의미합니다.

명령은 이벤트 생성 주체가 상대의 특정 동작을 기대합니다.

관찰은 이벤트 생성 주체가 어떤 동작을 기대하거나 관심을 가지지 않습니다.

• 발생한 사건을 표현하는 메시지 형식
• 중요한 정보, 이벤트 자체에 충분한 정보를 포함
• 불변-과거의 메시지를 변경할 수 없음을 보장
• 과거 시제의 동사로 표현됨, 예, "새로운 주문이 생성되었다."
• 이벤트 생성 시스템은 이벤트가 어떻게 처리되는지 관여하지 않음

AWS의 이벤트

이벤트 자체만으로 의미를 표현할 수 있도록 정의되어야 합니다.

Event 형식의 표준화 시도

CNCF (Cloud Native Computing Foundation)에 CloudEvents가 인큐베이터 프로젝트로 등록되어 있고, 1.0v이 릴리즈 됐습니다.

Event 형식 - Blob vs. Structured objects

• 이벤트 처리의 병목현상 대부분의 원인은 메시지 형식이 아닌 시스템이나 저장소 레벨에 문제가 있었습니다.
• 사람 눈으로도 이벤트의 내용을 확인할 수 있고 동적으로 타입이 결정되는 파이썬, 자바스크립트에서도 용이한 JSON이 좋은 선택일 수 있습니다.

이벤트 드리븐 구조가 적합?

• 트랜잭션 정보가 포함된 이벤트를 전달하고 있습니까?
  • 메시지 자체만으로도 이벤트에 대한 설명이 가능해야 합니다.
  • 확장성, 가용성에 있어 Stateless 구조가 장점이 있습니다.
    
• 추가 비용 없이 적용 가능한 유용한 정보입니까?
  • AWS의 많은 서비스가 이벤트를 기반으로 다른 서비스를 호출하도록 구성되어 있습니다.
  • 대표적인 예가 S3에 저장된 파일을 변경 시 람다 함수를 호출하는 것입니다.
    
• 강력하게 분리된 마이크로 서비스를 위해 필요한가요?
  • 비동기방식의 호출과 버퍼구조를 사용합니다.
  • AWS SQS가 이런 구조로 되어있습니다.
    
• Pub Sub 구조가 필요한가요?
  • 서비스 간 메시지 송수신에 Pub/Sub 모델이 적합한지 확인이 필요합니다.

어플리케이션 통합 서비스

Pub/Sub을 지원하는 AWS 서비스

• 서버리스 Pub/Sub
  • Amazon Simple Notification Service (Amazon SNS)
  • Amazon EventBridge
• 관리형 메시지 브로커
  • Amazon MQ
• 데이터 스트리밍
  • Amazon Kinesis Data Streams
  • Amazon Managed Streaming for Kafka

데이터 스트리밍은 이벤트 처리보다 많은 양의 데이터 스트리밍에 적합합니다.

Amazon EventBridge

• 완전 관리형, 사용한 만큼 지불
• 17 타겟 서비스
• SaaS 업체와의 기본 통합
  • 별도의 API polling이나 webhook 설정 없이도 사스앱에 데이터를 편하게 가져올 수 있습니다.
• 이벤트 드리븐 아키텍처를 손쉽게 빌드
  • 이벤트를 연결하거나 필터링하는데 사용자의 추가 부담이 적습니다.

---

• 이벤트 소스
  • AWS 서비스
  • SaaS 앱 (Zendesk, New Relic 등)
  • 커스텀 앱
• 이벤트 버스
  • 필요한 룰을 선택적으로 이벤트를 구동 가능
  • 새로운 이벤트는 정해진 버스를 통해 개별룰로 전달 됨
  • 이벤트 버스 룰에 기반되 필터링 되거나 가공된 후 타겟에 전달됨
• 타겟
  • AWS Lambda
  • Amazon Kinesis Data Firehose
  • AWS Step Functions
  • Amazon Simple Queue Service (Amazon SQS)

Amazon EventBridge - 이벤트 룰

• 필터링
  • 접두어 일치
  • 산술 비교
  • 속성의 존재 유무 확인
  • 제외
  • 복수 일치

필터링을 이벤트에서 수신하는 단에서 구현하는 경우 불필요한 리소스를 사용하게 됩니다. 코드가 시작되는 부분에서 필터링과 관련된 코드가 들어가기 때문에 코드의 가독성, 응집성, 유지 보수성이 떨어집니다.

Amazon EventBridge는 메타데이터뿐만 아니라 페이로드기반으로도 필터링이 가능합니다.

Amazon EventBridge vs. SNS

Amazon EventBridge

• SaaS (Software as a Service, SaaS) 어플리케이션에 적합합니다.
• AWS 서비스 이벤트에 반응하는 어플리케이션 구축할 때 사용하기에 좋습니다.

Amazon SNS

• 높은 처리량, 짧은 지연시간을 가지는 메시지를 처리하고, 높은 팬아웃 구성 (Fanout Pattern)이 필요한 경우 권장됩니다.

통합 서비스 사용 방법

어떤 패턴으로 서비스를 통합할 수 있는지에 대해 알아봅니다.

메시지 채널

지점간(큐)

• 동일한 메세지는 단일 수신자만 수신하게 됩니다.
• 수신자의 수가 늘어날 경우 확장해나가는 구조를 가질 수도 있습니다.
• 수신자의 수를 제한해 최대 트래픽을 조절할 수도 있습니다.

AWS SQS에 AWS Lambda를 연결하는 경우 큐에 들어오는 메시지 증가에 따라 동시 실행되는 람다개수가 늘어나는 경우가 있습니다. 이경우에도 람다의 동시성 한도를 설정해 최대 트래픽을 제한할 수 있습니다.

• 서버리스 기반 서비스
  • Amazon Simple Queue Services (SQS)

게시자-구독자 (토픽)

• 다중 구독자가 동일한 메시지를 받을 수 있습니다.
• 메시지가 콜 방식이 아니라 푸시 방식으로 전달되기 때문에 내구성있는 구독자 구성이 필요합니다.
  • 예) 구독자가 AWS Lambda로 구성되어있고 메세지 수신 시 DynamDB에 저장한다고 가정한다면, 평소에는 정상으로 동작하는 코드라 하더라도 들어오는 트래픽이 많아짐에 따라 DynamDB에 쓰로틀링(throttling)이 발생할 수 있고, 정상적인 메시지 처리를 할 수 없게 됩니다.
• 서버리스 기반 서비스
  • Amazon Simple Notification Service (Amaznon SNS)
  • Amazon EventBridge

Amazon MQ (managed Apache Active MQ)

• 큐, 토픽 두가지를 지원하는 AWS의 비 서버리스 서비스입니다.
• 기존 오프레미스에서 사용하고 있던 JMS (Java Messaging Service), AMQP (Advanced Message Queue Protocol) 를 사용할 수 있는 장점이 있습니다.

토픽-큐-연결

• 가장 많이 사용되는 방식입니다.
• 수신자가 필요한 만큼 가져오는 것이 아니라 게시자가 일방적으로 메시지를 push 하는 방식입니다.
• 게시자의 요청이 증가하는 경우 서로 다른 처리속도를 가진 시스템 사이의 확장성 문제를 유발할 수 있습니다.
• 이러한 시스템 간 처리속도 차이로 인한 병목현상을 방지하기 위해 큐를 사용하여 버퍼를 구성하는 연결 구조가 필요합니다.
• 큐를 추가하면 메세지를 처리하는 어플리케이션이 자신의 처리속도에 맞추어 처리할 수 있고, 시스템 확장에 용이합니다.

메시지 전달 QoS

• Amazon SQS의 FIFO Queue
  • 정확히 1회의 처리를 제공합니다.
  • 성능이 더 떨어집니다.
  • 비용이 더 비쌉니다.
  • FIFO Queue를 제대로 사용하기 위해서는 다중 소비자를 사용하는 방식이 불가능합니다. (소비자가 구동되는 환경이나 조건 등에 의해 결과가 뒤집힐 수 있기 때문입니다.)
• Amazon SQS의 Standard Queue
  • 적어도 한 번의 전송이 지원됩니다.

꼭 필요한 경우가 아니라면 Standard Queue가 권장됩니다.

리플레이 큐 - 동일한 메세지를 리플레이 파이프라인 큐에 저장하고, 메인 작업에서 큐를처리하는 과정에 장애 발생 시, 관련 이벤트를 리플레이 큐에서 메인 큐로 추가할 수 있습니다.

데드-레터 (dead-letter) 큐 - Amaznon SNS에서도 지원하고 있습니다. - 구독 엔드포인트에 접속할 수 없는 경우 메시지를 저장하여 어플리케이션의 복원력 및 내구성 개선을 위해 사용할 수 있습니다.

메시지 라우팅

메시지 필터

• 구독자는 필터의 룰에 기반한 집합의 메시지만 수신할 수 있는 장점이 있습니다.
• 구독자가 메시지를 선택할 수 있고, 필터링을 위해 구독자의 자원을 활용하지 않는 장점이 있습니다.

대기자 목록

• 장점 - 연관된 구독자에게 선택적으로 보낼 수 있습니다.
• 단점 - 발신자 또는 추가 컴포넌트가 관여하여 라우팅하는 구조이기 때문에 잠재된 커플링이 추가될 수 있습니다.

토픽? 메시지 필터?

토픽

• 게시자가 구독자를 고려해 이벤트 전송 시 선택적으로 토픽을 사용해야 합니다.
• 게시자와 구독자 사이의 일부 종속성이 발생합니다.

메시지 필터

• 게시자는 동일한 속성을 가진 이벤트를 하나의 토픽으로 보내게 되어 이벤트 라우팅 로직에 관여하지 않아도 됩니다.
• 구독자는 원하는 데이터만 받을 수 있으므로 별도의 필터링 로직을 애플리케이션 단에 추가할 필요없이 비즈니스 로직만을 응집성 있게 가질 수 있다는 장점이 있습니다.

분산 - 수집

분산-수집구조의 이해를 돕기 위한 견적요청 예시 시나리오입니다.

1. 요청자는 견적에 필요한 항목에 대해 새로운 이벤트를 생성합니다.
2. 견적 시스템들은 새로운 견적에 견적정보를 수신한 후 각자의 기준에 맞춰 견적을 산출합니다.
3. 개별 시스템들은 완료된 견적정보들을 큐로 일괄 전송하게 됩니다.
4. 집계 시스템에서는 큐의 저장된 견적 결과를 기반으로 최종 선택을 하게 됩니다.

이와 같이 분산-수집구조는 분할 정복과 같은 병렬 처리 시나리오에 유용하게 적용 가능합니다.

정리

• 이벤트 드리븐 아키텍처는 마이크로서비스간의 느슨한 결합을 가능하게 합니다.
  • 따라서 유연성, 탄력성, 확장성있는 시스템을 구성할 수 있습니다.
• 이벤트는 발생한 사건을 표현하는 형식이고, Pub/Sub 방식으로 다대다 전달이 가능해야 합니다.
• 적절한 통합 서비스 및 패턴을 사용하여 어플리케이션을 통합합니다.
  • 서버리스 솔루션을 활용하면 비지니스 차별화 기능을 구현하는데 집중할 수 있습니다.
• 큐는 메시지 전달에 버퍼 역할을 수행하여 게시자와 구독자의 메시지 생성 및 처리 속도의 차이를 극복하게 합니다.
  • 대규모 분산환경에서 큐의 역할은 중요하기 때문에 운영환경에서 안정적으로 적용 가능하도록 큐의 제약이나 사용에 대한 파악을 권장합니다.

후기

이벤트 드리븐 구조는 여러가지 장점과 사용자가 어떤 방식으로 구성할지에 대한 선택지가 많아 보였습니다. 하지만 상황에 맞는 옳은 구성을 취하려면 자신의 상황에 대한 이해와 AWS의 서비스, 서드 파티 어플리케이션 등 폭 넓은 지식과 경험이 필요해 보였습니다. 잘사용하기 쉽지 않아 보이지만 잘 사용할 수만 있다면 다양한 가능성을 만들어줄 수 있는 아키텍처 같습니다.

긴글 읽어주셔서 감사합니다. ?‍♂️

참조

Amazon SNS란 무엇입니까? | AWS 문서

Amazon Simple Queue Service이란? | AWS 문서

Amazon SQS FIFO(선입선출) 대기열 | AWS 문서

Amazon Simple Queue Service(SQS) 및 Amazon Simple Notification Service(SNS) 사용 | AWS 문서