마이크로서비스 아키텍처: 개념, 동인 및 구현 패턴

1. 소개 및 개요

본 내용은 Software Engineering Radio 팟캐스트(에피소드 213)에서 Johannes Thönes와 James Lewis가 마이크로서비스 주제에 대해 논의한 내용을 기반으로 합니다. 이 대화는 2015년 초, 거대한 모놀리식 애플리케이션 유지보수의 어려움에 대한 대응으로 주목받기 시작한 이 아키텍처 스타일에 대한 정의, 동기 및 실무적 고려사항을 탐구합니다.

2. 마이크로서비스 정의

마이크로서비스는 작고 집중된 애플리케이션 구성 요소로 개념화됩니다.

2.1 핵심 특성

논의에 따르면, 마이크로서비스는 다음과 같은 몇 가지 핵심 속성을 가집니다:

독립적 배포: 다른 서비스에 변경을 요구하지 않고 배포할 수 있습니다.
독립적 확장: 특정 부하에 따라 수평 또는 수직으로 확장할 수 있습니다.
독립적 테스트: 격리된 상태에서 검증할 수 있습니다.
단일 책임: 변경되거나 교체되어야 하는 주된 이유가 하나입니다. 하나의 응집된 작업을 수행하며 쉽게 이해할 수 있습니다.

2.2 단일 책임의 예시

마이크로서비스가 수행하는 "단일 작업"은 기능적이거나 교차 기능적(비기능적)일 수 있습니다:

기능적: 특정 도메인 리소스를 제공 (예: 사용자 서비스, 게시글 서비스, 보험의 위험 계산 서비스).
교차 기능적: 메시지를 읽고 비즈니스 로직을 적용하여 전달하는 큐 프로세서. 캐싱이나 로깅과 같은 특정 비기능적 요구사항에 대한 책임.

3. 마이크로서비스의 부상

3.1 인기 동인

마이크로서비스의 인기는 업계 전반의 보편적인 고통 지점인 관리 불가능한 모놀리식 애플리케이션에 기인합니다. 조직들은 5-10년 동안 성장하여 너무 수정하기 어렵거나 SaaS로 배포하거나 클라우드에서 효과적으로 확장하기 어려워진 애플리케이션에 직면하고 있습니다.

3.2 기술 부채 해결

마이크로서비스는 이러한 모놀리스를 프로세스 외부에서 실행되는 더 작고 협력하는 구성 요소로 분할하는 해결책으로 등장했습니다. Netflix와 같은 기업들이 대규모로 시연한 이 접근 방식은 독립적인 유지보수, 확장 및 교체를 가능하게 합니다. 핵심 동인은 소프트웨어를 더 빠르게 제공하고 모놀리식 아키텍처에 의해 방해받는 지속적 전달과 같은 실천법을 활용해야 하는 필요성입니다.

4. 도입 및 구현 패턴

4.1 그린필드 vs 브라운필드

핵심 질문은 마이크로서비스로 새 프로젝트를 시작할 것인지(그린필드), 아니면 기존 모놀리스를 리팩터링할 것인지(브라운필드)입니다. 논의는 경험적으로 대부분의 조직이 모놀리스로 시작한 후 나중에 리팩터링하며, 기존 코드베이스 내에서 경계가 분명한 컨텍스트와 분리선을 식별하는 과제에 직면한다고 언급합니다.

4.2 운영 복잡성

팟캐스트 발췌문은 공간 제한으로 인해 운영 복잡성과 DevOps에 미치는 영향에 대한 완전한 논의가 불가능했다고 언급합니다. 이는 마이크로서비스가 개발 및 확장성 문제를 해결하는 반면, 모니터링, 배포 오케스트레이션 및 네트워크 신뢰성에서 새로운 과제를 야기한다는 것을 의미합니다.

5. 핵심 통찰 및 분석

핵심 통찰

마이크로서비스는 만능 해결책 기술이 아닙니다. 이는 모놀리식 개발의 병목 현상에 대한 조직적, 경제적 대응입니다. Netflix 사례에서 암시된 바와 같이, 진정한 가치 제안은 독립적이고 병렬적인 가치 전달 흐름을 가능하게 하는 것입니다. 이 아키텍처는 단일 코드베이스에서 작업하는 대규모 팀을 괴롭히는 조정 비용과 배포 마찰을 직접적으로 겨냥합니다. 이 문제는 Melvin Conway의 격언 "시스템을 설계하는 조직은... 해당 조직의 커뮤니케이션 구조의 복사본인 설계를 생산하도록 제약된다"로 공식화되었습니다. 마이크로서비스는 바람직한 커뮤니케이션 구조를 강제하는 시스템을 설계함으로써 이를 뒤집으려 시도합니다.

