스키마 레지스트리를 사용하는 가장 큰 이유는 데이터의 호환성과 품질을 보장하기 위함이다. 메시지의 스키마가 없다면 Producer에게 발생한 장애가 모든 Consumer 들에게 전파될 수 있다.
그렇기에 카프카를 사용한다면 스키마 레지스트리 사용은 필수라고 말할 수 있다.
Producer가 토픽에 메시지를 생성하고 Consumer가 토픽의 메시지를 소비하기까지 스키마 레지스트리 입장에선 다음과 같은 단계가 수행된다.
1. 토픽에 등록된 스키마 관리
2. Producer의 메시지 Validation Check
3. Consumer의 메시지 Validation Check
그런데, 운영 중 스키마를 변경해야 하는 경우가 생겼다면 어떻게 해야 할까?
다 같이 운영을 중단하고 스키마를 변경한 뒤 운영을 재개할 수도 있겠지만 스키마 레지스트리는 각 단계에서 자연스럽게 스키마를 변경할 수 있는 옵션을 제공한다.
Compatibility라고 표현하는 호환성이다. 스키마는 하나만 존재하는 게 아니라 여러 버전이 존재할 수 있다. 그리고 여러 개의 모드가 존재한다. 대표적인 3가지는 아래와 같다.
- Backward (default)
- Forward
- Full
여러개의 모드가 존재하는 이유는 스키마를 변경하는 시나리오가 다르기 때문이다. 서비스의 환경에 따라, 특성에 따라 다를 수 있는 부분에서 유연성을 제공한다.
Backward 호환성 (Consumer First)
- 새로운 스키마가 이전 스키마를 사용하는 데이터를 성공적으로 읽을 수 있는 경우
- 특징: 새로운 필드를 추가할 때는 이를 옵셔널 필드로 설정하고, 기존 필드를 유지합니다. 이렇게 하면 이전 버전의 컨슈머가 새로운 스키마로 생성된 데이터를 문제없이 처리할 수 있습니다.
Forward 호환성 (Producer First)
- 이전 스키마가 새로운 스키마를 사용하여 생성된 데이터를 성공적으로 읽을 수 있는 경우
- 특징: 기존 필드를 제거하지 않고 새로운 필드를 추가하는 경우, 이전 버전의 프로듀서가 생성한 데이터는 새로운 버전의 컨슈머가 처리할 수 있어야 합니다. 즉, 새로운 컨슈머는 모든 필드가 필수가 아니라고 가정하고 작동해야 합니다.
Full 호환성 (don't care)
- 스키마가 Backward 호환성과 Forward 호환성을 모두 만족시키는 경우
- 특징: 프로듀서는 새로운 필드를 추가하거나 기존 필드를 수정할 때, 이전 버전의 컨슈머와 미래 버전의 컨슈머 모두와 호환될 수 있도록 합니다. 이를 위해 새로운 필드는 옵셔널로 추가하고, 중요한 필드는 제거하지 않습니다.
