🏛 Data Flow Architecture

Data Flow Architecture

• 입력 데이터의 연속적인 흐름에 대한 일련의 변형이 특징이다.
• 데이터 흐름이 명시적이다.

• 프로세스간 다른 상호작용은 없다.

• 거의 선현의 데이터 흐름 시스템이다.
• 매우 단순하고 고도로 제한된 순환구조도 있을 수는 있다.
• 중간에 유저와의 인터랙션이 없다. 이벤트도 없다.

Batch Sequential Style

• 보통 웹서비스 관점에서는 요청-응답 형식이 아니라 응답이 없는 구조를 말한다.

## 별도의 프로그램이 순서대로 실행됩니다. 데이터는 다음과 같이 전달됩니다.

한 프로그램에서 다음 프로그램으로 집계합니다.

□ ### 요소

∎ 구성 요소: 독립 프로그램
∎ 커넥터: 파일
□ 데이터는
대부분 파일 형태의 프로그램입니다.
□ ### 관계

∎ 하나의 프로그램에서 생성된 파일은
다음 프로그램에 입력
□ ### 제약

∎ 각 프로그램은
다음 프로그램 시작

혜택

∎ 간단한 구성
∎ 처리 단계의 재사용
∎ I/O 데이터가 일치하는 경우에만 처리 단계를 쉽게 교체
□ ### 약점

∎ 높은 대기 시간
∎ 낮은 처리량
∎ 동시성 없음
∎ 비대화형

Pipe and Filter Style

이 아키텍처의 주요 특징은 동시성과
증가된 실행 .
∎ 루프가 허용됩니다.

• 데이터가 스트림형태로 들어오는 경우
• 방범카메라라던지 => 영상 스트림이 흘러들어올때 필터로 CNN이라던지 이런 느낌
• 사용자랑 인터렉션 가능하지만 뭔ㄱ ㅏ어렵다

필터 2,3 병렬처리 가능

• 단점 : 필터간 정보 공유가 어렵다. 그냥 흘러들어오는 스트림만 알수있다.

요소

∎ 구성 요소: 필터
□ 소스 데이터의 일부 를 싱크 데이터로 점진적으로 변환
□ 두 종류의 필터 – 능동 필터 와 수동 필터
∎ 커넥터: 파이프
□ 단방향 흐름, 순서 보존, 데이터 보존
□ ### 관계

∎ 파이프의 소스 끝이 필터의
출력 포트
∎ 파이프의 싱크 끝이 필터의 입력에 연결됩니다.
포트.
□ ### 제약

∎ 필터는 독립 엔터티여야 합니다.

=> 서블릿 필터 인터셉터도 이 구조인가?

혜택

∎ 간단한 구성
∎ 필터 재사용
∎ 시스템 유지 및 개선 용이
∎ 필터의 분산 병렬 처리를 통한 성능 향상
□ ### 약점

∎ Interactive I/O를 잘 다루지 못함
∎ 많은 수의 독립 필터를 사용하면 상당한 양의 필터를 추가할 수 있습니다.
계산 오버헤드
∎ 파이프 및 필터 시스템은 장기 실행 계산에 적합하지 않을 수 있습니다.
∎ 낮은 내결함성

Process Control Style

• positive feedback, negative feedback을 주고받는거 같은 형태의 구조

데이터 흐름은 프로세스의 실행을 제어하는 변수 집합 에서 나옵니다 .

설정값

∎ 제어 변수에 대한 원하는 값입니다.
□ ### 조작된 변수

∎ 조작된 변수 값은 컨트롤러에 의해 조정 또는 변경됩니다.
□ ### 입력변수

∎ 처리 장치에 대한 입력 데이터
□ ### 통제변수

∎ 제어 변수는 기본 시스템에 대한 값을 제공하며 다음과 같아야 합니다.
센서에 의해 측정됩니다.

예시 크루즈 컨트롤

비교

##문제가 순차적인 상태로 분해될 수 있는 경우,
∎ 일괄 순차 또는 파이프라인 아키텍처 고려

∎ 추가로 각 단계가 증분식이므로 이후 단계가 이전 단계보다 먼저 시작될 수 있습니다. => 배치는 인크리멘탈하는 개념
□ 파이프라인 아키텍처 고려

□ ### 문제가 데이터의 연속 스트림에 대한 변환과 관련된 경우
∎ 파이프 및 필터 아키텍처 고려

□ ### 시스템이 예측할 수 없는 제어 작업을 포함하는 경우
###If your system involves controlling action which is subject to unpredictable external perturbation

∎ 폐쇄 루프 프로세스 제어 아키텍처 고려

Data Flow Software Architecture에 대해 정리해보고, 해당 아키텍처에 속하는 이키텍처들을 정리해 보려합니다. 주제에서 알 수 있듯이 데이터의 흐름에 대한 소프트웨어 아키텍처입니다. Data Flow Software Architecture는 전체 소프트웨어 시스템을 연속적인 데이터 집합에 대한 일련의 변환으로 봅니다.

