Spring XD - 아키텍처

소개

Spring XD는 데이터 획득, 실시간 분석, 배치 처리 및 데이터 추출을 위한 단일화된 분산 확장 서비스이다. Spring XD의 아키텍처는 백명이상의 개발자가 수년에 걸쳐 진행한 Spring Batch, Integration and Data 프로젝트에 기반한 아키텍처이다. 이러한 프로젝트 기반하에 Spring XD는 데이터 처리를 시작하기 위해 즉시 사용할 수 있는 서버와 설정 DSL을 제공한다. 

Spring XD는 두가지 모드의 동작을 가지고 있다. Single 모드는 하나의 프로세스가 모든 processing 및 administration을 담당한다. 이 모드는 어플리케이션의 쉽고 단순하게 개발하고 테스팅할 수 있도록 도와준다. 분산 모드는 클러스트에 작업을 분산할 수 있다. Administrative 서버는 user command와 runtime event에 반응하여 클러스터 공유된 런타임의 상태 및 작업 수행을 관리한다.

Runtime Architecture

Spring XD의 가장 중요한 컴포넌트는 XD Admin과 XD Container 서버이다. HTTP를 통해 Admin server에 DSL를 사용해서 요청된 작업 처리를 요청 할 수 있다. 그러면 Admin 서버는 수행 작업을 수행 모듈로 매핑한다. 모듈은 Spring ApplicationContext로 구현된 실행의 단위이다. 분산 런타임은 multiple XD 컨테이너 서버 중 실행할 모듈을 제공한다. 하나의 XD 컨테이너는 여러개의 모듈을 실행할 수 있다. Single 모드를 사용한다면 모든 모듈은 하나의 XD Container와 XD Admin Server가 하나의 프로세스에서 실행 될 것이다. 

DIRT Runtime

분산환경 줄여서 DIRT는 여러개의 XD 컨테이너 인스턴스에 작업을 분산 할 수 있다. XD Admin 서버는 수행 작업을 개별적인 모듈 정의로 쪼갠다. 그리고 각 모듈을 ZooKeeper를 이용해 컨테이너 인스턴스에 할당한다. 각 컨테이너는 모듈 정의를 기다렸다가 모듈이 할당되거나 디플로이되면 Spring ApplicationContext를 수행한다

모듈들은 설정된 메시징 미들웨어(Rabbit, Redis) 사용하여 데이터를 공유한다. 모듈간의 메시징을 감소하기 위해서 여러개의 모듈을 하나의 모듈처럼 동적할 수 있게 결합시키기도 한다.

Support for other distributed runtimes

1.0 릴리이즈부터 XD Admin과 XD 컨테이너 인스턴스를 수행하는 것을 Spring XD 자체적으로 가능하다. 또 다른 대안으로 Spring XD를 Hadoop의 YARN에서 수행가능하며 미래에는 Pivotal Cloud Foundary를 지원할 예정이다. 

Single Node Runtime

싱글 노드 런타임은 같은 프로세스에서 Admin, Container, Zookeeper 및 HSQLDB를 실행시킨다. 싱글 노드 런타임은 테스팅과 개발을 목적으로 하지만 작은 프로덕션의 경우에는 적당할 수 있다. 

Admin Server Architecture

Admin Server는 embeded servlet 컨테이너를 이용해 REST endpoint를 노출한다. REST를 이용해 stream의 생성, 디플로이, 언디플로이, 제거 및 작업, 런타임 상태 조회, 분석과 가은 기능을 제공한다. Admin Server는 Spring MVC와 Spring HATEOAS의 구현체이며 REST의 표현은 HATEOAS의 정책을 따른다. Admin Server와 Container 서버의 모니터 및 런타임 상태 업데이트는 ZooKeeper를 이용한다.

Container Server Architecture

Spring XD 데이터 처리에서 주요한 컴포넌트는 다음과 같다. 

Streams, Jobs, Taps

Stream은 어떻게 event-driven 데이터가 수집되고 처리되고 저장되고 전달되는지에 대한 정의이다. 예를 들어 stream은 syslog data를 수집해서 필터링하여 HDFS에 저장할 수 있다.

Job은 조잡하고 시간이 많이 걸리는 배치 프로세싱 단계를 잘 편성한 것이다. 예를들어 작업은 HDFS 연산을 수행하고 이어 여러개의 MapReduce 작업 처리를 수행하도록 정의할 수 있다.

Tap은 Stream이나 Job이 처리에 간섭하지 않고 데이터를 처리하는데 사용된다. 전화에서 사용하는 wiretap처럼 Stream에 위치한 Tap은 데이터를 consuming할 수 있다. Tap은 원래의 Stream처리에 영향을 주지 말아야 한다.

Streams

Spring XD는 event stream을 처리하는 프로그래밍 모델은 Spring Integration 프로젝트가 구현체이기도 한 EIP 패턴이다. 프로그래밍 모델은 쉽게 테스트할 수 있도록 설계되었다. Stream은 다음과 같은 타입의 모듈들로 구성된다. Input Source, Processing Steps, Output sink.

