Merge branch 'eden' of https://github.com/danmooozi/software-architecture into eden

Author: EdenKim-dev

ch17_마이크로서비스_아키텍처_스타일/ch17_eden.md

@@ -2,14 +2,10 @@
 
 ## 17.1 역사
 
-대부분의 아키텍처 스타일은 반복되는 패턴을 발견한 아키텍트의 이름을 따서 명명되며, 소프트웨어 개발 환경의 변화 속에서 자연스럽게 공통의 결정에 이르게 된 경우가 많습니다.  
-하지만 이와 달리 마이크로서비스 아키텍처는 마틴 파울러와 제임스 루이스의 블로그 게시글에서 시작하여, 초기부터 이름이 붙여졌습니다.  
-그들의 글은 마이크로서비스의 철학과 개념을 이해하는 데 큰 도움이 되었습니다.
-
 마이크로서비스는 **도메인 주도 설계(DDD)의 영향을 많이 받았으며**, 특히 **디커플링을 강조하는 경계 콘텍스트 개념이 결정적인 역할**을 했습니다.  
 소프트웨어의 **각 도메인은 코드와 데이터베이스 스키마에 속한 여러 엔티티와 행위를 포함**합니다.  
 전통적인 모놀리식 아키텍처에서는 도메인들이 공통 클래스를 통해서 단일한 데이터베이스에 접근했습니다.  
-이와 달리 마이크로서비스에서는 각 경계 콘텍스트가 독립적으로 코드와 데이터 스키마를 정의하고, 외부와의 커플링을 최소화했습니다.
+이와 달리 마이크로서비스에서는 **각 경계 콘텍스트가 독립적으로 코드와 데이터 스키마를 정의**하고, **외부와의 커플링을 최소화**했습니다.
 
 소프트웨어 아키텍처에서 재사용은 유익하지만, 이를 위해 서로를 상속하고 조합하다 보면 커플링이 발생합니다.  
 **디커플링이 중요한 목표일 경우, 중복을 허용해 재사용을 줄이는 것이 더 적합**합니다.  
@@ -20,31 +16,31 @@
 <img src="./ch17_eden/17-1.png" width="500">
 
 각 마이크로서비스는 단일 목적만을 가지므로, 서비스 규모가 서비스 지향 아키텍처보다 작습니다.  
-각 서비스는 독립적으로 작동하는 데 필요한 데이터베이스와 기타 종속 컴포넌트를 자체적으로 완비하고 있습니다.
+각 서비스는 독립적으로 작동하는 데 필요한 데이터베이스와 기타 종속 컴포넌트를 자체적으로 완전히 갖추고 있습니다.
 
 ## 17.3 분산
 
 마이크로서비스는 분산 아키텍처입니다.  
-각 서비스는 자체 프로세스로 실행되며, 각 프로세스의 실행 환경은 물리적 컴퓨터에서 격리된 가상 머신과 컨테이너로 발전했습니다.  
+**각 서비스는 자체 프로세스로 실행**되며, 각 프로세스의 실행 환경은 물리적 컴퓨터에서 격리된 가상 머신과 컨테이너로 발전했습니다.  
 각 서비스를 자체 프로세스로 분리하면 공유 리소스 등으로 인한 문제들이 자연스럽게 해결됩니다.  
-과거에는 도메인마다 인프라를 구축하는 것이 비현실적이었으나, 현재는 클라우드 리소스와 컨테이너 기술의 발전으로 도메인 및 운영 레벨에서 디커플링을 구현할 수 있게 되었습니다.
+과거에는 도메인마다 인프라를 구축하는 것이 비현실적이었으나, 현재는 **클라우드 리소스와 컨테이너 기술의 발전으로 도메인 및 운영 레벨에서 디커플링을 구현할 수 있게 되었습니다.**
 
-마이크로서비스는 분산 아키텍처이기 때문에 네트워크 호출과 보안 검증으로 인해 성능이 저하될 수 있습니다.  
+마이크로서비스는 분산 아키텍처이기 때문에 **네트워크 호출과 보안 검증으로 인해 성능이 저하**될 수 있습니다.  
 또한 트랜잭션이 서비스 경계를 넘지 않도록 유의해야 합니다.  
