Merge branch 'main' of https://github.com/danmooozi/software-architecture into eden

Author: JadenKim-dev

README.md

@@ -37,3 +37,7 @@
 | 08 | [컴포넌트 기반 사고](https://github.com/danmooozi/software-architecture/blob/main/ch08_컴포넌트_기반_사고/ch08_lia.md) | 24.10.21 | 오시연 |
 | 09 | [아키텍처 스타일 기초](https://github.com/danmooozi/software-architecture/blob/main/ch09_아키텍처_스타일_기초/ch09_mono.md) | 24.10.28 | 김원호 |
 | 10 | [레이어드 아키텍처 스타일](https://github.com/danmooozi/software-architecture/blob/main/ch10_레이어드_아키텍처_스타일/ch10_wynter.md) | 24.10.28 | 김수빈 |
+| 11 | [파이프라인 아키텍처 스타일](https://github.com/danmooozi/software-architecture/blob/main/ch11_파이프라인_아키텍처_스타일/ch11_max.md) | 24.11.05 | 이찬형 |
+| 12 | [마이크로커널 아키텍처 스타일](https://github.com/danmooozi/software-architecture/blob/main/ch12_마이크로커널_아키텍처_스타일/ch12_eden.md) | 24.11.05 | 김영호 |
+| 13 | [서비스 기반 아키텍처 스타일](https://github.com/danmooozi/software-architecture/blob/main/ch13_서비스_기반_아키텍처_스타일/ch13_lia.md) | 24.11.12 | 오시연 |
+| 14 | [이벤트 기반 아키텍처 스타일](https://github.com/danmooozi/software-architecture/blob/main/ch14_이벤트_기반_아키텍처_스타일/ch14_mono.md) | 24.11.12 | 김원호 |

ch11_파이프라인_아키텍처_스타일/ch11_lia.md

@@ -0,0 +1,86 @@
+# CHAPTER 11 파이프라인 아키텍처 스타일
+> 파이프라인 아키텍처는 소프트웨어 아키텍처에서 끊임없이 등장하는 기본적인 아키텍처 스타일임. 개발자와 아키텍트가 기능을 개별 파트로 분리하기로 결저정하는 순간부터 이 패턴이 수반됨.
+대부분의 개발자는 이 아키텍처를 Bash나 Zsh 같은 유직스 터미널 쉘 언어의 기초 원리임을 알고 있음. 
+## 11.1 토폴로지
+파이프라인 아키텍처는 다수의 파이프와 필터로 구성됨
+
+![alt text](ch11_lia/image.png)
+
+파이프와 필터는 특정한 방식으로 조정되며, 보통 필터 간 단방향 통신은 점대점 방식으로 구성함
+
+### 11.1.1 파이프
+
+: 한 소스에서 입력을 받아 다른 소스로 출력을 내는, 필터 간 통신 채널
+
+- 성능상 이유로 보통 단방향, 점대점 방식으로 구성함.
+- 파이프를 오가는 페이로드의 데이터는 어떤 포맷이라도 가능하지만, 아키텍트는 고성능에 유리한 적은 양의 데이터를 선호함
+
+### 11.1.2 필터
+
+- 자기 완비형(self-contained)이고, 다른 필터와 독립적이며, 일반적으로 무상태성임.
+- 한 가지 태스크만 수행하므로 복합 태스크는 여러 필터를 이어 붙여 처리하면 됨
+- 네 종류
+    1. 프로듀서
+        
+        : 시작점. 아웃바운드만 있어서 소스라고도 함
+        
+    2. 변환기
+        
+        : 입력을 받아 필요시 일부 또는 전체 데이터를 변환한 후, 그 결과를 아웃바운드 파이프로 전달함. 함수형 프로그래밍의 맵.
+        
+    3. 테스터
+        - 입력을 받아 하나 이상의 기준에 대해 테스트를 하고 그 결과에 따라 필요시 결과를 생상함. 함수형 프로그래밍의 리듀스
+    4. 컨슈머
+        - 파이프라인 흐름의 종착역
+        - 파이프라인 프로세스의 최종 결과를 데이터베이스에 저장하거나 유저 인터페이스 화면에 표시함
+- 각 파이프와 필터는 단방향이고 단순해서 얼마든지 조합할 수 있음
+
+## 11.2 예제
+전자 데이터 교환(EDI) 도구
+
+; 파이프와 필터로 한 종류의 문서를 다른 종류의 문서로 변환함
+
+ETL 도구
+
+; 다른 데이터베이스나 데이터소스로 데이터를 변환하여 플릴 때 파이프라인 아키텍처를 이용함
+
+**다양한 서비스의 텔레메트리(원격 계측) 정보를 아파치 카프카에 스트리밍하는 예제**
+
+![alt text](ch11_lia/11-2.png)
+
+- 서비스 정보 캡처(프로듀서) 필터는 카프카 토픽을 구독하여 서비스 정보를 받아 이 데이터를 지속 시간 필터라는 테스터 필터에 보내고, 카프카에서 받아온 데이터가 서비스 요청 지속 시간(밀리초)과 연관되어있는지 판단함
+- 서비스 정보 필터 - 토픽에 연결하는 일만 신경 씀
+- 지속 시간 필터 - 데이터 검증 후 필요시 다음 파이프에 보내는 작업만 함
+    - 서비스 요청 지속 시간과 관련 있으면 지속 시간 계산기(변환기) 필터로 전달
+    - 관련이 없으면 가동 시간 필터(테스터)로 전달, 가동 시간 메트릭과 관련 있는지 체크
+        - 관련이 없으면, 파이프라인 즉시 종료
+        - 관련이 있으면, 가동 시간 계산기(변환기) 필터로 보내 해당 서비스의 가동 시간 메트릭을 계산
+    - 두 변환기는 수정된 데이터를 데이터베이스 출력 컨슈머로 보내 몽고DB에 저장함
+
+→ 파이프라인 아키텍처의 확장성을 잘 나타냄. 데이터베이스 접속 대기 시간 처럼 새로 수집된 메트릭을 데이터베이스에 전달해야 할 경우, 간단히 가동 시간 필터 다음에 테스트 필터를 하나 더 추가하면 됨.
+
+## 11.3 아키텍처 특성 등급
+![alt text](ch11_lia/11-3.png)
+
+- 파이프라인 아키텍처 스타일은 애플리케이션 로직을 필터 타입(프로듀서, 테스터, 변환기, 컨슈머)에 따라 나누는, 기술 분할 아키텍처임.
+- 보통 모놀리식 형태로 구현/배포하므로 아키텍처 퀀텀은 언제나 1
+- 주요 강점
+    - 전체 비용 및 단순성
+        
+        : 모놀리식에 가깝기 때문에 분산 아키텍처 스타일에 수반되는 복잡도가 없고, 단순해서 알기 쉽고 구축 및 유지보수 비용도 적게 듬. 
+        
+- 배포성, 시험성
+    
+    : 필터를 통한 모듈성이 더 우수하므로 레이어드 아키텍처보다 조금 나음
+    
+- 신뢰성
+    
+    : 레이어드 아키텍처와 마찬가지로 분산 아키텍처에서 자주 목격되는 네트워크 트래픽, 대역폭 부족, 레이턴시 탓
+    
+- 탄력성, 확장성
+    
+    : 모놀리식 배포. 확장을 하려면 대부분 멀티스레딩, 내부 메시징을 비롯해 갖가지 병렬 처리 프랙티스와 기법이 동원됨. 
+    
+- 내고장성
+    
+    : 모놀리식 배포 탓에, 또 부족한 아키텍처 모듈성 때문에 내고장성도 별로. 어느 한 작은 파트에 OOM이 발생하면 애플리케이션 전체적으로 영향을 받고 충돌이 발생함

ch11_파이프라인_아키텍처_스타일/ch11_lia/11-2.png

@@ -0,0 +1,119 @@
+# 11. 파이프라인 아키텍처 스타일
+
+- 기본적인 아키텍처 스타일
+- 개발자와 아키텍트가 기능을 개별 파트로 분리하기로 결정하는 순간부터 이 패턴이 수반
+- Bash나 Zsh 같은 유닉스 터미널 쉘 언어의 기초 원리
+- 함수형 언어 개발자는 언어 구조와 이 아키텍처 요소가 유사하다고 생각
+- 맵리듀스 프로그래밍 모델을 응용한 많은 도구가 이 기본 토폴로지를 따른다.
+    - MapReduce: 대규모 데이터 처리를 위한 프로그래밍 모델로, 'Map' 단계와 'Reduce' 단계로 구성.
+    - Map 단계 : 데이터를 변환하는 역할을 하며, 이는 파이프라인의 변환기(transformer) 필터와 유사.
+    - Reduce 단계 : 변환된 데이터를 집계하는 역할을 하며, 이는 파이프라인의 테스터(tester) 필터와 유사한 개념.
+
+## 11.1 토폴로지
+
+- 파이프라인 아키텍처는 다수의 **파이프**와 **필터**로 구성.
+    <img width="671" alt="스크린샷 2024-11-03 오후 8 40 31" src="https://github.com/user-attachments/assets/936b628b-5241-4af4-89bf-b8372348e8db">
+
+- 단방향 통신
+- 점대점 방식
+    - 두 노드 간에 직접적이고 독립적으로 연결을 제공하는 네트워크 구성 방식
+
+### 11.1.1 파이프
+
+- 한 소스에서 입력을 받아 다른 소스로 출력을 내는, 필터 간 통신 채널
+- 파이프는 성능상 이유로 보통 단방향, 점대점 방식으로 구성
+- 페이로드의 데이터는 어떤 포맷이라도 가능, 아키텍트는 고성능에 유리한 적은 양의 데이터를 선호
+
+### 11.1.2 필터
+
+- 자기 완비형
+    - 독립적으로 작동 가능
+- 일반적으로 무상태성
+    - 이전의 작업의 결과나 상태를 저장하지 않는다.
+    - 이전 작업의 영향을 받지 않는다.
+
+### 필터의 네 가지 종류
+
+**프로듀서**
+
+- 프로세스의 시작점
+- 아웃바운드만 있어서 소스라고도 불린다.
+    - 들어오는 트래픽 없고 나가는 트래픽만 있다.
+
+**변환기**
+
+- 입력을 받아 데이터 변환
+- 그 결과를 아웃바운드 파이프로 전달
+- 맵
+
+**테스터**
+
+- 입력을 받아 하나 이상의 기준에 대해 테스트
+- 결과에 따라 필요시 결과를 생산
+- 리듀스
+
+**컨슈머**
+
+- 파이프라인 흐름의 종착역
+- 프로세스의 최종 결과를 데이터베이스에 저장하거나 유저 인터페이스 화면에 표시
+
+**예제**
+
+- 어떤 텍스트 파일을 일고 가장 출현 빈도가 높은 단어 n개를 찾아 빈도 순으로 정렬한 결과를 출력하는 프로그램
+
+```jsx
+tr -cs A-Za-z ‘\n tr A-Z a-z |
+sort |
+uniq -c |
+sort -rn | sed ${l}q
+```
+
+- **`tr -cs A-Za-z '\n'`**: `tr` 명령어는 텍스트를 변환하는 데 사용됩니다. `cs` 옵션은 문자 세트를 반전시켜 일치하지 않는 문자(공백이나 특수 문자 등)를 줄 바꿈(`\n`) 문자로 변환합니다. 여기서는 알파벳(A-Z, a-z) 이외의 모든 문자를 줄 바꿈으로 대체하여 단어들을 분리합니다.
+- **`tr A-Z a-z`**: 대문자를 소문자로 변환하여 대소문자 구분 없이 단어를 비교할 수 있도록 만듭니다.
+- **`sort`**: 텍스트의 모든 줄을 알파벳 순서로 정렬합니다. 이때 각 줄은 하나의 단어로 구성됩니다.
+- **`uniq -c`**: 정렬된 단어 리스트에서 중복되는 단어를 카운팅합니다. `c` 옵션은 각 단어의 빈도 수를 함께 출력합니다.
+- **`sort -rn`**: `uniq -c`로 얻은 빈도 수를 내림차순(-r)으로 정렬하여, 가장 빈도수가 높은 단어가 먼저 나오도록 합니다. `n` 옵션은 숫자로 정렬하게 만듭니다.
+- **`sed ${l}q`**: `sed`는 스트림 편집기로 텍스트를 변형할 수 있는 명령어입니다. `${l}`은 스크립트에 정의된 변수로, 출력할 단어의 개수를 지정합니다. 예를 들어 `l=10`이라면 상위 10개의 단어만 출력됩니다. `q`는 해당 숫자만큼 출력 후 종료하게 만듭니다.
+
+## 11.2 예제
+
+- EDI
+    - 전자 데이터 교환 도구
+    - 파이프와 필터로 한 종류의 문서를 다른 종류의 문서로 변환
+- ETL
+    - 추출, 변환, 적재 도구
+    - 다른 데이터베이스나 데이터소스로 데이터를 변환
+- **아파치 카멜**
+    - 여러 시스템 간에 데이터를 쉽게 전달하고 통합하는 역할
+- **오케스트레이터**
+    - 워크플로우와 프로세스를 관리
+    - 각각의 서비스가 어느 순서로 호출되어야 하는지, 어떤 데이터가 필요하고 어디로 보내져야 하는지 등을 결정
+- **중재자**
+    - 각각의 서비스가 직접적으로 서로를 호출하지 않고, 중재자를 통해 데이터를 주고 받도록 하는 구조
+    
+
+### 다양한 서비스의 텔레메트리 정보를 아파치 카프카에 스트리밍하는 예제
+
+- 텔레메트리 정보
+    - 원격 시스템에서 수집한 상태, 성능, 이벤트 관련 데이터를 의미
+<img width="703" alt="스크린샷 2024-11-03 오후 8 40 44" src="https://github.com/user-attachments/assets/75afc817-fca0-4864-956c-12ca5a09d6d4">
+
+1. 서비스 정보 캡쳐
+- 카프카 토픽을 구독하여 서비스 정보를 받아 이 데이터를 지속 시간 필터라는 테스터 필터에 보내고 카프카에서 받아온 데이터가 서비스 요청 지속 시간과 연관되어 있는지 판단.
+- 카프카 토픽에 연결하는 일만 신경을 쓴다.
+
+2. 지속 시간 필터
+- 데이터 검증 후 필요시 다음 파이프에 보내는 작업만 한다.
+- 만약 데이터가 서비스 요청 지속 시간과 관련이 있으면 지속 시간 필터는 이 데이터를 지속 시간 계산기 필터로 전달하고, 관련이 없으면 가동 시간 필터로 보내 데이터가 가동 시간 메트릭과 관련 있는지 체크
+- 만약 없으면 해당 데이터는 이 특정한 처리 흐름에 아무 쓸모가 없으므로 파이프라인은 즉시 종료
+- 반대로, 관련이 있으면, 가동 시간 계산기 필터로 보내 해당 서비스의 가동 시간 메트릭을 계산
+
+3. 변환기
+- 두 변환기는 수정된 데이터를 데이터베이스 출력 컨슈머로 보내 몽고 DB에 저장.
+
+## 11.3 아키텍처 특성 등급
+
+- 파이프라인 아키텍처 스타일은 애플리케이션 로직을 필터 타입에 따라 나누는, 기술 분할 아키텍처
+- 보통 모놀리식 형태로 구현/배포하므로 아키텍처 퀀텀은 언제나 1
+    - 모놀리식 배포 탓에, 또 부족한 아키텍처 모듈성 때문에 내고장성도 별로
+        - 어느 한 작은 파트에 OOM이 발생하면 애플리케이션 전체적으로 영향을 받고 충돌이 발생

ch11_파이프라인_아키텍처_스타일/ch11_lia/11-3.png

@@ -0,0 +1,47 @@
+# 11.파이프라인 아키텍처 스타일
+
+힘수형 언어 개발자는 언어 구조와 이 아키텍처 요소가 유사하다고 생각할 것입니다.
+
+## 11.1 토폴로지
+
+![image](https://github.com/user-attachments/assets/34054ad5-c0fb-4861-9b85-a151849e780d)
+
+파이프와 필터는 특정한 방식으로 조정되며, 보통 필터 간 단방향 통신은 점대점 방식으로 구성합니다.
+
+### 11.1.1 파이프
+
+파이프는 한 소스에서 입력을 받아 다른 소스로 출력을 내는, 필터 간 통신 채널입니다. 파이프는 성능상 이유로 보통 단방향, 점대점 방식으로 구성합니다. 파이프를 오가는 페이로드의 데이터는 어떤 포맷이라도 가능하지만,아키텍트는 고성능에 유리한 적은 양의 데이터를 선호합니다.
+
+### **11.1.2** 필터
+
+필터는 자기 완비형(다른 서비스나 모듈 등을 호출하지 않아도 스스로 동작하는 성질) 다른 필터와 독립적이며 일반적으로 무상태성입니다. 
+
+파이프라인 아키텍처 스타일에서 필터는 다음 네 가지 종류가 있습니다.
+
+- 프로듀서
+    - 프로세스의 시작점입니다. 아웃바운드만 있습니다.
+- 변환기
+    - 입력을 받아 필요시 일부 또는 전체 데이터를 변환한 후, 그 결과를 아웃바운드 파이프로 전달합니다. 함수형 프로그래밍의 열혈팬들은 이 기능을 맵map이라고 부릅니다
+- 테스터
+    - 입력을 받아 하나 이상의 기준에 대해 테스트를 하고 그 결과에 따라 필요시 결과를 생산합니다. 함수형 프로그래머는 이 기능을 리듀스라고 부릅니다
+- 컨슈머
+    - 파이프라인 흐름의 종착역입니다. 컨슈머는 파이프라인 프로세스의 최종 결과를 데이터베이스에 저장하거나 유저 인터페이스 화면에 표시합니다.
+
+## 11.2 예제
+
+파이프라인 아키텍처 패턴은 다양한 애플리케이션, 특히 간단한 단방향 처리 태스크에서 흔히 볼 수 있습니다.
+
+![image](https://github.com/user-attachments/assets/cfb4b30d-f2c4-4569-8684-898ee6ad0ffe)
+
+
+서로 다른 종류의 데이터를 카프카에 스트리밍 처리하는 파이프라인 아키텍처 스타일의 용례를 눈 여겨 보세요.
+
+## **11.3** 아키텍처 특성 등급
+
+이 아키텍처의 주요 강점은 모듈성과 결부된 전체 비용 및 단순성입니다.
+
+이 아키텍처는 원래 모놀리식에 가깝기 때문에 분산 아키텍처 스타일에 수반되는 복잡도가 없고 단순해서 알기 쉽고 구축 및 유지보수 비용도 비교적 적게 듭니다.
+
+이 아키텍처의 탄력성과 확장성은 모놀리식 배포 때문에 점수가 낮습니다.
+
+모놀리식 내부 기능 중에는 더러 확장 가능한 것들도 있지만,확장을 하려면 대부분 멀티스레딩, 내부 메시징을 비롯해 이 아키텍처와는 안 어울리는 갖가지 병렬 처리 프랙티스와 기법이 동원됩니다.

ch11_파이프라인_아키텍처_스타일/ch11_lia/image.png

@@ -0,0 +1,26 @@
+# CHAPTER 11 파이프라인 아키텍처 스타일
+
+## 11.1 토폴로지
+
+파이프라인 아키텍처는 다수의 파이프와 필터로 구성됩니다. 파이프와 필터는 특정한 방식으로 조정되며, 보통 필터 간 단방향 통신은 점대점 방식으로 구성합니다.
+
+### 11.1.1 파이프
+
+파이프는 한 소스에서 입력을 받아 다른 소스로 출력을 내는, 필터 간 통신 채널입니다. 파이프는 성능상 이유로 보통 단방향, 점대점 방식으로 구성합니다.
+
+### 11.1.2 필터
+
+필터는 자기 완비형이고 다른 필터와 독립적이며, 일반적으로 무상태성입니다. 필터는 한 가지 태스크만 수행하므로 복합 태스크는 여러 필터를 이어 붙여 처리하면 됩니다.
+
+* 프로듀서: 프로세스의 시작점입니다. 아웃바운드만 있어서 소스라고도 합니다.
+* 변환기: 입력을 받아 필요시 일부 또는 전체 데이터를 변환한 후 그 결과를 아웃바운드 파이프로 전달합니다. 맵이라고도 합니다. 
+* 테스터: 입력을 받아 하나 이상의 기준에 대해 테스트를 하고 그 결과에 따라 필요시 결과를 생산합니다. 리듀스라고 부릅니다.
+* 컨슈머: 파이프라인 흐름의 종착역입니다. 최종 결과를 데이터베이스에 저장하거나 유저 인터페이스 화면에 표시합니다.
+
+## 11.2 예제
+
+## 11.3 아키텍처 특성 등급
+
+배포성, 탄력성, 진화성, 내고장성, 확장성 1!
+
+전체비용, 단순성 5