2905 words
15 minutes
[MSA]Major Patterns
Overview
01. Decomposition Patterns
트래픽 증가에 따른 아키텍처 설계 고려사항
일반적인 해결방법
- Vertical Scaling
- Horizontal Scaling
- Load Balancing
- Caching
- CDN (Content Delivery Network)
- Database Sharding
- 어플리케이션 분리
02. Communication Patterns
Sync Communication
- Http Based RESTful API
- GraphQL API
- gRPC API
- WebSocket API
Patterns
- Gateway Routing
- Gateway Aggregation
- Gateway Offloading : API Gateway가 백엔드 서비스의 부하를 줄이기 위해 일부 작업을 오프로드하는 패턴. 예를 들어, 인증, 로깅, 캐싱 등을 API Gateway에서 처리하고, 백엔드 서비스는 비즈니스 로직에 집중할 수 있도록 함.
- BFF: Backend for Frontend. 프론트엔드 애플리케이션에 최적화된 백엔드 서비스를 제공하는 패턴. 각 프론트엔드 애플리케이션(웹, 모바일 등)에 맞춤형 API를 제공하여 클라이언트의 요구사항을 충족시킴.
- API Gateway Pattern: 모든 클라이언트에 대해 단일 진입점을 제공하는 패턴. 클라이언트 요청을 적절한 서비스로 라우팅하고, 인증, 로깅, 캐싱 등의 공통 기능을 처리함.
Async Communication
- single-receiver communication (one-to-one)
- multi-receiver communication (one-to-many model-topic)
- dependency inversion principles
Patterns
- Fan-out Publish/Subscribe Messaging Pattern: 메시징 시스템에서 다수의 소비자에게 메시지를 전달하는 패턴. 발행자가 메시지를 발행하면, 여러 구독자가 해당 메시지를 수신함. 이를 통해 시스템의 확장성과 유연성을 향상시킬 수 있음.
- Topic-Queue Chaining Pattern: 메시징 시스템에서 토픽과 큐를 연결하여 메시지를 전달하는 패턴. 토픽은 다수의 소비자에게 메시지를 전달하고, 큐는 단일 소비자에게 메시지를 전달함.
- Load Balancing: 메시징 시스템에서 부하 분산을 위해 여러 소비자에게 메시지를 분배하는 패턴. 이를 통해 시스템의 확장성과 가용성을 향상시킬 수 있음.
Problems & Solutions
- 클라이언트-서비스 직접통신 -> Well Defined API
- 서비스간 통신으로 인한 네트워크 부하 증가 -> gRPC API
- 서비스 간 통신으로 발생되는 연쇄적인 쿼리 문제 -> Aggreage query operations , Service Aggregator Pattern
- 동기화 통신에서는 처리시간이 오래걸리는 작업 수행 불가 -> Asynchronous Communication, Event-Driven Architecture
03. Data Management Patterns
Data Management
- shared database(anti-pattern)
- CAP theorem (Consistency, Availability, Partition Tolerance)
- Eventual Consistency:
일관성이 완벽하게 보장되지 않지만, 시간이 지남에 따라 시스템이 일관된 상태로 수렴하는 것을 의미. 분산 시스템에서 데이터의 일관성을 유지하기 위해 사용됨. - Data Partitioning : Horizontal Partitioning, Vertical Partitioning.
- Sharding : 데이터베이스의 데이터를 여러 서버에 분산 저장하여 성능과 확장성을 향상시키는 기술. 각 서버는 데이터의 일부만을 저장하며, 이를 통해 대규모 데이터베이스의 부하를 분산시킬 수 있음.
- Materialized View : 데이터베이스에서 자주 조회되는 데이터를 미리 계산하여 저장하는 기술. 이를 통해 조회 성능을 향상시킬 수 있으며, 데이터 변경 시 자동으로 업데이트되도록 설정할 수 있음.
- CQRS (Command Query Responsibility Segregation) : 명령(Command)과 조회(Query)를 분리하여 처리하는 아키텍처 패턴. 이를 통해 시스템의 복잡성을 줄이고, 성능을 향상시킬 수 있음. 명령은 데이터 변경을 담당하고, 조회는 데이터를 읽는 역할을 수행함.
- Event Sourcing : 시스템의 상태를 이벤트로 기록하여 상태 변경을 추적하는 패턴. 이를 통해 시스템의 상태를 재구성할 수 있으며, 이벤트 로그를 통해 시스템의 동작을 분석할 수 있음.
Problems & Solutions
- 마이크로서비스에 대한 다양한 데이터 요구사항 및 스케일링 시 데이터베이스 병목 현상 -> Data Partitioning, Sharding
- 데이터베이스 작업은 비용이 많이 들고 성능이 낮음 -> 분산 캐시, Materialized View, Storing frequently accessed data in memory
- 데이터베이스의 일관성 문제 -> Eventual Consistency, CQRS, Event Sourcing
04. Transaction Management Patterns
Distributed Transactions
- SAGA (Saga Pattern) : 분산 트랜잭션을 관리하기 위한 패턴으로, 여러 서비스 간의 트랜잭션을 순차적으로 처리하고, 각 단계에서 실패 시 보상 작업을 수행하여 전체 트랜잭션을 롤백하는 방식.
- Compensating Transaction : SAGA 패턴에서 각 단계의 작업이 실패했을 때, 이전 단계의 작업을 취소하기 위한 보상 작업을 수행하는 방식. 이를 통해 전체 트랜잭션의 일관성을 유지할 수 있음. 여기서 보상 작업은 원래 작업을 취소하는 것이 아니라, 해당 작업의 영향을 상쇄하는 작업을 수행함.
- Two-Phase Commit (2PC) : 분산 트랜잭션을 처리하기 위한 전통적인 방법으로, 모든 참여자가 트랜잭션을 커밋할 준비가 되었는지 확인하고, 모든 참여자가 커밋을 수행하는 방식. 이 방법은 트랜잭션의 일관성을 보장하지만, 성능과 확장성에 제한이 있을 수 있음.
- Transactional Outbox : 메시징 시스템과 데이터베이스 간의 일관성을 유지하기 위한 패턴으로, 데이터베이스에 트랜잭션을 기록하고, 해당 트랜잭션이 커밋된 후에 메시지를 발행하는 방식. 이를 통해 데이터베이스와 메시징 시스템 간의 일관성을 유지할 수 있음.
- CDC (Change Data Capture) : 데이터베이스의 변경 사항을 실시간으로 감지하고, 이를 다른 시스템에 전달하는 기술. 이를 통해 데이터베이스의 변경 사항을 다른 시스템과 동기화할 수 있으며, 이벤트 기반 아키텍처에서 유용하게 사용됨.
- Dual Write : 데이터베이스와 메시징 시스템에 동시에 데이터를 기록하는 방식. 이를 통해 데이터베이스와 메시징 시스템 간의 일관성을 유지할 수 있으며, 데이터베이스의 변경 사항을 실시간으로 메시징 시스템에 전달할 수 있음.
- Event Hub : 이벤트 기반 아키텍처에서 이벤트를 중앙 집중식으로 관리하는 시스템. 이를 통해 다양한 서비스 간의 이벤트를 효율적으로 처리하고, 이벤트의 흐름을 추적할 수 있음. 이벤트 허브는 이벤트의 발행, 구독, 라우팅 등을 담당하며, 시스템의 확장성과 유연성을 향상시킬 수 있음.
- High Volume Event Processing : 대량의 이벤트를 실시간으로 처리하는 기술. 이를 통해 시스템의 성능과 확장성을 향상시킬 수 있으며, 이벤트의 흐름을 실시간으로 분석하고, 필요한 작업을 수행할 수 있음. 대량의 이벤트를 처리하기 위해 분산 시스템, 병렬 처리, 스트리밍 데이터 처리 등의 기술이 사용됨.
Problems & Solutions
- 기본적으로 분산 트랜잭션에서 마이크로서비스간 일관성을 어떻게 유지할 것인가에 대한 문제 -> SAGA, Compensating Transaction, Two-Phase Commit (2PC)
- 수백만 건의 이벤트를 처리해야 하는 경우, 이벤트의 흐름을 어떻게 관리할 것인가에 대한 문제 -> Event Driven Architecture, Event Hub, High Volume Event Processing
- 다운타임을 최소화하고, 시스템의 가용성을 유지하기 위한 문제 -> Transactional Outbox, CDC, Dual Write
06. Resilience Patterns
- Retry : 서비스 간의 통신에서 일시적인 장애가 발생했을 때, 해당 요청을 일정 횟수만큼 재시도하는 패턴. 이를 통해 일시적인 네트워크 문제나 서비스 장애로 인한 요청 실패를 극복할 수 있음.
- Circuit Breaker : 서비스 간의 통신에서 장애가 발생했을 때, 해당 서비스에 대한 요청을 일시적으로 차단하여 시스템의 안정성을 유지하는 패턴. 이를 통해 장애가 발생한 서비스에 대한 요청을 반복적으로 시도하는 것을 방지하고, 시스템의 부하를 줄일 수 있음.
- Bulkhead : 시스템의 일부를 격리하여 장애가 발생했을 때, 전체 시스템에 영향을 미치지 않도록 하는 패턴. 이를 통해 시스템의 안정성을 향상시킬 수 있으며, 특정 서비스나 컴포넌트의 장애가 전체 시스템에 영향을 미치지 않도록 할 수 있음.
- Timeout : 서비스 간의 통신에서 요청이 일정 시간 내에 응답하지 않을 경우, 해당 요청을 취소하고 오류를 반환하는 패턴. 이를 통해 서비스 간의 통신에서 발생할 수 있는 지연이나 무한 대기를 방지할 수 있음.
- Fallback : 서비스 간의 통신에서 요청이 실패했을 때, 대체 로직을 실행하여 시스템의 가용성을 유지하는 패턴. 이를 통해 서비스 간의 통신에서 발생할 수 있는 오류를 처리하고, 시스템의 안정성을 향상시킬 수 있음.
- Distributed Logging and Distributed Tracing : 분산 시스템에서 각 서비스의 로그와 트레이스를 중앙 집중식으로 관리하는 기술. 이를 통해 시스템의 동작을 추적하고, 문제를 진단할 수 있으며, 시스템의 성능을 모니터링할 수 있음. 분산 로깅과 트레이싱은 시스템의 복잡성을 줄이고, 문제 해결을 용이하게 함.
07. Deployment Patterns
- Sidecar : 애플리케이션의 기능을 확장하기 위해 별도의 프로세스로 실행되는 컴포넌트. 주로 로깅, 모니터링, 보안 등의 기능을 담당하며, 애플리케이션과 함께 배포되어 독립적으로 실행됨.
- Service Mesh : 마이크로서비스 간의 통신을 관리하고, 보안, 로깅, 모니터링 등의 기능을 제공하는 인프라 계층. 서비스 메시는 서비스 간의 통신을 자동으로 처리하고, 트래픽 관리, 장애 복구, 보안 등을 지원함.
- Blue-Green Deployment : 새로운 버전의 애플리케이션을 배포할 때, 기존 버전과 새로운 버전을 동시에 운영하여, 새로운 버전이 안정적인지 확인한 후에 트래픽을 전환하는 배포 전략. 이를 통해 다운타임을 최소화하고, 롤백이 용이함.
- Rolling Deployment : 애플리케이션의 새로운 버전을 점진적으로 배포하여, 전체 시스템에 영향을 미치지 않도록 하는 전략. 이를 통해 새로운 버전의 안정성을 검증하고, 문제가 발생했을 때 빠르게 롤백할 수 있음.
- Canary Deployment : 새로운 버전의 애플리케이션을 소수의 사용자에게 먼저 배포하여, 안정성을 검증한 후에 전체 사용자에게 배포하는 전략. 이를 통해 새로운 버전의 문제를 조기에 발견하고, 전체 시스템에 영향을 미치지 않도록 함.
Reference
back link
- [[msa_02_major_patterns]]
- [[00_MSA_index]]
[MSA]Major Patterns
https://yjinheon.netlify.app/posts/03be/msa/msa_02_major_patterns/