-따라서 서비스를 어느 정도로 세분화 할지에 대해서 심사숙고 해야 하며, 서비스 세분화가 마이크로서비스 아키텍처의 성공의 핵심입니다.
+이러한 문제들을 예방하기 위해서는 **서비스를 어느 정도로 세분화 할지에 대해서 심사숙고** 해야 합니다.
 
 ## 17.4 경계 콘텍스트
 
 마이크로서비스의 핵심 철학은 경계 콘텍스트 개념입니다.  
-각 서비스는 도메인이나 워크플로를 모델링하여, 애플리케이션에 필요한 모든 요소(클래스, 컴포넌트, 데이터베이스 스키마 등)를 포함합니다.  
-마이크로서비스는 요소를 공유해서 커플링을 만드는 것보다는, 중복하더라도 커플링을 제거하는 것을 선호합니다.  
-각 마이크로서비스는 특정 도메인이나 서브도메인을 나타내도록 구성되어, 전체 아키텍처는 도메인 주도 설계의 논리적 개념을 물리적으로 구현한 형태가 됩니다.
+**각 서비스는 도메인이나 워크플로를 모델링**하여, **애플리케이션에 필요한 모든 요소(클래스, 컴포넌트, 데이터베이스 스키마 등)를 포함**합니다.  
+마이크로서비스는 요소를 공유해서 커플링을 만드는 것보다는, **중복하더라도 커플링을 제거하는 것을 선호**합니다.  
+각 마이크로서비스는 특정 도메인이나 서브도메인을 나타내도록 구성되어, 전체 아키텍처는 도메인 주도 설계의 논리적 개념을 물리적으로 구현합니다.
 
 ### 17.4.1 세분도
 
 과도하게 서비스를 세분화할 경우, 작은 로직 추가를 위해서도 서비스 간 통신 링크의 재구축이 필요해지는 문제가 발생할 수 있습니다.  
 ‘마이크로서비스’라는 용어는 서비스 지향 아키텍처의 ‘거대 서비스’에 대비해 작은 서비스를 의미하려고 만들어진 것입니다.  
-서비스를 지나치게 세분화하는 것은 적절하지 않습니다.  
+**서비스를 지나치게 세분화하는 것은 적절하지 않습니다**.  
 서비스 경계는 도메인이나 워크플로를 캡처하는 것이 목표이며, 어느 정도의 경계가 적절한지는 시스템과 비즈니스 프로세스마다 달라질 수 있습니다.  
 좋은 서비스 설계는 반복적인 시도를 통해 이루어지며, 처음부터 완벽한 설계를 기대하기보다는 다양한 옵션을 적용하며 개선해 나가야 합니다.
 
@@ -64,40 +60,40 @@
 
 ### 17.4.2 데이터 격리
 
-마이크로서비스는 경계 콘텍스트를 기반으로 데이터를 격리하며, 공유 스키마나 데이터베이스로 인한 커플링을 최대한 배제합니다.  
-데이터 격리는 서비스 세분도 설계 시 중요한 요소이며, 단순히 데이터베이스 엔티티를 기준으로 모델링하지는 않아야 합니다.(엔티티 함정 피하기)
+마이크로서비스는 **경계 콘텍스트를 기반으로 데이터를 격리**하며, **공유 스키마나 데이터베이스로 인한 커플링을 최대한 배제**합니다.  
+데이터 격리는 서비스 세분도 설계 시 중요한 요소이며, **단순히 데이터베이스 엔티티를 기준으로 모델링하지는 않아야 합니다.(엔티티 함정 피하기)**
 
