351
16
장
이벤트 기반 마이크로서비스 배포
비엔티티 이벤트는 중대한 스키마 변경이 일어나도 재처리가 꼭 필요한 것은 아닙니다. 대부분
의 이벤트 스트리밍 애플리케이션은 서비스가 엔티티 스트림을 다시 구체화하는 것과 같은 방
식으로 이벤트 스트림을 정기적으로 재처리하지 않기 때문입니다. 컨슈머는 새 이벤트 정의를
그냥 새 이벤트 스트림으로 추가하고 비즈니스 로직을 수정하면 옛 이벤트, 새 이벤트 모두 처
리할 수 있습니다. 옛 이벤트가 이벤트 스트림에서 만료되면 어차피 비즈니스 로직에서 옛 이
벤트 스트림은 떨어져 나가겠죠.
중대한 스키마 변경은 다음 두 가지 방법으로 마이그레이션할 수 있습니다.
●
옛 스키마를 가진 이벤트 스트림, 새 스키마를 가진 이벤트 스트림, 이렇게 이벤트 스트림
2
개를 이용해 최종 일관적으로 마이그레이션
eventual
migration
●
옛 스키마를 가진 이벤트 스트림은 삭제하고 새로운 스트림으로 단일화/동기화하는 마이
그레이션
16.5.1
이벤트 스트림
2
개를 통해 최종 일관적으로 마이그레이션
이벤트 스트림을 이원화하여 최종 일관적으로 마이그레이션을 하려면 프로듀서가 옛 스키마,
새 스키마로 이벤트를 만들어 각각의 스트림에 기록해야 합니다. 옛 스트림은 사용하지 않는
것으로
deprecated
표시하고 옛 스트림을 소비했던 컨슈머들은 알아서 새 스트림으로 이전하도록
놔둡니다. 언젠가 모든 컨슈머가 새 스트림으로 이전되면 옛 스트림은 삭제하거나 장기 데이터
저장소에 보관하면 됩니다.
이 마이그레이션 전략은