컨텐츠 바로가기

10.14 (월)

"이벤트 기반 프로그래밍에 대한 가벼운 접근 방식" 마이크로소프트 드래시의 이해

댓글 첫 댓글을 작성해보세요
주소복사가 완료되었습니다
마이크로소프트 애저 인큐베이션팀은 마이크로소프트 하이퍼스케일 클라우드에서 상당히 흥미로운 구성요소 중 하나다. 전통적인 소프트웨어 개발팀과 연구 조직의 중간 정도에 해당하는 성격으로, 대규모 분산 시스템 문제를 해결하기 위한 솔루션 개발을 담당한다.
ITWorld

ⓒ Getty Images Bank

<이미지를 클릭하시면 크게 보실 수 있습니다>



이러한 솔루션은 데이퍼(Dapr), 래디어스(Radius)와 같은 개발자 툴 또는 KEDA(Kubernetes event-driven autoscaling) 시스템과 같은 쿠버네티스의 확장 프로그램일 수 있다. 최신 퍼블릭 릴리스는 관리 툴과 새로운 애플리케이션 플랫폼의 하이브리드다.


드래시란?

애저 CTO 마크 루시노비치가 블로그를 통해 최근 발표한 드래시(Drasi)는 핵심 이벤트를 감지해 즉각 대응하기 위한 툴이다. 여기서 대응이란 하드웨어 또는 소프트웨어 장애가 발생한 경우 플랫폼 아키텍처를 재구성하는 것일 수도 있고, 예를 들어 센서가 화학 공정에서 문제를 감지하는 경우 압력 초과 대응 또는 화재 대응을 실행하는 것일 수도 있다.

마이크로소프트 애저 인큐베이션 프로젝트 대부분은 오픈소스이며, 드래시 역시 예외는 아니다. 이미 아파치 2.0 라이선스로 CNCF(Cloud Native Computing Foundation)과 깃허브 리포지토리에 제출됐다. 설명 사이트에서 더 자세한 내용을 볼 수 있다.

이와 같은 이벤트 기반 아키텍처는 분산 시스템에서 비교적 일반적인 설계 패턴이다. 다른 분산 개발 모델과 마찬가지로 나름의 문제도 있는데, 이런 문제는 대규모에서 특히 두드러진다. 분당 수십 또는 수백 개의 이벤트가 발생하는 정도에서는 원하는 메시지를 쉽게 감지하고 대응할 수 있다. 그러나 애플리케이션 또는 서비스가 커져서 글로벌 플랫폼에 걸쳐 메시지의 수가 수십만, 또는 수백만 개에 이르게 되면 소규모 시스템에서는 작동했더라도 새로운 부하에서는 붕괴될 가능성이 높다.

규모가 커지면 이벤트 기반 시스템은 복잡해진다. 메시지와 이벤트가 많은 형식으로 전송되고 독립적인 사일로에 저장되므로 추출 및 처리하기가 어렵고 많은 경우 복잡한 쿼리 메커니즘이 필요하다. 또한 메시지 큐 시스템이 느려지고 혼잡해지면서 지연이 증가하거나 메시지 처리 시간이 초과되기도 한다. 이벤트에 신속하게 대응해야 하는 경우 이 취약한 상태는 사용하고 관리하기가 어렵게 된다.

드래시의 역할은 여기에 있다. 드래시는 관련 이벤트를 탐지하고 대응하는 프로세스를 자동화하는 더 나은 방법을 제공한다. 마이크로소프트는 이 프로세스를 "지능적 대응 자동화"라고 설명한다. 드래시는 복잡하고 중앙화된 이벤트 데이터 저장소가 필요 없고 탈중앙화를 사용해 이벤트의 출처와 가까운 곳, 즉 로그 파일과 변경 피드에서 이벤트를 찾는 가벼운 툴을 목표로 제작됐다.


드래시의 변경 사항 처리 방법

데이터는 탈중앙화되고 다양한 형식으로 저장되지만 드래시를 사용하면 익숙한 개발 기법을 사용해 쿼리를 작성하고 이러한 쿼리 결과의 변화에 대응하는 트리거를 설정할 수 있다. 이 프로세스의 핵심에는 소스(Source), 지속적 쿼리(Continuous Query), 리액션(Reaction) 3가지 개념이 있다.

드래시 애플리케이션에서 소스란 데이터가 수집되고 변경을 관찰할 수 있는 모든 장소다. 로그 파일과 데이터베이스 업데이트, 애저 이벤트 그리드와 같은 게시 및 구독 툴을 통해 전달된 이벤트, 또는 애저 펑션의 출력일 수도 있다.

