Files
2nd/01_Archive/2026-04-20/Microservices-Architecture.md

2.6 KiB

id, category, confidence_score, tags, last_reinforced, github_commit
id category confidence_score tags last_reinforced github_commit
P-REINFORCE-AI-048 10_Wiki/💡 Topics/Software Architecture 0.99
microservice
architecture
distributed system
scalability
2026-06-XX [P-Reinforce] Processed Microservices-Architecture.md

Microservices-Architecture (마이크로서비스 아키텍처)

📌 한 줄 통찰 (The Karpathy Summary)

하나의 거대한 애플리케이션을 작고 독립적인 서비스들의 집합으로 나누어, 각 서비스를 독립적으로 개발, 배포, 확장할 수 있게 하는 분산 시스템 설계 방식이다.

📖 구조화된 지식 (Synthesized Content)

  • 정의: 단일 책임 원칙(SRP)을 아키텍처 수준까지 끌어올린 개념이다. 비즈니스 도메인별로 독립적인 서비스 경계(Bounded Context)를 설정하고, 각 서비스를 자체 데이터베이스와 통신 메커니즘으로 운영한다.
  • 장점 (Scalability & Resilience):
    1. 독립적 배포: 특정 기능의 장애가 전체 시스템에 영향을 미치지 않는다 (Fault Isolation).
    2. 기술 스택 자유도: 각 서비스는 가장 적합한 언어와 데이터베이스를 선택할 수 있다 (Polyglot Persistence/Programming).
    3. 확장성: 트래픽이 몰리는 특정 서비스만 독립적으로 자원을 증설할 수 있다.
  • 주요 과제 및 해결책:
    1. 분산 트랜잭션 관리: 여러 서비스에 걸친 데이터 일관성 유지가 어렵다. (해결책: Saga 패턴, 이벤트 기반 아키텍처).
    2. 서비스 간 통신 오버헤드: 네트워크 호출이 빈번하여 지연 시간이 발생할 수 있다. (해결책: API Gateway 도입, 메시지 큐 활용).

⚠️ 모순 및 업데이트 (Contradictions & RL Update)

  • 과거 데이터와의 충돌: 마이크로서비스가 모든 문제의 해결책은 아니다. 서비스 경계 설정 실패(Poor Bounded Context Identification)는 오히려 복잡성만 높이는 '분산 트랜잭션 지옥'을 만들 수 있다.
  • 정책 변화: MSA 도입 시, 서비스 간 통신 규약 (API Contract) 정의가 가장 중요한 첫 번째 단계이며, 이를 위한 API 게이트웨이 및 서비스 메시(Service Mesh)의 활용이 표준으로 자리 잡고 있다.

🔗 지식 연결 (Graph)