54 lines
6.4 KiB
Markdown
54 lines
6.4 KiB
Markdown
---
|
|
id: P-REINFORCE-AUTO-6DFA0C
|
|
category: "10_Wiki/💡 Topics/Programming & Language"
|
|
confidence_score: 0.90
|
|
tags: [auto-reinforced]
|
|
last_reinforced: 2026-04-20
|
|
github_commit: "[P-Reinforce] Continuous Worker - 마이크로서비스 아키텍처 (MSA)"
|
|
---
|
|
|
|
# [[마이크로서비스 아키텍처 (MSA)|마이크로서비스 아키텍처 (MSA)]]
|
|
|
|
## 📌 한 줄 통찰 (The Karpathy Summary)
|
|
> 마이크로서비스 아키텍처(MSA)는 단일 애플리케이션을 비즈니스 도메인을 중심으로 모델링된 작고 자율적이며 독립적으로 배포 가능한 서비스들의 모음으로 구성하는 소프트웨어 설계 접근 방식입니다 [1-3]. 이는 기존의 모놀리식(Monolithic) 아키텍처와 대비되며, 각 서비스는 자체 프로세스에서 실행되고 HTTP REST나 비동기 메시징 큐와 같은 가벼운 메커니즘을 통해 통신합니다 [1, 2, 4]. 이 아키텍처는 조직의 민첩성을 높이고 기술적 이질성을 수용하며 복잡한 시스템의 확장성을 향상시킵니다 [1, 4-6].
|
|
|
|
## 📖 구조화된 지식 (Synthesized Content)
|
|
**핵심 개념 및 특징 (Core Concepts & Characteristics)**
|
|
* **관심사의 분리 (Separation of Concerns):** MSA는 애플리케이션을 "사용자 관리"나 "결제 처리"와 같은 특정 비즈니스 기능을 처리하는 작고 세분화된 서비스로 나눔으로써, 관심사의 분리(SoC)를 매우 세밀한 수준까지 적용합니다 [4, 7, 8].
|
|
* **독립성과 자율성:** 각 서비스는 고유한 코드베이스, CI/CD 파이프라인, 자체 데이터 저장소를 가지며 단일 비즈니스 요구사항에 집중합니다 [4, 8]. 중앙 집중식 거버넌스에서 벗어나 서비스별로 가장 적합한 도구와 기술 스택을 선택할 수 있는 자율성을 부여합니다 [4].
|
|
|
|
**마이크로서비스 아키텍처의 장점 (Advantages)**
|
|
* **민첩성 및 병렬 개발:** 대규모 시스템을 관리 가능한 조각으로 나누어 여러 팀이 병렬로 작업할 수 있습니다 [1]. 전체 애플리케이션을 재배포할 필요 없이 업데이트를 더 자주, 개별적으로 릴리스할 수 있습니다 [1].
|
|
* **기술의 이질성 (Technology Heterogeneity):** 단일 비즈니스 유닛 내에서 각기 다른 기술을 지원하므로, 개발팀은 상황에 맞는 가장 적합한 프로그래밍 언어와 폴리글랏(Polyglot) 영속성 환경을 도입할 수 있습니다 [4, 6].
|
|
* **회복성 (Resilience & Fault Isolation):** 결함 격리 수준이 높아 한 서비스 단위에 장애가 발생하더라도 시스템 전체 비즈니스에 미치는 영향을 최소화할 수 있습니다 [6].
|
|
|
|
**단점 및 과제 (Disadvantages & Challenges)**
|
|
* **분산 시스템의 복잡성:** 네트워크를 통한 통신 메커니즘 구현, 부분적 장애(Partial failure) 처리, 여러 서비스에 걸쳐 일어나는 요청의 추적 및 상호 작용 테스트가 훨씬 어렵습니다 [9-11].
|
|
* **비용 및 리소스 소모 증가:** 수많은 서비스를 배포하고 관리하는 데 있어 DevOps 및 오케스트레이션 도구에 대한 높은 리소스 요구사항이 발생합니다 [11, 12]. 또한, 각 서비스 인스턴스가 독립된 JVM 런타임이나 개별 가상 머신(VM)에서 실행되어야 하므로 메모리 소비와 인프라 유지 비용이 크게 증가합니다 [9, 13].
|
|
|
|
**서비스 구성 패턴 (Composition Patterns)**
|
|
* **Aggregator Pattern:** 여러 다른 서비스를 차례대로 호출하여 결과를 수집합니다 [14].
|
|
* **Proxy Pattern:** 개별 서비스를 호출할 때 프록시 계층을 두어 보안이나 라우팅을 제공합니다 [14].
|
|
* **Branch Pattern:** 한 서비스가 동시에 두 개 이상의 다른 서비스와 통신합니다 [14].
|
|
* **Chained Pattern:** 서비스들을 사슬처럼 연결하여 한 서비스의 출력이 다음 서비스의 입력이 되도록 합니다 [14].
|
|
* **Shared Resource Pattern:** 클라이언트나 로드 밸런서가 필요에 따라 각 서비스와 직접 통신합니다 [15].
|
|
|
|
**넷플릭스(Netflix)의 전환 사례**
|
|
* 넷플릭스는 7년에 걸쳐 기존의 모놀리식 RDBMS 아키텍처를 마이크로서비스로 전환했습니다 [16, 17].
|
|
* 주요 우선순위는 효율성, 혁신, 그리고 99.999%에 달하는 고가용성(안정성) 확보였습니다 [3, 18].
|
|
* 무상태(Stateless) 서비스 원칙, 수직적 확장(Scale up) 대신 수평적 확장(Scale out) 선택, 다중 리전(Multi-Regional) 복제, 그리고 'Chaos Monkey'를 통한 자동화된 파괴 테스트 등을 적용하여 시스템 회복성을 갖추었습니다 [17, 19].
|
|
|
|
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
|
- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
|
|
- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
|
|
|
|
## 🔗 지식 연결 (Graph)
|
|
- **Related Topics:** [[관심사의 분리 (Separation of Concerns)|관심사의 분리 (Separation of Concerns)]], [[모놀리식 아키텍처 (Monolithic Architecture)|모놀리식 아키텍처 (Monolithic Architecture)]], [[단일 책임 원칙 (SRP)|단일 책임 원칙 (SRP)]], [[클린 아키텍처 (Clean Architecture)|클린 아키텍처 (Clean Architecture)]]
|
|
- **Projects/Contexts:** [[넷플릭스 (Netflix) 마이크로서비스 도입 사례|넷플릭스 (Netflix) 마이크로서비스 도입 사례]], [[Cosmos 플랫폼 (Netflix)|Cosmos 플랫폼 (Netflix)]]
|
|
- **Contradictions/Notes:** 소스에 따르면 MSA는 배포 독립성, 빠른 릴리스, 확장성이라는 분명한 장점을 지니지만 [1, 3, 12], 분산 시스템으로 인한 복잡성(네트워크 지연, 부분적 실패, 테스트의 어려움) 및 많은 수의 가상 머신(VM)/JVM 런타임 운영에 따른 메모리 오버헤드와 비용 폭증이라는 상충 관계(Trade-off)를 명확히 가집니다 [9-11, 13]. 따라서 단순한 소규모 프로젝트보다는 빠르고 복잡하게 확장하는 대규모 시스템에 적합한 아키텍처입니다 [12].
|
|
|
|
---
|
|
*Last updated: 2026-04-18*
|
|
- Raw Source: 00_Raw/2026-04-20/마이크로서비스 아키텍처 (MSA).md
|
|
---
|