지속적 쿼리는 CQL(Cypher Query Language)로 작성되며, 소스에서 데이터 변경을 모니터링하면서 변경에 의해 트리거되는 스위치 역할을 한다. 쿼리가 트리거되면 시스템이 리액션을 전송한다.

리액션은 간단하게는 알림일 수도 있고, 사전 구성된 일련의 프로세스를 트리거하는 입력이 될 수도 있다. 프로세스는 드래시를 사용하는 목적에 따라 달라진다. 예를 들어, 산업용 IOT 시스템에 위치한다면 일련의 하드웨어 제어에 따라 작동하면서 통제불능의 산업 프로세스를 종료할 수 있다. 시스템 관리 지원 시나리오의 리액션은 재해 복구 사이트 또는 데이터베이스 복제본에 대한 페일오버 프로세스를 시작할 수 있다. 드래시 리액션은 필요에 따라 단순하거나 복잡해질 수 있다.


모든 이벤트의 집결

드래시의 이벤트 기반 컴퓨팅 접근 방식에서 가장 흥미로운 부분은 과거라면 많은 종류의 이벤트 관리 툴이 필요했을 기능을 모두 지원한다는 것이다. 하나의 드래시 인스턴스는 라이브 텔레메트리와 함께 수동으로 업데이트되는 데이터도 처리할 수 있다. 예를 들어 드래시는 일련의 기계 장비에 대한 유지보수 로그와 함께 해당 디바이스의 라이브 텔레메트리도 읽을 수 있다. 하나의 쿼리가 예약된 유지보수 기간, 그리고 문제 가능성(그 자체가 소리를 사용해 문제를 감지하는 ML 애플리케이션이 생성한 이벤트일 수 있음)을 나타내는 알려진 텔레메트리, 두 가지 모두 모니터링할 수 있다.

드래시는 각기 개별적인 알림 대신 이런 여러 시스템을 하나로 모은다. 많은 애저 툴과 마찬가지로 확장성이 매우 뛰어나고 단일 사이트 또는 글로벌 기업 전체의 결과를 제공할 수 있다. 다양한 API를 드래시 리소스 관리 방법으로 래핑하는 명령줄 툴이 함께 제공된다. 모든 관리가 API를 통하므로 자체 관리 툴을 구축할 수 있다.

드래시 애플리케이션의 핵심은 일련의 지속적 쿼리다. 기존 쿼리와는 데이터를 처리하는 방식에 큰 차이가 있다. 드래시는 지속적으로 쿼리를 실행함으로써 기반 데이터 소스에 변경이 일어나는 대로 변경 사항의 맵을 구축할 수 있으며, 특정 시점 결과 또는 동적 피드를 사용할 수 있다. 동적 피드는 복잡한 ETL 없이 애저 시냅스 분석에 데이터를 제공하는 SQL 서버의 변경 피드와 개념적으로 비슷하다.


CQL을 사용한 변경 쿼리 작성

여러 소스로 작업하고 변경 데이터를 가져오는 작업은 그래프 데이터베이스 작업과 비슷한 부분이 많으므로 드래시가 Neo4J의 CQL 버전을 사용해서 지속적 쿼리를 작성하는 것도 놀랍지는 않다. SQL에 익숙하다면 알아볼 수 있겠지만 CQL도 쿼리 작성을 위한 많은 비슷한 구조를 지원한다. MATCH를 사용해서 경로를 찾고 WITH와 WHERE 절, 일반적인 데이터 유형 및 속성도 있다. 비교적 제한된 데이터 소스 집합을 다루므로 쿼리를 작성하기 위해 필요한 대부분의 기능을 여기서 찾을 수 있을 것이다.

목표는 CQL 쿼리를 사용해서 데이터에서 찾는 변경 사항을 설명하는 것이다. 쿼리 내에서 로직을 지원하므로 현재 보고 있는 데이터, 그리고 모든 소스에 걸쳐 나머지 데이터와 이 데이터의 관계를 캡슐화하는 쿼리를 하나로 작성할 수 있다. CQL은 모든 소스를 상호연결된 단일 그래프로 취급하므로 소스를 모으기 위해 복잡한 조인을 쓸 필요가 없다. 모든 소스는 필요에 따라 높거나 낮은 밀도로 채울 수 있는, 동일한 n차원 이벤트 공간의 일부이다.

