재권 7주차 ch15, ch16 (#40)

ch15/jaekwon.md

@@ -0,0 +1,94 @@
+## 15장. 공간 기반 아키텍처 스타일
+
+> 처음에는 공간, 데이터베이스 분할 얘기가 나오길래 지리적으로 분산된 데이터베이스 아키텍처 스타일을 얘기하는가 싶었는데...
+얘기하고자 하는 것은 이런 것들인듯.. 처음보는 아키텍처!!
+인메모리 데이터베이스 + 메모리 그리드
+데이터 라이터/리더를 통한 비동기 방식의 데이터베이스 접근
+HPA
+
+동시 유저 부하 수가 많은 + 동시 유저수가 극단적으로 가변적, 탄력적인 서비스에 적합
+
+> 새로운 용어들이 등장하는데, 왜 이런 용어들을 써서 어렵게 설명하는지 모르겠음. 역사 속 용어들을 그대로 쓴게 아닐까..
+
+토폴로지
+* 처리 장치
+    * 애플리케이션 로직
+    * 인메모리 그리드 & 데이터 복제 엔진
+        * 헤이즐캐스트, 아파치 이그나이트, 오라클 코히어런스
+* 가상 미들웨어
+    * 메시징 그리드
+        * 요청을 전달 + 세션 관리 + 로드 밸런서
+        * HA proxy, Nginx, Apache WebServer
+    * 데이터 그리드
+        * 아마도 NAM Network Attacted Memory를 얘기하는듯
+        * > 이런식의 구성을 요즘에도 쓰는 곳이 있나? 이런게 있었다..정도로 알고있으면 되려나
+    * 처리 그리드
+        * 요청을 오케스트레이션
+            * ex. 주문과 결제 요청의 순서를 조정
+    * 배포 관리자
+        * 동적으로 처리 장치를 늘리고 줄이는 역할
+        * k8s HPA
+* 데이터 펌프
+    * 공간 기반 아키텍처에서는 데이터베이스에 직접 데이터를 쓰고, 읽지 않습니다. 데이터 펌프를 통해서만 접근
+    * 때문에 항상 비동기로 동작하고, 메모리 캐시와 데이터베이스의 최종적 일관성을 실현하는 역할
+    * 데이터 라이터
+        * 도메인 기반. 도메인마다 데이터 라이터를 가진다
+        * 처리 장치 기준. 처리 장치마다 데이터 라이터를 가진다
+    * 데이터 리더
+        * 대부분의 데이터는 캐시에서 읽기 때문에 데이터 리더를 통해 데이터베이스에서 읽어가는 경우는 장애 상황 외에는 없다
+        * 도메인 기반도 가능하지만 보통은 처리 장치마다 1개씩
+
+등장 개념
+* grid computing: 여러 컴퓨터의 자원을 네트워크를 통해 연결하여 하나의 큰 컴퓨팅 리소스처럼 사용하는 기술을 의미
+* NAM: JVM 인스턴스들끼리 데이터, 메모리를 공유할 수가 없었던 문제가 있었다. DB나 파일로 서로 공유하기에는 비용이 너무 많이 들었고..그래서 나온게 서로 간의 메모리를 하나의 거대한 메모리로 묶어서 사용하는 NAM이란 컨셉. 모든 인스턴스에 데이터가 공유되고, 증설이 필요할때 메모리 수평 확장이 가능하다.
+
+![image](assets/image23.png){width="800" height="500"}
+
+
+### 15.2 데이터 충돌
+
+서비스 인스턴스에 캐시 업데이트가 빈번하게 발생하면 캐시 충돌이 발생할 수 있다
+(모든 처리 장치들이 각자의 캐시를 업데이트할 수 있다!)
+
+캐시 충돌률을 계산하는 공식들이 나온다..책을 참고
+
+### 15.3 클라우드 대 온프레미스 구현
+
+처리장치 + 가상 미들웨어 + 데이터 펌프는 클라우드에 구성
+데이터베이스 + 데이터 리더,라이터는 온프렘에 구성
+
+이런 하이브리드 구성도 가능
+
+### 15.4 복제 캐시 대 분산 캐시
+
+인메모리 그리드를 사용하기 때문에 데이터는 비동기로 서로 복제된다 (복제 캐시)
+복제 캐시는 공간 기반 아키텍처의 표준 캐시 모델이지만
+캐시의 크기가 엄청나게 크거나(100MB 이상?) 너무 빈번하게 업데이트가 발생하면 쓰기 어렵다
+
+그래서 보통은 외부에 중앙 캐시 서버를 둔다 (분산 캐시)
+위의 문제들을 해결할 수 있지만, 캐시 서버가 외부에 있기 때문에 네트워크 레이턴시가 발생하고, 캐시 서버 down시에 장애가 발생할 수 있다
+active-standby 구성에서 standby 서버가 뜰때의 데이터 불일치도 발생 가능
+
+캐시 크기와 업데이트의 빈도를 보고 결정
+
+### 15.5 니어 캐시
+
+분산 캐시와 인메모리 데이터 그래드의 하이브리드 버전
+
+분산 캐시를 full backing cache
+각 처리 장치의 인메모리에 있는 캐시를 front cache
+라고 한다고 한다
+
+추천 되지 않는 방법이라고 하니 개념만 알아두자
+
+### 15.6 예시
+
+* 콘서트 티켓 판매 시스템
+* 온라인 경매 시스템
+
+둘다 급증하는 트래픽을 잘 처리할 수 있고(탄력성)
+비동기 기반으로 요청을 빠르게 처리할 수 있다(성능)
+
+> 근데 오히려 이런 서비스야말로 캐시 충돌이나 데이터 일관성이 중요한거 아닌가?
+
+![image](assets/image24.png){width="800" height="600"}

ch16/jaekwon.md

@@ -0,0 +1,49 @@
+## 16장. 오케스트레이션 기반 서비스 지향 아키텍처 스타일
+
+서비스 기반 아키텍처는 분산 아키텍처였다
+거기에 오케스트레이션 해주는 레이어가 추가로 생긴 것
+
+![image](assets/image25.png){width="800" height="300"}
+
+중심 철학은 '엔터프라이즈 레벨의 재사용'
+
+택소노미(Taxonomy): '분류체계'라는 뜻. 그리스어로 분류하다(taxis)와 법, 과학(nomos)이란 단어가 합쳐져 탄생
+
+토폴로지
+* 비즈니스 서비스
+    * 진입점
+    * 코드는 없고, 입력, 출력, 스키마 정보만 가지고 있다
+* 엔터프라이즈 서비스
+    * 세분화된 공유 구현체
+    * 특정 비즈니스 도메인(유저 생성, 재고 계산) 같은 원자적 행위를 구현한다. 이러한 행위들은 오케스트레이션 엔진을 통해 묶이고, 더 큰 단위의 비즈니스 서비스를 구성하는 요소가 된다
+    * 왜? '재사용'을 잘하기 위해서 이렇게 엔터프라이즈 서비스라는 개념으로 코드들을 묶은 것이다
+        * 현실 세상에서는 잘 통하지 않았다
+* 애플리케이션 서비스
+    * 모든 서비스들이 동일한 레벨의 세분화 또는 재사용이 필요한 것은 아니다. 1번만 사용할꺼라면 애플리케이션 서비스에 개발할 수 있다
+    * ex. 지리 공간 정보 조회, 이런 로직을 재사용 가능한 서비스로 구현하고 싶지 않을때
+* 인프라 서비스
+    * 모니터링, 로킹, 인증/인가
+* 오케스트레이션 엔진
+    * 비즈니스 서비스 구현체를 서로 엮어서, 트랜잭션 조정, 메시지 변환 등의 기능을 수행
+    * 비즈니스 <-> 엔터프라이즈 서비스 관계, 이 둘을 매핑하는 방법, 트랜잭션의 경계 등을 정의
+    * 콘웨이의 법칙에 따르면...이 엔진을 담당하는 팀은 계속해서 커지고 책임이 많아지고 결국 병목이 될 것이다
+    * 모든 요청은 오케스트레이션 엔진으로 흘러감. 심지어 내부 호출에서도
+
+### 16.4 재사용 그리고 커플링
+
+이 아키텍처의 주된 목표는 서비스 레벨의 재사용이다
+보험회사를 예로 들면 고객과 관련된 여러 기능들이 있다
+* 자동차 및 주택소유자 보험팀
+* 생명 보험팀
+* 상업신용 보험팀
+* 장애 보험팀
+* 상해보장 보험팀
+* 여행 보험팀
+
+여기에는 모두 '고객'이라는 개념이 포함되어있는데,
+이걸 엔터프라이즈 서비스로 모두 통합한것이다 (재사용을 위해서!)
+
+재사용은 되겠지만, 모든 팀들과 커플링되어버렸다 (마치 big ball of mud가 되었다)
+하나가 수정되면 모두 수정되어야한다
+
+![image](assets/image26.png){width="800" height="600"}