Event-Driven Architecture

개요

마이크로서비스 아키텍처는 독립적으로 배포 및 확장 될 수 있는 서비스(Loosely Coupled)들을 조합하여 하나의 애플리케이션을 완성하는 아키텍처이다. 마이크로서비스를 적용하면 빠른 배포 주기와 장애 확산 차단, 대용량 분산환경 시스템 구축, 폴리그랏 프로그래밍 적용 등의 장점을 얻을 수 있으며, 최근 아니 2~3년 전부터 빠르게 Enterprise IT시장을 잠식해 나가고 있는 핫한 아키텍처라 할 수 있다.

마이크로서비스 아키텍처를 통해 분해된 서비스는 경량화 기반 민첩성/유연성을 보장하고, 확장성을 제공하며, 장애 탄력성을 통한 복구전략을 수립하는 등 Container Management Platform과 상통하는 아키텍처 방식으로 많은 주목을 받고있다.

다만 마이크로서비스 아키텍처는 Inner, Outer, Testing, CI/CD 등 모든 요소에서 문제점이 나타나고 있으며, Legacy 단일 애플리케이션의 단순함에 익숙한 우리 IT 인들은 다소 거부감이 나타나기도 한 실정이다.
몇가지 예를 들어보자면,
세분화 된 서비스는 가볍고 빠르고 민첩하지만, 장애 추적 포인트가 분산되고, 모니터링, 로깅 등 주요 Telemetry 요소들을 적시 적소에 반영하더라도 사실 기존 Legacy보다 장애 분석에 소요되는 시간이 확실히 늘어났다. 이는 기술요소의 어려움은 둘째치고, 장애가 발생한 위치를 찾아내는 것 부터 어려움이 있으며, 찾아 내더라도 세분화된 서비스 간 트랜잭션의 관계를 분석하고, 원인을 찾아 내야 하는 요소들이 너무나 많다보니 항상 강조하는 Telemetry 요소들의 높은 운영자 성숙도에 따라 분석 능력은 천차만별로 달라질 수 있다.
다른 예를 들어보자면, 기존 Legacy 환경은 WEB, WAS, DB로 대표되는 3Tier 아키텍처에서 현재는 API Gateway, Service Mesh, Container Management, Telemetry, CI/CD Automation, Backing Services 그리고 Container의 WEB/WAS/DB... 등등 기술 요소의 확장은 때로 편의성과 민첩성을 제공하지만, 이는 어디까지나 이러한 기술을 능숙하게 다루고 적용하고 설계할 수 있을 때의 이야기이며, 지금 우리는 여전히 아주 부족한 상태에서 시작하는 클라우드 초년생일 뿐이다.
마지막으로 하나 더 예를 들어보자면, 분산 트랜잭션 관리에 대한 엄격한 정책이 세워져야 한다. 마이크로서비스를 구성하는 그 기반이 되는 원칙은 바로 Loosely Coupled이다. 이는 각 서비스간 결합을 최소화 또는 없애는 방향을 찾아야 한다. Database는 각 서비스 별로 별도로 제공되며, 결합도를 낮추기 위한 Message Queue를 검토해야 한다. 역시나 기술의 어려움은 둘째치더라도, Database의 분리에 들어가는 비용, 시간, 노력,,, Backing Services의 선택, 비용 등등 더 이상 말하지 않아도 이해할 것이라 생각한다.

 

지금부터 설명할 내용은 바로 이러한 마이크로서비스 아키텍처로 적용된 시스템의 문제점들을 보완하고 대책을 마련하기 위한 Event-Driven Architecture에 대해 살펴보고자 한다.

What?

Event-Driven이란 다음과 같이 정의할 수 있다.

• Event 즉 사건 기반으로 아키텍처 설계 (사건이란 중요하고 의미 있는 일 예를 들어 자동차를 구매하면, 자동차의 재고를 줄이는 일과 같은 이벤트가 발생하면, 그 이벤트에 의해 필수적으로 일어나게 되는 또 다른 이벤트를 정의하는 일)

