'이벤트 주도 아키텍처'가 뜨는 이유··· "룰 기반 서비스 해체 후 데이터 공유"

API와 서비스의 액세스 패턴이 이용자 주도형에서 머신 주도형으로 이동하고 있음을 깨달은 개발자라면 아마도 이미 이벤트 주도 아키텍처(event-driven architectures)를 눈여겨보고 있을 것이다.
 

이 아키텍처를 이용하면 룰 기반 서비스를 해체하고 이벤트에 기반해 데이터를 공유하는 마이크로서비스를 만들 수 있다. 이는 사물 인터넷 기기, 데이터 스트림, 워크플로우 시스템, 여타 변화하는 조건을 감지하고 대응하는 서비스 사이의 실시간 복합적 트랜잭션을 대량으로 처리하는 매우 강력한 방법이다.

지난 20년 동안의 인터넷 기반 아키텍처를 되돌아보면 오늘날 이벤트 주도 아키텍처가 왜 중요한지 더 명확해진다. 개발자 대부분은 사용자 경험을 관리하고 비즈니스 로직을 처리하고 백-엔드 API 및 데이터 소스와 상호작용하도록 설계된 2계층, 3계층 웹 아키텍처에 익숙하다. 모델 뷰 컨트롤러(Model-View-Controller, MVC) 등 성숙한 패턴은 여러 플랫폼 상에 구현된 프레임워크를 이용해 이런 유형의 애플리케이션을 지원한다. 

따라서 앞선 개발자들은 프레젠테이션으로부터 비즈니스 로직을 분리하는 것이 애플리케이션 개발을 조정하는 데 중요하다는 사실을 재빨리 깨달았다. 모바일 애플리케이션 개발의 일부로 API를 설계할 정도로 성숙한 조직이 많아졌고, 일부 개발자는 이들 API에 걸친 다단계 트랜잭션과 워크플로우를 제어하기 위해 서비스 버스를 도입했다.   

이들은 이제 더는 이용자가 API의 주 고객이 아닌 오늘날의 새로운 아키텍처 요구를 향한 초기 단계다. 기업 내외에 훨씬 더 많은 애플리케이션, 데이터 서비스, 센서가 생겨나면서 이용자 아니라 이들이 API 및 서비스의 주 고객이 된 것이다. 이들 서비스는 통합된 서비스 생태계에서 이벤트를 감지하고 이에 대응할 수 있는 마이크로서비스로 개발될 때 새롭고 변화하는 비즈니스 요구에 대응할 수 있다. 그 결과 오늘날 이벤트 주도 아키텍처는 점점 더 중요해지고 있다.

이벤트 주도 아키텍처의 정의
이벤트 주도 아키텍처를 이해하는 한 가지 쉬운 방법은 입력과 출력 이벤트 패턴에 기초해 서비스를 정의하는 것이다. 

- 센서, 이용자 입력, 데이터 스트림 등 새 이벤트를 생성하는 서비스 
- 상태 변화를 통해 이벤트를 생성하는 서비스. 예컨대 구독 종료, 기상 알람 등 데이터 기반의 변화이다. 
- 디스플레이, 대시보드 등 이벤트를 주로 처리하고 소비하는 서비스 

마틴 파울러는 서비스에 의해 실행된 기능의 이벤트 유형을 상세히 설명한다. 예를 들어, 이벤트 알림은 응답을 처리하지 않으면서 배포되고, 이벤트 수행 상태는 이벤트의 완전한 디테일을 배포하며, 이벤트 소싱 서비스는 상태 변화를 기록한다. 그 후, 비즈니스 로직이 배포되는 방식에 따라 여러 토폴로지가 있다. 예를 들어 중재자 토폴로지는 중앙의 시스템이 미가공 이벤트를 처리한 후 다운스트림 변화 이벤트를 재배포해야 하는 아키텍처에 적절하다.  

이벤트 주도 아키텍처를 설계할 때에는 고려해야 할 운영 측면도 있다. 예컨대 확장성 요소, 레이턴시 요건, 서비스 수준, 성능 요소, 보안 요건, 오류 처리 요건 등이다. 결과적으로 이벤트 유형, 토폴로지, 운영 고려 사항이 이벤트 주도 아키텍처를 설계하는 데 필요한 모든 요소다. 
 
이벤트 주도 아키텍처 사례
이벤트 주도 아키텍처가 제 역할을 하는 사례는 다양하다. 유능한 CTO들도 이에 동의한다.

