|
| 1 | +# 17장. 마이크로서비스 아키텍처 스타일 |
| 2 | + |
| 3 | +## 17.1 역사 |
| 4 | + |
| 5 | +1. 아키텍터 스타일의 명명 |
| 6 | + - 기존 스타일은 반복 패턴 발견 후 명명 |
| 7 | + - 소프트웨어 생태계 변화로 자연스럽게 결정됨 |
| 8 | +2. 마이크로서비스의 시작 |
| 9 | + - 2014년, 마틴 파울러와 제임스 루이스의 블로그 Microservice로 확산 |
| 10 | +3. DDD와 경계 콘텍스트 |
| 11 | + - 도메인 주도 설계(DDD)의 영향을 받음 |
| 12 | + - 경계 콘텍스트: 내부 요소만 결합, 외부와 디커플링 유지 |
| 13 | +4. 재사용 vs 디커플링 |
| 14 | + - 재사용은 커플링 유발 |
| 15 | + - 마이크로서비스는 디커플링을 위해 중복을 우선 |
| 16 | + |
| 17 | +## 17.2 토폴로지 |
| 18 | + |
| 19 | + |
| 20 | + |
| 21 | +- 마이크로서비스는 단일 목적만 수행하며, 다른 분산 아키텍처보다 서비스 규모가 작음. |
| 22 | +- 각 서비스는 독립적으로 작동하기 위해 필요한 데이터베이스 및 종속 컴포넌트를 자체적으로 포함함. |
| 23 | + |
| 24 | +## 17.3 분산 |
| 25 | + |
| 26 | +1. 마이크로서비스와 분산 아키텍처 |
| 27 | + - 서비스는 자체 프로세스로 실행되며 가상 머신과 컨테이너로 발전 |
| 28 | + - 독립된 프로세스를 통해 공유 인프라에서 발생하는 리소스 제약과 잘못된 분리 문제를 해소 |
| 29 | +2. 기술 발전의 역할 |
| 30 | + - 클라우드 리소스와 컨테이너 기술로 도메인 및 운영 레벨의 디커플링이 현실화 |
| 31 | +3. 성능의 한계 |
| 32 | + - 네트워크 호출과 보안 검증으로 인해 성능 저하 발생 |
| 33 | + - 서비스 세분도 결정이 중요 |
| 34 | +4. 트랜잭션 경계 관리 |
| 35 | + - 트랜잭션이 서비스 경계를 넘지 않도록 설계 필요 |
| 36 | + - 성공의 핵심은 적절한 서비스 세분화 |
| 37 | + |
| 38 | +## 17.4 경계 콘텍스트 |
| 39 | + |
| 40 | +1. 경계 콘텍스트 개념 |
| 41 | + - 각 서비스는 도메인이나 워크플로를 모델링하며, 필요한 모든 요소(클래스, 데이터베이스 스키마 등)를 포함 |
| 42 | + - 커플링을 최소화하기 위해 중복을 선호 |
| 43 | +2. 도메인 분할의 철학 |
| 44 | + - 마이크로서비스는 도메인 도는 서브도메인을 독립적으로 구현 |
| 45 | + - 도메인 주도 설계(DDD)의 논리적 개념을 물리적으로 실현한 결과물 |
| 46 | + |
| 47 | +### 17.4.1 세분도 |
| 48 | + |
| 49 | +1. 세분화의 문제점 |
| 50 | + - 서비스를 지나치게 잘게 나누면 서비스 간 통신 복잡성이 증가. |
| 51 | + - 마이크로서비스는 이름일 뿐, 세분화를 지시하는 명령은 아님 |
| 52 | +2. 서비스 경계 설정의 가이드라인 |
| 53 | + - 목적 : 각 서비스는 도메인을 기반으로 설계하며, 응집력을 높이고 핵심 기능을 담당 |
| 54 | + - 트랜잭션: 여러 엔티티가 관여하는 트랜잭션은 서비스 경계 설정의 단서가 될 수 있음. |
| 55 | + - 코레오그래피 : 서비스 간 통신이 과도하면 더 큰 단위로 통합 고려 |
| 56 | +3. 설계 접근법 |
| 57 | + - 적절한 세분도는 반복적 이터레이션을 통해 다듬어야 함 |
| 58 | + - 초기 설계가 완벽할 수 없으므로 다양한 옵션을 실험하며 최적화 |
| 59 | + |
| 60 | +### 17.4.2 데이터 격리 |
| 61 | + |
| 62 | +1. **데이터 격리의 필요성** |
| 63 | + - 마이크로서비스는 공유 데이터베이스나 스키마 등 통합 지점을 없애고 데이터를 격리. |
| 64 | + - 서비스 세분화 시 데이터 격리를 고려해야 하며, 단순히 데이터베이스 엔티티에 기반한 설계는 지양. |
| 65 | +2. **데이터 분산 접근법** |
| 66 | + - 도메인별로 **진실 공급원(Single Source of Truth)**을 정의하거나, 데이터베이스 복제와 캐시를 활용. |
| 67 | + - 데이터는 아키텍처 전반에 분산되어야 함. |
| 68 | +3. **데이터 격리의 장점** |
| 69 | + - 팀별로 독립적인 데이터베이스 및 스토리지 도구 선택 가능. |
| 70 | + - 다른 팀에 영향을 주지 않고 상황에 맞게 적합한 데이터베이스와 의존성을 선택 가능. |
| 71 | + - 구현 세부 사항에 얽매이지 않는 유연성 제공. |
| 72 | + |
| 73 | +### 17.5 API 레이어 |
| 74 | + |
| 75 | +1. **API 레이어의 역할** |
| 76 | + - 여러 시스템 컨슈머 간의 **프록시** 역할로 간접화하거나, 네이밍 서비스 등 운영 장치와 연결 가능. |
| 77 | + - 다양한 용도로 활용되지만 **비즈니스 로직**은 API 레이어가 아닌 경계 콘텍스트 내부에서 처리해야 함. |
| 78 | +2. **철학적 원칙** |
| 79 | + - API 레이어를 **중재자**나 **오케스트레이션 도구**로 사용하면 마이크로서비스의 철학에 어긋남. |
| 80 | + - 마이크로서비스는 **도메인 분할**에 초점을 맞추며, 기술 분할과 차별화됨. |
| 81 | + |
| 82 | +## 17.6 운영 재사용 |
| 83 | + |
| 84 | +1. **운영 관심사 분리** |
| 85 | + - 모니터링, 로깅, 회로 차단기 등은 서비스별로 운영이 일관되게 관리되어야 함. |
| 86 | + - **사이드카 패턴**: 운영 관심사를 별도의 사이드카 컴포넌트로 처리해 각 서비스에 공통적으로 적용. |
| 87 | +2. **사이드카 패턴의 장점** |
| 88 | + - 공유 인프라팀이 사이드카를 관리 및 업그레이드하며 일관성을 유지. |
| 89 | + - 사이드카는 서비스 메시를 통해 로깅, 모니터링 등을 통합 제어하며 공통 인터페이스 제공. |
| 90 | +3. **서비스 메시와 디스커버리** |
| 91 | + - **서비스 메시**: 모든 마이크로서비스를 하나의 네트워크로 연결해 공통 운영을 제어하는 콘솔 역할. |
| 92 | + - **서비스 디스커버리**: API 레이어에서 요청을 관리하며, 확장성과 탄력성을 지원. |
| 93 | + - 디스커버리 도구를 통해 요청 빈도를 모니터링하고 필요에 따라 서비스 인스턴스를 자동 확장. |
| 94 | + |
| 95 | +## 17.7 프런트엔드 |
| 96 | + |
| 97 | +1. **마이크로서비스와 유저 인터페이스** |
| 98 | + - 마이크로서비스는 유저 인터페이스와 백엔드의 분리를 선호하지만, 실용적인 이유로 완전한 분리가 어려움. |
| 99 | + - 초기 비전에서는 유저 인터페이스가 DDD 원칙에 따라 경계 콘텍스트의 일부로 포함되었으나, 외부 제약으로 인해 실현이 어려움. |
| 100 | +2. **유저 인터페이스 스타일** |
| 101 | + - **모놀리식 프런트엔드**: 단일 유저 인터페이스가 API 레이어를 통해 호출되어 다양한 형태의 웹, 모바일, 데스크톱 애플리케이션을 처리. |
| 102 | + - **마이크로프런트엔드**: 유저 인터페이스를 백엔드 서비스에서 동기적으로 세분화하고 격리. 각 서비스는 자기 서비스에 해당하는 UI를 내보내며, 프런트엔드는 이를 조정. |
| 103 | + - **마이크로프런트엔드 구현**: 리액트와 같은 컴포넌트 기반 웹 프레임워크나 이를 지원하는 오픈 소스 프레임워크를 사용하여 구현. |
| 104 | + |
| 105 | +## **17.8** 통신 |
| 106 | + |
| 107 | +1. **세분도와 통신 스타일** |
| 108 | + - 마이크로서비스를 구축할 때 아키텍트와 개발자는 데이터 격리와 통신 방식을 적절히 세분화하려고 노력. |
| 109 | + - 올바른 통신 스타일을 선택하는 것이 서비스 디커플링에 중요한 영향을 미친다. |
| 110 | +2. **동기 vs 비동기 통신** |
| 111 | + - **동기 통신**: 호출자가 수신자의 응답을 기다리는 방식. |
| 112 | + - **비동기 통신**: 이벤트와 메시지를 활용하며, 주로 이벤트 기반 아키텍처를 사용한다. |
| 113 | + - **비동기 통신 패턴**: 브로커 패턴과 중재자 패턴은 코레오그래피 및 오케스트레이션 패턴으로 나타난다. |
| 114 | +3. **프로토콜 인지 이종 간 상호 운용성** |
| 115 | + - **프로토콜 인지**: 서비스는 다른 서비스를 호출할 때 사용하는 프로토콜을 알고 있어야 하며, 아키텍트는 이를 표준화해야 한다. |
| 116 | + - **이종**: 마이크로서비스는 각기 다른 기술 스택을 사용할 수 있으며, 이는 환경에 따라 다를 수 있다. |
| 117 | + - **상호 운용성**: 여러 서비스가 서로 호출하며 협력하는 과정이 중요하다. |
| 118 | + |
| 119 | +### 17.8.1 코레오그래피와 오케스트레이션 |
| 120 | + |
| 121 | +1. **코레오그래피와 브로커 이벤트 기반 아키텍처** |
| 122 | + - 코레오그래피는 중앙 중재자 없이 각 서비스가 독립적으로 다른 서비스를 호출. |
| 123 | + - 서비스 간 분리된 이벤트를 사용하여 경계 콘텍스트 철학을 따름. |
| 124 | + - 예시: 유저가 요청 시, 필요한 정보를 다른 서비스에서 호출해 보충. |
| 125 | +2. **도메인/아키텍처 동형성** |
| 126 | + - 아키텍처 스타일이 문제에 적합한지 평가하는 특성. |
| 127 | + - 마이크로서비스는 브로커 이벤트 기반 아키텍처와 유사함. |
| 128 | +3. **중재자 패턴** |
| 129 | + - 전역 중재자가 없으므로, 로컬 중재자를 두어 서비스 호출을 조정. |
| 130 | + - 예시: 중재자가 다른 서비스를 호출해 필요한 데이터를 조합. |
| 131 | +4. **복잡한 비즈니스 프로세스와 중재자 역할** |
| 132 | + - 프런트 컨트롤러 패턴을 사용해 하나의 서비스가 여러 타 서비스를 조정. |
| 133 | + - 서비스 복잡도가 증가하지만, 조정 역할이 집중됨. |
| 134 | +5. **오케스트레이션** |
| 135 | + - 비즈니스 프로세스를 다룰 때 오케스트레이션을 사용해 중재자가 서비스를 조정. |
| 136 | + - 서비스 간 커플링을 생성하지만, 중재자가 조정 작업을 전담. |
| 137 | + |
| 138 | +### 17.8.2 트랜잭션과 사가 |
| 139 | + |
| 140 | +1. **트랜잭션과 마이크로서비스** |
| 141 | + - 마이크로서비스는 극도의 디커플링을 추구하지만, 여러 서비스에 걸친 트랜잭션을 조정하는 문제는 아키텍트에게 큰 도전. |
| 142 | + - 트랜잭션을 여러 서비스에 걸쳐 사용하면 마이크로서비스 아키텍처의 디커플링 원칙에 위배되며, 동적 커네이선스 문제가 발생할 수 있음. |
| 143 | + - 트랜잭션 경계는 서비스 세분도를 가늠할 수 있는 지표로 활용되므로, 불필요하게 트랜잭션으로 서비스를 엮기보다는 세분도를 적절히 조정하는 것이 중요. |
| 144 | +2. **사가 패턴 (Saga Pattern)** |
| 145 | + - 분산 트랜잭션을 처리하기 위한 패턴으로, 중재자가 각 서비스 호출을 조정하고 트랜잭션의 성공/실패를 기록. |
| 146 | + - 트랜잭션의 한 부분이 실패하면, 중재자는 이전에 성공한 부분을 되돌리는 보상 트랜잭션을 실행. |
| 147 | + - **보상 트랜잭션**: 실패한 트랜잭션을 되돌리기 위해 각 작업에 대한 언두 로직을 작성. |
| 148 | +3. **트랜잭션 설계의 복잡성** |
| 149 | + - 사가 패턴을 사용하면 네트워크 트래픽이 많이 발생하고, 비동기 요청과 보류된 트랜잭션 상태로 인해 설계가 복잡해짐. |
| 150 | + - 트랜잭션 작업마다 언두 로직을 개발해야 하므로, 설계, 구현, 디버깅에 큰 부담이 될 수 있음. |
| 151 | + - 트랜잭션을 걸기보다는 세분도를 바로잡는 것이 기본 원칙이지만, 예외적인 경우에만 사가 패턴을 사용하는 것이 권장됨. |
| 152 | + |
| 153 | +### 17.9 아키텍처 특성 등급 |
| 154 | + |
| 155 | +1. **마이크로서비스 아키텍처 특성** |
| 156 | + - **별점 1개**: 마이크로서비스 아키텍처는 자동화 배포, 시험성, 그리고 현대 엔지니어링 프랙티스를 매우 잘 지원. |
| 157 | + - **별점 5개**: 확장성, 탄력성, 진화성 등 주요 강점으로, 마이크로서비스는 분산 시스템에서 높은 내고장성, 신뢰성을 지원. |
| 158 | +2. **확장성 및 탄력성** |
| 159 | + - 마이크로서비스 아키텍처는 고도로 분리된 작은 배포 단위를 통해 빠르게 변화하는 시스템을 지원. |
| 160 | + - **확장성**: 마이크로서비스는 성능 문제가 발생할 수 있지만, 분산 아키텍처는 여러 서비스의 확장을 통해 문제를 해결. |
| 161 | + - **탄력성**: 운영 자동화 및 지능적 통합을 통해 아키텍처의 탄력성을 강화. |
| 162 | +3. **성능 및 통신** |
| 163 | + - 분산 아키텍처에서의 성능 오버헤드는 주로 잦은 네트워크 호출과 보안 체크에 의한 것. 이를 해결하기 위해 데이터 캐시, 데이터 복제 등의 기술이 사용됨. |
| 164 | + - **네트워크 호출 감소**: 과도한 네트워크 호출을 줄이고 성능을 개선하기 위해 코레오그래피 스타일을 선호. |
| 165 | +4. **도메인 중심 아키텍처** |
| 166 | + - 마이크로서비스는 각 서비스의 경계와 도메인이 일치해야 하며, 도메인 중심적인 아키텍처를 지향. |
| 167 | + - **디커플링**: 고도의 디커플링을 추구하여, 시스템의 변화에 유연하게 대응할 수 있음. |
| 168 | +5. **마이크로서비스의 도전** |
| 169 | + - 마이크로서비스 아키텍처는 디커플링을 극대화하려는 철학으로, 이를 잘 구현하면 엄청난 이점을 얻을 수 있지만, 그 과정에서 복잡성도 증가. |
| 170 | + - 규칙을 이해하고 이를 지능적으로 깨뜨릴 수 있어야 아키텍처의 이점을 극대화할 수 있음. |
| 171 | + |
| 172 | +마이크로서비스 아키텍처는 유연성과 확장성을 제공하지만, 성능 최적화와 트랜잭션 관리 등 복잡한 도전 과제를 동반하므로 신중한 접근이 필요하다. |
0 commit comments