Input source는 외부 소스로 부터 메시지를 생성한다. XD는 다양한 소스(예 : syslog, tcp, http)를 지원한다. 모듈의 출력은 메시지인데 메시지는 payload와 key-value 형태의 메시지 헤더로 구성된다. 메시지는 소스로부터 message channel을 통해 흐르고, 선택적으로 Processing Step을 거쳐 Output sink로 전달되다. Ouput sink는 메시지를 외부 리소스로 전달한다. 

단순한 stream 선형처리는 UNIX의 파이프엔 필터 모델에 비유할 수 있다. 필터는 어떤 이벤트를 생산하고 처리하고 소비하는 컴포넌트이다. 이것은 stream(source, processing steps and sink)의 모듈과 일치한다. 파이프는 필터간에 데이터가 전송되는 길이다. 이는 stream의 데이터를 전송하는 Message Channel과 일치한다. HTTP로 데이터를 읽어서 그것을 파일로 작성하는 간단한 stream을 UNIX 파이프/필터 문법을 사용하여 정의하면 다음과 같다. 

http | file

파이프는 HTTP source로 부처 File sink로 데이터를 전달하는 메시지 채널을 표현한다. 메시지 채널의 구현은 메모리, Redis 혹은 RabbitMQ일 수 있다. 추상화된 메시지 채널은 pluggable하게 데이터 전송 구현체를 교체할 수 있도록 XD 아키텍처에서 지원한다. 미래 버젼에서는 JMS 같은 전송을 지원할 예정이다.

UNIX 파이프/필터 문법은 선형 처리를 위한 Spring XD DSL의 기반이다.  비선형 처리는 named channel을 사용해서 부분적으로 지원한다. 하나의 스트림을 여러개의 스트림으로 효과적으로 분리하기 위해 라우터 싱크와 결합할 수 있다. 미럐에는 추가적은 비선형 프로세싱 지원이 있을 것이다.

Stream에 기반한 프로그래밍 모델은 버젼 4.0부터 Spring Integration으로부터 Spring Core에 포함되었다. 메시지 핸들러 클래스 주요 컨셉은 입력된 데이터를 처리하기 위한 코딩 표준을 단순하게 하자는 것이다. 예를 들어 http source로 부터 전달된 HTTP POST 바디 데이터는 다음과 같이 처리 할 수 있다.

public class SimpleProcessor {

public String process(String payload) { 

return payload.toUpperCase();

} 

}

메시지로부터 수신된 payload는 메소드 퍼리에 string으로 전달된다. Payload의 내용은 http request의 body이다. 해당 처리의 리턴값을 다음 단계의 Message로서 전달 될 것이다. 이러한 프로그래밍 표준은 매우 쉽게 당신의 processor 컴포넌트를 독립적으로 개발하고 테스트 할 수 있게 한다. Spring XD에서는 SpEL과 Groovy를 이용한 필터와 트랜스포머를 개발하는데 코드가 필요없도록 한다. 예를 들어 트랜스포머와 같은 처리 스텝을 stream을 추가하는 단순한 방법은 다음과 같다.

http | transformer --expression=payload.toUpperCase() | file

Streams Deployment

Container 서버는 ZooKeeper를 통해 모듈 디플로이 이벤트를 받을 수 있도록 받을 수 있도록 구동된다. 컨테이너 노드가 모듈 디플로이 이벤트를 처리할 때, 모듈의 입력과 출력 채널은 Stream 처리를 수행하기 위해 데이터 버스에 연결된다.  

싱글 노드 설정에서는 데이터버스는 인메모리 다이렉트 채널이고, 분산 설정에서는 데이터버스는 설정된 전송 미들웨어를 통해 통신한다. Redis, Rabbit 모두 Spring XD 분산을 지원한다.

예제 http | file에서 Admin는 각 모듈을 분리된 컨테이너 인스턴스에 할당할 수 있다. 모듈의 정의는 Module Registry에 저장된다. 모듈은 Spring XML 정의을 포함하며, 모듈의 동작을 담당하는 클래스 및 디펜던시 jar들로 구성된다. 모듈정의는 DSL로 전달된 파라미터로 모듈 정의를 커스터마이징할 수 있는 변수 placeholder를 포함한다. 예를 들어 http listening port를 옵션으로 전달하면 모듈 정의 placeholder값을 대체시킨다.

Module Registry는 파일 시스템 <xd-install-directory>/modules를 기반으로 한다. 컨터이너에 의해 모듈 디플로이먼트가 처리 될때, 모듈정의는 registry로 부터 로드되고 Container 프로세스내에 모듈을 실행하기 위한 새로운 Spring ApplicationContext를 생성한다. 

Jobs

배치 작업의 생성과 실행은 기능적으로 Spring Batch와 Spring for Apache Hadoop 프로젝트를 기반으로 한다.

Taps

Taps는 Stream이나 Job에 의한 데이터처리를 간섭하지 않고 소비하는 것을 제공한다. Taps는 Stream 데이터의 메트릭스 수집이나 분석을 수행하는데 추천한다.