▲

GN⁺: 관계형 데이터에서 이벤트로의 전환

 (event-driven.io)
2P by neo 11달전 | favorite | 댓글 1개

관계형 데이터에서 이벤트로의 전환 안내서

  • 이벤트 소싱 교회에서는 비즈니스 데이터를 잃지 않고 이벤트로 보존함.
  • 이벤트는 발생한 사실들을 나타내며, 각 작업 후에 저장됨.
  • 이벤트 스트림은 기록된 모든 이벤트의 목록으로, 불변성을 가지며 과거의 실수를 새로운 이벤트를 추가하여 수정할 수 있음.

1. 상태 컬럼 찾기

  • 상태 컬럼의 값은 데이터의 생명주기 단계를 반영할 수 있음.
  • 예를 들어, 주문이 시작될 수 있고, 배송될 수 있으며, 결제될 수 있음.
  • 이러한 상태는 Order Initiated, Order Shipped, Order Paid 같은 이벤트로 전환될 수 있음.

2. 날짜 컬럼 확인

  • 날짜 컬럼은 프로세스의 중요한 사건들에 대한 정보를 제공할 수 있음.
  • ShipmentDate, DeliveryDate, OrderPlacementDate 등은 비즈니스 용어를 알려주고 새로운 이벤트를 도입하는 데 도움이 될 수 있음.

3. 컬럼 선택성 분석

  • Nullable 컬럼은 나중에 제공되거나 선택적일 수 있음.
  • 필수 컬럼은 첫 Order Initiated 이벤트에서 제공되어야 함.

4. 1 대 다 관계가 가장 많은 테이블 검색

  • 이벤트 소싱에서는 비즈니스 프로세스를 중심으로 데이터를 그룹화하여 효율적인 처리를 추구함.
  • 1 대 다 관계가 많은 테이블은 스트림 유형의 후보가 될 수 있음.

5. 명시적인 이벤트 도입

  • 관계형 데이터를 이벤트로 마이그레이션할 때, 새로 발견한 이벤트를 임포트 중에 재사용하지 말고, Order Imported 이벤트를 명시적으로 제공해야 함.

6. 실험 및 검증

  • 안전한 환경에서 프로토타입을 시도하고, 결과를 예상과 비교하며, 서두르지 않고 반복해야 함.

GN⁺의 의견

  • 이 글에서 가장 중요한 것은 관계형 데이터베이스에서 이벤트 소싱으로 전환하는 과정에서 비즈니스 데이터를 보존하는 새로운 접근 방식의 중요성임.
  • 이 글이 흥미로운 이유는 기존의 데이터 관리 방식에서 벗어나 데이터의 생명주기를 더 잘 이해하고 활용할 수 있는 방법을 제시하기 때문임.
  • 이벤트 소싱은 기술적인 관점 뿐만 아니라 비즈니스와 기술 팀 간의 공통된 이해를 구축하는 데 도움이 될 수 있음.
