[Architectural Style] Data flow architecture 개념요약과 유형

 

DATA FLOW ARCHITECTURE

---

데이터플로우 아키텍쳐는 입력되는 정보를 계속 변경해 나가는 설계기법이다.

데이터플로우 패턴은 상당히 명백하며, 프로세스 간 다른 상호작용이 없다.

 

주요 구성요소

 

데이터플로우 아키텍쳐의 주요 구성요소는 두가지 입니다.

1. Component(Data Transformer)

- 입력을 바탕으로 출력을 생성합니다.

 

2. Connector(Data Channel)

- I/O stream, I/O files, buffer 등으로 구현되며, 데이터가 흘러가는 연결을 의미합니다.

 

Data flow system의 유형

 

일반적으로 데이터는 제멋대로 흘러가지만,  우리는 선형으로 흘러가는 데이터흐름을 가진 시스템 또는 단순한 구조에 주로 관심을 갖습니다. 대표적인 data flow style에는 3가지 유형이 있습니다.

 

반응형

 

Batch sequential

 

순차적인 프로세싱을 수행하며 입력이 완료되었을 때 작업을 진행합니다.

실행되는 프로그램들을 순서에 따라 분리하며, 결과를 다음 단계의 입력으로 전달합니다.

*장점: 단순한 구조, 각 단계의 높은 재사용성과 교체성

*약점: 상호작용 불가, 동시성 부족, 한번 시작되면 응답까지의 오랜 시간이 걸림

*제약사항:  각 프로그램은 이전 단계가 끝나기 전 까지는 실행되지 못한다는 제약사항을 가집니다.

 

Pipe and Filter

 

pipe and filter 스타일의 가장 큰 특징은 동시성과 증가하는 수행(incremented execution) 입니다.

또한,  이 스타일 에서는 loop도 허용이 됩니다.

Component는 Filter, Connector는 Pipe를 가지며, 필터의 유형은 Active, Passive 로 구분됩니다.

Active filter: 데이터를 가져오고 직접 다른 pipe로 전달합니다.
Passive filter: Active pipe와 함께 동작하며, Filter로 부터 데이터를 가져와 처리 후 다음 필터에 전달합니다.

 

Pipe and filter 스타일은 리눅스 명령어에도 적용이 되어 있습니다.

실제로 파이프 라고 불리는데요, 아래와 같은 명령어 구성을 사용해 보신 분들이 많을 것 입니다.

$ ls -ㅣ | grep myfile

 

Pipe and filter style의 장단점은 다음과 같습니다.

- 장점 : 단순한 조합, Filter의 재사용성, 용이한 유지보수성, 분산 처리를 통한 성능 향상 가능

- 단점 : Interactive I/O 처리에 부적합, 많은 filter의 추가로 인한 연산 오버헤드 발생,  Low fault tolerance(중간filter에 문제가 생기면 모든 시스템에 문제 발생)

 

Process Control

 

Process control 설계는 변수의 설정을 통해 프로세스의 실행을 제어합니다. Cruise control, QoS control 시스템에 적합 한 설계이며,  안정적인 시스템 유지를 목적으로 많이 사용됩니다.

원하는 값을 설정하고(Set point), 센서를 통해 입력되는 제어 값(Controlled variable) 과 설정값의 차이를 계산하여 Manipulated variable을 산출하여 실제 Input Variable에 대한 제어를 수행합니다.

Cruise control 설계의 예시를 활용하여 각 요소들을 설명하면 다음과 같습니다.

- Set point : 사용자가 원하는 속도
- Controlled variable : 현재 자동차의 속도
- Manipulated variable: Accelerator 의 정도( 연료가 들어가는 수준 )
- Input Variable : 연료 투입 량

 

오늘은 Data flow architecture에 대해 알아봤습니다.

개인적인 의견으로는 Data flow architecture에 속하는 설계들이 어플리케이션 개발에 그리 자주 사용하게되는 아키텍쳐라고 생각이 되지는 않습니다. 

요즘은 데이터를 계속 흘려보내면서 수행할만한 작업들이 그리 많지 않은 것 같아서요.

그래도 컴포넌트 내부에서 일어나는 특정 일련의 동작들은 이런 아키텍쳐를 채택할 수도 있어 보입니다만..

이걸 Data flow 아키텍쳐를 채택해서 만들었다 라는 설명이 그리 큰 의미가 있을지는 의문입니다.