논리적 흐름

서술은 다음과 같은 설득력 있는 인과 관계 체인을 따릅니다: (1) 모놀리스는 기술 부채를 축적하고 변화에 마비됩니다. (2) 비즈니스는 클라우드 확장성과 지속적 전달을 요구합니다. (3) 모놀리식 아키텍처는 결합도 때문에 이러한 목표와 근본적으로 호환되지 않습니다. (4) 해결책은 모놀리스를 경계가 분명한 컨텍스트를 따라 분할하여 독립적으로 배포 가능한 단위를 만드는 것입니다. 이 논리는 타당하지만 분할의 "방법"인 엄청난 중간 복잡성을 간과하고 있습니다.

강점과 결점

강점: 독립적 배포 가능성을 주요 특성으로 강조한 점은 정확합니다. 이것이 팀 자율성과 더 빠른 릴리스 주기를 가능하게 하는 지렛대입니다. 콘웨이의 법칙과 CQRS(생략된 주제로 언급됨)과의 연결은 작용하는 더 깊은 사회-기술적 패턴에 대한 인식을 보여줍니다.

결점: 2015년의 관점은 "단일 책임"을 정의하는 용이성에 대해 눈에 띄게 낙관적입니다. 이후의 업계 경험은 이것이 가장 어려운 부분이며, 잘못 정의된 서비스 경계가 분산된 모놀리스를 초래하는 저주임을 드러냈습니다. 대본은 또한 운영 오버헤드를 위험할 정도로 경시합니다. Fowler의 기념비적 글이 나중에 상세히 설명한 바와 같이, 개발 복잡성을 운영 복잡성으로 교환하게 됩니다. Docker를 "인기 있는 도구"로 언급한 것은 역사적 스냅샷입니다. 컨테이너화 생태계는 마이크로서비스가 대규모로 실용적으로 실행 가능하게 만든 빠진 운영 인프라였습니다.

실행 가능한 통찰

리더를 위해: 유행 때문에 마이크로서비스를 시작하지 마십시오. 변경 리드 타임과 배포 빈도를 측정하는 것으로 시작하십시오. 코드베이스 조정으로 인해 이들이 나쁘다면 마이크로서비스를 고려하십시오. 아키텍트를 위해: 주요 설계 도구는 기술 체크리스트가 아닌 도메인 주도 설계(DDD) 컨텍스트 맵입니다. 기술 계층이 아닌 비즈니스 역량을 기반으로 경계를 정의하십시오. 팀을 위해: 사전에 플랫폼 엔지니어링에 투자하십시오—자동화된 배포, 서비스 디스커버리, 관측 가능성은 사후 고려사항이 아닙니다. 그것들은 기초입니다. 제안된 경로—모놀리스에서 리팩터링—는 여전히 가장 현명합니다. 스트랭글러 피그 패턴을 사용하여 모놀리스의 일부를 서비스로 점진적으로 교체하십시오. 이는 위험을 관리하고 학습을 가능하게 합니다.

6. 기술 프레임워크 및 수학적 모델

팟캐스트는 대화 형식이지만, 기본 원칙은 공식화될 수 있습니다. 핵심 모델은 팀 규모(N), 커뮤니케이션 경로 및 아키텍처 결합도 간의 관계입니다.

N개의 팀이 있는 모놀리식 아키텍처에서 잠재적 커뮤니케이션 경로는 $O(N^2)$로 확장됩니다. 한 모듈의 변경이 다른 많은 모듈에 영향을 미칠 수 있기 때문입니다. 이는 조정 오버헤드를 생성합니다. 마이크로서비스는 경계가 분명한 컨텍스트와 API를 강제함으로써 이를 줄이려 합니다. 목표는 네트워크 호출을 통해 교차 서비스 커뮤니케이션 비용 $C_{comm}$을 명시적으로 높게 만들어, 변경 비용 $C_{internal}$이 낮은 서비스 내부의 강력한 모듈성을 장려하는 것입니다.

변화 전파 확률($P_{prop}$)에 대한 단순화된 모델은 다음과 같을 수 있습니다:

$P_{prop} \approx \frac{C_{comm}}{C_{comm} + C_{internal}}$

잘 설계된 마이크로서비스 아키텍처는 $C_{comm}$(네트워크 지연, API 버전 관리)을 경계를 넘는 변경의 지배적 요소로 만들어 관련 없는 변경에 대한 $P_{prop}$를 최소화합니다.

7. 실험 결과 및 사례 연구

팟캐스트는 Netflix를 주요 사례 연구로 인용합니다. 2015년까지 Netflix는 모놀리식 백엔드를 수백 개의 마이크로서비스로 분해하여 다음과 같은 것을 가능하게 했습니다:

