이벤트 소싱 아키텍처: 도메인 이벤트 저장 시스템 심층 분석

이벤트 소싱은 애플리케이션의 상태가 일련의 이벤트에 의해 결정되는 아키텍처 패턴입니다. 엔터티의 현재 상태를 저장하는 대신 해당 엔터티의 변경 사항을 나타내는 불변 이벤트 시리즈를 유지합니다. 이 블로그 게시물에서는 이벤트 소싱 아키텍처를 자세히 살펴보고 특히 도메인 이벤트 저장 시스템에 중점을 둘 것입니다.

이벤트 소싱이란 무엇입니까?

기존 시스템에서는 엔터티의 현재 상태가 데이터베이스에 직접 저장됩니다. 업데이트가 발생하면 기존 레코드가 수정되거나 덮어쓰여집니다. 이 접근 방식은 많은 애플리케이션에서 잘 작동하지만 다음과 같은 경우에는 제한 사항이 있습니다.

• 감사 및 기록 추적이 중요한 경우.
• 복잡한 상태 전환을 재구성해야 하는 경우.
• 실시간 데이터 전파 및 이벤트 기반 아키텍처가 필요한 경우.

이벤트 소싱은 각 상태 변경 사항을 불변 이벤트로 저장하여 이러한 제한 사항을 해결합니다. 이러한 이벤트는 추가 전용 이벤트 저장소에 유지됩니다. 엔터티의 현재 상태를 재구성하려면 이벤트가 발생한 순서대로 다시 재생됩니다. 모든 트랜잭션이 기록되고 잔액이 모든 트랜잭션을 합산하여 계산되는 원장과 같다고 생각하십시오.

주요 개념

• 도메인 이벤트: 도메인에서 발생한 상황을 나타내는 사실입니다. 이는 상태 변경에 대한 불변 기록입니다. 예로는 OrderCreated, OrderShipped, PaymentReceived가 있습니다.
• 이벤트 저장소: 도메인 이벤트를 저장하고 검색하도록 최적화된 추가 전용 데이터 저장소입니다. 이벤트 지속성, 검색 및 구독을 위한 메커니즘을 제공합니다.
• 이벤트 핸들러: 도메인 이벤트에 반응하는 구성 요소입니다. 읽기 모델을 업데이트하고, 외부 통합을 트리거하거나, 기타 작업을 수행할 수 있습니다.
• 읽기 모델: 특정 쿼리 패턴에 최적화된 비정규화된 데이터 표현입니다. 이벤트 핸들러에 의해 업데이트되고 데이터의 읽기 전용 뷰를 제공합니다.
• 스냅샷: 엔터티의 현재 상태를 주기적으로 저장하여 상태 재구성을 최적화하는 데 사용되는 기술입니다. 상태를 재구성할 때 시스템은 최신 스냅샷을 로드하고 스냅샷이 생성된 후에 발생한 이벤트만 다시 재생합니다.

이벤트 소싱의 이점

이벤트 소싱은 기존 CRUD(생성, 읽기, 업데이트, 삭제) 아키텍처에 비해 다음과 같은 여러 가지 장점을 제공합니다.

• 완전한 감사 추적: 모든 상태 변경 사항이 이벤트로 기록되어 애플리케이션 데이터의 포괄적인 기록을 제공합니다. 이는 감사, 디버깅 및 규정 준수에 매우 중요합니다.
• 시간적 쿼리: 특정 시점의 엔터티 상태를 쿼리하는 기능입니다. 이를 통해 과거 분석 및 보고가 가능합니다. 예를 들어 특정 날짜에 특정 지역에서 발생한 주문 수를 확인할 수 있습니다.
• 간소화된 디버깅: 이벤트를 다시 재생하여 애플리케이션의 과거 상태를 재현할 수 있으므로 버그를 더 쉽게 식별하고 수정할 수 있습니다.
• 특정 작업에 대한 성능 향상: 상태 재구성이 느릴 수 있지만 읽기 모델 업데이트는 특정 쿼리 패턴에 대해 매우 최적화될 수 있습니다.
• 이벤트 기반 아키텍처: 이벤트 소싱은 이벤트 기반 아키텍처와 자연스럽게 일치하여 실시간 데이터 전파 및 다른 시스템과의 통합을 가능하게 합니다.
• 더 쉬운 진화: 기존 이벤트 스트림에 영향을 주지 않고 새로운 이벤트 핸들러를 추가하기만 하면 되기 때문에 새로운 기능을 추가하거나 기존 기능을 수정하는 것이 종종 더 쉽습니다.
• 향상된 확장성: 여러 노드에 이벤트 처리를 분산하면 확장성과 복원력을 향상시킬 수 있습니다.