-마이크로서비스 아키텍처에서는 단일 데이터베이스를 단일한 진실 공급원으로 사용하지 않고, 아키텍처 전반에 데이터를 분산시키는 식으로 설계해야 합니다.  
+마이크로서비스 아키텍처에서는 **단일 데이터베이스를 단일한 진실 공급원으로 사용하지 않고, 아키텍처 전반에 데이터를 분산시키는 식으로 설계**해야 합니다.  
 이를 위해 도메인별로 진실 공급원을 식별하거나, 데이터베이스 복제나 캐시 기술을 활용하는 등 구체적인 방안을 마련해야 합니다.  
 데이터를 격리하는 것은 복잡한 작업이지만, 각 서비스가 독립적으로 적합한 데이터베이스와 도구를 선택할 수 있어 유연성이 높아진다는 이점이 있습니다.  
 팀 간에 간섭 없이 필요에 따라 데이터베이스나 의존성을 변경할 수 있다는 점도 큰 장점입니다.
 
 ## 17.5 API 레이어
 
 마이크로서비스 다이어그램에서는 여러 시스템 컨슈머 간에 API 레이어(유저 인터페이스, 시스템 간 호출)가 자주 등장합니다.  
-이 때 API 레이어는 프록시를 이용하여 통신을 간접화하거나, 네이밍 서비스와 연결되어 필요한 작업을 수행하는 등, 유용하게 활용될 수 있습니다.  
+이 때 **API 레이어는 프록시를 이용하여 통신을 간접화하거나, 네이밍 서비스와 연결되어 필요한 작업을 수행하는 등, 유용하게 활용**될 수 있습니다.  
 다만 API 레이어는 중재자나 오케스트레이션 도구로 사용하지 말아야 하며, 비즈니스 로직은 경계 콘텍스트 내부에서 처리해야 합니다.
 
 ## 17.6 운영 재사용
 
-마이크로서비스는 운영 관심사(모니터링, 로깅, 회로 차단기 등)와 도메인 로직을 분리합니다.  
+마이크로서비스는 **운영 관심사(모니터링, 로깅, 회로 차단기 등)와 도메인 로직을 분리**합니다.  
 운영 관심사의 경우 여러 마이크로서비스에서 공통되는데, 공통 요소를 효과적으로 관리하려면 사이드카 패턴을 활용하는 것이 유리합니다.  
-사이드카 패턴에서는 각 서비스에 공통 운영 관심사를 처리하는 컴포넌트를 두는 식으로 운영합니다.  
+**사이드카 패턴에서는 각 서비스에 공통 운영 관심사를 처리하는 컴포넌트를 두는 식으로 운영**합니다.  
 모니터링 도구 업그레이드 같은 작업이 필요해지면 공유 인프라팀이 사이드카를 업데이트하는 식으로 처리합니다.  
 이를 통해 공통 기능을 개별 팀에 맡기는 대신, 표준화된 방식으로 처리하여 업그레이드 및 관리가 용이해집니다.
 
-추가로 서비스 메시(Service Mesh)를 구축하면, 각 서비스들에 포함된 공통 사이드카를 일원화하여 제어할 수 있습니다.  
+**추가로 서비스 메시(Service Mesh)를 구축하면, 각 서비스들에 포함된 공통 사이드카를 일원화하여 제어**할 수 있습니다.  
 서비스 메시에서 각 사이드카는 서비스 플레인과 연결되어, 모든 마이크로서비스에 대해 일관된 운영 인터페이스를 제공합니다.  
 각 서비스는 메시 내에서 하나의 노드로 작동하며, 개발자는 서비스 메시를 전체 서비스를 관리하는 콘솔로 사용합니다.  
 이를 통해 모니터링, 로깅 등 운영에 관련된 공통 관심사를 글로벌하게 제어할 수 있습니다.
 
 <img src="./ch17_eden/17-3.png" width="500">
 
-또한 마이크로서비스 아키텍처의 탄력성과 확장성을 개선하기 위해 서비스 디스커버리(service discovery)를 사용할 수 있습니다.  
+또한 마이크로서비스 아키텍처의 **탄력성과 확장성을 개선하기 위해 서비스 디스커버리(service discovery)를 사용**할 수 있습니다.  
 모든 요청이 서비스 디스커버리를 거치도록 설정하여 요청 수와 빈도를 모니터링하고, 필요 시 서비스 인스턴스를 확장하도록 설계할 수 있습니다.  
 일반적으로 서비스 디스커버리는 서비스 메시 안의 API 레이어로 배포되어, 모든 마이크로 서비스의 일부로 포함됩니다.
 