▲
neo 11달전  [-]
Hacker News 의견

  • PostgreSQL 및 FOSS 리포팅 도구 사용 권장

    • 애플리케이션에서 PostgreSQL을 이미 사용 중이라면, 이벤트 데이터를 PostgreSQL에 저장하고 FOSS 리포팅 도구(Apache Superset, Metabase 등)를 사용할 것을 권장함.
    • 데이터가 약 2TB에 도달할 때까지 PostgreSQL을 사용하고, 그 이후에는 온라인으로 2TB의 데이터가 필요한지, 아니면 일별/시간별 요약만 필요한지 결정함.
    • 한 클라이언트 사례에서는 10TB 이상의 데이터와 초당 1500개의 이벤트를 처리하고 있으며, 상세 데이터는 2일간 온라인에 유지하고 나머지는 요약하여 S3로 이동시켜 Athena SQL을 통해 쿼리할 수 있음.
    • AWS RDS 멀티-AZ를 사용하여 자동 장애 전환을 지원하고, 한 명의 엔지니어가 월 5시간 미만으로 모든 것을 유지 관리함.
    • PostgreSQL은 데이터를 한 곳에 보관하고, 배우고, 관리하며, 확장할 수 있는 단일 시스템을 제공함.
    • 비테크니컬 인력도 Metabase나 Preset과 같은 시스템에서 쉽게 차트를 만들 수 있음.
    • PostgreSQL은 매년 발전하고 있으며, 필요한 경우 PostgreSQL과 호환되는 시스템(Aurora, TimescaleDB, CitusDB 등)을 통해 추가적인 확장이 가능함.

  • 이벤트 주도 아키텍처의 적절한 사용 시기

    • 고객이 특정 행동을 하고 응답을 기대하는 경우는 이벤트 주도가 아닌 요청/응답 패턴임.
    • 이벤트 주도는 예상치 못한 상황에서 발생하는 경우를 의미함. 예를 들어, GitHub에 코드를 푸시하면 빌드가 트리거되는 것과 같은 상황임.

  • 이벤트 소싱에 대한 회의적인 경험 공유

    • 한 팀이 이벤트 소싱을 고려했으나, 명확한 이점이 보이지 않고 새로운 것을 시도하는 위험성 때문에 결국 사용하지 않기로 결정함.
    • 학습 기회를 놓친 것에 대한 후회는 없으며, 필요하지 않은 상황에서 복잡한 문제에 뛰어들지 않음을 긍정적으로 평가함.

  • 도메인 이벤트 모델링의 유용성

    • 도메인 이벤트 모델링은 문제를 해결하려는 도메인 전문가들과 소통하는 데 유용함.
    • 오랜 기간의 상태 머신에 대한 감사 추적을 제공하는 시스템을 구현할 때는 Temporal.io/durable functions와 같은 도구를 사용하는 것이 더 나음.
    • 이러한 도구는 내부적으로 이벤트 소싱을 사용하며, 중복 제거 및 멱등성을 고려하여 코드를 작성하도록 강제함.

  • 이벤트 소싱의 구현에 대한 질문

    • 이벤트 스트림에서 현재 상태를 효율적으로 재구성하는 방법과 데이터베이스에서 이벤트 스트림을 모델링하는 방법에 대한 설명이 부족함.

  • 상향식 대 하향식, 맞춤형 대 범용

    • 하향식 접근법은 비즈니스 도메인에서 시작하여 사용 가능한 기술, 도구, 벤더에 맞게 구현을 매핑함.
    • 상향식 접근법은 사용 가능한 기술, 도구, 벤더에서 시작하여 작동하는 솔루션을 조합함.
    • 맞춤형 접근법은 DDD, CQRS/ES, Sagas, TBUI, GraphQL, 대수적 데이터 타입 등을 포함함.
    • 범용 접근법은 RDBMS, CRUD, REST, ACID 트랜잭션, CDC, 범용 관리 UI, 노코드/로우코드, 제한된/범용 타입 등을 포함함.

  • 이벤트 기반 아키텍처에 대한 지지와 비판

    • 이벤트 기반 아키텍처에 대한 지지는 있으나, 해당 아티클이 주장을 명확히 전달하는 데 실패함.
    • 데이터 관계와 비즈니스 행동 사이의 차이점에 초점을 맞추면, 운영 관계형 데이터 저장소에서 벗어나는 것이 더 명확해짐.

  • 이벤트 소싱과 관계성의 필요성

    • 이벤트 소싱의 많은 장점에도 불구하고, 여전히 관계성이 필요함.
    • 관계성이 애플리케이션 계층 코드에 모두 암시되어 있다면, 이는 받아들일 수 없음.
    • 관계성을 쿼리하거나 관계 뷰를 최신 상태로 유지하는 방법이 필요함.

  • 관계형 데이터의 지지

    • 복잡성을 피하고 전통적인 관계형 데이터에 충실하기로 결정함.

  • 이벤트 주도 설계에 대한 새로운 인식

    • 최근에 이벤트 주도 설계를 알게 되었으며, AI가 지배하는 세계에서 최적의 데이터 구조를 고려하던 중 비슷한 결론에 도달함.
    • 이벤트 주도 설계가 복잡성을 관리하고 데이터를 실제로 활용할 수 있다면 가치가 있을 것이라고 생각함.
    • 향후 몇 년 동안 AI가 모든 비즈니스 이벤트에 대한 지식을 가지고 쿼리할 수 있게 되면서 이벤트 주도 설계가 보편화될 것으로 예상함.
답변달기