소프트웨어 아키텍처 The Hard Parts 3주차 - 이동현

2026/Fundamentals_of_Software_Architecture_2nd_Edition/donghyeon/week3.md

@@ -0,0 +1,73 @@
+# 6 ~ 7장
+
+## 논의
+
+성능 향상을 위해 서비스를 분해했는데, 네트워크 오버헤드 등의 이유로 전체 응답성이 떨어져 다시 합쳤던 경험이 있다면 공유해보면 좋을 것 같습니다.
+
+## 내용
+
+- 데이터 분해(요)인
+    - 변경 영향 범위: 테이블 변경 시 얼마나 많은 서비스가 영향을 받는가
+    - 커넥션 관리: 데이터베이스가 여러 분산 서비스와 커넥션을 맺을 수 있는가
+    - 확장성: 액세스하는 서비스 수요에 맞게 데이터베이스를 확장할 수 있는가
+    - 내고장성: 장애 및 수리 등의 사유로 가동 중단될 때 얼마나 많은 서비가 영향을 받는가
+    - 아키텍처 퀀텀: 단일 공통 데이터베이스가 바람직하지 않은 단일 아키텍처 퀀텀을 유발하는가
+    - 데이터베이스 유형 최적화: 여러 종류의 데이터베이스를 사용해 데이터를 최적화할 여지가 있는가
+- 데이터 통합(요)인
+    - 데이터 관계
+    - 데이터베이스 트랜잭션
+- 데이터 분해 과정
+    1. 데이터베이스 분석과 데이터 도메인 생성
+    2. 데이터 도메인에 테이블 할당
+    3. 데이터 도메인에 접속하는 데이터베이스 커넥션 분리
+    4. 개별 데이터베이스 서버로 스키마 이전: "백업 및 복원" or "복제"
+    5. 독립적 데이터베이스 서버로 전환
+- 데이터베이스 타입
+  | 항목 | 관계형 | 키-값 | 문서형 | 컬럼형 | 그래프 | NewSQL | 클라우드 네이티브 | 시계열 |
+  |------------------------------|:-----:|:----:|:-----:|:-----:|:----:|:-----:|:---------------:|:-----:|
+  | 학습 용이성 | 4 | 3 | 3 | 2 | 1 | 3 | 2 | 1 |
+  | 데이터 모델링 용이성 | 3 | 1 | 3 | 1 | 2 | 3 | 2 | 2 |
+  | 확장성 / 처리량 | 2 | 4 | 2 | 4 | 3 | 3 | 4 | 4 |
+  | 가용성 / 내분할성 | 1 | 4 | 3 | 4 | 3 | 3 | 3 | 2 |
+  | 일관성 | 5 | 2 | 2 | 1 | 3 | 2 | 3 | 3 |
+  | 언어 지원 / 성숙도 / 커뮤니티 | 4 | 3 | 3 | 2 | 2 | 2 | 2 | 2 |
+  | 읽기/쓰기 우선순위 | 중간 | 읽기 | 읽기 | 쓰기 | 읽기 | 중간 | 읽기 | 읽기 |
+    - 관계형: Oracle, MySQL, PostgreSQL
+    - 키-값: Redis, Amazon Dynamo DB
+    - 문서형: MongoDB, Couchbase
+    - 컬럼형: Cassandra, Amazon SimpleDB
+    - 그래프: Neo4j, Infinite Graph, Tiger Graph
+    - NewSQL: VoltDB, ClustrixDB, SimpleStore
+    - 클라우드 네이티브: Snowflake, Datomic, Redshift
+    - 시계열: InfluxDB, Amazon Timestream
+- 서비스 세분도 분해(요)인
+    - 서비스의 범위와 기능: 기능의 응집도와 컴포넌트 전체 사이즈를 고려
+    - 코드 변동성
+    - 확장성/처리량
+    - 내고장성
+    - 보안: 요구되는 보안 수준
+    - 신장성(=확장성, Extensibility): 새로운 기능을 추가하는 능력
+        - Scalability(부하에 대응하는 능력)와 같은 **확장성**이라 명확성을 위해 신장성 사용한 듯
+- 서비스 세분도 통합(요)인
+    - 데이터베이스 트랜잭션
+    - 워크플로와 코레오그래피: 기능들이 단단히 결합된 서비스들간에서 발생
+        - 과도한 IPC -> 내고장성, 성능 이슈
+        - 요청의 70%는 자체 처리가 가능하다면 서비스를 분리한 상태로 두는게 합리적
+        - 나머지 30%가 매우 빠른 응답을 요한다면 서비스를 합치는 것이 타당할 수도
+        - 즉 요청 처리 성능, 응답성과 함께 요청의 중요도 역시 통합인 중 하나
+        - 운영 측면에서 데이터 일관성과 무결성이 그 무엇보다 중요한 경우 통합 고려
+    - 공유 코드
+    - 데이터 관계
+- 서비스 세분도 정리
+  |종류|요인|적용해야 하는 이유|
+  |--|--|--|
+  |분해인|서비스 범위| 응집도가 강한 단일 목적의 서비스|
+  ||코드 변동성|민첩성(테스트 범위와 배포 리스크가 줄어든다)|
+  ||확장성|비용절감, 빠른 응답성|
+  ||내고장성|전체 가동 시간 개선|
+  ||보안 액세스|어떤 기능의 보안 액세스 강화|
+  ||신장성|민첩성(새로운 기능을 추가하기 쉽다)|
+  |통합인|데이터베이스 트랜잭션|데이터 무결성 및 일관성|
+  ||워크플로|내고장성, 성능, 신뢰성|
+  ||공유 코드|유지 보수성|
+  ||데이터 관계|데이터 무결성 및 정확성|