Merge branch 'Meet-Coder-Study:main' into main

Author: hokyung-lee

11장/[6주차]_11장_파이프라인_아키텍쳐_스타일_황준호.md

@@ -0,0 +1,45 @@
+### Chapter 11 파이프라인 아키텍쳐 스타일
+
+<img src="../images/pipeline_architecture.jpeg" alt="파이프라인 아키텍쳐" style="zoom:40%;" />
+
+- 파이프
+
+  - 한 소스에서 입력을 받아 다른 소스로 출력을 내는, 필터간 통신 채널
+  - 성능 상 이유로 보통 단방향, 점대점 방식
+
+- 필터
+
+  - 자기 완비형(다른 서비스 호출x), 다른 필터와 독립적, 일반적으로 무상태성(상태를 보관x)
+  - 한 가지 태스크만 수행한다. 복합 태스크는 여러 필터를 붙여서 처리함
+  - 필터의 종류
+    1. 프로듀서
+       - 프로세스의 시작점
+       - 아웃바운드만 있어서 소스라고도 함 (들어오는 트래픽은 없고 나가는 트래픽만 있기 때문)
+    2. 변환기
+       - 입력을 받아 변환 후 아웃바운드 파이프로 전달
+       - 함수형 프로그래밍에서의 `map`
+    3. 테스터
+       - 입력을 받아 하나 이상의 기준에 대해 테스트를 하고 필요시 결과 생산
+       - 함수형 프로그래밍에서의 `reduce`
+    4. 컨슈머
+       - 프로세스의 끝
+       - 파이프라인 최종 결과를 데이터베이스에 저장하거나 유저 인터페이스 화면에 표시
+
+- 예시
+
+  - 전자 데이터 교환 도구, ETL(추출, 변환, 적재)도구, 아파치 카멜 등에서 쓰임
+
+  - 다양한 서비스의 원격 계측 정보를 카프카에 스트리밍하는 예제
+
+    <img src="../images/pipeline_architecture_example.jpeg" alt="파이프라인 아키텍쳐 예" style="zoom:40%;" />
+
+    - 이 예제는 파이프라인 아키텍쳐의 확장성을 잘 보여줌
+    - 데이터베이스 접속 대기시간을 데이터베이스에 전달해야 할 경우 가동시간 필터 다음에 테스트 필터를 하나 추가하면 된다
+
+- 파이프라인 아키텍쳐의 아키텍쳐 특성 등급
+
+  - 전체 비용, 단순성 :+1: : 모놀리식에 가깝고 필터간에 독립적이기 때문에 분산 아키텍쳐에 비해 단순하고, 유지보수 비용도 적게 든다.
+  - 배포성, 시험성 😐 : 간단한 변경에도 전체적으로 다시 배포해야함. 하지만 필터를 통한 모듈성이 더 우수하므로 레이어드 아키텍쳐보다는 조금 나음
+  - 신뢰성 😐 : 분산 아키텍쳐에 비해 네트워크 트래픽, 대역폭, 레이턴시 문제는 덜함
+  - 탄력성, 확장성 :-1: : 모놀리식 배포 때문에
+  - 내고장성 :-1: : 모놀리식 배포 때문, 또 부족한 모듈성 때문. 어느 파트에 메모리 부족이 발생하면 어플리케이션 전체적으로 영향을 받음

12장/12-마이크로커널 아키텍터 스타일.md

