From 6209e365811cb0d3a1c6776ef44fa1b403640a76 Mon Sep 17 00:00:00 2001 From: chichoon Date: Fri, 20 Mar 2026 18:35:24 +0900 Subject: [PATCH 1/8] add chapter 10 --- .../chichoon/09.md | 42 +++++++++++++++++++ 1 file changed, 42 insertions(+) create mode 100644 2026/Fundamentals_of_Software_Architecture_2nd_Edition/chichoon/09.md diff --git a/2026/Fundamentals_of_Software_Architecture_2nd_Edition/chichoon/09.md b/2026/Fundamentals_of_Software_Architecture_2nd_Edition/chichoon/09.md new file mode 100644 index 00000000..37cda007 --- /dev/null +++ b/2026/Fundamentals_of_Software_Architecture_2nd_Edition/chichoon/09.md @@ -0,0 +1,42 @@ +## Chapter 10: 분산 데이터 액세스 + +### 개요 + +- 서비스간 통신패턴: 서비스 간 데이터를 주고받는 방식 + - 요청하는 대로 데이터를 다 줬다가는 레이턴시가 발생하므로 성능이 떨어진다 + - 또한 여러 서비스가 데이터 때문에 커플링되어 의존성이 생기기 때문에, 한 쪽을 수정할 때 다른 쪽도 수정해야 하는 불상사가 발생 + +--- + +### 컬럼 스키마 복제 패턴 + +- 컬럼을 여러 테이블에 복제해서, 다른 경계 콘텍스트에서도 가져다 쓸 수 있게 하는 방법 +- 데이터를 매번 동기화해야 함 => 일관성 유지 어려움 +- 데이터 오너십 통제 어려움 + - 복제해서 다른 서비스에 쥐어주는 순간, 해당 데이터는 내 소유가 아니기 때문 + +### 복제 캐싱 패턴 + +- 데이터를 그대로 복사하여 새 테이블에 저장하는 것이 아니라, 대신 캐싱을 하는 방법 +- 캐시는 서비스별로 고유하게 저장되기 때문에 타 서비스와 공유되지 않음 (분산 캐싱) +- 단점 + - 대신 위의 스키마 복제 패턴과 동일하게, 디펜던시만 이동했을 뿐 동기화 문제에서 자유롭지 않다 + - 캐시 데이터는 중앙으로 공유되기 때문에, 타 서비스에서 데이터를 자유롭게 업데이트 할 수 있는 것은 그대로고, 경계 콘텍스트도 무너질 수 있다 + - 중앙 분산 캐시 (각 서비스별 캐시가 공유되는 위치) 는 원격 호출을 위해 접근해야 하므로 레이턴시가 늘어나는 것도 동일하다 + - 경우에 따라 복제 캐싱이 지원되지 않을 수 있다 +- 장점 + - 각 서비스별로 캐시를 갖고 있기 때문에 서로 간섭할 일이 없다 + - 또한 각 서비스별 캐시에 접근하면 되므로 데이터 액세스가 빠르다 +- 트레이드오프 + - 캐시 데이터와 시작 타이밍에 서비스가 크게 의존한다 + - 각 서비스별로 캐시에 데이터를 채우므로, 그 캐시에 접근하는 다른 서비스는 해당 주인 서비스가 먼저 시작되어야 대기 상태에서 탈출할 수 있다 + - 데이터 양이 많을 경우 실용성이 떨어진다 + - 캐시 수만큼 용량이 \*n 이 되므로 + +### 데이터 도메인 패턴 + +- 여러 서비스가 공유하는 테이블을 하나의 스키마에 집어넣어 관리 +- 서비스가 서로 디커플링되어 디펜던시 문제와 응답성, 처리량, 확장성 이슈가 해소됨 +- 여러 서비스가 동일한 테이블을 바라보기 때문에, 무결성 문제에서도 자유롭다 +- 다만 해당 스키마의 테이블 구조가 변경될 경우 다른 서비스들도 영향을 받을 수 있다 +- 서비스 오너십과 경계 콘텍스트를 엄격하게 설정하여 타 서비스가 접근해야 하면 안될 데이터들을 적절히 막는 것이 좋다 From 27c224813e9324d2fa5b416f1bc39a82f1c45079 Mon Sep 17 00:00:00 2001 From: chichoon Date: Fri, 20 Mar 2026 18:35:29 +0900 Subject: [PATCH 2/8] add chapter 11 --- .../chichoon/10.md | 61 +++++++++++++++++++ 1 file changed, 61 insertions(+) create mode 100644 2026/Fundamentals_of_Software_Architecture_2nd_Edition/chichoon/10.md diff --git a/2026/Fundamentals_of_Software_Architecture_2nd_Edition/chichoon/10.md b/2026/Fundamentals_of_Software_Architecture_2nd_Edition/chichoon/10.md new file mode 100644 index 00000000..2c4a3635 --- /dev/null +++ b/2026/Fundamentals_of_Software_Architecture_2nd_Edition/chichoon/10.md @@ -0,0 +1,61 @@ +## Chapter 11: 분산 워크플로 관리 + +### 개요 + +- 조정: 분산 아키텍처에서 도메인에 특정한 작업을 수행하고, 그와 관련된 부수적인 문제를 처리하기 위해 서비스를 조합하는 것 + +--- + +### 오케스트레이션 통신 스타일 + +- 오케스트레이터 (중재자) 를 이용하여 워크플로 상태나 에러, 알림 등을 관장 +- 복잡한 워크플로를 오케스트레이션을 통해 하나의 관리자가 전담하여 관리한다 +- 에러 조건 및 경로를 다루는 것이 가장 어려운데, 오케스트레이터는 각 트랜잭션을 관리함으로써 각 서비스의 상태와 에러 여부를 관장한다 +- 장점 + - 중앙화 워크플로: 상태와 동작을 통합한 컴포넌트 운용 + - 에러 처리 + - 복원성 + - 상태 관리 +- 단점 + - 응답성 + - 내고장성 + - 확장성 + - 서비스 커플링 + +``` +궁금증: ESB도 전역 오케스트레이터라는데, ESB는 서비스간 결합을 유도하기 때문에 오케스트레이션이랑 차이가 있다고 한다. 허나 그냥 오케스트레이터랑 ESB가 무엇이 다른지 이해가 안된다. 오케스트레이터 중 하나가 ESB라는게 아닌가? +``` + +--- + +### 코레오그래피 통신 스타일 + +- 중앙 조정을 하는 오케스트레이션과 달리, 각 서비스가 개별로 움직이는 스타일 +- 서로 통신하고 에러 처리도 한다 +- 허나 하나의 시나리오 진행 중에 서비스에서 오류가 발생할 경우, 이미 진행이 많이 되어 각 서비스를 거쳐간 상태이기 때문에 에러가 인지한 직후 이벤트를 생성해서 메시지를 브로드캐스팅해야 다른 서비스들이 볼 수 있다 +- 통신 경로가 많아질 수 밖에 없는 구조 +- 장점 + - 응답성, 확장성, 내고장성, 서비스 디커플링 + - 사실상 오케스트레이션과 반대됨 +- 단점 + - 분산된 워크플로 + - 상태 관리 + - 에러 처리 + - 복원성 + +### 워크플로 상태 관리 + +- 코레오그래피 통신 스타일에서는 워크플로의 상태를 관장하는 대장이 따로 없다 + - 위에 오케스트레이션 방식에서는 오케스트레이터가 직접 관장했음 +- 이 경우 상태를 관장하는 방법이 다음과 같다 + - 프론트 컨트롤러: 시나리오상 가장 먼저 호출된 서비스에게 책임을 맡기기 + - 무상태 코레오그래피: 각 서비스별 스냅샷을 구축하여 워크플로 전이 상태를 유지하지 않음 +- 스탬프 커플링: 서비스 간 전송되는 메시지 계약에 워크플로 상태를 같이 넣어서 전달 + +--- + +### 오케스트레이션 <-> 코레오그래피 간 트레이드오프 + +- 에러 빈도가 낮고, 에러 시나리오가 복잡하지 않으면 코레오그래피 + - 확장성 면에선 코레오그래피가 훨씬 편하다 +- 경계 조건과 에러 조건이 너무 복잡하면 오케스트레이션 From 0c5a856fff8e1e3d83966379b8fafc0b4d020d73 Mon Sep 17 00:00:00 2001 From: chichoon Date: Fri, 20 Mar 2026 18:51:16 +0900 Subject: [PATCH 3/8] feat: chapter 12 --- .../chichoon/11.md | 155 ++++++++++++++++++ 1 file changed, 155 insertions(+) create mode 100644 2026/Fundamentals_of_Software_Architecture_2nd_Edition/chichoon/11.md diff --git a/2026/Fundamentals_of_Software_Architecture_2nd_Edition/chichoon/11.md b/2026/Fundamentals_of_Software_Architecture_2nd_Edition/chichoon/11.md new file mode 100644 index 00000000..d4150f7f --- /dev/null +++ b/2026/Fundamentals_of_Software_Architecture_2nd_Edition/chichoon/11.md @@ -0,0 +1,155 @@ +## Chapter 12: 트랜잭셔널 사가 + +### 개요 + +- 사가 패턴: 각 업데이트가 완료되면 이벤트를 발행하고, 다음 업데이트를 실행시키는 릴레이 트랜잭션 +- 만약 업데이트들 중 하나라도 실패하면, 보상 트랜잭션을 가동시켜 이전 모든 변경사항을 무로 되돌린다 + +--- + +### 트랜잭셔널 사가 패턴 + +- 에픽 사가 +- 폰 태그 사가 +- 페어리테일 사가 +- 타임트래블 사가 +- 판타지 픽션 사가 +- 호러 스토리 사가 +- 패럴렐 사가 +- 앤솔로지 사가 +- 이름이 공식은 아니고 적당히 붙인듯 + +--- + +### 에픽 사가 + +- 오케스트레이티드 사가 라고도 함 +- 동기 통신 + 원자적 일관성 + 오케스트레이션 조정 +- 트랜잭션 중 하나의 호출이라도 실패할 경우, 모두 실패한 것으로 처리해 이전 상태로 되돌림 + - 성공 or 실패밖에 없다는 뜻 +- 보상 트랜잭션을 사용하여 구현 + - 분산 트랜잭션 도중 다른 서비스가 수행한 작업을 되돌리는 업데이트 + - 중재자는 요청 처리 성공여부를 모니터링하다가, 실패할 경우 다른 서비스를 보상호출 하여 중단 +- 높은 결합도 (복잡한 커플링) +- 높은 복잡도 + - 동기 호출이라 이에 대한 복잡도는 내려감 +- 응답성이 떨어짐 +- 이 패턴을 구현하기 위한 조정 및 병목은 확장성을 낮춤 + +--- + +### 폰 태그 사가 + +- 에픽 사가에서 사용하는 조정방식을 오케스트레이션 > 코레오그래피로 바꿈 + - 동기 + 원자성 + 코레오그래피 +- 텔레폰 게임 (한 사람이 다른 사람에게 비밀을 이야기하여 마지막 사람이 이를 맞추는 게임) 과 유사하여 이런 이름이 붙음 +- 오케스트레이터가 따로 없음 + - 따라서 각 서비스별로 책임 체인을 갖고 실패시 거슬러 올라갈 수 있어야 함 +- 결합도는 에픽 사가에 비해 약간 줄어듦 (코레오그래피이므로) + - 큰 차이는 없음 +- 에픽 사가보다 훨씬 복잡해짐 + - 오케스트레이터의 빈 자리를 채우기 위해 더 많은 로직이 각 서비스별로 들어가게 됨 +- 오케스트레이션이 없어졌으므로 응답성은 좋아짐 + - 허나 에러 처리에 더 많은 시간이 소요되므로 이 때문에 응답성이 낮아질 수 있음 +- 마찬가지로 오케스트레이션을 사용하지 않아 확장성이 아주 조금 좋아짐 + +--- + +### 페어리테일 사가 + +- 동기 + 최종일관성 + 오케스트레이션 +- 서비스가 잠시 중단되었을 경우, 최종 일관성을 통해 변경된 데이터를 일시 캐싱 +- 오케스트레이터가 존재는 하지만, 트랜잭션을 관리하지 않음 + - 요청, 응답, 에러처리만 + - 트랜잭션은 각 서비스가 알아서 관리 +- 동기 통신이라 이해하기 쉽고, 오케스트레이터가 있어 관리하기 쉬우며, 전체 트랜잭션이 없고 최종 일관성에 따라 서비스 각각이 수행하는 트랜잭션만 관리하면 됨 +- 결합도는 매우 높음 (동기 + 오케스트레이션) + - 단 트랜잭션이 최종 일관성으로 대체되어, 그에 따른 결합도는 약간 낮아짐 +- 복잡도가 매우 낮음 (최종일관성 + 오케스트레이션) + - 아주 간단한 조합으로만 만들어짐 +- 응답성 + - 동기 호출이지만 빠른 편 +- 확장성 + - 커플링 (결합도) 이 낮아 확장성도 좋음 + +--- + +### 타임 트래블 사가 + +- 동기 + 최종일관성 + 코레오그래피 +- 중재자가 없으므로 도메인 서비스들이 알아서 워크플로우를 관리해야 함 + - 요청을 받고, 작업 수행 후, 다음 서비스에 요청 전달 + - 각 단계가 한 방향으로, 하나의 시간적 흐름으로 순차적으로 흘러감 +- 트랜잭션이 없어 워크플로 모델링이 쉽지만, 오케스트레이터가 없으므로 각 서비스별로 워크플로 상태와 정보를 다 가지고 있어야 함 + - 워크플로가 복잡할 수록 오케스트레이터의 필요성이 증가 + - 따라서 워크플로가 단순할 때 타임트래블 사가가 적합하다 +- 결합도가 비교적 낮고 확장성이 좋음 +- 트랜잭션이 없어 복잡도가 낮음 +- 동기 호출을 사용하기 때문에 오버헤드가 발생하여 응답성은 약간 낮은 편 +- 확장성이 매우 좋음 + +--- + +### 판타지 픽션 사가 + +- 비동기 + 원자적 일관성 + 오케스트레이션 +- 에픽 사가와 비슷하지만, 비동기를 사용 + - 따라서 분산 트랜잭션을 병렬로 수행 + - 이 비동기성 때문에 중재자가 해야할 일도 복잡해진다 +- 오케스트레이터로 조정되는 워크플로가 비동기로 움직이는 것은 일을 더 복잡하게 만들기 쉽다 +- 비동기 통신 때문에 결합도는 매우 높음 => 복잡도도 높음 +- 다수의 호출에 의해 트랜잭션 조정이 이루어지므로, 하나 이상의 서비스가 실패하면 응답성도 수직 하락함 +- 트랜잭션 체제를 사용하므로 높은 확장성 얻기가 어려움 +- 단점만 잔뜩 있는데, 비동기 통신 하나로 에픽 사가의 단점을 상쇄할 수 있다는 믿음 때문에 많이 사용되는 편 + - 정말 별로라는 뜻 + +--- + +### 호러 스토리 사가 + +- 이름부터가 호러이다 +- 비동기, 원자적 일관성, 코레오그래피 사용 +- 원자적 일관성이라는 가장 엄격한 체제 아래 가장 느슨하게 만드는 비동기 통신과 코레오그래피가 어우러져 있는 매우 최악의 조합 +- 중재자가 없기 때문에, 각 서비스들은 비동기성 때문에 언제 어디서 어긋날지 모를 트랜잭션을 계속 추적하고 되돌릴 준비를 해야 한다 + - 하나의 트랜잭션 호출이 실패할 경우 해당 파트를 전부 되돌려야 하는데, 이 조건이 매우 까다롭기 때문에 에러 처리가 매우 어렵다고 할 수 있다 +- 결합도는 에픽 사가보단 낫다 (중재자를 사용하지 않으므로) +- 매우 복잡하다 +- 중재자 패턴이 아니므로 확장은 비교적 잘 된다 +- 서비스끼리 지속적으로 통신해야 하므로 좋지 않은 응답성 + +--- + +### 패럴렐 사가 + +- 비동기 통신, 최종 일관성, 오케스트레이션 +- 에픽 사가에서의 동기 통신에 기반된 트랜잭션 패턴은 성능 저하가 일어날 수밖에 없으므로, 이를 비동기와 최종일관성으로 보완 +- 중재자가 있으므로 복잡한 워크플로에 적합하다 +- 제약조건이 느슨한 대신, 각 단계에서 발생할 에러나 문제점을 중재자에 떠맡기므로, 이 부분에서의 타이밍 문제와 안정성이 떨어지게 된다 +- 결합도가 낮으면서 복잡도도 같이 낮다 +- 확장성이 매우 좋다 +- 비동기 통신 덕이 응답성도 좋다 + +--- + +### 앤솔로지 사가 + +- 에픽 사가의 정반대 +- 비동기 통신, 최종 일관성, 코레오그래피 + - 결합도가 낮을 수밖에 없는 요소 조합 +- 중앙 조정 기능이 없기 때문에 서비스는 복잡해지지만, 그 외의 특성 면에선 좋아진다 +- 단순하면서 선형적으로 진행되는 워크플로에 적합 + - 중앙조정 기능이 없기 때문에 단순한 워크플로에 적합한 것 + - 성능이 높아야 하고, 확장성도 추구한다면 가장 적합 +- 결합도가 매우 낮은 대신, 복잡도가 매우 높다 (코레오그래피 때문) +- 확장성, 탄력성은 결합도가 낮으므로 같이 낮음 +- 응답성 높음 + +--- + +### 상태 관리와 최종 일관성 + +- 상태 관리와 최종 일관성은 유한 상태 기계를 통해 현재 사가 상태를 파악하고 오류를 해결하는 방법 + - 사가 상태 기계: 분산 아키텍처에서 있을 법한 모든 가능한 경로를 기술하는 패턴 + - 각 상태가 변경될 때마다 수행할 액션과 전이 상태가 등장 + - 모든 상태 전이와 그에 해당하는 액션 목록을 정리하고, 이를 토대로 코드로 구현하는 것이 좋음 + - 사가 관리 기법: 상태들을 enum화 하고 트랜잭션을 클래스로 구현하는 것 같다 From 9fa0733a972f41f8c67cedb32187910d49b38ac3 Mon Sep 17 00:00:00 2001 From: chichoon Date: Fri, 20 Mar 2026 19:06:50 +0900 Subject: [PATCH 4/8] add chapter 13 --- .../chichoon/12.md | 53 +++++++++++++++++++ 1 file changed, 53 insertions(+) create mode 100644 2026/Fundamentals_of_Software_Architecture_2nd_Edition/chichoon/12.md diff --git a/2026/Fundamentals_of_Software_Architecture_2nd_Edition/chichoon/12.md b/2026/Fundamentals_of_Software_Architecture_2nd_Edition/chichoon/12.md new file mode 100644 index 00000000..c2911c0d --- /dev/null +++ b/2026/Fundamentals_of_Software_Architecture_2nd_Edition/chichoon/12.md @@ -0,0 +1,53 @@ +## Chapter 13: 계약 + +### 개요 + +- 계약: 종류가 다른 아키텍처 파트가 어떻게 연결될 것인지 정의한 것 + - 아키텍처의 거의 모든 부분에서 영향을 끼친다 +- 하드 파트 계약: 어떤 정보나 디펜던시를 전달하기 위해, 아키텍처의 각 파트에서 사용되는 포맷 +- 계약이란 곧 프레임워크와 라이브러리 간의 디펜던시, 통합점, 각 서비스간 통신 등 서로를 연결시키는 모든 기술들을 포괄하는 개념 + +--- + +### 엄격한 계약 vs 느슨한 계약 + +- 엄격한 계약: 이름, 타입, 순서 등 세부사항을 전부 준수하고, 모호한 부분을 남기지 않음 + - 단, 여러 아키텍처 파트에서 두루 쓰이면서 자주 변경되는 경우, 엄격한 계약에 취약점이 생길 수 있다 + - JSON 에 키, 값 쌍을 엄격하게 제한할 수 있다 +- 느슨한 계역: 커플링이 느슨한 경우 + - REST, 그래프QL 등 + - 다른 개발자가 하나의 리소스와 기능을구축하고 이 리소스를 확장한다고 해도, 특정 기능이 갑자기 문제가 생기지 않는 경우 +- 필요한 정보 외에도 갖은 정보들을 다 계약에 넣어버릴 경우, 취약점이 생기기 쉽다 + - 예를 들어, 고객의 위시리스트는 고객의 이름 식별자만 있으면 된다 + - 허나 고객의 성별, 나이 등의 정보까지 제공해버리면 안티패턴 + - 또한 해당 정보가 수정될 경우 계약이 깨지면서 위시리스트 기능까지 수정해야 할 수도 있다 +- 트레이드오프 + - 엄격한 계약 + - 계약 충실도 보장 (계약만으로 스키마 검증 가능) + - 버저닝 + - 장점이자 단점인데, 적절하지 못한 버저닝 (버전을 너무 많이 만들거나 너무 적게 만들기) 는 서비스를 더 복잡하게 만든다 + - 빌드 시 검증이 쉽다 + - 문서화하기 좋음 + - 커플링이 단단해짐 (한 쪽 변경하면 다른 쪽도 변경해야 함) + - 느슨한 계약 + - 높은 디커플링, 매우 유연함 + - 스키마 정보가 엄격하지 않으므로, 계약을 더 자유롭게 발전 가능 + - 계약 자체가 엄격하지 않으므로, 이름 - 값 쌍 누락 또는 철자 오류 등 결합이 발생할 여지가 큼 + - 피트니스 함수를 통해 느슨한 계약을 수행하는 데 필요한 정보가 모두 들어오는지 확인이 필요 +- 마이크로서비스에서는? + - 여러 서비스의 관계와 전달되는 정보, 결합도를 생각해야 한다 +- 컨슈머 주도 계약 + - 사용자가 서비스 제공자로부터 받고 싶은 정보를 계약에 넣고, 이를 토대로 빌드에 포함시켜 계약 테스트를 수행하는 기법 + - 필요에 따라 계약을 엄격하게 하거나, 느슨하게 할 수 있다 + - 자동 테스트로 테스트 가능하므로 이 부분에선 엄격할 수 있다 + - 단, 기술자가 이 절차들을 정확히 인지하고 지켜야 한다 + +--- + +### 스탬프 커플링 + +- 서비스 끼리 매우 큰 데이터를 주고받지만, 각 서비스는 그 데이터 안에서도 매우 작은 일부만 사용하는 경우 +- 위의 위시리스트 예시에서, 고객의 이름 (또는 ID) 만 있으면 되지만 모든 회원 정보를 전부 제공하는 경우? +- 데이터 때문에 계약에 과도한 커플링이 발생하면서, 전체 구조가 매우 취약해진다 +- 대역폭에 비해 너무 큰 데이터가 오고가면서 통신에 문제가 생길 수 있다 +- 코레오그래피 방식을 사용할 수 밖에 없는 경우, 스탬프 커플링을 이용하여 도메인 정보, 워크플로 상태를 계약에 넣어 전달하면 각 서비스는 이를 받아 계약 상태와 워크플로 상태를 업데이트하여 다음 서비스에 전달할 수 있다 From 440159523c61d5ca9efa0824a5b23aa4ebf9b34e Mon Sep 17 00:00:00 2001 From: chichoon Date: Fri, 20 Mar 2026 19:19:19 +0900 Subject: [PATCH 5/8] add chapter 14 --- .../chichoon/13.md | 47 +++++++++++++++++++ 1 file changed, 47 insertions(+) create mode 100644 2026/Fundamentals_of_Software_Architecture_2nd_Edition/chichoon/13.md diff --git a/2026/Fundamentals_of_Software_Architecture_2nd_Edition/chichoon/13.md b/2026/Fundamentals_of_Software_Architecture_2nd_Edition/chichoon/13.md new file mode 100644 index 00000000..e4459439 --- /dev/null +++ b/2026/Fundamentals_of_Software_Architecture_2nd_Edition/chichoon/13.md @@ -0,0 +1,47 @@ +## Chapter 14: 분석 데이터 관리 + +### 개요 + +- 운영 데이터와 분석 데이터를 분리하려면? + - 두 종류의 데이터는 용도가 완전히 다르므로 + +--- + +### 데이터 웨어하우스 + +- 모든 어플리케이션이 모놀리식일 때의 이야기 +- 데이터 웨어하우스 패턴을 통해 쿼리 가능한 분석 데이터를 제공하려고 했다 +- 운영 데이터들이 개별 데이터베이스들에 각각 들어있으므로, 이를 한번에 쿼리하고 분석값을 내놓는 것은 어렵기 때문에, 분석용 데이터는 웨어하우스로 추출 +- 데이터 웨어하우스는 데이터를 반정규화 하여 처리 속도를 높이고, 쿼리를 단순하게 한다 +- 각 디비별 내장 매커니즘을 사용하여 스키마를 웨어하우스용 스키마로 변환해야 하는데, 스키마가 변경되면 이걸 반복해야 하므로 변경 관리가 어렵다 +- 데이터가 웨어하우스에 머무르는 구조라, 모든 분석은 웨어하우스가 전담한다 + - 따라서 데이터 분석자도 데이터 웨어하우스를 바라보고 사용한다 + - 분석을 위해서는 도메인 지식이 필요 +- 단점 + - 통합 취약성: 특정 도메인 변경 시 관련 스키마도 함께 변경해야 한다 + - 웨어하우스 간에 온갖 데이터가 복잡하게 엮여있어, 이를 분석하기 위해 높은 도메인 지식과 모든 분야의 사람들이 달려들어서 분석과 데이터 변경을 도와야 한다 + - 대체 스키마 구축을 통해 시스템이 점점 복잡해진다 + - 아무튼 매우 복잡한 것에 비해 비즈니스적 가치는 떨어져서, 실패한 방식이 되었다 + - 유지보수도 매우 비쌌고, 병목 유발, 등등 + +--- + +### 데이터 레이크 + +- 데이터 웨어하우스의 중앙화 모델과 파이프라인은 그대로 +- 변환 후 적재 방식을, 적재 후 변환 방식으로 바꿈 + - 스키마 변환 필요성이 줄어들어, 데이터가 있는 그대로 저장됨 + - 이 데이터들을 분석가들이 필요한 형태로 가공하여 응답해주는 것 +- 이 중에서 필요한 데이터를 골라내기가 어렵다 +- 민감정보가 같이 저장되므로, 사생활 침해의 여지가 있다 +- 기술 분할에 초점을 둠 (요즘 대세는 도메인 분할) + +--- + +### 데이터 메시 + +- 분석 데이터를 탈중앙화 방식으로 접근하고 관리 +- 도메인 오너십: 각 데이터별로 출처가 되거나 일급 컨슈머가 되는 서비스들이 데이터를 소유하고 관리한다 +- 데이터를 프로덕트로 서비스하는 개념을 도입하였고, 데이터 프로덕트 퀀텀을 통해 데이터를 적절하게 찾아내고 이해하기 쉽게끔 관리한다 +- 도메인 팀이 데이터를 관리할 수 있는 셀프 서비스 플랫폼을 두고 있음 +- 데이터 프로덕트 퀀텀 From 59789f615b48531a4c6801901d605c243ebdca07 Mon Sep 17 00:00:00 2001 From: chichoon Date: Fri, 20 Mar 2026 19:57:58 +0900 Subject: [PATCH 6/8] add chapter 15 --- .../chichoon/14.md | 52 +++++++++++++++++++ 1 file changed, 52 insertions(+) create mode 100644 2026/Fundamentals_of_Software_Architecture_2nd_Edition/chichoon/14.md diff --git a/2026/Fundamentals_of_Software_Architecture_2nd_Edition/chichoon/14.md b/2026/Fundamentals_of_Software_Architecture_2nd_Edition/chichoon/14.md new file mode 100644 index 00000000..e98e08c4 --- /dev/null +++ b/2026/Fundamentals_of_Software_Architecture_2nd_Edition/chichoon/14.md @@ -0,0 +1,52 @@ +### Chapter 15: 자신만의 트레이드오프 분석 + +### 개요 + +- 책에서 살펴본 분산 아키텍처들과 각 트레이드오프를 고려하여 적재적소에 사용하는 스킬이 필요하겠다 +- 다음 3단계를 거침 + - 어느 파트가 서로 연관되어 있는지 확인 (연관된 차원 확인) + - 어떻게 서로 결합되어 있는지 확인 + - 상호 의존적 시스템의 변경 영향도 파악 후 트레이드오프 파악 + +--- + +### 서로 연관된 차원 확인 + +- 커플링 + - X를 변경하면 그 때문에 Y도 변경해야 할까? 를 생각하면 된다 +- 결합점 분석 + - 결합점을 식별하면, 각 특성들을 조합하여 적절한 아키텍처를 찾아내면 된다 + - 동기 / 비동기 여부, 일관성 방식, 오케스트레이션 / 코레오그래피 + - 결합도, 복잡도, 응답성 / 가용성, 확장성 / 탄력성 + - 각 패턴을 분석하고, 특성을 비교하면 몇 가지 특징이 보인다 + - 결합도와 확장성 / 탄력성은 반비례한다 + - 결합도가 높아질 수록 확장성은 떨어짐 + - 응답성 / 가용성과 결합도 또한 어느정도 반비례한다 + - 여러 차원을 조합해보면서 의미를 파악하기 위해, 경우의 수 매트릭스를 작성하는 것도 좋다 +- 트레이드오프 평가 + - if 시나리오를 반복하여 주어진 상황에서의 각 특성 선택 시 트레이드오프를 고민한다 + +### 트레이드오프 기법 + +- 정성적 분석 vs 정량적 분석 + - 각 표들은 전부 정성적 분석에 근거한 자료들이다 + - 대량의 데이터에 통계적 분석 기법을 동원하여 정량적 분석도 가능할 것 +- MECE 리스트 + - 상호 배제, 전체 포괄 + - 상호 배제: 비교 대상간 서로 기능이 겹치지 않아야 한다 + - 다른 부분은 무시하고 특정 기능만 비교한다는 전제가 있어야 함 + - 전체 포괄: 의사 결정 과정에서 모든 가능성을 짚어보고, 명백한 기능은 빠트리면 안됨 +- 콘텍스트 왜곡의 함정 + - 트레이드오프 검토 시에는 콘텍스트에 따라 의사 결정을 해야 한다 + - 그렇지 않으면 트레이드오프 분석 결과가 외부 요인에 막대한 영향을 받게 되므로 + - 분석 결과에 특정한 부가 콘텍스트가 결여되어 있다면, 실제 적용 시 무용지물이 된다 + - 의사 결정 콘텍스트를 정확하게 좁혀가면 아키텍트가 생각해야 할 것들이 줄고, 설계가 단순해진다 + - 만약에? 게임을 반복하여 아키텍처 차원간 영향을 꼼꼼히 고려해야 한다 +- 모델과 연관된 도메인 케이스 + - 도메인 동인을 추가하여 아키텍트가 가능한 방안을 걸러내고, 트레이드오프에 집중하는 데에 도움이 된다 +- 차고 넘치는 증거보다 한마디 결론이 낫다 + - 트레이드오프 분석에 온갖 정보를 수집하려고 하려는 사람이 있는데, 정보의 양 때문에 질이 묻힐 가능성이 있다 + - 중요한 핵심 주제로만 좁히는 것이 낫다 +- 터무니없는 말과 에반젤리즘은 금물 + - 어떠한 신기술이 좋아보인다고 해서 너무 매몰되지 말라는 뜻 + - 장점과 단점을 정직하게 평가한 자료를 이용하여 검토해야 한다 From fc5233da98b461ae44db37699587c3187e555608 Mon Sep 17 00:00:00 2001 From: chichoon Date: Fri, 20 Mar 2026 20:12:01 +0900 Subject: [PATCH 7/8] fix: review --- .../chichoon/09.md | 11 +++++++---- 1 file changed, 7 insertions(+), 4 deletions(-) diff --git a/2026/Fundamentals_of_Software_Architecture_2nd_Edition/chichoon/09.md b/2026/Fundamentals_of_Software_Architecture_2nd_Edition/chichoon/09.md index 37cda007..28827c8b 100644 --- a/2026/Fundamentals_of_Software_Architecture_2nd_Edition/chichoon/09.md +++ b/2026/Fundamentals_of_Software_Architecture_2nd_Edition/chichoon/09.md @@ -18,11 +18,14 @@ ### 복제 캐싱 패턴 - 데이터를 그대로 복사하여 새 테이블에 저장하는 것이 아니라, 대신 캐싱을 하는 방법 -- 캐시는 서비스별로 고유하게 저장되기 때문에 타 서비스와 공유되지 않음 (분산 캐싱) +- 캐시는 서비스별로 고유하게 저장되기 때문에 타 서비스와 공유되지 않음 +- 다른 캐싱 패턴 + - 단일 메모리 캐싱: 각 서비스별 고유 캐시 데이터를 가지고 있음 + - 분산 캐싱: 데이터를 외부 캐시 서버에 보관, 이 덕분에 서비스간 데이터 공유가 가능 + - 캐시 데이터는 중앙으로 공유되기 때문에, 타 서비스에서 데이터를 자유롭게 업데이트 할 수 있는 것은 그대로고, 경계 콘텍스트도 무너질 수 있다 + - 중앙 분산 캐시 (각 서비스별 캐시가 공유되는 위치) 는 원격 호출을 위해 접근해야 하므로 레이턴시가 늘어나는 것도 동일하다 + - 대신 위의 스키마 복제 패턴과 동일하게, 디펜던시만 이동했을 뿐 동기화 문제에서 자유롭지 않다 - 단점 - - 대신 위의 스키마 복제 패턴과 동일하게, 디펜던시만 이동했을 뿐 동기화 문제에서 자유롭지 않다 - - 캐시 데이터는 중앙으로 공유되기 때문에, 타 서비스에서 데이터를 자유롭게 업데이트 할 수 있는 것은 그대로고, 경계 콘텍스트도 무너질 수 있다 - - 중앙 분산 캐시 (각 서비스별 캐시가 공유되는 위치) 는 원격 호출을 위해 접근해야 하므로 레이턴시가 늘어나는 것도 동일하다 - 경우에 따라 복제 캐싱이 지원되지 않을 수 있다 - 장점 - 각 서비스별로 캐시를 갖고 있기 때문에 서로 간섭할 일이 없다 From f2da1a20806fdbf6f1557e3d1dd30587965c87bf Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?=EC=B5=9C=EC=A7=80=EC=9C=A4?= Date: Fri, 20 Mar 2026 20:12:27 +0900 Subject: [PATCH 8/8] Update 2026/Fundamentals_of_Software_Architecture_2nd_Edition/chichoon/12.md Co-authored-by: gemini-code-assist[bot] <176961590+gemini-code-assist[bot]@users.noreply.github.com> --- .../chichoon/12.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/2026/Fundamentals_of_Software_Architecture_2nd_Edition/chichoon/12.md b/2026/Fundamentals_of_Software_Architecture_2nd_Edition/chichoon/12.md index c2911c0d..9c3d8c44 100644 --- a/2026/Fundamentals_of_Software_Architecture_2nd_Edition/chichoon/12.md +++ b/2026/Fundamentals_of_Software_Architecture_2nd_Edition/chichoon/12.md @@ -14,7 +14,7 @@ - 엄격한 계약: 이름, 타입, 순서 등 세부사항을 전부 준수하고, 모호한 부분을 남기지 않음 - 단, 여러 아키텍처 파트에서 두루 쓰이면서 자주 변경되는 경우, 엄격한 계약에 취약점이 생길 수 있다 - JSON 에 키, 값 쌍을 엄격하게 제한할 수 있다 -- 느슨한 계역: 커플링이 느슨한 경우 +- 느슨한 계약: 커플링이 느슨한 경우 - REST, 그래프QL 등 - 다른 개발자가 하나의 리소스와 기능을구축하고 이 리소스를 확장한다고 해도, 특정 기능이 갑자기 문제가 생기지 않는 경우 - 필요한 정보 외에도 갖은 정보들을 다 계약에 넣어버릴 경우, 취약점이 생기기 쉽다