-## 17.7 프런트엔드
+## 17.7 프론트엔드
 
 마이크로서비스는 디커플링을 선호하기 때문에, 유저 인터페이스(UI)와 백엔드를 분리하는 것을 이상적으로 여깁니다.  
 초기에는 UI를 경계 콘텍스트 일부로 포함하려 했으나, 현실적인 제약으로 인해 이를 달성하기 어려웠습니다.  
@@ -111,7 +107,7 @@
 ## 17.8 통신
 
 마이크로서비스 구축 시 어떤 통신 방식을 선택하는지는 서비스 디커플링에 중요한 지점입니다.  
-크게는 동기와 비동기 중에서 결정해야 하는데, 마이크로서비스 아키텍처는 일반적으로 프로토콜 인지 기반의 이종 간 상호 운용성(protocol-aware heterogeneous interoperability)을 활용합니다.
+크게는 **동기와 비동기 중에서 결정**해야 하는데, 마이크로서비스 아키텍처는 일반적으로 **프로토콜 인지 기반의 이종 간 상호 운용성(protocol-aware heterogeneous interoperability)을 활용**합니다.
 
 #### 프로토콜 인지 (protocol-aware)
 
@@ -130,22 +126,22 @@ REST, 메시지 큐 등 호출 방식을 표준화하여 서비스 간 통신을
 
 ### 17.8.1 코레오그래피와 오케스트레이션
 
-코레오그래피는 브로커 이벤트 기반 아키텍처와 동일한 통신 스타일로, 중앙 중재자를 두지 않습니다.  
+**코레오그래피**는 브로커 이벤트 기반 아키텍처와 동일한 통신 스타일로, **중앙 중재자를 두지 않습니다**.  
 마이크로서비스 아키텍트는 디커플링을 추구하므로, 도메인/아키텍처 동형성(domain/architecture isomorphism) 관점에서 마이크로서비스의 형상은 커플링을 최소화하는 브로커 이벤트 기반 아키텍처를 닮았습니다.
 
-코레오그래피에서 각 서비스는 중앙 중재자 없이 자신의 필요에 따라 다른 서비스를 호출합니다.  
+코레오그래피에서 각 서비스는 **중앙 중재자 없이 자신의 필요에 따라 다른 서비스를 호출**합니다.  
 아래 예시에서는 유저가 요청한 위시 리스트 상세 정보를 제공하기 위해 CustomerWishList와 CustomerDemographics 서비스를 조합하여 데이터를 반환해야 합니다.  
 아래와 같이 처음 요청을 받은 서비스가 다른 서비스를 호출하여 정보를 종합하게 됩니다.
 
 <img src="./ch17_eden/17-7.png" width="500">
 
-코레오그래피 아키텍처를 사용하면 에러 처리와 조정 같은 공통 문제가 더 복잡해지는 단점이 있습니다.  
+코레오그래피 아키텍처를 사용하면 **에러 처리와 조정 같은 공통 문제가 더 복잡해지는 단점**이 있습니다.  
 워크플로가 복잡해질수록 이 문제는 더 두드러집니다.
 워크플로 소유저는 자신의 도메인의 책임과 함께 여러 서비스를 조정하는 중재자 역할도 함께 수행해야 하며(프런트 컨트롤러 패턴), 이로 인해 서비스의 복잡도가 증가합니다.
 
 <img src="./ch17_eden/17-9.png" width="500">
 
-복잡한 비즈니스 프로세스는 오케스트레이션 방식을 사용하는게 더 나을 수 있습니다.  
+**복잡한 비즈니스 프로세스는 오케스트레이션 방식을 사용**하는게 더 나을 수 있습니다.  
 중재자가 비즈니스 워크플로의 복잡한 처리와 조정을 전담하여, 서비스 간 커플링이 발생하긴 하지만 다른 서비스에의 영향은 최소화 됩니다.  
 **도메인과 워크플로는 본질적으로 커플링되는 경우가 많다는 것을 감안**하고, 도메인과 아키텍처를 균형 있게 반영하여 선택을 내려야 합니다.