독립적 확장: 영화 추천이나 결제와 같은 서비스는 피크 부하 시 독립적으로 확장될 수 있습니다.
신속한 혁신: 팀은 전체 스택 조정 없이 하루에 여러 번 서비스를 배포할 수 있습니다.
기술 이질성: 다른 서비스는 작업에 가장 적합한 언어(예: Java, Node.js)로 작성될 수 있습니다.

차트 설명 (가상): 모놀리식 애플리케이션과 마이크로서비스 아키텍처를 두 축으로 비교하는 막대 차트: (1) 배포 빈도 (일일 배포): 모놀리스는 낮은 막대(예: 0.1), 마이크로서비스는 높은 막대(예: 50+)를 보여줍니다. (2) 장애로부터의 평균 복구 시간(MTTR): 모놀리스는 높은 막대(예: 4시간), 마이크로서비스는 낮은 막대(예: 30분)를 보여줍니다. 장애가 특정 서비스로 격리될 수 있기 때문입니다.

DevOps 현황 보고서에서 인용된 후속 연구들은 느슨하게 결합된 서비스 지향 아키텍처와 더 높은 소프트웨어 전달 성과를 통계적으로 연관시켰습니다.

8. 분석 프레임워크: 실용적 예시

시나리오: 전자상거래 모놀리스가 업데이트에 어려움을 겪고 있습니다. "결제" 기능 변경은 전체 회귀 테스트가 필요하며 "상품 카탈로그" 업데이트와 충돌합니다.

프레임워크 적용:

경계가 분명한 컨텍스트 식별: 도메인 주도 설계를 사용하여 핵심 도메인 식별: 주문, 카탈로그, 재고, 사용자 관리, 결제.
서비스 경계 정의: 각 컨텍스트에 대한 마이크로서비스 생성. 주문 서비스는 결제 로직과 주문 데이터를 소유합니다.
계약 수립: 명확한 API 정의. 주문 서비스는 결제 서비스의 processPayment(orderId, amount) API와 재고 서비스의 reserveStock(itemId, quantity) API를 호출합니다.
데이터 소유권: 각 서비스는 자체 데이터베이스를 소유합니다. 주문 서비스는 자체 "orders" 테이블을 가지며, 재고 데이터베이스를 직접 쿼리하지 않습니다.
배포 및 관측 가능성: 각 서비스는 컨테이너화되어 독립적으로 배포되며, 메트릭(지연 시간, 오류율)을 중앙 대시보드에 게시합니다.

결과: 결제 팀은 이제 카탈로그나 재고 팀의 개입 없이 주문 서비스에 대한 업데이트를 배포할 수 있어, 조정 오버헤드를 크게 줄이고 배포 빈도를 높입니다.

9. 미래 적용 및 연구 방향

마이크로서비스의 진화는 2015년 관점을 넘어 계속됩니다:

서비스 메시: Istio 및 Linkerd와 같은 기술이 인프라 계층에서 교차 관심사(보안, 관측 가능성, 트래픽 관리)를 처리하기 위해 등장하여 개별 서비스의 코드 부담을 줄였습니다.
서버리스 & FaaS: 함수형 서비스(FaaS, 예: AWS Lambda)는 마이크로서비스의 극단적인 형태로, 운영 복잡성을 완전히 클라우드 공급자에게 넘기고 더 세분화된 확장을 가능하게 합니다.
AI/ML 통합: 마이크로서비스는 ML 모델을 독립적인 예측 서비스로 배포하는 사실상의 패턴이 되어, A/B 테스트와 알고리즘의 신속한 반복을 가능하게 하고 있습니다.
엣지 컴퓨팅: IoT 및 실시간 분석 시나리오에서 낮은 지연 시간 처리를 위해 경량 마이크로서비스를 엣지 장치에 배포합니다.
연구 초점: 자동화된 서비스 분해 도구, 분산 시스템의 지능형 장애 예측, 서비스 코레오그래피 상호작용의 형식적 검증에 대한 향후 연구가 필요합니다.

10. 참고문헌

Lewis, J., & Fowler, M. (2014). Microservices. MartinFowler.com. Retrieved from https://martinfowler.com/articles/microservices.html
Newman, S. (2015). Building Microservices. O'Reilly Media.
Forsgren, N., Humble, J., & Kim, G. (2018). Accelerate: The Science of Lean Software and DevOps. IT Revolution Press.
Conway, M. E. (1968). How Do Committees Invent? Datamation, 14(5), 28-31.
Google Cloud. (2019). The 2019 Accelerate State of DevOps Report. DORA.
Netflix Technology Blog. (Various). https://netflixtechblog.com/