이벤트 주도 플랫폼 업체인 밴티크(Vantiq)의 CTO 폴 버터워스는 디지털 기업이라면 다른 사업 단위에 가치가 있는 이벤트를 한 사업 단위로부터 떼어내 비즈니스 기회를 실시간으로 다루어야 한다고 제안했다. 그는 “실시간 디지털 기업은 전사적으로 발생하는 이벤트와 이러한 이벤트에 대응하는 조치로 자연스럽게 구현된다. 디지털 기업의 핵심은 한 사업 단위에서 이벤트가 발생하면 수많은 개별 사업 단위가 이 이벤트에 독립적이고 비동기적으로 대응한다는 점이다”라고 말했다.

예를 들어 여러 사업 단위가 공통된 고객 세그먼트와 상호작용하지만 다른 제품과 서비스를 판매하는 경우다. 한 사업 단위의 모든 고객 접점은 다른 사업 단위에서도 도움이 되는 이벤트를 생성한다. 따라서 기존 관계를 해체하면 다른 사업 단위가 영업이나 고객 경험 향상에 이를 활용할 수 있다. 왜냐하면 각 사업 단위가 관심 이벤트에서 나온 정보를 어떻게 사용할 것인지 다양하게 결정할 수 있기 때문이다. 단, 여기서 한 가지 중요하게 고려해야 할 점은 누가 어떤 이벤트, 어떤 유형의 데이터에 접근할 것인지 권리와 권한을 정하는 것이다. 

두 번째 비즈니스 요구는 상태 변화를 관리하는 복합적 업무 프로세스와 연관된다. 이벤트 서비스 플랫폼 스트림리오(Streamlio)의 공동 설립자인 카시크 라머사미는 “이벤트 주도 아키텍처는 이벤트에 대한 응답 속도가 매우 중요하거나, 이벤트를 처리하는 것이 상태를 추적하고 갱신하는 더 효과적인 방식일 때 가치가 있다. 예를 들어 마이크로서비스 통합은 흔히 이벤트 주도 아키텍처와 상관성을 갖는다”라고 말했다.  

실제로 여러 부품이 여러 지역에서 여러 업체를 통해 만들어지는 복잡한 공급망을 가정해 보자. 여기에 이벤트 주도 아키텍처를 적용하면 다음과 같은 것이 가능하다.

- 공급자 시스템은 생산 현황 정보를 실시간으로 공지
- 경영 시스템은 이벤트를 비동기적으로 포착해 생산 주문을 공유 
- 다운스트림 공급자 시스템은 생산 주문을 포착해 생산 결과물을 조정

인-메모리 그리드 공급자인 해절캐스트(Hazelcast)의 CTO인 그레그 럭은 “이벤트 주도 아키텍처는 통상적인 데이터 축적과 질의 관행을 바꾼다. 이벤트는 데이터이고 즉석에서 처리된다. 이는 데이터를 처리하는 메시징 및 스트리밍 인프라가 필요하다는 것을 의미한다. 데이터를 신속하게 처리, 저장하려면 인-메모리 데이터 그리드와 결합하는 방법도 있다”라고 말했다. 

이를 이용하면 데이터가 다수의 사용자에 스트림 되는 실시간 이벤트 상황의 애플리케이션 요건을 충족할 수 있다. 이벤트를 실시간으로 전송하고 활용하는 자율 주행차가 대표적이다. 주행 관련 의사결정 과정에서 정보를 저장하고 검색하는 데 따른 지연은 짧으면 짧을수록 좋다.

이벤트 주도 아키텍처 만들기
클라우드 서비스 통합업체 델 부미(Dell Boomi)의 CTO 마이클 모턴은 대기업이 이벤트 주도 아키텍처를 구현하는 방법에 대해 조언했다. 그는 “이벤트 주도 아키텍처를 생성해 핵심 프로젝트를 지원하려 한다면 더 넓은 시야에서 전사적 이벤트 통합, 배포, 운영까지 고려해야 한다. 기존에는 배치 프로세싱이 일반적이었겠지만, 이는 더 이상 성공적일 수 없고 디지털 트랜스포메이션 요건을 충족할 수도 없다”라고 말했다. 

즉 이벤트 주도 아키텍처는 배치 프로세싱을 가진 기업이나 이벤트 주도형이 아닌 엔터프라이즈 시스템 및 SaaS 플랫폼이 통합된 기업에서 제한적 범위로 적용될 수밖에 없다는 것이다. 모턴은 "실제 구현 절차는 대부분의 아키텍처 변경과 마찬가지다. 적절한 플랫폼을 선택하고 작게 시작해 가치를 증명하고 기능을 강화하는 것이다. 이는 이벤트 주도 아키텍처를 반복적으로 개발하는 탁월한 방법이기도 하다"라고 말했다. ciokr@idg.co.kr