이벤트 소싱의 과제

이벤트 소싱은 또한 신중하게 고려해야 할 몇 가지 과제를 제시합니다.

• 복잡성: 이벤트 소싱을 구현하려면 다른 사고방식과 도메인 모델링 및 이벤트 기반 원칙에 대한 더 깊은 이해가 필요합니다.
• 최종 일관성: 읽기 모델은 이벤트 저장소와 최종적으로 일관성을 가지므로 사용자 인터페이스에 지연 및 불일치가 발생할 수 있습니다. 낙관적 잠금 또는 보상 트랜잭션과 같은 최종 일관성을 처리하기 위한 전략을 구현해야 합니다.
• 이벤트 버전 관리: 애플리케이션이 진화함에 따라 도메인 이벤트의 구조가 변경될 수 있습니다. 이벤트 마이그레이션 또는 스키마 진화와 같은 이벤트 버전 관리를 처리하기 위한 전략을 구현하여 이전 버전과의 호환성을 보장해야 합니다.
• 상태 재구성: 이벤트를 다시 재생하여 엔터티의 상태를 재구성하는 데 시간이 오래 걸릴 수 있습니다(특히 이벤트 수가 많은 엔터티의 경우). 스냅샷은 이 문제를 완화하는 데 도움이 될 수 있습니다.
• 적절한 이벤트 저장소 선택: 애플리케이션의 성능, 확장성 및 안정성 요구 사항을 충족하는 적절한 이벤트 저장소를 선택하는 것이 중요합니다.

도메인 이벤트 저장 시스템: 비교 개요

1. 관계형 데이터베이스(SQL)

PostgreSQL, MySQL 및 SQL Server와 같은 관계형 데이터베이스는 이벤트 저장소로 사용할 수 있습니다. ACID(원자성, 일관성, 격리성, 지속성) 속성과 강력한 데이터 일관성을 제공하지만 높은 처리량 이벤트 처리에 가장 효율적인 선택이 아닐 수 있습니다.

장점:

• ACID 속성: 데이터 무결성 및 일관성을 보장합니다.
• 성숙한 기술: 광범위한 도구 및 지원을 갖춘 잘 확립된 기술입니다.
• 친숙성: 대부분의 개발자는 관계형 데이터베이스에 익숙합니다.
• 강력한 일관성: 강력한 일관성 보장을 제공합니다.

단점:

• 성능 병목 현상: 대용량 이벤트 스트림에 대한 성능 병목 현상이 될 수 있습니다.
• 스키마 진화 과제: 스키마 변경 사항을 처리하는 것은 복잡할 수 있으며 신중한 계획이 필요합니다.
• 확장성 제한: 관계형 데이터베이스 확장은 특히 쓰기 작업이 많은 워크로드의 경우 어려울 수 있습니다.
• 추가 전용 작업에 최적화되지 않음: 관계형 데이터베이스는 특히 추가 전용 작업을 위해 설계되지 않았으므로 성능에 영향을 미칠 수 있습니다.

구현 예(PostgreSQL):

도메인 이벤트를 저장할 테이블을 만듭니다.

            CREATE TABLE events (
  event_id UUID PRIMARY KEY,
  aggregate_id UUID NOT NULL,
  event_type VARCHAR(255) NOT NULL,
  event_data JSONB NOT NULL,
  created_at TIMESTAMP WITHOUT TIME ZONE NOT NULL DEFAULT (NOW() AT TIME ZONE 'utc')
);

            

              
                Copy
              
            
          

새 이벤트를 삽입합니다.

            INSERT INTO events (event_id, aggregate_id, event_type, event_data)
VALUES (uuid_generate_v4(), 'a1b2c3d4-e5f6-7890-1234-567890abcdef', 'OrderCreated', '{"orderId": "ORD-123", "customerId": "CUST-456", "amount": 100}');

            

              
                Copy
              
            
          

2. NoSQL 데이터베이스

MongoDB, Cassandra 및 Couchbase와 같은 NoSQL 데이터베이스는 관계형 데이터베이스에 비해 더 많은 유연성과 확장성을 제공합니다. 대용량 이벤트 스트림을 처리하는 데 적합하지만 데이터 일관성 보장이 더 약할 수 있습니다.

장점:

• 확장성: 수평 확장을 위해 설계되었으며 대량의 데이터를 처리할 수 있습니다.
• 유연성: 스키마 없음 또는 유연한 스키마로 더 쉽게 이벤트 버전을 관리할 수 있습니다.
• 성능: 높은 처리량 읽기 및 쓰기 작업에 최적화되어 있습니다.
• 비용 효율성: 특정 워크로드의 경우 관계형 데이터베이스보다 비용 효율적일 수 있습니다.

