Microservices Architecture
Microservices Architecture(마이크로서비스 아키텍처) 는 복잡한 애플리케이션을 작고 독립적으로 배포 가능한 서비스 단위로 분해하여, 각 서비스가 자체 데이터와 비즈니스 로직을 관리하고, API 를 통해 상호작용하는 아키텍처 스타일이다. 이 구조는 확장성과 장애 격리, 빠른 배포, 기술 스택의 다양화, 팀별 독립 개발 등 다양한 이점을 제공한다. 반면, 서비스 간 통신, 데이터 일관성, 운영 관리 복잡성 등 새로운 도전 과제도 동반한다. Netflix, Amazon 등 글로벌 IT 기업들이 대표적으로 적용하고 있다.
배경
모놀리식 아키텍처의 한계:
- 대규모 애플리케이션에서 코드베이스 복잡성 증가
- 부분적 변경을 위해 전체 애플리케이션 재배포 필요
- 기술 스택 다양성 제한
- 확장 시 전체 애플리케이션 스케일링 필요
역사적 발전 과정:
- 2000 년대 초: SOA (Service-Oriented Architecture) 등장
- 2005-2010 년: Amazon, Netflix 등이 확장성 문제 해결을 위해 서비스 분해 실험
- 2011 년: " 마이크로서비스 " 용어 등장
- 2014 년: Martin Fowler 와 James Lewis 가 마이크로서비스 개념 정리
- 2015 년 이후: 주류 아키텍처 패턴으로 확산
기술적 배경:
- 클라우드 컴퓨팅의 성숙
- 컨테이너화 기술 (Docker) 발전
- API 중심 설계 패러다임 확산
- DevOps 문화와 자동화 도구 발전
- 쿠버네티스 등 오케스트레이션 플랫폼 성숙
- 클라우드 네이티브 환경에서 자동 확장성 제공
마이크로서비스 아키텍처는 2000 년대 초반 대규모 웹 서비스의 확산과 함께 등장했다. 초기에는 Amazon 과 Netflix 같은 기업들이 모놀리식 시스템의 한계를 극복하기 위해 서비스 지향 아키텍처 (SOA) 를 발전시키면서 시작되었다.
목적 및 필요성
비즈니스 목적:
- 개발 속도 향상: 팀별 독립적 개발 및 배포로 출시 시간 단축
- 기술 혁신 촉진: 서비스별 최적 기술 스택 선택 가능
- 시장 적응성: 빠른 기능 추가 및 변경으로 시장 변화 대응
- 비용 최적화: 필요한 서비스만 확장하여 리소스 효율성 증대
기술적 필요성:
- 확장성: 서비스별 독립적 확장으로 성능 최적화
- 장애 격리: 일부 서비스 장애가 전체 시스템에 미치는 영향 최소화
- 기술 다양성: 서비스 특성에 맞는 최적 기술 스택 활용
- 유지보수성: 작은 단위의 코드베이스로 이해 및 수정 용이
핵심 개념
Microservices Architecture(마이크로서비스 아키텍처) 는 하나의 대규모 애플리케이션을 독립적으로 배포, 확장, 관리할 수 있는 작은 서비스 (마이크로서비스) 들의 집합으로 구성하는 아키텍처 스타일이다.
주요 개념
서비스 분해 (Service Decomposition)
- 단일 책임 원칙 (Single Responsibility Principle) 기반의 서비스 설계
- 비즈니스 도메인 중심의 경계 설정 (Domain-Driven Design, DDD)
- 느슨한 결합 (Loose Coupling) 과 높은 응집도 (High Cohesion) 추구
독립성 (Independence)
- 개발, 배포, 확장의 독립성
- 서비스별 전용 데이터베이스 (Database per Service)
- 기술 스택의 자유로운 선택 (Polyglot Programming)
분산 시스템 특성
- 네트워크를 통한 서비스 간 통신
- 분산 데이터 관리 및 일관성 처리
- 장애 격리 (Fault Isolation) 및 복원력 (Resilience)
API 기반 통신
- RESTful API, gRPC, 메시징 시스템 활용
- 서비스 디스커버리 (Service Discovery) 메커니즘
- 비동기 통신 패턴 지원
DevOps 통합
- 지속적 통합/배포 (CI/CD) 파이프라인
- 컨테이너화 (Containerization) 및 오케스트레이션
- 모니터링 및 관찰 가능성 (Observability)
실무 구현 연관성 분석
개발 측면:
- 팀 구조: Conway’s Law 에 따라 조직 구조가 아키텍처에 반영
- 코드베이스: 서비스별 독립적인 저장소 관리
- 테스팅: 단위 테스트, 통합 테스트, 계약 테스트 (Contract Testing) 전략
운영 측면:
- 인프라스트럭처: 클라우드 네이티브 환경에서 컨테이너 기반 배포
- 모니터링: 분산 추적 (Distributed Tracing), 로그 집계, 메트릭 수집
- 보안: 서비스 메시 (Service Mesh) 활용한 보안 정책 적용
데이터 측면:
- 데이터 일관성: 이벤트 소싱 (Event Sourcing), SAGA 패턴 활용
- 데이터 동기화: 이벤트 드리븐 아키텍처 (Event-Driven Architecture) 구현
- 캐싱: 분산 캐싱 전략 및 캐시 무효화 처리
주요 기능 및 역할
서비스 분해 (Service Decomposition)
- 비즈니스 기능별 서비스 분리
- 독립적인 배포 단위 생성
- 팀 구조와 서비스 구조 일치 (Conway’s Law 적용)
서비스 통신 (Service Communication)
- REST API, GraphQL, gRPC 등을 통한 동기 통신
- 메시지 큐, 이벤트 스트림을 통한 비동기 통신
- 서비스 간 계약 정의 및 버전 관리
데이터 관리 (Data Management)
- 서비스별 독립적 데이터베이스 운영
- 분산 트랜잭션 처리
- 데이터 일관성 보장 메커니즘
운영 및 모니터링
- 분산 추적 (Distributed Tracing)
- 중앙집중식 로깅
- 서비스 헬스 체크 및 장애 감지
특징
독립성 (Independence)
- 개발 독립성: 각 팀이 독립적으로 서비스 개발 가능
- 배포 독립성: 다른 서비스에 영향 없이 개별 서비스 배포
- 기술 독립성: 서비스별 최적 기술 스택 선택 가능
- 확장 독립성: 필요에 따라 개별 서비스만 확장
분산성 (Distribution)
- 네트워크 기반 통신: 서비스 간 네트워크를 통한 상호작용
- 지리적 분산: 여러 데이터센터에 서비스 분산 배치 가능
- 로드 밸런싱: 트래픽을 여러 인스턴스에 분산
탄력성 (Resilience)
- 장애 격리: 개별 서비스 장애가 전체 시스템에 전파되지 않음
- 자동 복구: 헬스 체크를 통한 자동 재시작
- 백프레셔 처리: 부하 상황에서의 적절한 대응 메커니즘
핵심 원칙
단일 책임 원칙 (Single Responsibility Principle)
- 각 서비스는 하나의 비즈니스 기능에만 집중
- 명확한 서비스 경계 정의
- 높은 응집도 추구
자율성 (Autonomy)
- 독립적인 개발, 배포, 확장
- 서비스별 팀 소유권 (Team Ownership)
- 의사결정의 분산화
분산 거버넌스 (Decentralized Governance)
- 중앙 집중식 통제 최소화
- 서비스별 기술 선택 자유
- 표준화와 자율성의 균형
장애 대비 설계 (Design for Failure)
- 장애를 예상하고 대비하는 설계
- 우아한 성능 저하 구현
- 빠른 복구 메커니즘
진화 가능성 (Evolvability)
- 변화에 대한 유연한 대응
- 하위 호환성 유지
- 점진적 업그레이드 지원
주요 원리
서비스 분해 원리
마이크로서비스 경계를 정의하는 가장 효과적인 방법 중 하나는 비즈니스 도메인을 기반으로 하는 것이다. 도메인 주도 설계는 이러한 접근 방식을 제공한다.
graph TD A[모놀리식 애플리케이션] --> B[비즈니스 기능 분석] B --> C[도메인 경계 식별] C --> D[서비스 후보 정의] D --> E[데이터 의존성 분석] E --> F[서비스 경계 확정] F --> G[마이크로서비스 설계] H[DDD 적용] --> C I[컨웨이 법칙 고려] --> D J[트랜잭션 경계 분석] --> E
마이크로서비스 분해는 비즈니스 도메인을 중심으로 진행된다. 도메인 주도 설계 (DDD) 의 경계 컨텍스트 (Bounded Context) 개념을 활용하여 서비스 간 명확한 경계를 설정한다.
API 중심 설계 (API-First Design)
API 를 구현하기 전에 API 를 먼저 설계하는 접근 방식으로, 클라이언트와 서버 개발 팀이 독립적으로 작업할 수 있게 한다.
프로세스:
- API 명세 작성 (OpenAPI/Swagger 등)
- API 계약에 대한 이해관계자 동의 확보
- 모의 서버 (Mock Server) 생성으로 병렬 개발 지원
- API 구현 및 계약 테스트
데이터 관리 원리
마이크로서비스에서는 각 서비스가 자체 데이터베이스를 소유하며, 서비스 간 데이터 공유는 API 를 통해서만 이루어진다. 분산 트랜잭션은 SAGA 패턴을 통해 관리된다.
자율성과 느슨한 결합
마이크로서비스의 핵심 가치 중 하나는 서비스 팀의 자율성이다. 이를 위해 서비스 간의 느슨한 결합이 필수적이다.
원칙:
- 동기적 호출 최소화
- API 버전 관리 전략 수립
- 공유 데이터베이스 지양
- 비동기 통신 활용
- 서비스별 독립적인 배포 파이프라인 구축
내결함성 설계
분산 시스템에서는 네트워크 지연, 서비스 장애 등 다양한 장애 상황이 발생할 수 있다. 마이크로서비스는 이러한 장애에 대비한 설계가 필요하다.
패턴:
- 서킷 브레이커 (Circuit Breaker): 장애 서비스로의 호출을 차단하여 시스템 보호
- 타임아웃 (Timeout): 응답 지연에 대한 방어 메커니즘
- 재시도 (Retry): 일시적 장애에 대응하기 위한 자동 재시도
- 폴백 (Fallback): 서비스 호출 실패 시 대체 응답 제공
- 벌크헤드 (Bulkhead): 장애 격리를 위한 리소스 할당 제한
작동 원리 및 방식
요청 처리 흐름
sequenceDiagram participant C as Client participant AG as API Gateway participant US as User Service participant OS as Order Service participant PS as Payment Service participant MB as Message Broker C->>AG: 주문 요청 AG->>AG: 인증/인가 검증 AG->>US: 사용자 정보 조회 US->>AG: 사용자 정보 반환 AG->>OS: 주문 생성 요청 OS->>OS: 주문 데이터 저장 OS->>MB: 주문 생성 이벤트 발행 MB->>PS: 주문 생성 이벤트 전달 PS->>PS: 결제 처리 준비 OS->>AG: 주문 ID 반환 AG->>C: 주문 완료 응답
- 클라이언트 요청: 모든 클라이언트 요청은 API 게이트웨이를 통해 전달
- 라우팅: API 게이트웨이가 적절한 마이크로서비스로 요청 라우팅
- 서비스 처리: 각 마이크로서비스가 독립적으로 비즈니스 로직 처리
- 이벤트 발행: 상태 변경 시 이벤트를 발행하여 다른 서비스에 알림
- 응답 반환: 처리 결과를 클라이언트에게 반환
서비스 간 통신 방식
동기 통신:
- REST API: HTTP/HTTPS 기반 RESTful 서비스
- GraphQL: 클라이언트가 필요한 데이터만 요청
- gRPC: 고성능 RPC 프레임워크
비동기 통신:
- 메시지 큐: 점대점 메시징
- 이벤트 스트림: 발행 - 구독 패턴
- 웹훅: HTTP 콜백 기반 알림
구조 및 아키텍처
전체 아키텍처 구조
graph TB subgraph "클라이언트 계층" Web[웹 애플리케이션] Mobile[모바일 앱] API_Client[API 클라이언트] end subgraph "API 게이트웨이 계층" Gateway[API Gateway] LB[로드 밸런서] end subgraph "서비스 계층" UserService[사용자 서비스] OrderService[주문 서비스] PaymentService[결제 서비스] ProductService[상품 서비스] NotificationService[알림 서비스] end subgraph "데이터 계층" UserDB[(사용자 DB)] OrderDB[(주문 DB)] PaymentDB[(결제 DB)] ProductDB[(상품 DB)] end subgraph "인프라스트럭처 계층" ServiceMesh[서비스 메시] Monitoring[모니터링] ConfigServer[설정 서버] MessageBus[메시지 버스] end Web --> Gateway Mobile --> Gateway API_Client --> Gateway Gateway --> LB LB --> UserService LB --> OrderService LB --> PaymentService LB --> ProductService UserService --> UserDB OrderService --> OrderDB PaymentService --> PaymentDB ProductService --> ProductDB UserService -.-> MessageBus OrderService -.-> MessageBus PaymentService -.-> MessageBus NotificationService -.-> MessageBus ServiceMesh -.-> UserService ServiceMesh -.-> OrderService ServiceMesh -.-> PaymentService ServiceMesh -.-> ProductService
구성 요소
구성 요소 | 기능 | 역할 | 특징 |
---|---|---|---|
마이크로서비스 | 특정 비즈니스 기능 구현 | 독립적인 배포 단위, 비즈니스 로직 처리 | 상태 비저장, 자율 운영, 개별 스케일링 가능 |
API 게이트웨이 | 요청 라우팅, 인증/인가, 속도 제한 | 서비스 진입점, 횡단 관심사 처리 | 단일 진입점, 요청/응답 변환, 프로토콜 변환 |
서비스 레지스트리 | 서비스 위치 정보 관리 | 서비스 디스커버리 지원 | 동적 등록/해제, 헬스 체크, 클라이언트 - 서버 위치 정보 매핑 |
설정 서버 | 중앙화된 설정 관리 | 환경별 설정 제공, 설정 변경 반영 | 버전 관리, 암호화 지원, 실시간 구성 반영 가능 |
데이터 저장소 | 서비스 전용 데이터 저장 | 데이터 영속성 보장 | 서비스별 독립, 다양한 DB 유형 지원 (RDB, NoSQL 등) |
서비스 메시 (선택) | 서비스 간 통신, 보안, 모니터링 | 네트워크 레벨 서비스 관리 | 사이드카 패턴, 트래픽 제어, mTLS, 정책 기반 통신 관리 |
메시지 브로커 (선택) | 비동기 메시지 전달 | 이벤트 기반 통신 지원 | 발행 - 구독 모델, 메시지 영속성 및 순서 보장 |
모니터링 시스템 (선택) | 시스템 상태, 로그, 트레이싱 수집 | 운영 가시성 제공 | 메트릭, 로그, 분산 추적 통합, 경고/알림 지원 |
CI/CD 파이프라인 (선택) | 빌드, 테스트, 배포 자동화 | 지속적 통합 및 배포 지원 | 서비스별 파이프라인, 자동화 테스트, 무중단 배포 가능 |
컨테이너 오케스트레이션 (선택) | 컨테이너 수명주기 및 리소스 관리 | 서비스 배포 및 확장 자동화 | 자동 복구, 스케줄링, 롤링 업데이트, 자가 치유 |
구현 기법
카테고리 | 구현 기법 | 정의 및 구성요소 | 목적 | 실제 예시 |
---|---|---|---|---|
서비스 분해 | 도메인 주도 분해 (DDD) | 도메인 모델, 바운디드 컨텍스트, 애그리거트 기반 서비스 경계 설정 | 응집도 높은 서비스 구성, 도메인 중심 아키텍처 실현 | 전자상거래 도메인 → 주문, 결제, 배송 서비스 분할 |
트랜잭션 기반 분해 | 트랜잭션 흐름 분석 → 독립 처리 가능한 서비스로 분할 → SAGA 패턴 적용 | 트랜잭션 경계 명확화, 데이터 일관성 보장 | 주문 처리 트랜잭션 → 주문, 결제, 재고 서비스 분할 | |
API 설계/통신 패턴 | API Gateway 패턴 | 단일 진입점, 인증/인가, 요청 집계, 속도 제한, 로깅 기능 포함 | 클라이언트 복잡성 감소, 횡단 관심사 집중 처리 | 사용자 대시보드 요청 → API Gateway → 여러 서비스 병렬 호출 |
BFF (Backend For Frontend) | 프론트엔드 특화 API 제공 → 모바일/웹 별도 구성 | 클라이언트 맞춤형 API 구성 | 모바일용 경량 API, 웹용 풍부한 API 제공 | |
동기 통신 (REST, gRPC) | 요청/응답 기반, 빠른 응답 필요 시 사용 | 간단한 통신, 낮은 지연시간 요구 시 적합 | 사용자 인증 요청, 상세정보 조회 | |
비동기 통신 (Event Streaming 등) | 메시지 큐 (RabbitMQ), 스트리밍 (Kafka) 기반 이벤트 전달 | 서비스 간 결합도 최소화, 확장성과 복원력 향상 | 주문 이벤트 → 결제/알림/분석 서비스 비동기 처리 | |
Request-Response / Pub-Sub | 직접 호출 vs 이벤트 기반 다대다 처리 방식 구성 | 통신 방식 유연화 및 서비스 복원력 강화 | 알림 시스템 구성 등 | |
데이터 관리 패턴 | Database per Service | 각 서비스가 독립 DB 보유, Polyglot Persistence 가능 | 데이터 독립성, 스키마 격리, 장애 전파 방지 | 주문은 PostgreSQL, 알림은 MongoDB |
CQRS | Command 모델 (쓰기) / Query 모델 (읽기) 분리 구성 | 읽기/쓰기 성능 최적화, 확장성 개선 | 등록/수정은 PostgreSQL, 조회는 Elasticsearch | |
Event Sourcing | 모든 상태 변경을 이벤트로 저장하고 상태 재구성 | 감사 추적, 변경 이력 관리, CQRS 와 결합 용이 | 계좌 이력 이벤트 저장 → 복원 | |
SAGA 패턴 | 분산 트랜잭션을 로컬 트랜잭션 연속으로 처리, 보상 트랜잭션 포함 | 글로벌 트랜잭션 없이 데이터 일관성 확보 | 항공편 예약 실패 시 호텔 예약 보상 취소 | |
배포 전략 | 컨테이너화 + 오케스트레이션 | Docker 패키징 + Kubernetes 자동 배포/스케일링 구성 | 배포 단순화, 자원 최적화, 확장성 보장 | 서비스별 Pod 관리 |
Blue-Green / Canary / Rolling | 새 버전 점진 배포 + 자동 롤백 구성 | 무중단 배포, 리스크 감소 | Canary: 5% 트래픽만 신규 버전 처리 | |
Feature Toggle | 기능별 플래그로 릴리스 여부 제어 | 기능 롤아웃 제어 및 실험적 배포 가능 | 베타 기능 유저 한정 활성화 | |
Serverless | 이벤트 기반 배포, 자동 확장, 함수 중심 실행 | 비용 최적화, 인프라 관리 최소화 | AWS Lambda 기반 이메일 처리 | |
트랜잭션 관리 | Saga (Orchestration / Choreography) | 중앙 조정자 기반 흐름 관리 / 이벤트 기반 자율 흐름 구성 | 분산 트랜잭션 일관성 보장, 복잡한 프로세스 제어 | 결제 실패 시 주문/재고 보상 취소 |
보상 트랜잭션 | 실패 발생 시 이전 단계 롤백 처리 정의 | 원자성 보장 없이도 일관성 유지 가능 | 재고 차감 후 결제 실패 → 재고 복원 | |
운영 자동화 | CI/CD 파이프라인 | 코드 커밋 → 테스트 → 배포 자동화 구성 | 배포 신뢰성 향상, 개발 생산성 개선 | GitHub Actions, Jenkins 파이프라인 |
Feature Flag / A/B 테스트 | 조건 기반 기능 분기, 실험 적용 | 사용자 피드백 수집, 위험 최소화 | 로그인 화면 A/B 테스트 | |
컨테이너 보안 및 DevSecOps | 이미지 취약점 검사, 보안 스캐닝, 무결성 검증 등 적용 | 운영 신뢰도 강화, 배포 전 보안 점검 자동화 | Trivy, Aqua 사용 | |
서비스 인프라 | 서비스 메시 (Istio, Linkerd) | 통신 트래픽 제어, mTLS 적용, 사이드카 구조 | 보안, 로깅, 리트라이, 트래픽 제어 등 자동화 | Envoy 사이드카 + Istio 컨트롤 |
메시지 브로커 (Kafka, RabbitMQ) | 이벤트 발행/구독 기반, 메시지 큐 기반 통신 구성 | 확장성 높은 비동기 통신 구조 | 주문 이벤트 발행 → 여러 컨슈머 처리 | |
서비스 디스커버리 | Consul, Eureka 등 동적 위치 검색 | 마이크로서비스 확장성 및 네트워크 유연성 확보 | Pod 등록/제거 자동화 | |
시스템 회복력 | Circuit Breaker / Retry / Timeout | 장애 시 요청 차단 / 재시도 / 대기시간 제한 구성 | 장애 확산 방지, 빠른 복구, 사용자 경험 유지 | 주문 서비스 장애 시 즉시 우회 |
Bulkhead / Fallback | 격리된 자원 블록 구성 / 대체 플랜 제공 | 한 서비스 장애가 전체에 미치지 않도록 설계 | 인증 서비스 장애 시 임시 메시지 처리 | |
관찰 가능성 (Observability) | 로깅, 메트릭, 트레이싱 | Prometheus, Grafana, Jaeger 등 통합 | 시스템 상태 가시화, 성능 병목 분석, 장애 추적 | 분산 추적 + 알림 시스템 |
OpenTelemetry | 로그/메트릭/트레이스를 통합한 표준 수집 프레임워크 | 도구 간 일관된 수집 및 분석 구조 구성 | FastAPI + OTEL Exporter | |
마이그레이션 전략 | Strangler Fig 패턴 | 기존 모놀리스를 점진적으로 마이크로서비스로 대체 | 리스크 최소화, 단계별 현대화 전략 적용 | 일부 기능만 독립 서비스로 전환 후 점진 확장 |
도메인 주도 분해 (DDD–Bounded Context)
|
|
설명: Order 와 Payment 등의 도메인 서비스로 분리. 각각 독립 실행 가능한 API 를 가짐.
트랜잭션 분해 ‧ SAGA 패턴 (Choreography 방식)
|
|
설명: 주문과 결제 서비스를 이벤트 기반으로 연결하여 트랜잭션 관리.
API Gateway
|
|
설명: 단일 진입점에서 여러 마이크로서비스로 라우팅.
BFF (Backend For Frontend)
설명: 모바일과 웹 별도 API 를 제공해 클라이언트 최적화.
CQRS
설명: 쓰기는 RDB, 읽기는 ElasticSearch 로 분리하여 성능 최적화.
Event Sourcing
설명: 모든 변경을 이벤트로 저장하고, 재생으로 상태 복원.
Container, Orchestration (Kubernetes)
|
|
설명: Kubernetes 를 이용한 컨테이너 자동 스케일링 구성.
Canary 배포
설명: 신규 버전을 일부 노드에만 배포해 안전하게 테스트.
Feature Toggle
설명: 기능 온/오프 플래그로 실험 배포 지원.
Saga 패턴–오케스트레이션
설명: 중앙 컨트롤러로 단계별 서비스 호출 및 실패 시 보상 처리 구현.
CI/CD
메시지 브로커 (Kafka)
설명: 주문 이벤트를 Kafka 로 비동기 발행하여 확장성 확보.
Circuit Breaker
설명: 장애 시 요청 차단 및 회복 대기 전략 제공.
Observability (로깅, 모니터링, 트레이싱)
설명: OpenTelemetry 로 분산 트레이싱 구현.
Strangler Fig 패턴
|
|
설명: 모놀리스를 점진적으로 독립 서비스로 대체하는 전략.
장점
카테고리 | 항목 | 설명 |
---|---|---|
1. 운영/배포 유연성 | 독립적 배포 및 롤백 | 서비스 단위로 개별 배포 가능하므로 배포 주기가 단축되고, 장애 발생 시 해당 서비스만 롤백 가능 |
배포 민첩성 | 변경이 빠르게 반영되어 빠른 기능 출시 및 실험 가능 | |
무중단 배포 가능성 | Blue-Green, Canary 전략 등과 결합하여 시스템 중단 없이 배포 가능 | |
2. 확장성/성능 | 선택적 확장성 | 트래픽이 집중되는 특정 서비스만 확장하여 비용 최적화 및 리소스 효율성 향상 |
독립적 스케일링 | 서비스마다 독립적으로 수평 또는 수직 확장 가능 | |
3. 안정성/격리성 | 장애 격리 | 하나의 서비스 장애가 전체 시스템에 영향을 주지 않음 (Circuit Breaker 등과 결합 시 효과 극대화) |
데이터 격리 | 서비스별 전용 데이터베이스를 통해 데이터 일관성과 보안 강화 | |
4. 조직 및 팀 구조 | 팀 자율성 | 각 팀이 서비스의 전체 생명주기를 관리, 책임감 및 의사결정 속도 증가 |
조직 분리 | 서비스별로 전담팀 운영 가능 → 크로스 펑셔널 팀 구성 용이 | |
5. 개발 생산성 | 병렬 개발 가능성 | 여러 팀이 동시에 독립적으로 기능 개발 가능 → 릴리즈 병목 제거 |
작은 코드베이스 유지 | 각 서비스가 작고 명확한 범위를 가지므로 코드 유지보수성이 향상됨 | |
빠른 개발 주기 | 작고 독립된 단위로 개발되어 변화 대응력 향상 | |
6. 기술 유연성 | 기술 스택 다양성 | 각 서비스마다 최적의 언어, 프레임워크, 데이터베이스를 선택 가능 (폴리글랏 아키텍처 실현) |
새로운 기술 도입 용이 | 전체 시스템에 영향 없이 일부 서비스에서만 신규 기술 실험 가능 | |
7. 비즈니스 민첩성 | 비즈니스 변화 대응력 | 시장 변화나 사용자 요구에 빠르게 적응 가능 |
기능별 릴리스 최적화 | 특정 기능만 빠르게 배포하거나 비활성화 가능 (Feature Toggle 등과 연계) |
단점과 문제점 그리고 해결방안
단점
항목 | 설명 | 해결책 |
---|---|---|
운영 복잡성 증가 | 서비스 수 증가에 따른 배포, 모니터링, 구성 관리 등의 운영 부담 증가 | Kubernetes 기반 자동화, GitOps, 서비스 메시, APM 도구 도입 |
테스트 복잡성 | 서비스 간 의존성으로 인한 통합 테스트 환경 구성 및 유지 어려움 | Contract Testing, 테스트 더블 (Mock, Stub), 테스트 자동화 구축 |
네트워크 지연 및 비용 | 서비스 간 통신 증가로 인한 응답 지연과 트래픽 비용 상승 | gRPC, HTTP/2, 캐싱 전략, 로컬 호출, 로드밸런싱 적용 |
데이터 일관성 관리 | 분산 데이터베이스 환경에서의 트랜잭션 일관성 보장이 어려움 | Saga 패턴, 이벤트 소싱, Eventually Consistent 모델 도입 |
보안 구성 복잡성 | 다수의 서비스에 대해 개별 인증/인가, 보안 설정 필요 | 서비스 메시 기반 mTLS, API Gateway 인증, 중앙 집중형 보안 정책 적용 |
분산 시스템 복잡성 | 장애 분석, 로깅, 트레이싱, 설정 관리 등 복잡도 급증 | OpenTelemetry, Centralized Config Server, Observability Stack 도입 |
기술 및 운영 인프라 요구 | CI/CD, DevOps, 모니터링 등 다양한 도구와 기술에 대한 준비 필요 | DevOps 역량 강화, 플랫폼 엔지니어링, 교육 투자 |
버전 관리 및 호환성 | 독립적 배포 환경에서 서비스 간 API 버전 불일치 가능성 | API 버전 관리 (SemVer), 하위 호환 보장, Blue-Green/Canary 배포 전략 적용 |
문제점
항목 | 원인 | 영향 | 탐지 및 진단 | 예방 방법 | 해결 방법 및 기법 |
---|---|---|---|---|---|
서비스 간 순환 의존성 | 잘못된 서비스 분해, 공유 모델 남용 | 장애 전파, 배포 순서 제약 | 의존성 그래프 분석, 정적 분석 도구 사용 | DDD 기반 설계, API Contract 관리 | 서비스 경계 재설계, 이벤트 기반 통신 전환 |
분산 트랜잭션 실패 | 네트워크 지연/장애, 서비스 다운타임 | 데이터 불일치, 비즈니스 로직 오류 발생 | 분산 트레이싱, 트랜잭션 상태 모니터링 | Saga, 보상 트랜잭션 설계 | 자동 재시도, 장애 복구 절차 수립 |
서비스 디스커버리 실패 | 서비스 레지스트리 장애, 네트워크 파티션 | 서비스 호출 불가, 시스템 전체 장애 가능성 | 헬스 체크, 서비스 등록 상태 감시 | 다중 레지스트리 구성, 캐싱, Client-Side Discovery | DNS 폴백, 클라이언트 사이드 로드밸런싱 |
설정 불일치/오류 | 환경별 설정 분산, 설정 동기화 실패 | 서비스 이상 동작, 보안 누수 | 설정 검증 스크립트, diff 비교 도구 | 중앙화된 설정 서버 (Spring Cloud Config 등) | 설정 롤백, Canary 설정 배포 |
데이터 동기화 지연 | 이벤트 처리 지연, 큐 적체 | 사용자 경험 저하, 데이터 불일치 | 큐 대기 시간, 이벤트 처리 지연 로그 모니터링 | 이벤트 스키마 설계, 병렬 처리, 파티셔닝 | 메시지 큐 확장, 배치 처리, 비동기 재처리 |
버전 호환성 문제 | API 변경 시 하위 호환 미비 | 호출 오류, 서비스 충돌 | API 테스트, 소비자 기반 계약 테스트 (Pact 등) | API 버전 유지, Gradual Deployment | Semantic Versioning, Blue-Green 배포 적용 |
장애 전파 위험 | 동기 호출 기반 강한 결합 구조 | 전체 시스템으로 장애 확산 | Circuit Breaker 모니터링, 호출 체인 분석 | 느슨한 결합, 비동기 통신, Fallback 설계 | 서킷 브레이커, Bulkhead, Retry, Timeout 패턴 적용 |
메시지 누락/중복 처리 문제 | 메시지 브로커 미설계, idempotency 미흡 | 이벤트 재처리 실패 또는 중복 이벤트 발생 | DLQ 모니터링, 메시지 추적 시스템 | 메시지 유일 ID 부여, 보장 옵션 설정 | 중복 허용 처리, 메시지 상태 저장, 수신 확인 (ACK) 시스템 도입 |
테스트 환경 충돌 | 통합 테스트 시 외부 의존성 존재 | 테스트 실패율 증가, 신뢰성 저하 | 테스트 격리 분석, CI/CD 테스트 로그 | 서비스 Mocking, Contract Testing | 테스트 피라미드 설계, 환경 분리 |
보안 위협 | 서비스 수 증가 → 공격 표면 확대 | 데이터 유출, 시스템 침입 | 보안 스캔, 취약점 관리 도구 사용 | Zero Trust 모델, 공통 보안 정책 정의 | 서비스 메시 보안, 인증/인가 일관화 (OAuth2, JWT 등) 적용 |
도전 과제
카테고리 | 도전 과제 | 원인 / 영향 | 해결 방안 및 도구/패턴 |
---|---|---|---|
데이터 관리 | 데이터 일관성 보장 | 분산 DB 로 인해 트랜잭션 일관성 보장 어려움 → 데이터 불일치, 비즈니스 오류 | SAGA 패턴, 이벤트 소싱, CQRS, Eventually Consistency 전략 도입 |
데이터 거버넌스 | 데이터 소유권 분산, 품질 관리 부재 → 규제 위반, 분석 어려움 | 스키마 레지스트리, 데이터 카탈로그, 데이터 메시 아키텍처, 자동 품질 검증 시스템 | |
통신 및 인터페이스 | 서비스 간 통신 복잡성 | 호출량 증가, 네트워크 지연 → 시스템 성능 저하, 장애 전파 | gRPC, 비동기 메시징 (RabbitMQ/Kafka), 서킷 브레이커, Retry, Timeout, API Gateway 활용 |
버전 호환성 문제 | 독립 배포로 인한 API/스키마 충돌 → 서비스 간 통신 실패 | API 버전 관리 (SemVer), Consumer Contract Testing(Pact), Blue-Green 배포, 하위 호환 유지 | |
관찰성 및 운영 | 분산 시스템 모니터링 | 서비스 수 증가 및 호출 체인 복잡성 → 장애 탐지 어려움, MTTR 증가 | OpenTelemetry, Prometheus, Grafana, Jaeger, 중앙 집중형 로깅 (ELK, Loki), 메트릭/헬스체크 통합 |
로깅 및 트레이싱 일관성 부족 | 상관관계 ID 누락, 로그 분산 → 문제 진단 지연 | 구조화된 로깅, 트레이스 ID 전파, 공통 로깅 프레임워크 적용 | |
테스트 복잡성 | 서비스 간 의존성, 통합 테스트 환경 부족 → 테스트 누락/실패 | Contract Testing, Service Virtualization, 통합 테스트 자동화, 테스트 데이터 관리 | |
배포 및 자동화 | 배포 복잡성 | 수많은 서비스의 동시 배포와 충돌 가능성 → 버전 불일치, 장애 발생 | CI/CD 파이프라인 구축, Canary/Blue-Green 배포, GitOps 기반 관리, Feature Toggle |
설정 관리 어려움 | 환경별 설정 불일치, 동기화 실패 → 서비스 오작동, 보안 리스크 | 중앙 집중형 설정 서버 (Spring Cloud Config), 암호화 설정, 환경 비교 도구 활용 | |
멀티 클러스터/클라우드 운영 | 여러 클라우드 및 클러스터 간 구성 차이 → 벤더 종속, 네트워크 장애 | Kubernetes Federation, Istio Multi-cluster, External DNS, 클러스터 간 라우팅 제어 | |
보안 및 인증 | 마이크로서비스 간 보안 강화 | 다수의 엔드포인트, 인증 일관성 부족 → 데이터 유출, 불법 접근 위험 | Zero Trust 모델, 서비스 메시 기반 mTLS, OAuth2.0, JWT, API Gateway 보안 정책 적용 |
공격 표면 확대 | 마이크로서비스 증가로 인한 보안 대상 확대 → 침투 위험 증가 | 보안 스캐닝 자동화, 침입 탐지 시스템, 최소 권한 설정 (RBAC), 정기적인 보안 점검 | |
조직/문화/구조 | 서비스 경계 정의의 어려움 | 모호한 도메인 분리로 인해 순환 의존성 발생 → 장애 전파, 개발 병목 | DDD(도메인 주도 설계), 이벤트 스토밍, API Contract 기반 설계, 바운디드 컨텍스트 식별 |
Conway’s Law 대응 | 조직 구조가 아키텍처에 영향을 줌 → 팀 간 협업 장애, 서비스 분리 실패 | 팀 토폴로지 적용, Cross-functional 팀 구성, 서비스별 책임 명확화 | |
DevOps 문화 정착 | 개발 - 운영 사일로, 자동화 미흡 → 배포 지연, 운영 불안정 | 지속적 교육, 책임 공유, 배포 권한 위임, DevOps 툴 체계 도입 (CI/CD, Infra as Code) | |
성능 최적화 | 네트워크 병목 및 지연 | 호출 체인 과도, 원거리 통신 → 응답 속도 저하, 리소스 낭비 | 스마트 캐싱, 데이터 지역성 최적화, GraphQL Federation, HTTP/2, CDN 활용 |
메시지 중복/누락 | 메시지 브로커 미설계, 비보장 처리 → 데이터 불일치, 중복 처리 | 메시지 idempotency 설계, DLQ 구성, 메시지 상태 저장, 중복 허용 처리 패턴 |
분류 기준에 따른 종류 및 유형
분류 기준 | 유형 | 특징 및 설명 | 적용 사례 |
---|---|---|---|
1. 통신 방식 | 동기식 마이크로서비스 (Synchronous) | REST API, gRPC 기반 실시간 통신 구조 | 인증, 결제, 실시간 조회 등 |
비동기식 마이크로서비스 (Asynchronous) | 메시지 큐, 이벤트 기반 비동기 처리, 느슨한 결합 구조 | 주문 처리, 알림, 데이터 파이프라인 | |
하이브리드 마이크로서비스 (Hybrid) | 주요 로직은 동기, 부가 로직은 비동기 처리 혼합 사용 | 알림 + 결제 처리 복합 로직 | |
2. 배포 방식 | 컨테이너 기반 | Docker, Kubernetes 환경에서 컨테이너 단위로 배포 | 클라우드 네이티브 앱, MSA 전환 |
서버리스 기반 | FaaS(Function-as-a-Service) 기반, 요청 발생 시에만 실행 | 이벤트 기반 로직, 단기성 작업 | |
VM 기반 | 전통적인 가상머신 인프라 위에 직접 배포 | 레거시 시스템, 온프레미스 환경 | |
3. 데이터 관리 방식 | Database per Service | 각 서비스가 독립적인 데이터베이스를 가지며 높은 응집도와 낮은 결합도를 제공 | 금융, 커머스, 분산 시스템 전반 |
Shared Database | 여러 서비스가 하나의 데이터베이스를 공유, 빠른 개발 초기엔 유리하나 일관성/확장성에 제약 | 레거시 통합, 전환 단계 시스템 | |
Event Sourcing | 상태 변경을 이벤트 로그로 저장하여 이벤트 재생으로 현재 상태 구성 | 감사를 위한 추적, 변경 불변 시스템 | |
다중 저장소 (Polyglot Persistence) | 서비스 별로 서로 다른 DBMS 선택 (SQL, NoSQL 등) | 콘텐츠 관리, AI/분석 플랫폼 | |
4. 서비스 경계 설계 | 도메인 기반 (DDD) | 비즈니스 도메인 중심으로 서비스 분할, Bounded Context 명확화 | 대규모 기업 시스템, 도메인 복잡도 높을 때 |
기능 기반 (Function-based) | 기능 단위 (ex: 사용자, 주문, 결제) 로 서비스 분리 | 스타트업, 단일 제품 중심 서비스 | |
5. 서비스 크기 | 나노서비스 (Nano Service) | 매우 작은 단위로 나누어진 기능 단위 서비스, 하나의 함수 수준 | 서버리스 함수, 간단한 유틸 서비스 |
마이크로서비스 (Microservice) | 명확한 비즈니스 책임을 가지는 단위 서비스로 가장 일반적인 형태 | 대다수 MSA 시스템 | |
미니서비스 (Mini Service) | 여러 관련 기능을 하나의 서비스로 유지, 마이크로서비스와 모놀리스의 중간 크기 | 레거시 모놀리스 점진적 분리 구조 | |
6. 트랜잭션 제어 방식 | Orchestration Saga | 중앙 서비스 (Orchestrator) 가 각 로컬 트랜잭션을 순차 실행 및 제어 | 워크플로우 기반 처리 |
Choreography Saga | 각 서비스가 이벤트 수신 후 자체 로직을 처리하고 후속 이벤트 발행 | 이벤트 기반 처리 구조 | |
7. 프론트엔드 통합 방식 | 마이크로프론트엔드 (Micro Frontend) | 프론트엔드를 서비스 단위로 분리하여 독립 배포 가능 | 대규모 웹앱, SPA 구조 |
모놀리식 프론트엔드 | 모든 프론트엔드 기능을 하나의 코드베이스로 구성 | 전통적인 웹 애플리케이션 | |
8. 배포 환경 | 온프레미스 (On-premises) | 자체 인프라에 배포, 클러스터 및 네트워크 구성 필요 | 정부, 금융, 민감 정보 시스템 |
클라우드 기반 (Cloud-native) | 클라우드 서비스 및 오케스트레이션 환경에 최적화된 배포 | AWS, Azure, GCP 기반 서비스 | |
Service Cell 구조 | 여러 마이크로서비스를 기능 단위로 그룹핑하여 배포 | 고가용성, 서비스 독립성 강화 구조 |
실무 적용 예시
적용 분야 | 대표 시스템/서비스 | 사용 기술 및 패턴 | 주요 목적 | 핵심 효과 |
---|---|---|---|---|
전자상거래 | 쇼핑몰, 온라인 마켓 | API Gateway, Redis, Elasticsearch, Kubernetes | 기능별 독립 배포, 트래픽 급증 대응 | 99.9% 가용성 확보, 응답시간 50% 단축 |
OTT/미디어 | Netflix, YouTube, 스트리밍 플랫폼 | Service Mesh, CDN, Kafka, 추천 시스템 | 글로벌 확장, 트래픽 분산, 개인화 서비스 | 동시 사용자 1 억 명 지원, 빠른 배포 주기 |
핀테크/금융 | 디지털 뱅킹, 결제 게이트웨이 | Circuit Breaker, OAuth, API Gateway, HSM, 분산 트랜잭션 | 보안 강화, 규제 준수, 장애 격리 | 트랜잭션 성공률 99.99%, 민감 기능 분리로 안정성 강화 |
모빌리티/물류 | 배송/운송 플랫폼, 라이드셰어링 | 이벤트 기반 처리, 지리 공간 API, 실시간 추적 시스템 | 실시간 처리, 고객 응대 자동화 | 배송 시간 30% 단축, 장애 격리로 안정적 운영 |
IoT/센서 플랫폼 | 스마트홈, 제조 센서 시스템 | MQTT, Kafka, Time Series DB, Edge Gateway | 대규모 실시간 데이터 수집/처리 | 초당 100 만 이벤트 처리, 디바이스별 최적 통신 지원 |
교육 플랫폼 | 온라인 강의 서비스 | Micro Frontend, 알림 서비스, 결제 API | 기능 독립 운영, 빠른 피처 릴리즈 | 도메인 간 충돌 방지, 학습 피드백 실시간 처리 |
소셜 미디어 | SNS, 커뮤니티 서비스 | GraphQL, 실시간 메시징, 캐시 시스템 | A/B 테스트, 피드 개인화, 실시간 상호작용 | 사용자 참여도 40% 증가, 기능 실험/확장 용이 |
공공기관/헬스케어 | 민원/응급/보건 시스템 | AI 마이크로서비스, 자동화 처리, 보안 감사 로깅 | 자동화 및 분산 분석, 민감 데이터 분리 | 분석 응답시간 단축, 데이터 보안 및 프라이버시 확보 |
SaaS/기술 기업 | B2B 서비스 플랫폼 | 폴리글랏 아키텍처, CI/CD, 다중 DB 전략 | 기술 다양성 수용, 빠른 릴리즈 사이클 | 최적 기술 스택 채택 가능, 서비스 진화 유연성 확보 |
활용 사례
사례 1: Netflix 스트리밍 플랫폼
Netflix 는 전 세계 2 억 명 이상의 사용자에게 스트리밍 서비스를 제공하는 대표적인 마이크로서비스 아키텍처 사례.
시스템 구성도:
graph TB subgraph "Client Layer" WebClient[웹 브라우저] MobileApp[모바일 앱] TVApp[스마트 TV 앱] GameConsole[게임 콘솔] end subgraph "CDN Layer" CloudFront[Amazon CloudFront] OpenConnect[Netflix Open Connect] end subgraph "API Gateway Layer" Zuul[Zuul Gateway<br/>- 동적 라우팅<br/>- 모니터링<br/>- 보안<br/>- 복원력] end subgraph "Microservices Layer" subgraph "User Services" UserProfile[User Profile Service] Authentication[Authentication Service] Preferences[Preferences Service] end subgraph "Content Services" Catalog[Catalog Service] Metadata[Metadata Service] Recommendations[Recommendation Service] Search[Search Service] end subgraph "Playback Services" PlayAPI[Play API Service] VideoStreaming[Video Streaming Service] Bookmarks[Bookmarks Service] ViewingHistory[Viewing History Service] end subgraph "Platform Services" DeviceRegistration[Device Registration] TitleSelection[Title Selection] ABTesting[A/B Testing Service] Analytics[Analytics Service] end end subgraph "Data Layer" Cassandra[(Cassandra<br/>분산 NoSQL)] MySQL[(MySQL<br/>관계형 DB)] ElasticSearch[(ElasticSearch<br/>검색 엔진)] S3[(Amazon S3<br/>콘텐츠 저장)] end subgraph "Message Infrastructure" Kafka[Apache Kafka<br/>실시간 이벤트 스트림] SQS[Amazon SQS<br/>메시지 큐] end subgraph "Monitoring & Infrastructure" Hystrix[Hystrix<br/>Circuit Breaker] Eureka[Eureka<br/>Service Discovery] Ribbon[Ribbon<br/>Client-side Load Balancer] Atlas[Atlas<br/>Metrics Collection] end WebClient --> CloudFront MobileApp --> CloudFront TVApp --> OpenConnect GameConsole --> OpenConnect CloudFront --> Zuul OpenConnect --> Zuul Zuul --> UserProfile Zuul --> Catalog Zuul --> PlayAPI Zuul --> DeviceRegistration UserProfile --> MySQL Catalog --> Cassandra Recommendations --> ElasticSearch PlayAPI --> S3 UserProfile --> Kafka PlayAPI --> Kafka Recommendations --> Kafka UserProfile --> Hystrix Catalog --> Eureka PlayAPI --> Ribbon Analytics --> Atlas
활용 사례 Workflow
사용자 비디오 재생 요청 처리 과정:
sequenceDiagram participant User as 사용자 participant CDN as CDN participant Zuul as Zuul Gateway participant Auth as Auth Service participant Profile as Profile Service participant Catalog as Catalog Service participant PlayAPI as Play API participant Recommend as Recommendation Service participant Analytics as Analytics Service participant Kafka as Kafka User->>CDN: 비디오 재생 요청 CDN->>Zuul: 요청 전달 Zuul->>Auth: 사용자 인증 확인 Auth->>Zuul: 인증 성공 par 병렬 처리 Zuul->>Profile: 사용자 프로필 조회 Profile->>Zuul: 프로필 정보 반환 and Zuul->>Catalog: 콘텐츠 메타데이터 조회 Catalog->>Zuul: 메타데이터 반환 end Zuul->>PlayAPI: 재생 URL 요청 PlayAPI->>Zuul: 스트리밍 URL 반환 Zuul->>User: 재생 정보 응답 PlayAPI->>Kafka: 재생 이벤트 발행 Kafka->>Analytics: 시청 데이터 분석 Kafka->>Recommend: 추천 알고리즘 업데이트 Note over User,Kafka: 실시간 개인화 추천 업데이트
마이크로서비스 아키텍처의 역할:
- 확장성: 피크 시간대 특정 서비스 (재생, 추천) 만 선별적 확장
- 개인화: 사용자별 독립적인 추천 서비스 제공
- 글로벌 서비스: 지역별 CDN 과 연동된 분산 아키텍처
- 실험 플랫폼: A/B 테스트를 위한 독립적 서비스 배포
- 장애 격리: Hystrix Circuit Breaker 로 연쇄 장애 방지
마이크로서비스 유무에 따른 차이점:
- 마이크로서비스 아키텍처 적용 전 (모놀리식):
- 전체 시스템 재배포 필요로 인한 주 1 회 배포
- 특정 기능 장애 시 전체 서비스 중단
- 단일 기술 스택 제한 (Java)
- 수직적 확장만 가능
- 마이크로서비스 아키텍처 적용 후:
- 일일 수천 번의 독립적 서비스 배포
- 99.99% 가용성 달성 (개별 서비스 장애 격리)
- 다양한 기술 스택 활용 (Java, Python, Node.js)
- 서비스별 수평적 확장으로 비용 최적화
사례 2: 이커머스 플랫폼
시스템 구성: 주문 (Order), 결제 (Payment), 재고 (Inventory) 서비스
Workflow: 사용자가 주문 → 주문 서비스 → 결제 서비스 → 재고 서비스 → 각각 독립적으로 동작, 메시지 큐로 상태 전달
역할: 장애 격리, 확장성, 빠른 배포
미적용 시: 전체 시스템 장애, 배포 지연, 확장성 한계
sequenceDiagram participant User participant APIGW participant Order participant Payment participant Inventory User->>APIGW: 주문 요청 APIGW->>Order: 주문 생성 Order->>Payment: 결제 요청(비동기) Payment->>Inventory: 재고 차감(비동기) Inventory-->>Order: 재고 상태 전달 Order-->>APIGW: 주문 결과 APIGW-->>User: 주문 응답
사례 3: 전자상거래 플랫폼
시스템 구성
flowchart LR User --> API_Gateway API_Gateway --> OrderSvc API_Gateway --> InventorySvc API_Gateway --> PaymentSvc OrderSvc --> InventorySvc OrderSvc --> PaymentSvc OrderSvc --> MQ[Kafka] InventorySvc --> DB_I[(Inventory DB)] PaymentSvc --> DB_P[(Payment DB)] OrderSvc --> DB_O[(Order DB)]
- OrderSvc: 주문 생성, PaymentSvc 호출 → Inventory 요청 → 주문 승인 → Kafka 이벤트 발행
- InventorySvc: 재고 분석 및
deductEvent
소비하여 재고 조정 - PaymentSvc: 결제 처리
- DB 분리: 각 서비스 독립 DB 로 일관성 및 보안 확보
워크플로우: Saga (Choreography 방식)
- OrderSvc 에서 주문 수집
- PaymentSvc 로 결제 요청
- InventorySvc 에서 재고 갱신
- 이벤트 발행 (
order.created
,inventory.updated
) - 실패 시 보상:
payment.refund
,inventory.rollback
이벤트 발생
Microservices 도입 전/후:
단계 | Monolith 상태 | Microservices 적용 후 |
---|---|---|
개발 | 전체 코드베이스 컴파일/릴리즈 필요 | 개별 서비스 독립 개발 및 배포 가능 |
성능 대응 | 전체 인스턴스 확장 필요 | 주문 집중시 OrderSvc 만 수평 확장 가능 |
장애 시 | 한 서비스 장애 시 전체 시스템 영향 | 한 서비스 장애 시 도메인별 제한된 영향 |
기술 스택 | 통일된 언어/DB 사용 | 서비스별 적합 스택 선택 가능 (예: Go, MongoDB 등) |
구현 예시
JavaScript/Node.js
|
|
Python: Netflix 스타일의 비디오 스트리밍 플랫폼의 핵심 서비스
|
|
|
|
|
|
이 구현 예시는 마이크로서비스 아키텍처의 핵심 특징들을 보여준다:
- 서비스 독립성: 각 서비스가 독립적인 Flask 애플리케이션으로 구현
- API 기반 통신: REST API 를 통한 서비스 간 통신
- 인증/인가: JWT 토큰 기반 보안 구현
- 캐싱: Redis 를 활용한 성능 최적화
- 에러 처리: 각 서비스별 독립적인 에러 처리
- 모니터링: 헬스 체크 엔드포인트 제공
실무에서 효과적으로 적용하기 위한 고려사항 및 주의할 점
카테고리 | 항목 | 설명 | 권장사항 |
---|---|---|---|
1. 서비스 설계 전략 | 서비스 경계 정의 | 잘못된 경계는 결합도 증가와 확장성 저하를 초래함 | DDD 기반 도메인 분리, 이벤트 스토밍 활용 |
서비스 분할 전략 | 지나친 세분화는 운영 복잡도 증가 | SRP 기반의 Bounded Context 설계 | |
통신 패턴 설계 | 네트워크 지연, 오류 전파 등을 고려해 동기/비동기 혼합 설계 필요 | REST + 메시지 큐 조합, 캐싱 도입 | |
트랜잭션 경계 정의 | 분산 환경에서는 원자성 보장 어려움 | Saga, 보상 트랜잭션, 이벤트 소싱 적용 | |
API 설계 및 관리 | 계약 위반 방지 및 하위 호환성 유지 필요 | OpenAPI, Semantic Versioning 적용 | |
2. 데이터 전략 | 데이터베이스 분리 | 서비스 간 독립성과 배포 유연성 확보 | Database per Service, Polyglot Persistence |
데이터 일관성 관리 | 분산 환경에서는 eventual consistency 우선 | CQRS, Event Sourcing 조합 | |
데이터 성능 최적화 | 조회 성능 및 확장성 확보 필요 | 샤딩, 인덱싱, 캐싱 전략 병행 | |
3. 테스트 전략 | 서비스 간 통합 테스트 | 서비스 독립성으로 인해 전통적 통합 테스트 어려움 | Contract Testing, Mocking 활용 |
자동화된 품질 검증 | 릴리즈 주기 단축을 위한 테스트 자동화 필수 | 테스트 피라미드 구성, 정적 분석 도구 사용 | |
4. 배포 전략 | 점진적 전환 전략 | Big Bang 마이그레이션은 실패 확률 높음 | Strangler Fig, 단계적 분리 도입 |
배포 자동화 | 수동 배포는 휴먼 에러 및 관리 복잡성 초래 | GitOps, CI/CD, IaC 적용 | |
릴리스 전략 | 다운타임 없는 무중단 배포 필요 | Blue-Green, Canary, Rolling 배포 | |
5. 운영 전략 | 모니터링 및 관찰성 | 분산 시스템은 문제 추적 및 성능 분석이 어려움 | Prometheus, Grafana, Jaeger, OpenTelemetry |
로깅 및 트레이싱 | 분산 환경에서는 요청 흐름 추적이 핵심 | 중앙 로그 수집 (ELK), Distributed Tracing 도입 | |
장애 복원 및 자가 치유 | 장애 격리 및 복구 체계 없이는 전체 시스템 영향 가능 | Circuit Breaker, Retry, Kubernetes HPA 설정 | |
6. 보안 전략 | 서비스 간 인증 및 접근 제어 | 내부 통신이라도 강력한 인증 체계 필요 | OAuth2, JWT, API Gateway 인증 적용 |
통신 보안 | 외부 및 내부 트래픽 보호 | mTLS, 제로 트러스트 아키텍처 적용 | |
비밀 관리 및 감사 추적 | 민감 정보 노출 방지 및 규제 대응 | Vault, Secrets Manager, 감사 로그 보관 | |
7. 조직 및 문화 | 조직 구조 정렬 | 조직 구조는 시스템 아키텍처에 직접 영향을 미침 (Conway’s Law) | 도메인 중심 크로스펑셔널 팀 구성 |
협업 및 문서화 문화 | 다수 팀 간 협업을 위한 명세 공유 및 표준화 필요 | 계약 기반 문서화 (OpenAPI), 문서 자동화 툴 활용 | |
DevOps 문화 및 성숙도 | 자동화, 공유 책임 문화 없이는 마이크로서비스의 효과가 반감됨 | CI/CD + 모니터링 + 학습 기반 단계적 고도화 |
최적화하기 위한 고려사항 및 주의할 점
카테고리 | 최적화 항목 | 설명 | 권장사항 |
---|---|---|---|
1. 성능 최적화 | 서비스 간 통신 최적화 | 마이크로서비스 간 과도한 네트워크 호출로 인한 지연 최소화 | gRPC/HTTP2, 비동기 메시징, 요청 배칭, 로컬 캐시, CDN, API 집계 |
데이터 접근 성능 향상 | 읽기/쓰기 분리 및 캐싱을 통한 응답 속도 개선 | CQRS, Redis, 읽기 전용 복제본, LRU 캐시, 데이터 파티셔닝 | |
로드 밸런싱 | 트래픽을 효율적으로 분산하여 특정 인스턴스 과부하 방지 | 라운드로빈, 가중치 기반 라우팅, 지리적 로드밸런싱, API Gateway 통합 | |
코드 경량화 및 모듈화 | 서비스 내부 처리 로직의 단순화 및 응답 시간 최소화 | 단일 책임 원칙 (SRP), 고응집 구조, 유닛 테스트 기반 리팩토링 | |
2. 리소스 최적화 | 컨테이너 리소스 관리 | 서비스별 리소스 낭비 방지 및 클러스터 자원 최적 활용 | CPU/메모리 제한 설정, 프로파일링 기반 자원 할당, 수직/수평 확장 |
자동 확장성 확보 | 트래픽 증가에 대한 빠른 대응 및 안정적인 시스템 유지 | HPA, VPA, 클라우드 Auto-scaling, 예측 기반 스케일링 | |
피크 타임 용량 계획 | 고부하 시 성능 저하 방지 및 안정성 확보 | Rate Limiting, 백프레셔, 메시지 버퍼링, Queue 기반 처리 | |
3. 데이터 최적화 | 일관성 및 정합성 유지 | 마이크로서비스 간 데이터 불일치, 중복, 트랜잭션 오류 방지 | Event Sourcing, SAGA 패턴, 보상 트랜잭션, 데이터 정규화 |
데이터 통신 최소화 | 데이터 공유 시 불필요한 전송 방지, 성능 및 보안 개선 | 필요 데이터만 전송, DTO 최적화, 데이터 변경 이벤트 기반 통신 | |
4. 배포 자동화 | 무중단 배포 및 롤백 전략 | 안정적인 지속적 릴리즈 환경 구현 | Blue-Green, Canary, Rolling 배포, Feature Flag |
테스트 자동화 | 빠른 배포 주기에도 서비스 품질 보장 | 단위/통합/E2E 테스트, Mock/Stub 테스트, GitOps 기반 검증 | |
5. 관찰성 및 운영 | 모니터링 및 장애 대응 | 장애 탐지와 성능 분석을 위한 메트릭 수집 및 시각화 시스템 구축 | Prometheus, Grafana, ELK, 분산 트레이싱 (Jaeger/Zipkin), 구조화 로깅 |
서비스 수준 관리 (SLO/SLA) | 서비스 안정성, 신뢰도 확보 위한 목표 지표 설정 | SLI/SLO/SLA 정의, 에러 버짓 관리, 자동 알람 임계치 설정 | |
정밀한 리소스 메트릭 수집 | 커널 레벨까지 상세한 성능 분석 가능 | eBPF 기반 성능 분석 도구, CloudWatch, Datadog 등 | |
6. 보안 최적화 | 인증·인가 및 권한 관리 | 서비스 간, 사용자 간 보안 요구사항 대응 | OAuth2, JWT, API Gateway 인증 통합, RBAC |
네트워크 보안 | 서비스 간 통신 시 기밀성 및 무결성 보장 | mTLS, 서비스 메시 기반 암호화, 제로 트러스트 네트워크 | |
런타임 보안 및 취약점 대응 | 배포된 서비스 환경에 대한 실시간 위협 탐지 | 이미지 서명, 보안 스캔, 네트워크 정책 적용, 런타임 위협 탐지 | |
7. 구조 및 설계 | 서비스 경계 및 수명 최적화 | 지나치게 분리된 서비스로 인한 복잡도 및 유지보수 부담 | 도메인 중심 모델링 (DDD), 서비스 재통합 고려, Bounded Context 명확화 |
통신 구조 단순화 | 서비스 간 과도한 통신 의존성 제거, 장애 전파 최소화 | 이벤트 기반 아키텍처 적용, 데이터 로컬화, 캐싱 전략 | |
8. 문서화 및 협업 | 명세 자동화 및 공유 | 팀 간 협업, API 소비자 대상 일관된 문서 제공 | Swagger, OpenAPI, Wiki 기반 문서, 문서 린트 및 버전 관리 |
9. 비용 최적화 | 인프라 사용 및 비용 절감 | 오버엔지니어링 방지 및 클라우드 비용 절감 | 서비스 통합 검토, Spot 인스턴스 활용, Auto Shutdown, 비용 모니터링 도구 (예: CloudCost) |
- 성능: 트레이싱 기반 병목 분석 → 병렬 처리 및 비동기 구조 설계
- 보안: 마이크로서비스 간 보안은 mTLS + API Gateway 인증 + 최소 권한
- 운영 자동화: CI/CD + GitOps + Auto Scaling + Chaos Test 조합
- 비용: 리소스 할당량, 사용률, 클라우드 과금 기준을 실시간 모니터링하고 조정
주제와 관련하여 주목할 내용
카테고리 | 주제 | 핵심 항목 | 설명 |
---|---|---|---|
아키텍처 패턴 | 마이크로서비스 아키텍처 | 독립 서비스, 바운디드 컨텍스트 | 각 서비스가 독립적으로 동작하며 도메인 단위로 나눔 |
이벤트 기반 아키텍처 | 이벤트 소싱, CQRS, Saga 패턴 | 상태 변경을 이벤트로 저장하고 명령/조회 분리 및 분산 트랜잭션 관리 | |
서버리스 마이크로서비스 | FaaS 기반 구성 (AWS Lambda 등) | 이벤트 기반의 유연한 확장성과 비용 효율성 확보 | |
MACH 아키텍처 | Microservices, API-first, Cloud-native, Headless | 프론트엔드까지 분리된 고유연성 아키텍처 | |
통신 및 통합 | API 및 메시지 통신 구조 | REST, gRPC, GraphQL, 메시지 브로커 | 동기 및 비동기 혼합 통신 구조 설계 |
통신 인프라 구성 | API Gateway, Service Mesh, Service Discovery | 인증, 라우팅, 위치 탐색, 보안 자동화를 지원하는 통신 계층 구성 | |
데이터 관리 전략 | 데이터 저장 전략 | Database per Service, Polyglot Persistence | 서비스별 DB 분리 및 적합한 기술 선택 (SQL/NoSQL 등) |
일관성 및 처리 방식 | Eventual Consistency, Sharding | 최종 일관성과 확장성을 위한 설계 | |
배포 및 운영 전략 | 배포 구조 및 전략 | 컨테이너화, Kubernetes, Canary/Blue-Green | 무중단 배포 및 오케스트레이션 기반 자동화 |
운영 자동화 기술 | GitOps, CI/CD, IaC | 선언적 인프라 관리와 지속적 배포 자동화 | |
운영 플랫폼화 | 플랫폼 엔지니어링 | 내부 개발자 플랫폼 구성 (도구 + 표준) | |
모니터링 및 관찰성 | Observability | 메트릭 (Prometheus), 로깅 (ELK), 트레이싱 (Jaeger) | 복잡한 호출 흐름을 추적하고 시스템 가시성 확보 |
APM 및 통합 표준 | Datadog, New Relic, OpenTelemetry | 통합된 성능 모니터링 및 표준화된 추적 도구 사용 | |
Chaos Engineering | 장애 유도 실험으로 회복력 강화 | 카오스 실험을 통해 장애에 대한 회복력 테스트 | |
보안 아키텍처 | 인증 및 인가 | OAuth2.0, OIDC, JWT | 토큰 기반 인증 및 역할 기반 접근 제어 |
통신 보안 | Zero Trust, mTLS | 모든 요청을 신뢰하지 않고 검증, 쌍방향 TLS 적용 | |
비밀 및 권한 관리 | Vault, Secrets Manager, RBAC | 민감 정보 보안과 정책 기반 접근 제어 적용 | |
확장성과 복원력 | 자동 확장 | Kubernetes HPA | 트래픽 증가 시 자동으로 서비스 인스턴스 확장 |
장애 대응 및 회복 | Circuit Breaker, Retry, Fallback | 연쇄 장애 방지를 위한 회복성 설계 | |
최신 기술 트렌드 | AI/ML 통합 운영 | AIOps, MLOps | 운영 자동화 및 ML 모델 배포 전략 도입 |
Edge & WebAssembly | 엣지 컴퓨팅, 고성능 런타임 | 사용자 근처에서 실행 가능한 경량 아키텍처 | |
GraphQL Federation | GraphQL 스키마 통합 | 다수의 서비스에서 하나의 API 처럼 GraphQL 제공 | |
Data Mesh & Event Streaming | 도메인 기반 데이터 소유, 실시간 데이터 처리 | Kafka, Pulsar 기반 데이터 흐름 관리 | |
테스트 전략 | 계약 기반 테스트 | Pact, Spring Cloud Contract | 마이크로서비스 간 API 계약 검증 및 자동화 테스트 |
조직 운영 모델 | DevOps & SRE | 자동화된 운영 및 신뢰성 엔지니어링 | 개발 - 운영 통합과 가용성 보장 중심의 운영 문화 |
반드시 학습해야할 내용
카테고리 | 주제 | 핵심 항목 | 설명 |
---|---|---|---|
설계 원칙 및 이론 | 마이크로서비스 아키텍처 원칙 | 독립성, 느슨한 결합, SRP, Bounded Context, Conway’s Law | 도메인 중심 설계 및 조직 구조 연계 전략 |
분산 시스템 이론 | CAP 정리, BASE 모델, Vector Clock | 분산 환경에서의 제약 조건 및 트레이드오프 이해 | |
DDD (Domain-Driven Design) | Aggregate, Domain Event, Event Storming | 도메인 모델링 및 마이크로서비스 단위 설계 기반 | |
통신 구조 및 프로토콜 | API 설계 | RESTful API, GraphQL, gRPC | 서비스 간 통신 및 효율적 인터페이스 설계 |
메시징 및 이벤트 기반 통신 | Kafka, RabbitMQ, Pulsar, Redis Pub/Sub, AsyncAPI | 비동기 이벤트 기반 아키텍처 설계 | |
통신 인프라 구성 | API Gateway, Service Mesh(Istio, Linkerd), Service Discovery | 인증, 로깅, 라우팅, 위치 탐색 등 통신 관점 인프라 | |
데이터 관리 및 일관성 | 데이터 저장 전략 | Database per Service, Polyglot Persistence | 마이크로서비스에 적합한 분리된 데이터베이스 전략 |
일관성/트랜잭션 처리 | CQRS, Event Sourcing, SAGA 패턴 | 분산 트랜잭션 처리 및 상태 저장 전략 | |
배포 및 인프라 관리 | 컨테이너화 및 오케스트레이션 | Docker, Kubernetes, Helm | 표준화된 배포 환경과 자동화 |
배포 자동화 및 GitOps | ArgoCD, GitLab CI/CD, Jenkins, GitHub Actions | 지속적 통합과 자동화된 배포 파이프라인 구성 | |
클라우드 네이티브 환경 | AWS, Azure, GCP, Serverless (Lambda, Cloud Functions 등) | 클라우드 인프라 및 서버리스 구조 이해 | |
보안 및 인증/인가 | 서비스 보안 모델 | Zero Trust, mTLS, RBAC, OAuth2.0, OIDC, JWT | 서비스 간 인증 및 접근 제어 원칙 |
API 및 컨테이너 보안 | API 보안, 컨테이너 이미지 스캐닝, Runtime Security | API 접근 보호 및 런타임 보안 강화 | |
시크릿 관리 | Vault, K8s Secrets, AWS Secrets Manager | 민감 정보 안전 저장 및 주입 전략 | |
운영 및 관찰성 | 모니터링 및 메트릭 수집 | Prometheus, Grafana, ELK, Fluentd | 시스템 성능 및 로그 관찰 구성 |
분산 추적 및 APM | Jaeger, Zipkin, OpenTelemetry, Datadog | 전체 요청 흐름 및 병목 추적 | |
회복성과 SRE | SLI/SLO/SLA, Circuit Breaker, Chaos Engineering, 에러 버짓 | 장애 대응 및 신뢰성 중심 운영 전략 | |
커널 기반 관찰성 | eBPF 기반 모니터링 | 저수준 네트워크/시스템 추적 | |
테스트 전략 | 마이크로서비스 테스트 전략 | Unit, Integration, E2E, Contract Testing (Pact, Spring Cloud 등) | 서비스 간 계약 검증 및 회귀 방지 |
성능 테스트 | JMeter, k6, Gatling | 부하 테스트 및 응답 시간 측정 | |
조직 및 플랫폼 구조 | 플랫폼 엔지니어링 (IDP) | Internal Dev Platform, Self-service Dev Tools | 개발 생산성 향상 및 표준화된 개발 환경 |
조직 구조 및 협업 문화 | 팀 독립성, 문서화, DevOps/SRE 융합 | Conway’s Law 를 반영한 조직/서비스 정렬 |
용어 정리
카테고리 | 용어 | 설명 |
---|---|---|
1. 아키텍처 스타일 및 설계 철학 | ||
마이크로서비스 아키텍처 (Microservices Architecture) | 독립적으로 배포 가능한 소형 서비스들로 구성된 아키텍처 스타일 | |
모놀리식 아키텍처 (Monolithic Architecture) | 하나의 배포 단위로 모든 기능이 통합된 전통적인 구조 | |
서비스 지향 아키텍처 (SOA) | 독립적인 서비스들의 집합으로 구성된 분산 시스템 아키텍처 | |
도메인 주도 설계 (DDD) | 비즈니스 도메인에 따라 모델링하고 서비스 경계를 정의하는 설계 방법론 | |
바운디드 컨텍스트 (Bounded Context) | 도메인 모델이 적용되는 명확한 논리적 구역 | |
Event Storming | 도메인 이벤트 중심의 비즈니스 프로세스 모델링 기법 | |
2. 통신 구조 및 프로토콜 | ||
API Gateway | 외부 요청을 받아 내부 서비스로 라우팅하는 진입점 컴포넌트 | |
Service Mesh | 서비스 간 통신, 보안, 트래픽 제어를 위한 인프라 계층 (예: Istio, Envoy) | |
Service Discovery | 동적으로 서비스의 위치를 등록 및 검색하는 메커니즘 | |
Message Broker | 서비스 간 비동기 메시지 전달을 위한 미들웨어 (Kafka, RabbitMQ 등) | |
gRPC / REST / GraphQL | 서비스 간 데이터 통신을 위한 프로토콜 및 API 설계 스타일 | |
Synchronous / Asynchronous Communication | 동기/비동기 통신 방식 구분 | |
Load Balancer | 다수 인스턴스 간 트래픽 분산을 수행하는 컴포넌트 | |
3. 아키텍처 패턴 및 트랜잭션 전략 | ||
CQRS (Command Query Responsibility Segregation) | 명령 (쓰기) 과 조회 (읽기) 의 책임을 분리하는 패턴 | |
Event Sourcing | 상태 변경을 이벤트 시퀀스로 기록하는 방식 | |
Saga Pattern | 분산 트랜잭션을 보상 트랜잭션으로 분할 처리하는 워크플로우 패턴 | |
Circuit Breaker | 실패 서비스 호출을 차단해 장애 전파를 방지하는 패턴 | |
Sidecar Pattern | 애플리케이션과 별도로 실행되는 보조 컴포넌트 패턴 (주로 서비스 메시에서 사용) | |
Service Decomposition | 기능 단위로 애플리케이션을 분리하는 리팩토링 접근 방식 | |
4. 데이터 및 일관성 관리 | ||
Database per Service | 각 서비스가 자체 데이터베이스를 갖는 분리 전략 | |
Eventual Consistency | 시간이 지나며 최종적으로 데이터 일관성을 확보하는 모델 | |
Sharding | 데이터를 수평으로 분할해 확장성과 처리 성능 확보 | |
Polyglot Persistence | 서비스마다 적합한 DB 기술을 선택해 사용하는 전략 | |
5. 배포 및 운영 전략 | ||
Container / Container Orchestration | 컨테이너화 및 Kubernetes 기반의 배포/관리 자동화 기술 | |
Blue-Green Deployment | 두 환경을 번갈아 배포해 무중단 배포를 지원하는 방식 | |
Canary Deployment | 새로운 버전을 일부 트래픽에만 배포해 점진적으로 확산하는 방식 | |
Health Check | 애플리케이션 상태를 주기적으로 확인하는 메커니즘 | |
CI/CD (Continuous Integration / Delivery) | 지속적 통합 및 배포 자동화를 위한 파이프라인 구축 전략 | |
Platform Engineering | 내부 개발 플랫폼을 위한 도구, 템플릿, 자동화 구성 전략 | |
6. 보안 및 인증 모델 | ||
Zero Trust Architecture | 모든 접근 요청을 검증하고 기본적으로 신뢰하지 않는 보안 모델 | |
mTLS (Mutual TLS) | 클라이언트 - 서버 간 양방향 인증 및 암호화 통신 방식 | |
JWT (JSON Web Token) | 인증/인가 정보 전달을 위한 웹 토큰 형식 | |
OAuth 2.0 | 인증과 인가를 위한 표준 프로토콜 | |
7. 관찰 가능성 및 모니터링 | ||
Observability | 시스템 상태를 외부에서 추론 가능하게 하는 능력 (Metrics, Logs, Traces 포함) | |
Distributed Tracing | 분산 시스템에서 요청 흐름을 추적하는 기술 (예: Jaeger, Zipkin) | |
Metrics / APM | 시스템 성능 지표 / 성능 모니터링 도구 (예: Prometheus, Grafana) | |
SLI / SLO / SLA | 서비스 수준 지표, 목표, 계약으로 품질 및 신뢰성 관리 |
참고 및 출처
- 마이크로서비스 아키텍처 개념 – Red Hat
- AWS 마이크로서비스 가이드
- Microsoft 마이크로서비스 아키텍처 설계
- Netflix 클라우드 마이그레이션 완료 사례
- 마이크로서비스 패턴 – 크리스 리처드슨
- Google Cloud 마이크로서비스 아키텍처
- DDD 및 마이크로서비스 패턴 – Microsoft Learn
- 마이크로서비스 아키텍처란? 주요 개념 및 예제 – PayPro Global
- MSA란?(등장배경, 특징, 장단점) – 넌 잘하고 있어
- 1.2 MSA의 특징 – 위키독스
- Microservice Pattern 정의, 특징, 설명, 구현 방법, 장점과 단점
- 마이크로서비스 아키텍처 이해하기 – F‑Lab
- Microservices Pattern: Microservice Architecture pattern
- The evolution of the Microservice Architecture pattern language
- OpenLegacy’s Complete Guide to Microservices Design Patterns
- Microservices Design Patterns – GeeksforGeeks
- 7 Essential Microservices Design Patterns | Atlassian
- Enterprise Microservices: Benefits, Implementation, and Best Practices for 2024 | Turing
- 4 Microservices Examples: Amazon, Netflix, Uber, and Etsy
- Understanding design of microservices architecture at Netflix | TechAhead
- System Design Netflix | A Complete Architecture – GeeksforGeeks
- Adopting Microservices at Netflix: Lessons for Architectural Design
- Communication patterns: HTTP vs Messaging vs Hybrid
- Saga 구조: Orchestration vs Choreography
- Service mesh 개념
- Microservices 시장 동향 및 기술 동향
- Martin Fowler, “Microservice Prerequisites.”
- Atlassian 설명 “Microservices architecture … independently deployable services”
- Redis – Microservice Architecture Key Concepts
- Understanding Microservices: Architecture, Benefits, and Best Practices – TechAhead
- 10 Microservices Design Principles and Best Practices for Developers – Collabnix
- Challenges associated with microservices architecture – Dev.to
- 10 Microservices Best Practices for the Optimal Architecture Design – Capital One Tech
- Top 10 Essential Considerations for Microservice Architecture – The Architect Guild
- Visualizing Microservice Architecture – GRM Information Management
- 5 core components of microservices architecture – TechTarget
- Microservices architecture and design: A complete overview – vFunction