Kafka

BACKWARD — '컨슈머를 먼저 올려라'

BACKWARD 호환성은 '새 스키마를 쓰는 컨슈머가 이전 스키마로 생산된 데이터를 읽을 수 있어야 한다'는 규칙이다. 허용되는 변경은 필드 삭제, 그리고 기본값(default)이 있는 필드 추가다(기본값 없는 필수 필드 추가는 금지 — 옛날 데이터에는 그 필드가 아예 없는데 새 스키마가 필수라고 요구하면 읽을 수 없기 때문이다). 이 모드에서는 컨슈머(새 스키마로 읽는 쪽)를 프로듀서보다 먼저 업그레이드해야 안전하다 — 컨슈머가 이미 새 스키마를 이해할 준비가 된 상태에서 프로듀서가 나중에 새 스키마로 바꿔도 문제없다. Schema Registry의 기본 호환성 모드가 바로 BACKWARD다.

FORWARD — '프로듀서를 먼저 올려라'

FORWARD 호환성은 BACKWARD와 방향이 반대다 — '이전 스키마를 쓰는 컨슈머가 새 스키마로 생산된 데이터를 읽을 수 있어야 한다'. 허용되는 변경은 새 필드 추가(필수든 선택이든), 그리고 기본값이 있는 필드의 삭제다. 이 모드에서는 프로듀서(새 스키마로 쓰는 쪽)를 컨슈머보다 먼저 업그레이드해야 안전하다 — 프로듀서가 이미 새 스키마로 쓰기 시작해도, 아직 옛 스키마인 컨슈머가 그 데이터를 무리 없이 읽을 수 있기 때문이다.

FULL과 TRANSITIVE — 순서 걱정을 없애거나, 과거 전체를 검사하거나

FULL은 BACKWARD와 FORWARD를 동시에 만족해야 하는 가장 엄격한 모드다 — 두 방향 모두 안전해야 하므로 프로듀서와 컨슈머를 어느 순서로 배포해도 문제없다(순서를 신경 쓸 필요가 없어진다는 게 실무적 장점). 다만 허용되는 변경은 두 모드의 교집합(기본값 있는 필드의 추가/삭제 정도)으로 더 좁아진다.

TRANSITIVE 접미사(BACKWARD_TRANSITIVE, FORWARD_TRANSITIVE, FULL_TRANSITIVE)는 검사 범위의 차이다. 기본(non-transitive) 모드는 새 스키마를 '바로 직전 버전 하나'와만 비교해 호환성을 검사한다. TRANSITIVE 모드는 새 스키마가 '과거의 모든 버전'과 호환되는지 전부 검사한다. 왜 이게 중요한가 — 스키마를 v1→v2→v3로 연속으로 바꿀 때, v3가 v2와는 호환되더라도 v1과는 호환이 깨질 수 있다(예: v2에서 잠깐 생겼다 사라진 필드를 v3가 다시 다른 의미로 씀). 아직 v1 스키마로 남아있는 오래된 컨슈머나 재처리 작업이 있다면 non-transitive 검사만으로는 이 위험을 못 잡아낸다 — 과거 데이터를 장기간 재처리해야 하는 환경일수록 TRANSITIVE 모드가 안전하다.