Rails에서 이벤트 소싱 도입: 앱 재작성 없이 레거시 시스템 개선하기

이벤트 소싱: Rails 앱의 역사 추적 및 복원력 강화

이 콘텐츠는 데이터 변경의 맥락을 잃게 만드는 전통적인 CRUD(Create, Read, Update, Delete) 방식의 한계를 지적하고, 이를 극복하기 위한 해결책으로 이벤트 소싱(Event Sourcing)을 제시합니다. 이벤트 소싱은 데이터베이스에 대한 UPDATE나 DELETE 대신 모든 상태 변경을 불변하는 이벤트로 기록하여, 과거 상태를 재현하고 디버깅을 용이하게 합니다. 또한, Rails 앱을 재작성할 필요 없이 점진적으로 도입할 수 있는 방법을 설명합니다.

기술적 세부사항

• 전통적인 CRUD의 문제점: 데이터 변경의 "왜"를 상실하고, 문제 발생 시 복잡한 SQL을 통한 포렌식 분석이 필요하며, 특정 시점의 데이터를 조회하는 데 제약이 있습니다.
• 이벤트 소싱의 이점:
  • 히스토리 복원: 과거 사용자 등록 등 특정 시점의 데이터를 재현하여 문제 분석에 활용할 수 있습니다.
  • 감사 로그: 감사 로그 자체가 데이터베이스 역할을 하여 모든 변경 사항을 기록합니다.
  • 간편한 복구: 프로덕션 실수 발생 시 백업 복원 대신 이벤트 재실행으로 신속하게 복구할 수 있습니다.
• 구현 방식:
  • UPDATE 대신 AccountBalanceDeposited와 같은 이벤트 객체를 저장합니다.
  • 현재 상태는 저장된 모든 이벤트를 reduce하여 계산합니다.
  • DepositMoney와 같은 커맨드(Command)는 이벤트를 발행(publish)합니다.
• Rails에서의 구현 도구: Rails Event Store, Eventide, Kafka를 언급합니다.
• 이벤트 정의: RailsEventStore::Event를 상속받아 스키마를 정의합니다.
• 상태 재구성: AccountBalance 클래스를 예로 들어 이벤트 목록을 통해 현재 잔액 또는 특정 시점의 잔액을 계산하는 방법을 보여줍니다.
• 이벤트 구독: SendDepositNotification과 같은 핸들러를 통해 이벤트 발생 시 비동기적으로 작업을 수행하도록 구독할 수 있습니다.
• 성능 최적화: 스냅샷(Snapshot)을 주기적으로 저장하여 대규모 이벤트 스트림에서 상태 재구성에 드는 시간과 리소스를 절감합니다.
• 아키텍처 패턴: CQRS(Command Query Responsibility Segregation)와 유사한 Write Model(커맨드 처리 및 이벤트 발행)과 Read Model(최적화된 조회용 프로젝션) 분리를 활용합니다.
• 이벤트 변경 관리: Upcaster를 사용하여 이벤트 스키마 변경 시 과거 이벤트를 변환합니다.
• 주의사항: 이벤트 과도 사용("Event Spaghetti"), 과도한 설계("Over-Engineering"), 비멱능적(Idempotent) 설계 무시 등을 경고합니다.
• 점진적 도입: 기존 ActiveRecord 모델에 이벤트 발행을 추가하고, 점진적으로 로직을 프로젝션으로 이동시키는 방식을 권장합니다.

개발 임팩트

이벤트 소싱을 도입하면 애플리케이션의 투명성, 감사 용이성, 그리고 복원력이 크게 향상됩니다. 데이터 변경의 모든 과정을 기록함으로써 복잡한 디버깅 시나리오를 해결하고, 과거 시점으로 시스템 상태를 되돌리는 기능을 쉽게 구현할 수 있습니다. 또한, Write/Read 모델 분리를 통해 시스템 성능 및 확장성을 최적화할 수 있습니다.

커뮤니티 반응 (추론)

이 글은 개발자들이 흔히 겪는 데이터 변경 추적 및 복구의 어려움을 명확히 짚어내고 실용적인 해결책을 제시하므로, 커뮤니티에서 큰 공감을 얻을 것으로 예상됩니다. 특히 "But ActiveRecord Is Our Truth!"라는 소제목은 많은 개발자들이 고민하는 지점을 건드리며, 점진적 도입 방법을 제시함으로써 이벤트 소싱에 대한 진입 장벽을 낮춰줄 것입니다. 관련 토론에서는 이벤트 소싱의 장단점, 실제 적용 사례, 성능 고려 사항 등이 활발하게 논의될 수 있습니다.