단점:

• 최종 일관성: 관계형 데이터베이스에 비해 데이터 일관성 보장이 더 약할 수 있습니다.
• 복잡성: NoSQL 데이터베이스 개념 및 데이터 모델링 기술에 대한 더 깊은 이해가 필요합니다.
• 성숙도: 일부 NoSQL 데이터베이스는 관계형 데이터베이스보다 성숙도가 낮습니다.
• 쿼리 제한: 쿼리 기능이 관계형 데이터베이스에 비해 제한될 수 있습니다.

구현 예(MongoDB):

컬렉션에 도메인 이벤트를 저장합니다.

            {
  "event_id": "a1b2c3d4-e5f6-7890-1234-567890abcdef",
  "aggregate_id": "f1g2h3i4-j5k6-l7m8-n9o0-p1q2r3s4t5uv",
  "event_type": "OrderCreated",
  "event_data": {
    "orderId": "ORD-123",
    "customerId": "CUST-456",
    "amount": 100
  },
  "created_at": ISODate("2023-10-27T10:00:00.000Z")
}

            

              
                Copy
              
            
          

3. 전문 이벤트 저장소

EventStoreDB 및 AxonDB와 같은 전문 이벤트 저장소는 특히 이벤트 소싱을 위해 설계되었습니다. 추가 전용 저장소, 이벤트 버전 관리 및 스트림 관리와 같은 기능을 제공합니다. 이러한 데이터베이스는 이벤트 소싱에 진지한 경우 일반적으로 최상의 선택입니다.

장점:

• 이벤트 소싱에 최적화됨: 추가 전용 저장소, 스트림 관리 및 이벤트 버전 관리와 같은 기능을 갖춘 이벤트 소싱을 위해 특별히 설계되었습니다.
• 높은 성능: 높은 처리량 이벤트 처리에 최적화되어 있습니다.
• 최종 일관성 처리: 최종 일관성을 처리하기 위한 기본 제공 메커니즘.
• 스트림 관리: 이벤트 스트림 관리 및 쿼리를 단순화합니다.

단점:

• 공급업체 종속성: 공급업체 종속성을 도입할 수 있습니다.
• 비용: 다른 옵션보다 비용이 더 많이 들 수 있습니다.
• 학습 곡선: 새로운 기술을 배워야 합니다.
• 제한된 채택: 관계형 및 NoSQL 데이터베이스보다 채택률이 낮습니다.

구현 예(EventStoreDB):

EventStoreDB는 스트림을 사용하여 이벤트를 저장합니다. EventStoreDB 클라이언트 라이브러리를 사용하여 스트림에 이벤트를 추가할 수 있습니다.

4. 메시지 큐(Kafka, RabbitMQ)

Apache Kafka 및 RabbitMQ와 같은 메시지 큐는 특히 스트림 처리 프레임워크와 함께 이벤트 저장소로 사용할 수 있습니다. 높은 처리량, 확장성 및 내결함성을 제공하므로 대규모 이벤트 기반 애플리케이션에 적합합니다. 그러나 일반적으로 영구 저장소보다 일시적인 전송 메커니즘으로 더 많이 사용됩니다.

장점:

• 높은 처리량: 높은 처리량 메시지 처리를 위해 설계되었습니다.
• 확장성: 확장성이 뛰어나고 대량의 이벤트를 처리할 수 있습니다.
• 내결함성: 기본 제공 내결함성 메커니즘.
• 실시간 처리: 실시간 이벤트 처리를 지원합니다.

단점:

• 복잡성: 메시지 큐 개념 및 스트림 처리 프레임워크에 대한 더 깊은 이해가 필요합니다.
• 데이터 지속성: 데이터 지속성을 신중하게 구성해야 합니다.
• 이벤트 재실행: 이벤트를 다시 실행하는 것은 전문 이벤트 저장소를 사용하는 것보다 더 복잡할 수 있습니다.
• 순서 보장: 구성에 따라 순서 보장이 제한될 수 있습니다.

구현 예(Apache Kafka):

도메인 이벤트를 Kafka 토픽에 게시합니다.

            // Producer configuration
Properties props = new Properties();
props.put("bootstrap.servers", "localhost:9092");
props.put("key.serializer", "org.apache.kafka.common.serialization.StringSerializer");
props.put("value.serializer", "org.apache.kafka.common.serialization.StringSerializer");

Producer<String, String> producer = new KafkaProducer<>(props);