• 분산 아키텍처 환경에서 상호 간 결합도를 낮추기 위해 비동기 방식으로 메시지를 전달하는 아키텍처 패턴

• 컴퓨터 용어로는 키보드, 마우스를 동작하여 발생되는 일, 터치스크린을 터치하여 발생되는 일

등을 이벤트 트리븐이라 한다.

그렇다면 Even-Driven Architecture(이하 EDA)란 무엇인가?

Event Driven Architecture는 이벤트의 생산, 감지, 소비 및 반응 또는 시스템 상태의 중대한 변화를 지원하는 소프트웨어의 모델 또는 아키텍처 패러다임이다.

EDA는 복잡성과 역동성에 가장 효율적으로 대응할 수 있는 모델로 평가된다. 시시각각 발생하는 이벤트의 생성과 감지, 반응을 중심으로 구축되는 디자인 유형이기 때문이다. 실제로 EDA에선 고정된 구조가 없다. 심지어 구조 자체가 없을 때도 있다. 이벤트 발생으로 데이터와 데이터가 느슨하게 연결되며(coupling) 없던 구조가 생겨나기도 한다.
예를 들어보자면, 우리가 키보드와 마우스를 통해 동작하는 행위가 컴퓨터 입장에서는 이벤트가 되며 컴퓨터는 이벤트의 결과를 필수적으로 반환해야 하는 것이다.
일례로 야구경기 티켓을 예매하기 위해 예매사이트를 검색한다고 해보자. LG 홈 경기 잠실 야구장의 예매가능 좌석인 블루석 A10을 예매하면 시스템은 해당 좌석을 예매완료로 변경한다. 이때 이미 동일 화면을 띄워둔 또 다른 사용자가 동일 좌석 예매를 눌렀을때, 애매가능에서 예매완료 상태로 변경되었다는 메시지를 출력함으로써 무결성을 유지한다. 이때 무결성을 유지하기 위해 시스템은 키보드/마우스 입력에 따른 예매를 진행하기 전 예매가능상태임에도 불구하고 다시한번 테이블을 조회하여 가능상태가 맞는지 검증하는 과정을 추가하고, 결재가 진행 중일 경우 예매가능 상태를 일시적으로 예매완료 또는 예매진행중 상태로 변경하여 이후 구매자의 중복 구매를 막도록 한다. 이는 일반적인 Validation 방식이지만, CUD가 발생한 이벤트를 의미있는 이벤트로 판단하여 필수적인 결과를 발생시키는 한가지 예시라고 볼 수 있다.
이와 같은 예시를 보면 우리는 이미 Event-Driven Architecture를 적용하고 있었다고도 볼 수 있다. 즉 키보드와 마우스의 조작이 발생하면 이벤트가 발생할때 마다 새로운 관계를 맺기 위해 또 다른 사용자 또는 또 다른 시스템에 변경을 발생시키는 것이 바로 Event-Driven이라 할 수 있다. 특히 이와 같은 변경은 실시간으로 이루어져야 한다.