@@ -0,0 +1,51 @@
+> [소프트웨어 아키텍처 101](http://www.yes24.com/Product/Goods/104491433)
+
+# 마이크로커널 아키텍터 스타일
+
+이미 수십 년 전에 만들어진 마이크로커널 아키텍처는 오늘날에도 널리 쓰이고 있습니다. 이 아키텍처 스타일은 단일 모놀리식 배포 단위 패키징해서 다운로드 및 설치가 가능하며, 보통 고객 사이트에서 서드파티 제품으로 설치되는 제품 기반 애플리케이션에 적합하며, 비제품 고객 비지니스 애플리케이션에서도 많이 사용됩니다.
+
+## 토폴로지
+![](https://raw.githubusercontent.com/cheese10yun/TIL/master//assets/img-101.png)
+
+마크로커널 아키텍서 스타일은 코어 시스템과 플러그인 컴포넌트 라는 두 가지 아키텍처 요소로 구성된 비교적 단순한 모널리식 입니다. 애플리케이션 로직은 독립적인 플러그인 컴포넌트와 기본 코어 시스템에 골고루 분산되어 확작성, 적응성, 애플리케이션 기능 분리, 커스텀 처리 등을 수행합니다.
+
+> Comment
+> 
+> 마이크로커널 아키텍처라는 것이 코어 시스템과 컴포넌트가 핵심으로 보인다. 일반적인 마이크로서비스와 마이크로커널과는 상당히 다른 것으로 보여지며 마이크로서비스 아키텍처는 분산 환경에서의 시스템의 유기적인 조화와 그에 따른 안전성에 대한 부분으로 이해하고 있다.
+
+### 코어 시스템
+이클립스가 좋은 예입니다. 이클립스 코어 시스템은 파일을 열고, 텍스트를 고치고, 다시 파일을 저장할는 기본적인 텍스트 에디터에 불과합니다. 플러그인을 추가해야 비로소 쓸 만한 제품이 되죠. 그러나 다른 관점에서 바라보면, 코어 시스템은 커스텀 처리가 거의/전혀 필요 없는 애플리케이션을 관통하는 정상 경로 라고 정의할 수 있습니다. 코어 시스템의 순한 복잡도를 없애고 별도의 플러그인 컴포넌트를 장차갛면 확장성, 유지보수성은 물론 시험성도 좋아집니다.
+
+중략..
+
+예를 들어 Payment Processing이 코어 시스템을 나타내는 도메인이라면, 결제 도메인에 특정한 각 결제 수단(신용카드, 페이팔, 선불 카드. 기프트 카드 등)이 플러그인 컴포넌트가 되겠죠. 어떤 경우에도 전체 모놀리스 애플리케이션은 하나의 데이터베이스를 공유하는 것이 보통 입니다.
+
+![](https://raw.githubusercontent.com/cheese10yun/TIL/master//assets/img_101_2.jpg)
+
+코어 시스템 프리젠테이션 레이어는 코어 시스템에 내장하거나 별도의 UI로 구현하고 코어 시스템은 백엔드 서비스를 제공합니다.
+
+![](https://raw.githubusercontent.com/cheese10yun/TIL/master//assets/img_101_3.png)
+
+> Comment
+> 
+> 플러그인 컴포넌트 라고 하는 것으로 보아. 라이브러리 형태, Jar 형식의 공유를 말하는거 같은데. 개인적이로는 이런 패턴은 극히 싫어 한다. 일단 내부 시스템내에서 멀티 모듈성 컴포넌트 공유는 찬성하지만 코어 시스템이라는 것으로 하고 외부 서비스에게 이런 형식으로 공유하는 것은 반대하며, 내가 의사 결정권이 있는 경우 이런 시스템을 절대 택하지 않을거 같다. 내부 시스템 말고 외부 시스템, 외부 고객사 들에게 전달해주는 패턴으로는 적절해 보인다.
+
+### 플러그인 컴포넌트
+코어 시스템은 어떤 플러그인을 사용할 수 있는지, 그 플러그인을 가져오려면 어떻게 해야 하는지 알고 있어야 합니다. 가장 일반적인 구현 방법은 플러그인 레지스트리를 경우하는 것입니다. 이 레지스트리에는 플러그인 명칭, 데이터 계약, 세부 원격 엑세스 프로토컬 등 각 플러그인 모듈에 관한 정보가 있습니다.
+
+> Comment
+> 
+> 어떤 부분을 말하는건지 잘 이해는 되지 않지만 레지스트리 등록을 하는 넥서스나, 도커 허브 같은 것을 이야기하는 것으로 추청된다.
+
+## 계약
+플러그인 컴포넌트와 코어 시스템 간의 계약은 보통 플러그인 컴포넌트의 도메인 단위로 표준화되어 있고, 플러그인 컴포넌트가 수행하는 기능 및 입출력 데이터는 계약에 명시되어 있습니다. 서드파티 회사가 개발한 플러그인 컴포넌트의 계약을 어려분들 마음대로 바꿀 수 없을 떄에는 보통 커스텀 계약을 사용하며, 일반적인 코어 시스템이 각 플로그인별 코드를 필요로 하지 않도록 플러그인 계약과 여러분이 정한 표준 계약 간의 어댑터를 만듭니다.
+
+> Comment
+> 
+> 코어 시스템과, 그 하위의 플러그인 컴포넌의 간에 서로의 역활과 챔임에 대한 것으로 보인다. 그런데 설명이 이게 적절한지는 모르겠다...
+
+## 실제 용례
+이클립스 IDE, PMD, JIRA, Jenkins 등 많은 소프트웨어 개발/릴리스 도구가 마이크로 커널 아키텍처를 사용해서 개밸됐습니다.
+
+> Comment
+> JIRA 같은 도구에는 적잡하다고 생각한다. 대략적으로 정리했을 때 외부(고객사) 에게 특정 서비스를 제공(설치형) 하거나, 외부(고객사) 웹페이지에 특정 기능을 제공하는 상담 쳇봇, 결제 모듈 등등 이런 서비스에는 적합한 모듈로 보이지만 실제 일반적인 서비스 업에서는 이런 패턴은 적절해 보이지 않는다.

13장/empty.txt

@@ -0,0 +1,58 @@
+# 특징
+- 마이크로 서비스 아키텍처 스타일의 일종
+- 유연, 실용적
+- 비교적 덜 복잡하고 비용이 적음
+- 중앙 공유 데이터베이스를 사용
+
+## 토폴로지
+- 각각 때로 배포된 유저 인터페이스와 원격 서비스, 모놀리스 데이터베이스로 이루어진 대규모 분산 레이어 구조
+- 프로토콜은 일반적으로 REST 가장 많이 사용하나, 메시징, RPC, SOAP 도 사용가능
+- 유저 인터페이스는 대개 서비스 로케이터 패턴에 따라 유저 인터페이스, API 게이트웨이, 프록시에 내장된 유저 인터페이스를 직접 엑세스
+  - 서비스 로케이터 패턴이란?
+  - 런타임에 종속성을 주입
+  - ![서비스 로케이터 패턴](https://www.oracle.com/ocom/groups/public/@otn/documents/digitalasset/149540.jpg)
+  - 출처: https://www.oracle.com/java/technologies/service-locator.html
+
+## 토폴로지 변형
+- 다양한 변형이 존재
+- 유저 페이스가 1개 또는 여러개 가능(여러 도메인을 묶어서 유저인터페이스를 만들거나 하나의 도메인당 유저 인터페이스를 둘 수도 있음)
+- ![유저 인터페이스](./유저인터페이스.jpg) 
+  - (출처: 책 217쪽)
+- **각 데이터베이스에 있는 도메인 데이터를 다른 도메인 서비스가 필요하지 않도록 설계** 하는 것이 중요!
+--> 서비스간 상호 통신을 방지하고 데이터간 중복을 방지 가능
+- 리버스 프록시나 게이트웨이로 구성된 API 레이어를 유저 인터페이스와 서비스 사이에 둘 수도 있음
+
+## 서비스 설계 및 세분도
+- 도메인 서비스를 레이어드 아키텍처 스타일로 설계하는 것이 일반적 (API 퍼사드 레이어, 비지니스 레이어, 퍼시스턴스 레이어)
+- 서브 도메인을 이용해서 각 도메인 서비스를 분할하기도 함
+- 서비스 기반 아키텍처
+  - 내부 클래스 수준의 오케스트레이션
+  - 커밋과 롤백이 어느정도 수반되는 ACID 데이터베이스 트랜잭션을 지원
+  - 코드가 많이 배포될수록 문제 가능성(다소 큰 단위의 도메인 서비스 구성이므로)
+- 마이크로서비스 아키텍처
+  - 외부 서비스의 오케스트레이션
+  - BASE 트랜잭션(Base-Availability, Soft state, Eventual consistency)
+  - 각 서비스가 한가지 역할을 수행하므로 수정에 따른 다른 기능의 변경 가능성이 적음
+
+## 데이터베이스 분할
+- 서비스 기반 아키텍처에서 커스텀 공유 라이브러리에는
+  - 데이터베이스 테이블 스키마를 나타낸 공유 클래스 파일(엔티티 객체) 
+  - SQL 코드
+  - => 테이블이 하나만 변경되도 전체를 배포해야하고 전체 서비스에 영향을 줌
+- 데이터베이스의 변경 영향도와 리스크 낮추기
+  - 데이터베이스를 **논리적으로 분할**하고, 연합 공유 라이브러리를 통해 명시
+  - => 해당 공유 라이브러리를 사용하는 서비스에만 영향
+- 서비스 기반 아키텍처에서는 데이터베이스 변경을 통제하기 위해 데이터 도메인을 올바르게 정의, 관리하고 데이터베이스는 가급적 논리적으로 잘게 나누는 것이 좋다!!
+
+## 아키텍처 특성
+- 서비스 기반 아키텍처는 **도메인 위주로 구성**된 아키텍처!
+- 도메인 주도 설계와 잘 맞음
+- 가장 구현하기 쉽고 비용면에서도 효율적인 분산 아키텍처
+
+- 도메인 별로 테스트 가능 및 배포 가능
+- 도메인 별로 개별적인 확장성이 가능함 => 확장성
+- 내부 테이터(내부 네트워크망에서만 접속)와 기능을 외부 작업과 분리된 별도의 네트워크 영역에서 접근 가능 => 보안성
+- 도메인 서비스가 굵직한 편이라 분산 트랜젝션이 적음 => (다른 분산 아키텍처에 비해) 신뢰성이 높음, 정교한 조율이 덜 필요함
+- 장점: 민첩성, 시험성, 배포성, 확장성, 내고장성, 보안, 신뢰성
+- 퀀텀은 1개 또는 그 이상(예시: 외부에서 고객상대 퀀텀, 내부 운영 퀀텀 => 2개)
+- 서비스를 나누는 단위가 비교적 큰 편이므로 마이크로 서비스보다 확장성과 탄력성은 다소 떨어질 수 있음(별 2~3개)