소프트웨어 시스템은 데이터가 데이터 연산 처리 순서를 지시하고 제어하는 데이터 처리 요소로 분리 될 수 있습니다. 각 컴포넌트는 입력으로 데이터를 받고, 출력으로 연산된 데이터를 출력합니다. 이렇게 출력된 연산 데이터는 다음 컴포넌트의 입력이 됩니다. 이 부분이 Data Flow Software Architecture 들의 가장 큰 특징입니다.

데이터를 처리하는 각 서브시스템 컴포넌트들 사이의 연결은 I/O 스트림, I/O 파일, 버퍼나 파이프등 다양한 방법이 있습니다. 이 아키텍처에서 트리 구조에서는 사이클이 없는 선형적인 구조를 가지고 있으며, 그래프 토폴로지와 같은 데이터 흐름에서는 사이클이 발생할 수 있습니다.

Data Flow Software Architecture에 속하는 대표적인 구조 3가지는 아래와 같습니다.

Batch Sequential Architecture

Pipe and Filter Architecture

Process Control Architecture

Data Flow Software Architecture의 장점은 변경용이성과 재사용성입니다. 서브시스템은 서로간 독립적으로 구성되어 있습니다. 각 서브시스템은 서로간의 어떠한 영향없이 새로운 서브시스템으로 교체가 가능하며 중간에 새로운 서브시스템의 추가도 쉽기 때문에 아키텍처의 변경이 용이하고 각 서브시스템은 다른 아키텍처에서 재사용이 쉽습니다. 한 가지 유의점은 서브시스템 추가 시 출력되는 데이터 형태가 다음 서브시스템의 입력과 일치해야 합니다. A에서 B 모듈로 파일을 이용해 입출력을 하는 아키텍처에서 중간에 S 서브시스템을 추가한다고 합시다. 이때 S 서브시스템의 출력은 파일이 아니라 Buffer 형태를 사용한다면 추가가 불가능 합니다. 이런 점은 유의해야 합니다.

위와 같은 특징을 생각했을 때 전통적인 절차지향적 구조라는 생각이 듭니다. Data Flow Software Architecture는 컴파일러나 Batch 데이터 처리 등에서 많이 사용합니다.

다음 글에서 Batch Sequential, Pipe and Filter, Process Control을 순서대로 정리해보겠습니다.

감사합니다.

출처: https://sonseungha.tistory.com/507?category=534435 [Developer’s Delight]

Batch Sequential Architecture에 대해 정리해보겠습니다.

Batch Sequential Architecture는 이전 글에서 정리한 Data Flow Software Architecture 중 하나입니다. 참고가 필요하신 분은 해당 글을 확인해주세요.

2019/03/10 - [Developer’s Delight/Software Architecture] - [S/W Architecture] Data Flow Software Architectures

Batch Sequential Architecture는 1950~70년대에 많이 사용된 데이터 처리 모델입니다. 데이터는 하나의 서브시스템에서 다음 서브시스템으로 데이터로 전달됩니다. 각 데이터 전송 서브시스템 또는 모듈은 이전 서브시스템의 데이터 처리가 끝나기 전에는 스스로 시작할 수 없습니다. 정리하자만 A-B 로 연결된 Batch Sequential Architecture에서 B는 A가 모든 데이터 처리를 완료한 후 결과 데이터가 출력되기 전까지 스스로 독립적으로 시작할 수 없습니다. 데이터를 분리해 중간중간 처리가 아닌 하나의 서브시스템이 데이터를 처리한 전체 결과를 출력해야만 다음 서브시스템이 시작할 수 있습니다.

Batch Sequential Architecture를 구성하는 컴포넌트는 Program과 Data store입니다. 각 프로그램의 연결은 단방향 파이프로써 데이터 셋을 전달합니다. 아래와 같은 형태로 Batch Sequential Architecture가 구성됩니다.

입력 => FILTER -> FILTER -> FILTER -> FILTER -> FILTER => 출력

Batch Sequential Architecture는 서브시스템들이 단순하게 분리되어 있고 입력 데이터와 출력 데이터에 맞춘 서브시스템의 교체도 가능합니다. 서브시스템간 연결은 오직 데이터 이므로 데이터만 맞추면 된됩니다. 하지만 외부에서 서브시스템을 제어하기 위한 구현에서는 부적합하며 인터렉션을 위한 인터페이스를 제공할 수가 없다. 오직 데이터만이 입력과 출력이기 때문입니다. 또한 동시성을 지원하지 않기 때문에 낮은 성능과 높은 Latency를 가지는게 이 아키텍처의 한계입니다.

출처: https://sonseungha.tistory.com/508?category=534435 [Developer’s Delight]