// Create a record
ProducerRecord<String, String> record = new ProducerRecord<>("order-events", "ORD-123", "{\"event_type\": \"OrderCreated\", \"customerId\": \"CUST-456\", \"amount\": 100}");

// Send the record
producer.send(record);

producer.close();

            

              
                Copy
              
            
          

5. 클라우드 기반 이벤트 저장소

클라우드 공급자는 Azure Event Hubs, AWS Kinesis 및 Google Cloud Pub/Sub과 같은 관리형 이벤트 저장소 서비스를 제공합니다. 이러한 서비스는 확장성, 안정성 및 사용 편의성을 제공하므로 클라우드 네이티브 애플리케이션에 적합합니다.

장점:

• 확장성: 확장성이 뛰어나고 대량의 이벤트를 처리할 수 있습니다.
• 안정성: 기본 제공 안정성 및 내결함성.
• 사용 편의성: 관리형 서비스는 배포 및 유지 관리를 단순화합니다.
• 통합: 다른 클라우드 서비스와의 원활한 통합.

단점:

• 공급업체 종속성: 공급업체 종속성을 도입합니다.
• 비용: 자체 관리 솔루션보다 비용이 더 많이 들 수 있습니다.
• 대기 시간: 네트워크 대기 시간이 성능에 영향을 미칠 수 있습니다.
• 제어: 기본 인프라에 대한 제어가 적습니다.

성능 고려 사항

성능은 도메인 이벤트 저장 시스템을 선택할 때 중요한 요소입니다. 다음은 염두에 두어야 할 몇 가지 성능 고려 사항입니다.

• 쓰기 처리량: 들어오는 이벤트의 높은 볼륨을 처리하는 기능.
• 읽기 대기 시간: 이벤트를 검색하고 엔터티의 상태를 재구성하는 데 걸리는 시간.
• 동시성: 동시 읽기 및 쓰기 작업을 처리하는 기능.
• 저장 용량: 이벤트를 저장하는 데 필요한 저장 공간의 양.
• 네트워크 대기 시간: 애플리케이션과 이벤트 저장소 간의 대기 시간.

성능을 최적화하려면 다음 기술을 고려하십시오.

• 일괄 처리: 이벤트 저장소에 쓰기 전에 이벤트를 일괄 처리하면 쓰기 처리량을 향상시킬 수 있습니다.
• 캐싱: 자주 액세스하는 이벤트를 캐싱하면 읽기 대기 시간을 줄일 수 있습니다.
• 스냅샷: 스냅샷은 엔터티의 상태를 재구성할 때 다시 재생해야 하는 이벤트 수를 줄일 수 있습니다.
• 인덱싱: 집계 ID 및 기타 관련 속성을 기반으로 이벤트를 인덱싱하면 쿼리 성능을 향상시킬 수 있습니다.
• 샤딩: 여러 노드에 걸쳐 이벤트 저장소를 샤딩하면 확장성과 성능을 향상시킬 수 있습니다.

데이터 무결성

데이터 무결성은 이벤트 소싱에서 가장 중요합니다. 이벤트가 안정적으로 올바른 순서로 유지되는지 확인하는 것이 중요합니다. 다음은 데이터 무결성을 유지하기 위한 몇 가지 전략입니다.

• 트랜잭션: 트랜잭션을 사용하여 이벤트가 이벤트 저장소에 원자적으로 기록되도록 합니다.
• 멱등성: 이벤트 핸들러가 멱등성이 되도록 설계합니다. 즉, 의도하지 않은 부작용을 일으키지 않고 동일한 이벤트를 여러 번 처리할 수 있습니다.
• 낙관적 잠금: 낙관적 잠금을 사용하여 동일한 집계에 대한 동시 업데이트를 방지합니다.
• 이벤트 유효성 검사: 이벤트 저장소에 유지하기 전에 이벤트를 유효성 검사하여 유효하고 일관성이 있는지 확인합니다.
• 체크섬: 이벤트에 대한 체크섬을 계산하고 이벤트와 함께 저장합니다. 이벤트를 검색할 때 체크섬을 확인하여 손상되지 않았는지 확인합니다.

이벤트 버전 관리

애플리케이션이 진화함에 따라 도메인 이벤트의 구조가 변경될 수 있습니다. 이전 버전과의 호환성을 보장하고 데이터 손실을 방지하려면 이벤트 버전 관리를 처리하는 것이 중요합니다. 다음은 이벤트 버전 관리를 처리하기 위한 몇 가지 전략입니다.

