eda
복제
마스터-슬레이브 패턴(Master-Slave Pattern) 정리
개요
마스터-슬레이브 패턴은 데이터베이스 시스템에서 자주 사용되는 구조로, 복제와 분산의 한 형태입니다. 이 패턴은 데이터 일관성과 가용성을 보장하면서도 시스템의 확장성과 성능을 향상시키기 위해 사용됩니다.
주요 개념
마스터(Master)
역할: 데이터베이스의 주요 쓰기 작업(데이터 입력, 수정, 삭제)을 담당합니다.
특징: 모든 데이터 변경 사항이 마스터에서 이루어지며, 마스터는 변경된 데이터를 슬레이브로 전파합니다.
단일 포인트: 마스터가 고장 나면 전체 시스템의 쓰기 작업이 중단될 수 있는 단일 장애점이 됩니다.
슬레이브(Slave)
역할: 마스터의 데이터를 복제하여 읽기 작업(데이터 조회)을 처리합니다.
특징: 슬레이브는 마스터로부터 변경된 데이터를 주기적으로 받아서 업데이트합니다. 여러 개의 슬레이브가 있을 수 있으며, 이를 통해 읽기 작업을 분산하여 처리할 수 있습니다.
확장성: 슬레이브를 추가하여 시스템의 읽기 처리 성능을 높일 수 있습니다.
장점
성능 향상: 읽기 작업을 여러 슬레이브에 분산시켜 시스템의 읽기 성능을 크게 향상시킬 수 있습니다.
확장성: 슬레이브를 추가하는 것만으로도 시스템의 처리 능력을 확장할 수 있습니다.
데이터 백업: 슬레이브에 저장된 데이터는 마스터의 백업 역할도 할 수 있습니다.
단점
데이터 일관성 문제: 마스터에서 슬레이브로 데이터가 복제되는 과정에서 약간의 지연이 발생할 수 있어, 슬레이브에서 읽은 데이터가 최신이 아닐 수 있습니다.
마스터 장애: 마스터가 장애를 일으킬 경우, 쓰기 작업이 중단되며 시스템 복구가 필요합니다.
복잡성 증가: 마스터와 슬레이브 간의 데이터 동기화와 복제 설정이 복잡할 수 있습니다.
• 복제(Replication): 데이터나 서비스의 복사본을 만들어서 처리
• 분산(Distribution): 데이터나 서비스를 여러 곳에 나누어서 처리
분산
분산(Distribution)
• 여러 노드가 범위를 나누어 데이터 처리
• RDB의 파티셔닝(샤딩), Redis 클러스터
• 읽기&쓰기 부하를 분산할 수 있어서 성능 향상에 용이
• 밸런싱과 routing이 중요하고, consistent hashing과 같은 기법
사용됨.
• RDB에서는 JOIN 연산이 불가능
분산 문제 eda 사용이유
분산으로 해결되지 않는 문제
• 분산 처리에 따라오는 복잡도와 동시성 문제
ᄋ 데이터 일관성의 문제
ᄋ Routing의 처리
노드 개수 변화에 따른 재조정(rebalancing)
○ 부분 장애
•요청량이 급변할 때(spike traffic)의 확장 문제
• 처리량을 넘었을 때 발생할 수 있는 일시적인 오류
이벤트 기반 처리로 얻을 수 있는 것들
• 요청량 변화에 탄력적으로 대응(비동기적 특성으로 인한 쉬운 확장)
• 관련 서비스의 일시적 오류에도 데이터 유실 없이 정상 작동
● 다른 서비스들과의 느슨한 결합(변경 영향도 최소화)
• 대용량 데이터의 실시간 처리(Batch 처리와 비교)
eda와 다른것들
- 이벤트 알림(Event Notification)
개요:
이벤트 알림은 이벤트 기반 시스템에서 가장 단순한 형태의 패턴입니다. 이 패턴은 이벤트가 발생했음을 다른 시스템 또는 컴포넌트에게 알리기만 합니다.
설명:
이벤트 알림은 이벤트가 발생한 사실을 알리기 위해 사용됩니다. 예를 들어, 사용자가 주문을 완료하면 "주문 완료" 이벤트를 발생시킵니다. 이 이벤트는 관련된 다른 시스템(예: 배송 시스템)에게 주문이 완료되었다는 사실을 알리는 역할만 합니다. 이벤트에는 추가적인 데이터나 상태 정보가 포함되지 않으며, 수신자는 추가 데이터를 얻기 위해 별도의 요청을 보내야 할 수 있습니다.
차이점:
이벤트 알림은 이벤트 자체의 정보를 전달하지 않으며, 단순히 이벤트가 발생했다는 사실만을 전달합니다. 이 점에서 이벤트 기반 상태 전송과 다릅니다. 후자는 상태 정보까지 포함하여 전송하므로, 수신자가 추가 데이터를 요청할 필요가 없습니다.
- 이벤트 기반 상태 전송(Event-carried State Transfer)
개요:
이벤트 기반 상태 전송은 이벤트 발생 시 해당 이벤트와 관련된 상태 정보를 포함하여 전송하는 패턴입니다.
설명:
이 패턴에서는 이벤트가 발생하면, 이벤트에 관련된 상태 정보가 포함되어 다른 시스템으로 전송됩니다. 예를 들어, 사용자가 주문을 완료했을 때, "주문 완료" 이벤트에 주문의 상세 정보(주문 ID, 품목, 가격 등)를 포함하여 전송합니다. 수신자는 이 정보를 사용해 즉시 필요한 작업을 수행할 수 있으며, 추가적인 데이터 요청이 필요 없습니다.
차이점:
이벤트 알림과 달리, 이벤트 기반 상태 전송은 이벤트 발생 시점의 상태 정보까지 전달합니다. 따라서 수신자가 데이터를 실시간으로 활용할 수 있으며, 추가 요청이 필요하지 않지만, 이벤트의 크기가 커질 수 있다는 단점이 있습니다.
- 이벤트 소싱(Event Sourcing)
개요:
이벤트 소싱은 시스템의 상태를 직접 저장하지 않고, 상태 변화를 유발한 이벤트를 순차적으로 저장하는 패턴입니다.
설명:
이 패턴에서는 모든 상태 변경이 이벤트로 저장되며, 이러한 이벤트의 기록이 시스템의 상태를 재구성하는 데 사용됩니다. 예를 들어, 은행 계좌의 잔액을 저장하는 대신, 입금과 출금 이벤트를 모두 기록합니다. 시스템의 현재 상태(예: 계좌 잔액)를 알고 싶다면, 모든 이벤트를 순차적으로 재생하여 상태를 계산합니다.
차이점:
이벤트 소싱은 상태를 직접 저장하는 대신, 이벤트를 통해 상태를 재구성합니다. 이는 이벤트 알림이나 상태 전송과 달리, 시스템 상태의 변경 이력을 완벽하게 추적할 수 있다는 장점이 있지만, 상태를 재구성하는 과정이 복잡하고 시간이 오래 걸릴 수 있습니다.
- CQRS(Command and Query Responsibility Segregation)
개요:
CQRS는 명령(Command)과 조회(Query) 작업을 분리하여 각각의 모델로 관리하는 패턴입니다.
설명:
이 패턴은 시스템에서 쓰기 작업(명령)과 읽기 작업(조회)을 별도의 데이터 모델로 분리합니다. 예를 들어, 주문 시스템에서 주문 생성(쓰기)과 주문 조회(읽기)를 각각 다른 데이터베이스 또는 모델을 사용하여 처리합니다. 이로 인해 각 작업에 최적화된 데이터 구조를 사용할 수 있어 성능을 개선할 수 있습니다. CQRS는 종종 이벤트 소싱과 결합하여 사용되며, 읽기와 쓰기 모델 간의 일관성을 유지하는 것이 중요합니다.
차이점:
CQRS는 이벤트의 전달 방식보다는 시스템의 구조와 관련이 있습니다. CQRS는 쓰기와 읽기 작업을 분리하여 최적화하지만, 구조가 복잡해질 수 있습니다. 이벤트 알림, 상태 전송, 이벤트 소싱은 주로 이벤트를 어떻게 전달하고 저장할 것인지에 관한 패턴입니다.
EDA의 장단점
장점
• 느슨한 결합(유연성) 확장성
• 실시간 처리
•분산 아키텍처(MSA)
복잡성
단점
• 디버깅 어려움
• 일관성 관리
• 이벤트 소실 및 중복