Data flow Architecture에는 Batch Sequential, Pipe and Filter, Process Control Architecture 로 3가지로 분류할 수 있습니다. 그 중 Pipe and Filter Architecture에 대해 정리해보려 합니다.

Pipe and Filter Architecture는 데이트 스트림을 처리하는 시스템을 위한 구조를 제공합니다. 데이터를 처리하는 각 프로세싱 단계는 Filter 컴포넌트 내부에 포함되어 있습니다. 데이터는 Filter 사이를 Pipe를 통해 전달되게됩니다.

이러한 구조로 인해 Pipe and Filter Architecture는 Batch Sequential Architecture와 많이 비교됩니다. Batch Sequential Architecture에 대해에서는 아래 글을 참조해주세요.

2019/03/10 - [Developer’s Delight/Software Architecture] - [S/W Architecture] Batch Sequential Architecture

Pipe and Filter 구조의 구성요소는 크게 3가지 입니다. 데이터 스트림, 필터, 그리고 파이프입니다.

데이터 스트림은 XML이나 Json 파이트 스트림 등 first-in / first-out 버퍼를 가지고 있습니다. 특정 시스템에서는 마샬링, 언마샬링도 사용합니다. 다음 구성요소인 필터는 Pipe and Filter Architecture에서 독립적으로 데이터 스트림을 처리하는 구성요소입니다. 입력 데이터 스트림으로부터 데이터를 읽고, 읽어들인 데이터를 처리한 후 다음 필터로 전달하도록 파이프로 데이터를 전달합니다. Pipe and Filter는 데이터가 연결된 파이프를 통해 전달되면 그 즉시 처리를 하고 다음 필터로 전달합니다. 필터를 독립적으로 동작하므로 시스템에서 자유롭게 교체 및 추가가 가능합니다. 여기서 필터는 2가지 타입으로 다시 분류할 수 있습니다. Active(능동형) 필터와 Passive(수동형) 필터입니다. 먼저 능동형 필터는 데이터를 가져오고 전달하는 것을 필터에서 처리하고 수동형 필터는 파이프가 필터로부터 데이터를 가져오고, 다음 필터로 전달합니다. 즉 능동형 필터는 수동형 파이프와 함께 동작하고 수동형 필터는 능동형 파이프와 함께 동작합니다. 마지막 구성요소인 파이프는 필터 사이에 데이터 스트림을 이동하는 경로입니다.

Pipe and Filter 구조는 리눅스 사용자라면 많이 사용하는 파이프를 생각하시면 편합니다.

$cat example.txt

grep ‘test’

위와 같은 예제는 쉽게 이해할 수 있습니다. cat을 이용해 example.txt 내부 문자열들을 파이프를 통해 grep에게 전달되고 처리하게 됩니다.

이러한 Pipe and Filter Architecture의 장점은 Concurrency(동시성), Reusability(재사용), Modifiability(변경용이성), Simplicity(단순성), Flexibility(유연함)입니다. Concurrency는 과도한 데이터 처리에 대해 각 필터가 독립적으로 동작하여 높은 처리량을 얻을 수 있습니다. Reusability는 각 필터가 독립적으로 동작되며 다른 필터와의 종속성이 없으므로 각 필터를 다른 시스템에 재사용이 가능합니다. Modifiability는 필터 간 종속성이 낮기에 새로운 필터를 추가하거나 수정, 제거했을때에도 시스템에 다른 수정을 최소화 할 수 있습니다. 두 필터 사이의 파이프가 존재한다는 매우 단순한 구조를 가지고 있으며 각 해당 시스템의 데이터를 Sequential하게 Parallel하게 수행이 가능함으로 유연한 구조를 만들 수 있습니다.

하지만, Pipe and Filter 구조에도 여러 단점이 있습니다. 데이터 스트림 형태가 고정된 형태의 구조이기에 동적으로 데이터 포맷을 변경하는 구조에는 알맞지 않습니다. 만약 A 필터로 이미지가 입력되었는데 출력으로는 XML 포맷으로 출력하고 B 필터는 XML을 입력받아 Character Stream으로 출력한다면, 이 구조의 장점인 변경용이성, 유연함을 잃어버리게 됩니다.

이런 장점과 단점을 이해하고 정확하게 필요한 곳에 구조를 적용하는 연습이 필요할 것 같습니다. 마지막으로 많이 비교되는 Batch Sequential Architecture와의 차이점을 정리하고 글을 끝맺겠습니다.

Batch Sequential 과의 차이점

