From 79b9a6b684a6466561f8db6b95a6644569cfbe22 Mon Sep 17 00:00:00 2001 From: chichoon Date: Thu, 5 Feb 2026 22:39:52 +0900 Subject: [PATCH 1/5] initial commit for chapter 06 --- .../chichoon/05.md | 45 +++++++++++++++++++ 1 file changed, 45 insertions(+) create mode 100644 2026/Fundamentals_of_Software_Architecture_2nd_Edition/chichoon/05.md diff --git a/2026/Fundamentals_of_Software_Architecture_2nd_Edition/chichoon/05.md b/2026/Fundamentals_of_Software_Architecture_2nd_Edition/chichoon/05.md new file mode 100644 index 00000000..4e621725 --- /dev/null +++ b/2026/Fundamentals_of_Software_Architecture_2nd_Edition/chichoon/05.md @@ -0,0 +1,45 @@ +## Chapter 06: 운영 데이터 분리 + +### 개요 + +- 애플리케이션보다 훨씬 분해가 어려운 것이 데이터베이스 +- 데이터베이스를 분해해야 경계 구분이 명확해진다 + +### 데이터 분해인 + +- 데이터 분해 이유 (언제 분해해야할까?) +- 변경 관리 + - 테이블을 수정할 때 얼마나 많은 서비스에 영향을 끼치는지 + - 영향 받은 서비스를 명확히 알 수 있으면 괜찮은데, 그걸 모른 채로 배포했더니 프로덕션이 오동작하는 일도 있음 + - 데이터베이스를 적절히 분리하여 변경 관리에 이점을 얻을 수 있다 + - 자신을 소유한 서비스에만 영향을 미치게끔 독립적으로 운용 +- 커넥션 관리 + - 여러 서비스가 동일한 데이터베이스를 공유할 경우, 서비스와 연결된 커넥션 풀이 많아지면서 데이터베이스에 부하를 일으킨다 + - 커넥션이 너무 많으면 커넥션 대기가 걸림 + - 추후 서비스를 확장하게 될 경우, 커넥션이 더 늘어남을 고려해야 함 + - 데이터베이스를 분리함으로써 동시에 사용할 수 있는 커넥션 수를 늘릴 수 있다 +- 확장성 + - 서비스 응답 시간을 일정하게 유지하고, 요청량에 따라 서비스 규모를 늘리는 능력 + - 하나의 데이터베이스를 여러 서비스가 바라볼 경우, 커넥션 뿐만 아니라 처리량 부하도 심각해진다 + - 따라서 서비스 확장을 위해서는 데이터베이스 확장을 통해 처리량을 분산시키는것이 좋음 +- 내고장성 + - 여러 서비스가 하나의 데이터베이스를 공유할 경우, 장애가 해당 데이터베이스에만 발생하게 됨 + - 내고장성: 하나의 서비스나 데이터베이스가 고장나도, 다른 부분은 중단없이 가동시킬 수 있는 능력 + - 데이터베이스를 여러 개 두어 하나의 데이터베이스가 망가져도 다른 서비스가 문제없이 동작할수 있도록 하는게 좋다 +- 아키텍처 퀀텀 + - 어떤 경우에 데이터베이스를 분해하는 게 좋을지 알려주는 길잡이 + - 퀀텀 단위로 데이터베이스를 쪼개면 독립적인 서비스로 분리가 가능 +- 데이터베이스 타입 최적화 + - 데이터 처리 방식에 따른 분리 + +### 데이터 통합인 + +- 데이터 통합 이유 (언제 합쳐야할까?) +- 데이터 관계 + - 데이터베이스 테이블간에도 커플링이 발생할 수 있음 + - 외래 키를 통한 연결, 저장 프로시저 등 + - 데이터베이스 분해를 통해 내고장성을 높일지, 통합을 통해 테이블 간 관계를 유지하는게 나을지 고민해야 함 +- 데이터베이스 트랜잭션 + - 서로 다른 테이블에서 발생한 에러는 같은 트랜잭션으로 묶을 수 없기 때문에 데이터의 일관성과 무결성을 보장할 수 없음 + +### 모놀리식 데이터 분해 From 5150e9debdb91b2a8e23f371a018aba78ac72b79 Mon Sep 17 00:00:00 2001 From: chichoon Date: Thu, 5 Feb 2026 22:56:49 +0900 Subject: [PATCH 2/5] chapter 06 done --- .../chichoon/05.md | 55 +++++++++++++++++++ 1 file changed, 55 insertions(+) diff --git a/2026/Fundamentals_of_Software_Architecture_2nd_Edition/chichoon/05.md b/2026/Fundamentals_of_Software_Architecture_2nd_Edition/chichoon/05.md index 4e621725..33fe31e3 100644 --- a/2026/Fundamentals_of_Software_Architecture_2nd_Edition/chichoon/05.md +++ b/2026/Fundamentals_of_Software_Architecture_2nd_Edition/chichoon/05.md @@ -43,3 +43,58 @@ - 서로 다른 테이블에서 발생한 에러는 같은 트랜잭션으로 묶을 수 없기 때문에 데이터의 일관성과 무결성을 보장할 수 없음 ### 모놀리식 데이터 분해 + +- 마이그레이션 점진적 진행 과정 +- 데이터베이스 분석, 데이터 도메인 생성 + - 내부의 도메인 그룹 식별 +- 데이터 도메인에 테이블 할당 + - 테이블들을 특정 컨텍스트로 묶은 뒤, 각 데이터 도메인에 속하는 테이블들을 스키마에 할당 + - 서로 다른 도메인에 속한 테이블들 간 밀접한 커플링이 존재한다면, 이를 묶어야 함 + - synonym (일종의 심볼릭 링크와 같은 별칭) 을 이용하여 코드 분석을 용이하게 만드는 것도 좋은 방법 +- 데이터 도메인에 접속하는 데이터베이스 커넥션의 분리 + - 모든 데이터 접근이 서비스 - 스키마를 통해서만 이루어지도록 구성을 리팩토링 + - 교차 스키마 접근을 서비스 단위로 제거해야 함 + - 이 과정을 완료하여 서비스마다 데이터를 각각 소유하는 아키텍처로 전환됨 +- 개별 데이터베이스 서버로 스키마 이전 + - 위 단계에서 독립적인 접근으로 분리한 데이터 (스키마) 들을 물리적인 단일 데이터베이스 각각으로 옮김 + - 스키마를 옮길 땐 백업 후 복원하거나, 아예 스키마를 복제해서 새 데이터베이스로 커넥션 전환하는 방법이 있음 +- 독립적 데이터베이스 서버로 전환 + - 위에서 각 스키마를 이전하면, 서비스 커넥션도 전환할 수 있음 + - 하나의 서비스 덩어리를 독립적인 배포 단위로 작동시키는 것 + - 기존 큰 데이터베이스에 묶인 스키마와 커넥션을 전부 삭제하면, 이제 각 서비스는 자신의 데이터베이스를 가진 독립적인 도메인이 된다 + +### 데이터베이스 타입 선택 + +- 학습 용이성 + - 데이터베이스를 배우기 쉬운지 +- 모델링 용이성 + - 데이터 모델러가 얼마나 쉽게 도메인을 표현할 수 있는지 +- 확장성 및 처리량 + - 증가된 처리량을 데이터베이스가 얼마나 쉽게 확장 및 감당 가능한지 +- 가용성, 내분할성 + - 고가용성 구성을 지원하는지 +- 일관성 + - 항상 일관된 패러다임 지원 여부 +- 프로그래밍 언어 지원 + - 다양한 프로그래밍 언어 지원 여부 + +- 관계형 디비 + - 가용성보다 일관성 중시 + - 업계 표준이라 공부할 자료가 많고 모델링도 비교적 쉽다 +- 키-값 데이터베이스 + - 관계형 디비보다 배우는 것은 까다로우나, 확장성과 내분할성 면에서 이점을 갖는다 + - 테이블 조인 등의 과정이 필요없기 때문 +- 문서형 데이터베이스 + - 사람이 값을 읽기 쉬워 배우기 쉽고 FE 등에게도 익숙한 형식 +- 컬럼형 데이터베이스 + - 확장성과 내분할성은 최고이지만 이해하기가 어려움 +- 그래프 데이터베이스 + - 어렵고, 정보가 비교적 많지 않음 + - 데이터 흐름 방향성에 따라 복잡해지기 쉽다 +- NewSQL + - 관계형 데이터베이스와 유사하여 학습이 어렵지 않음 + - SQL을 지원하고, NoSQL의 확장성과 관계형 데이터베이스의 장점을 섞은 느낌 +- 클라우드 네이티브 데이터베이스 + - 관계형 데이터베이스와 비슷하고, 클라우드에 바로 올릴 수 있다 +- 시계열 데이터베이스 + - 시계열 분석에 특화 From e1d2e0b54e2038167bd2db612a474014ea246172 Mon Sep 17 00:00:00 2001 From: chichoon Date: Thu, 5 Feb 2026 22:57:25 +0900 Subject: [PATCH 3/5] =?UTF-8?q?=EC=A0=9C=EB=AA=A9?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- .../chichoon/05.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/2026/Fundamentals_of_Software_Architecture_2nd_Edition/chichoon/05.md b/2026/Fundamentals_of_Software_Architecture_2nd_Edition/chichoon/05.md index 33fe31e3..9c808727 100644 --- a/2026/Fundamentals_of_Software_Architecture_2nd_Edition/chichoon/05.md +++ b/2026/Fundamentals_of_Software_Architecture_2nd_Edition/chichoon/05.md @@ -78,6 +78,8 @@ - 프로그래밍 언어 지원 - 다양한 프로그래밍 언어 지원 여부 +#### 데이터베이스 종류별 특징 + - 관계형 디비 - 가용성보다 일관성 중시 - 업계 표준이라 공부할 자료가 많고 모델링도 비교적 쉽다 From 080a3dfc2e2be46140862e16da691bec9e16257d Mon Sep 17 00:00:00 2001 From: chichoon Date: Thu, 5 Feb 2026 23:57:11 +0900 Subject: [PATCH 4/5] chapter 07 --- .../chichoon/05.md | 4 ++ .../chichoon/06.md | 45 +++++++++++++++++++ 2 files changed, 49 insertions(+) create mode 100644 2026/Fundamentals_of_Software_Architecture_2nd_Edition/chichoon/06.md diff --git a/2026/Fundamentals_of_Software_Architecture_2nd_Edition/chichoon/05.md b/2026/Fundamentals_of_Software_Architecture_2nd_Edition/chichoon/05.md index 9c808727..beac3217 100644 --- a/2026/Fundamentals_of_Software_Architecture_2nd_Edition/chichoon/05.md +++ b/2026/Fundamentals_of_Software_Architecture_2nd_Edition/chichoon/05.md @@ -32,6 +32,10 @@ - 데이터베이스 타입 최적화 - 데이터 처리 방식에 따른 분리 +``` +논의점: 데이터 분해인에 정말 많은 요인들이 있는데, 이것들을 고려하기 수월하게 해 주는 피트니스 함수나 유틸리티는 어떤 것이 있을까? +``` + ### 데이터 통합인 - 데이터 통합 이유 (언제 합쳐야할까?) diff --git a/2026/Fundamentals_of_Software_Architecture_2nd_Edition/chichoon/06.md b/2026/Fundamentals_of_Software_Architecture_2nd_Edition/chichoon/06.md new file mode 100644 index 00000000..df4f300c --- /dev/null +++ b/2026/Fundamentals_of_Software_Architecture_2nd_Edition/chichoon/06.md @@ -0,0 +1,45 @@ +## Chapter 07: 서비스 세분도 + +### 개요 + +- 세분도: 작게 나눈 서비스들의 사이즈 정도 + +### 세분도 분해인 + +- 서비스를 작게 나눠야 하는 이유 +- 서비스의 범위와 기능 + - 서비스가 하는 일의 크기와, 컴포넌트의 사이즈 + - 서비스로 나눠지는 기준이 사람마다 다르고, 개발자는 서비스를 최대한 작게 나누려는 성향이 있기 때문에 서비스의 범위를 꼭 고려해야 한다 +- 코드 변동성 + - 소스 코드를 변경하는 빈도 + - 자주 변경되는 기능을 영향력이 적은 단일 서비스로 묶으면 타 기능에 끼치는 영향이 작아지기 때문에 테스트에 용이 +- 확장성 + 처리량 + - 처리량을 달성하기 위해 서비스를 확장할 필요가 있음 + - 서비스를 적절히 쪼개 다양한 처리량 목표를 달성하게 할 수 있다 +- 내고장성 + - 데이터베이스와 마찬가지로 하나의 도메인에 장애가 발생해도 다른 곳에 영향을 끼치지 않게끔 하는 것이 중요하다 +- 보안 + - 민감한 데이터를 다른 서비스가 접근하지 못하게 보호 + - 데이터 저장 뿐만 아니라 데이터 접근도 보안에 큰 영향을 끼친다 +- 신장성 + - 현재 기능에서 새로운 기능이 추가될 경우 리스크를 작게 만들어야 함 + +### 세분도 통합인 + +- 서비스를 합쳐서 크게 만들어야 하는 이유 +- 데이터베이스 트랜잭션 + - 데이터베이스와 비슷하게, 서로 다른 서비스끼리 데이터 공유가 잦은데 도메인이 분리되어 있을 경우 트랜잭션 적용이 어렵다 + - 이런 경우 통합하는 것이 좋다 +- 워크플로우와 코레오그래피 + - 기능간 결합도를 확인하고, 단단히 결합되어 있을 경우 전체 내고장성 보장을 위해 굳이 분리하지 않는 것도 방법 + - 데이터 일관성과 무결성을 중시한다면 서비스 통합도 대안이 된다 +- 공유 코드 + - 서비스들 간 코드를 공유해야 하는지 여부 + - 서비스가 분리되어 있을 경우 라이브러리나 코드 변경시 이를 사용하는 모든 서비스를 찾아서 같이 수정해야 함 + - 이 경우 서비스를 통합하는 게 방법일 수 있다 +- 데이터 관계 + - 서비스 간 데이터는 공유되지 않고 엄격한 콘텍스트로 나눠져 있으므로 서비스간 통신이 잦을 경우 이 서비스를 합치는 게 나을 수도 있다 + +### 적정 균형점 찾기 + +- 분해인과 통합인을 고려하여 트레이드오프를 결정해야 함 From 55fdc3214733d44bde7817101ad37fcd94176b19 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?=EC=B5=9C=EC=A7=80=EC=9C=A4?= Date: Fri, 6 Feb 2026 23:33:34 +0900 Subject: [PATCH 5/5] Apply suggestion from @gemini-code-assist[bot] Co-authored-by: gemini-code-assist[bot] <176961590+gemini-code-assist[bot]@users.noreply.github.com> --- .../chichoon/05.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/2026/Fundamentals_of_Software_Architecture_2nd_Edition/chichoon/05.md b/2026/Fundamentals_of_Software_Architecture_2nd_Edition/chichoon/05.md index beac3217..e3656585 100644 --- a/2026/Fundamentals_of_Software_Architecture_2nd_Edition/chichoon/05.md +++ b/2026/Fundamentals_of_Software_Architecture_2nd_Edition/chichoon/05.md @@ -23,7 +23,7 @@ - 하나의 데이터베이스를 여러 서비스가 바라볼 경우, 커넥션 뿐만 아니라 처리량 부하도 심각해진다 - 따라서 서비스 확장을 위해서는 데이터베이스 확장을 통해 처리량을 분산시키는것이 좋음 - 내고장성 - - 여러 서비스가 하나의 데이터베이스를 공유할 경우, 장애가 해당 데이터베이스에만 발생하게 됨 +- 여러 서비스가 하나의 데이터베이스를 공유할 경우, 해당 데이터베이스에 장애가 발생하면 이를 공유하는 모든 서비스가 영향을 받게 됨 - 내고장성: 하나의 서비스나 데이터베이스가 고장나도, 다른 부분은 중단없이 가동시킬 수 있는 능력 - 데이터베이스를 여러 개 두어 하나의 데이터베이스가 망가져도 다른 서비스가 문제없이 동작할수 있도록 하는게 좋다 - 아키텍처 퀀텀