Kafka Schema Registry — 비즈니스 이벤트 계약

Kafka 를 쓰면 Schema Registry 얘기가 나옵니다. 이걸 “Kafka 로 가는 모든 걸 검증하는 것” 으로 오해하기 쉬운데, 실제 역할은 더 좁고 분명합니다.

로그 아닌 비즈니스 이벤트 보호

“Fluent Bit → Kafka 로 가는 로그도 Schema Registry 를 거친다” 는 틀립니다. 로그 수집 파이프라인과 Schema Registry 는 완전히 독립입니다.

Schema Registry 가 지키는 건 서비스 간 비즈니스 이벤트입니다. 주문 생성, 결제 완료 같은 이벤트를 서비스 A 가 발행하고 서비스 B 가 구독할 때, 그 이벤트의 구조(주로 Avro 스키마)를 등록해두고 맞는지 검증합니다. 로그 파이프라인은 이걸 안 거칩니다. 두 흐름을 구분해야 합니다.

스키마가 왜 필요한가 — 발행자와 구독자의 계약

이벤트 기반 구조에서 발행자와 구독자는 서로를 직접 모릅니다. 발행자가 필드 이름을 바꾸거나 타입을 바꾸면, 구독자는 그걸 모른 채 파싱하다 깨집니다. Schema Registry 는 그 이벤트 구조를 양쪽이 합의한 계약으로 만들어 둡니다.

호환성 모드 — 런타임 장애를 배포 실패로

실무에서 제일 값진 건 호환성 모드인데, Schema Registry 에 BACKWARD 같은 모드를 걸어 두면 호환되지 않는 스키마를 등록·배포하는 시점에 거부합니다.

호환성 규칙을 어긴 스키마로 발행자를 배포하려 하면, 등록 단계에서 막힙니다. 그게 없었다면 이렇게 됐을 겁니다 — 발행자가 바뀐 이벤트를 그대로 발행하고, 구독자가 운영 중에 파싱하다 NPE 나 KeyError 로 죽습니다. 즉 운영 중 터질 장애가, 배포를 막는 것으로 앞당겨집니다.

• BACKWARD — 새 스키마로 옛 데이터를 읽을 수 있어야 함(구독자 먼저 업그레이드)
• FORWARD — 옛 스키마로 새 데이터를 읽을 수 있어야 함
• FULL — 양방향 다

운영 장애를 배포 시점에 미리 막기

Schema Registry 는 로그 파이프라인이 아니라 서비스 간 비즈니스 이벤트의 계약을 지킵니다. 그리고 호환성 모드로 깨질 변경을 배포 시점에 막아, 구독자가 운영 중에 죽는 사고를 배포 실패로 바꿉니다.