마이크로소프트는 CQL에 자체 드래시용 확장을 추가했다. 여기에는 데이터를 다른 시각으로 보게 해주는 흥미로운 기능도 포함된다. 이는 지속적 쿼리 측면에서 상당히 중요하다. 이 중에서 퓨처(Future) 함수는 기존의 시간적 기능을 넘어 데이터에 대해 미래 경계를 설정한다. 여기에는 시간을 설정하고 그 시점, 또는 그 시점까지 특정 부울이 참인지 여부를 확인하는 기능이 포함된다.

비교적 간단한 함수지만 이벤트에 새로운 경계를 추가할 수 있게 해준다. 부울로 계산되는 쿼리 식을 작성한 다음 결과를 사용해서 시간 경과에 따라 시스템이 변화하는 방식을 기반으로 미래 이벤트를 트리거할 수 있다. 과거 특정 시점의 값을 볼 수 있게 해주는 시간 함수와 함께 사용할 수 있다. 드래시를 통해 이제 복잡한 코드를 쓸 필요 없이 CQL 쿼리 내부의 함수에 집어넣어 주요 데이터가 시간 경과에 따라 어떻게 변화하는지 살펴볼 수 있다.

마이크로소프트는 CQL을 시작하는 데 도움이 되도록 포스트그레SQL 데이터 집합 형태로 일련의 샘플 데이터를 제공하지만, 개발 툴은 여전히 없다. 비주얼 스튜디오 코드 확장이 있다면 오류 위험을 줄이면서 쿼리를 작성하고 테스트하는 데 도움이 될 것이다. 지금으로서는 다양한 이벤트 소스의 샘플 데이터와 예상되는 출력을 사용해 작업하는 것이 최선이다. 특히 퓨처 함수를 사용할 계획이라면 목록과 시간 기반 연산을 사용하는 데 익숙해지는 데 어느 정도 시간이 걸린다.


리액션 제공

드래시는 지속적 쿼리의 결과에 따라 작동하는 리액션을 출력한다. 리액션은 둘 이상의 쿼리에서 데이터를 받을 수 있으므로 비교적 간단한 쿼리 조합에서 복잡한 동작을 제공할 수 있다. 현재 리액션 유형은 소수지만 대부분 시나리오를 충족한다. 주요 옵션 중 하나인 애저 이벤트 그리드는 훨씬 더 많은 후속 동작을 제공한다. 그 외에 웹 기반 SignalR 프로토콜을 기반으로 하거나 마이크로소프트 데이터버스(Dataverse) 비즈니스 데이터 플랫폼과 함께 작동하는 기능이 있다.

마지막 리액션 유형인 데뷰(Debut)는 지속적 쿼리의 결과 테이블을 지속적으로 업데이트하므로 데이터 소스에서 쿼리가 어떻게 작동하는지 살펴볼 수 있다. 프로덕션을 위한 툴이 아니라, 지속적 쿼리가 어떻게 작동하는지 알아보고 쿼리의 출력을 중심으로 이벤트 처리를 구조화할 방법을 파악하는 데 도움이 되는 기능이다.

변화하는 것은 많은 이유로 흥미롭다. 드래시는 이런 변화의 세부 사항을 포착하고 제공해서 정보에 근거한 조치가 이뤄질 수 있도록 한다. 드래시는 하드웨어 또는 소프트웨어에 대해 예방적 유지보수를 사용하여 신속하게 문제를 해결하는 데 도움이 될 수도 있고, 침입 및 기타 보안 침해에 대한 조기 경보를 제공할 수도 있다. 드래시로 무엇을 할지는 전적으로 사용하는 사람에게 달려 있다.

변경 데이터를 처리하기 위한 가벼운 프레임워크는 실제로 사용하기 전까지는 그 필요성을 인지하지 못하는 종류의 툴이다. 드래시는 지속적인 이벤트 흐름을 생성하는 시스템을 다루기 위한 새롭고 혁신적인 방법을 제공해서 실제로 중요한 이벤트를 식별할 수 있게 해준다.

특히 드래시는 애플리케이션 개발, 플랫폼 엔지니어링, 시스템 관리의 경계를 넘나드는 만큼 클라우드 인프라와 애플리케이션을 대규모로 구축하는 일을 한다면 드래시에 관심을 가져야 한다.
editor@itworld.co.kr

Simon Bisson editor@itworld.co.kr
저작권자 한국IDG & ITWorld, 무단 전재 및 재배포 금지
기사가 속한 카테고리는 언론사가 분류합니다.
언론사는 한 기사를 두 개 이상의 카테고리로 분류할 수 있습니다.