정리하자면 Event-Driven Architecture란 다음과 같다.
Event Driven MicroService(EDM)는 MSA가 적용된 시스템에서 이벤트 발생시 해당 이벤트 로그를 보관하고 이를 기반으로 동작하며, 비동기 통신을 통해 시스템 내 통합(integration)을 수행하는 Architecture이다.
- 이벤트
IT 영역에서 이벤트는 다양한 정의를 갖지만, 이 곳에서 언급하는 이벤트는 상태의 변경. 즉, 데이터의 변경,생성,삭제(CUD)를 통해 발생하는 서비스의 의미있는 변화를 뜻한다.
- 이벤트 로그를 보관
현재의 데이터는 상태 변경의 누적이라는 생각에서 시작한다. 이 때 상태 변경은 이벤트를 뜻하고 이를 누적하는 행위는 이벤트 로그를 보관하는 것이다. EDM 에서 생성된 이벤트는 반드시 보관되어야 한다. 보관된 이벤트는 데이터의 현재 상태를 구성하는 근간이 된다. 또한, 보관된 이벤트를 바탕으로 장애 발생 또는 특정 요구사항에 따라 지정된 시점으로 복원을 수행한다. 이벤트 로그를 보관하는 장소를 이벤트 스토어라 칭한다.
- 비동기 통신
amqp, mqtt, jms 등 메세징 프로토콜을 통한 메세지 큐 방식이 자주 사용된다. 서비스에서 데이터의 생성,변경,삭제(CUD)를 통해 이벤트가 발생하면 발행 서비스는 메세지의 형태로 이벤트를 발행하고, 해당 이벤트에 관심이 있는 서비스에서 구독을 수행한다. 메세지 큐를 사용함으로 requeue/dlq 등의 기능을 활용할 수 있다.
- 시스템 내 통합(integration)
이상적으로 구현된 MSA는 서비스 간 데이터 참조를 위한 내부 통신이 필요없지만, 현실적으로 서비스 간 내부 통신이 전혀 없는 시스템을 구현하기란 불가능에 가깝다. 다양한 사유로 여러 서비스 간 통신을 통해 연동이 발생한다.
이벤트를 데이터의 생성, 변경, 삭제로 정의했기 때문에 MSA의 데이터 관리와 밀접한 연관성을 갖는다. 데이터는 현재의 상태를 나타내고 이는 보관된 데이터 변경, 생성, 삭제 기록 즉, 이벤트 로그에 기반한다.
- 특정 서비스에서 기능을 수행한다.
- 이벤트가 발생(데이터의 생성,변경,삭제)하면 해당 도메인 객체를 기반으로 이벤트를 생성한다.
- 생성된 이벤트는 저장 공간에 보관되고 비동기 메세지 큐로 해당 이벤트에 관심이 있는 서비스들에게 전달된다.
- 이벤트를 구독한 서비스는 biz. logic을 수행한다.
- 수행 도중 오류가 발생하면 저장된 이벤트 로그를 기반으로 retry/rollback을 수행한다.
MSA는 나뉘어진 서비스와 서비스 별 각자의 데이터베이스 구성을 지향한다. 이로 인해 발생하는 새로운 요구사항들이 있다. EDM을 적용해 새로운 요구사항들을 충족시킬 수 있다.
서비스 별 각자 데이터베이스를 적용한 시스템에서 데이터의 무결성을 보장할 수 없지만 EDM을 통해 데이터의 최종적인 일관성을 유지할 수 있다.
- all commit or rollback → eventually consistency

Why?

• Loosely coupled : 이벤트 Publisher와 Subscriber는 이벤트 브로커를 통해 약결합 형태로 다양한 이벤트를 주고 받을 수 있으며, 서로 다른 네트워크에 분리하여 구성할 수 있다. 이는 확장성과 민첩성을 높여주는 요소이다.
• In Real-time Analytics : Event-Driven 아키텍처는 실시간 분석에 최적화 되어 있다.중요한 이벤트가 발생하기 전에 시간 내에 패턴을 찾고 분석 후 대응할 수 있다.
• Versatility : Event-Driven 아키텍처를 적용한 시스템은 예측 불가능하고 비선형적이며 비동기적인 환경으로 표준되어 있어 응답성이 향상된다. 이러한 시스템은 다양한 환경에서 적합하게 활용될 수 있다.

HOW?

• Publish/Subscribe Messaging : 마이크로서비스 및 서버리스 아키텍처에 사용되는 비동기 서비스 간 통신 형태이다. 이벤트가 공개되거나 생성되면 각 구독자에게 메시지를 Push 한다. 메시지가 수신된 후에는 반복되지 않으며 새 Subscriber에게는 이벤트가 표시되지 않는다. Subscriber는 Publisher에 대해 아무것도 알 필요가 없다.
• Event Source : 이벤트 소스는 이벤트를 이벤트 처리 시스템으로 전송한다. 이벤트 소스는 이벤트 프로세서와 N:N으로 전송 관계를 맺는다.
• Event Processor
• Event Consumer

https://www.xenonstack.com/insights/event-driven-architecture/