위에서 정리한 내용을 보면 Batch Sequential Architecture와 매우 유사해 보이지만 큰 차이점을 가지고 있습니다. Batch Sequential은 데이터가 처리되고 다음 데이터 처리 단계로 넘어가기 위해선 이전 데이터 처리가 모두 완료되어야 합니다. 즉 A에서 B 처리 단계로 데이터가 전달되기 위해선 모든 데이터가 A처리가 완료된 이후 B로 입력됩니다. 하지만 Pipe And Filter Architecture는 데이터 스트림 처리를 위한 구조로서 A 단계에서 모든 데이터가 처리되고 B의 입력이 되는 것이 아닌 A 단계에서 먼저 처리된 데이터는 바로 B의 입력으로 Pipe를 통해 전달됩니다. 100개의 데이터가 있을 때 Batch Sequential은 100개가 모두 처리된 이후 다음 스텝으로 입력되지만, Pipe And Filter는 100개 중 처리된 데이터는 B로 전달됩니다. 이 점이 가장 큰 차이입니다.

감사합니다.

출처: https://sonseungha.tistory.com/510?category=534435 [Developer’s Delight]

Process Control Architecture는 Data Flow Architecture 분류에 속하는 아키텍처입니다. 해당 분류에 속하는 아키텍처는 이전에 다뤘던 Batch Sequential, Pipe and Filter Architecture가 있습니다. 자세한 내용은 아래 링크 참고 부탁드립니다.

2019/03/10 - [Developer’s Delight/Software Architecture] - [S/W Architecture] Data Flow Software Architectures

2019/03/10 - [Developer’s Delight/Software Architecture] - [S/W Architecture] Batch Sequential Architecture

2019/03/14 - [Developer’s Delight/Software Architecture] - [S/W Architecture] Pipe and Filter Architecture

Process Control Architecture에 대해 간략히 정리해보겠습니다.

Process Control의 가장 큰 특징은 데이터의 흐름이 프로세스의 실행을 제어하는 변수 집합이라는 것입니다. 한 번에 이해하기 어려운 말인 것 같습니다. 좀 더 살펴보겠습니다.

Process Control Architecture는 임베디드 시스템에서 많이 사용됩니다. 시스템이 프로세스를 제어할 수 있는 변수에 의해 조작되는 시스템에 알맞는 아키텍처입니다. 많은 임베디드 시스템은 연속적으로 동작해야 합니다. 안정된 상태에 대한 출력 데이터를 유지하는게 가장 중요한 시스템입니다. 예를 들어 크루즈나 화장실 변기를 많이 예시로 듭니다. 화장실 변기 물을 내리면 다시 물이 차오릅니다. 그 때 차오르는 물의 높이는 항상 일정합니다. 이러한 시스템은 물의 높이 즉 출력 데이터를 안정화 시키기 위해 프로세스가 데이터를 제어하게 되는 구조가 됩니다.

해당 시스템을 구성하는 몇 개의 서브시스템이 있는데 각 서브시스템은 아래와 같습니다.

Controlled Variable : 기본 시스템에 대한 값을 제공하며 센서에 의해 측정되어지는 값

Input Variable : 프로세스에 대한 입력 값

Manipulated Variable : 컨트롤러에 의해 조정되거나 변경되는 값

Process : 변수를 조작하기 위한 메커니즘

Sensor : 시스템 제어와 같련된 변수의 값을 구하며 조작된 변수를 재계산 하기 위한 피드백으로 사용

Set Point : 이 값은 제어된 변수에 대한 원하는 값

Control Algorithm : 프로세스 변수 조작 방법을 결정하는데 사용함

출처 : https://www.cs.cmu.edu/afs/cs/project/tinker-arch/www/html/Tutorial_Slides/Soft_Arch/base.097.html

위 그림은 Cruise Control 시스템의 예제입니다. 자동차의 크루즈 모드는 일정한 속도를 유지하기 위한 시스템입니다. 원하는 속도가 입력 값이 되고 컨트롤러에 의해 Throttle이 설정됩니다. 해당 Throttle은 엔진을 동작하게 만들고 엔진은 바퀴를 회전시킵니다. 바퀴의 회전은 센서에 의해 측정되고 Controller에게 전달됩니다. Controller는 Desired Speed에 도달할 때 까지 지속적으로 Throttle을 설정하게됩니다.

위 와 같은 시스템이 Process Control Architecture를 적용한 시스템이라고 보시면 됩니다. 바퀴의 회전을 센서로 다시 컨트롤러에게 전달되는데요, 이처럼 출력 데이터가 다시 컨트롤러의 입력으로 전달되어 Close-loop 형태를 뛰는 구조들이 있습니다. 만약 출력 데이터가 다시 피드백 되지 않는다면 Open-loop 형태라고 합니다. Close-loop Feedback은 Open-loop보다 출력 데이터를 제어하는데 훨씬 좋은 구조라는 것을 알 수 있을겁니다.

이상으로 Process Control Architecture에 대해 정리해보았습니다.
감사합니다.

출처: https://sonseungha.tistory.com/512?category=534435 [Developer’s Delight]