• 이벤트 업캐스팅: 이벤트 저장소에서 읽을 때 이전 이벤트 버전을 최신 버전으로 변환합니다.
• 스키마 진화: 새로운 필드를 추가하거나 기존 필드를 수정하여 시간이 지남에 따라 이벤트 스키마를 진화시킵니다. 이전 이벤트 버전을 여전히 올바르게 처리할 수 있는지 확인합니다.
• 이벤트 마이그레이션: 이전 이벤트를 최신 스키마 버전으로 마이그레이션합니다. 이는 백그라운드 프로세스로 수행할 수 있습니다.

실제 예

이벤트 소싱은 다양한 산업 및 애플리케이션에서 사용됩니다. 다음은 몇 가지 실제 예입니다.

• 전자 상거래: 주문 기록, 재고 변경 및 고객 활동 추적. 예를 들어 글로벌 전자 상거래 플랫폼은 이벤트 소싱을 사용하여 다양한 국가의 주문을 추적하고, 통화 변환을 처리하고, 여러 창고에서 재고를 관리할 수 있습니다.
• 은행: 트랜잭션 기록, 계정 잔액 추적 및 재무 활동 감사. 다국적 은행은 이벤트 소싱을 사용하여 서로 다른 지점 및 통화에 걸쳐 트랜잭션을 추적하여 완전한 감사 추적을 보장할 수 있습니다.
• 게임: 플레이어 액션, 게임 상태 변경 및 이벤트 기록 추적. 온라인 멀티플레이어 게임은 종종 이벤트 소싱을 사용하여 여러 플레이어와 서버에서 일관된 게임 상태를 유지합니다.
• 공급망 관리: 제품 이동, 재고 수준 및 배송 일정 추적. 글로벌 물류 회사는 이벤트 소싱을 사용하여 여러 국가의 배송을 추적하고, 통관 절차를 처리하고, 배송 일정을 관리할 수 있습니다.

적절한 저장 시스템 선택: 의사 결정 매트릭스

어떤 도메인 이벤트 저장 시스템이 애플리케이션에 적합한지 결정하는 데 도움이 되도록 다음 의사 결정 매트릭스를 고려하십시오.

실행 가능한 통찰력

다음은 이벤트 소싱을 구현하기 위한 몇 가지 실행 가능한 통찰력입니다.

• 작게 시작하십시오: 이벤트 소싱을 더 크고 복잡한 도메인에 적용하기 전에 작고 잘 정의된 도메인부터 시작하여 이벤트 소싱에 대한 경험을 쌓으십시오.
• 도메인에 집중하십시오: 도메인을 신중하게 모델링하고 주요 도메인 이벤트를 식별하십시오.
• 적절한 저장 시스템을 선택하십시오: 애플리케이션의 성능, 확장성 및 데이터 일관성 요구 사항을 충족하는 이벤트 저장소를 선택하십시오.
• 이벤트 버전 관리를 구현하십시오: 이전 버전과의 호환성을 보장하기 위해 처음부터 이벤트 버전 관리를 계획하십시오.
• 성능을 모니터링하십시오: 잠재적인 병목 현상을 식별하기 위해 이벤트 저장소 및 이벤트 핸들러의 성능을 모니터링하십시오.
• 배포를 자동화하십시오: 이벤트 소싱 인프라의 배포 및 관리를 자동화하십시오.
• 장단점을 고려하십시오: 이벤트 소싱에는 장단점이 있습니다. 패턴에서 얻는 이점에 대해 복잡성이 발생한다는 점을 이해하십시오.

결론

이벤트 소싱은 완전한 감사 추적, 시간적 쿼리 및 특정 작업에 대한 향상된 성능을 포함하여 수많은 이점을 제공하는 강력한 아키텍처 패턴입니다. 그러나 복잡성, 최종 일관성 및 이벤트 버전 관리와 같이 신중하게 고려해야 할 과제도 제시합니다. 도메인 이벤트 저장 시스템을 신중하게 선택하고 모범 사례를 구현하면 이벤트 소싱을 성공적으로 활용하여 확장 가능하고 복원력이 뛰어나며 감사 가능한 애플리케이션을 구축할 수 있습니다.

이 가이드에서는 이벤트 소싱 및 여러 인기 있는 도메인 이벤트 저장 시스템에 대한 개요를 제공했습니다. 프로젝트 요구 사항의 특정 요구 사항에 맞게 최상의 시스템을 선택하십시오.

이 콘텐츠는 전 세계 사용자를 대상으로 하므로 고유한 상황과 문화적 맥락에 맞게 개념을 조정하고 적용하십시오. 이벤트 소싱 원칙은 보편적이지만 구현은 특정 요구 사항 및 리소스에 따라 다를 수 있습니다.