[🧙카프카] Kafka Schema Registry 사용 설명서

카프카는 메시지를 보내는 Producer와 Consuemr로 이루어져 있다. 카프카는 Producer가 메시지를 보낸 후 Consumer가 소비하려고 할 때 누가 보낸 메시지인지 확인할 수 있는 방법이 없다. 그래서 Producer가 메시지를 기존에 보내던 것과 다른 스키마 형식으로 보낸다면 Consumer는 바뀐 메시지를 받았을 때 문제가 크게 발생할 수도 있다.
이런 일을 방지하기 위해서 스키마 레지스트리를 사용할 수 있다.

Schema Registry란?

스키마 레지스트리는 Producer와 Consumer가 주고 받으려는 메시지의 스키마를 서로 알게 해주고 호환을 강제한다. 예를 들면 Producer가 처음에 정의했던 스키마와 호환되지 않는 스키마를 보내려고 할 때 보낼 수 없게 막아준다.
스키마 레지스트리는 카프카 외부에서 독립적으로 동작하며 REST API를 제공한다.

Schema Registry

 

Schema Registry 도커에서 실행하는 방법

같은 폴더에 docker-compose.yaml 파일과 .env 파일을 작성한 후 docker-compose up -d을 실행한다.
여기에 작성된 docker-compose.yaml은 스키마 레지스트리와 카프카 REST API도 함께 실행한다.

docker-compose.yaml

version: '3.3' networks: default: external: name: kafka services: cp-schema-registry: container_name: schema-registry environment: SCHEMA_REGISTRY_KAFKASTORE_BOOTSTRAP_SERVERS: ${BOOTSTRAP_SERVERS} SCHEMA_REGISTRY_LISTENERS: http://0.0.0.0:8081 image: confluentinc/cp-schema-registry:5.1.0 ports: - 8081:8081 cp-kafka-rest: container_name: kafka-rest environment: KAFKA_REST_BOOTSTRAP_SERVERS: ${BOOTSTRAP_SERVERS} KAFKA_REST_LISTENERS: http://0.0.0.0:8082 KAFKA_REST_SCHEMA_REGISTRY_URL: http://schema-registry:8081 KAFKA_REST_HOST_NAME: kafka-rest image: confluentinc/cp-kafka-rest:5.1.0 depends_on: - cp-schema-registry ports: - 8082:8082

.env
부트스트랩 서버가 더 존재한다면 콤마(,)로 구분한다.

BOOTSTRAP_SERVERS=PLAINTEXT://{YOUR_BOOTSTRAP_SERVER}:9092

 

Schema Evolution and Compatibility

스키마 레지스트리에서 호환성 규칙을 운영자가 설정할 수 있다. 스키마 레지스트리는 호환성 설정에 따라 새로운 스키마를 등록할 수 있는지 없는지 판단한다.

 

 

들어가기 전에

• 새로운 스키마 = 새로 등록할 스키마
• 가장 최근에 등록된 스키마 = 스키마 레지스트리에 등록된 스키마의 마지막 버전
• TRANSITIVE = 모든 등록된 버전으로 확인한다는 뜻이며, {OPTION}_TRANSITIVE가 없는 경우 마지막 버전으로 확인한다.

 

BACKWARD(DEFAULT)

소비자를 먼저 업그레이드 해야하기 때문에 이름이 BACKWARD이다.

컨슈머는 새로운 스키마를 사용해서 처리하지만, 가장 최근에 등록된 스키마를 사용하여 처리할 수도 있다.

• 필드 삭제가 가능하다.
• 선택적으로 필드 추가가 가능하다.
• 이전 스키마를 사용하는 소비자가 새 스키마를 사용하여 생성된 데이터를 읽을 수 있다는 보장이 없다. 새 이벤트 생성을 하기 전에 모든 소비자를 업데이트해야한다.

backward

 

 

FORWARD

프로듀서를 먼저 업그레이드 해야하기 때문에 이름이 FORWARD이다.

컨슈머는 마지막으로 등록된 스키마를 사용해서 처리하지만, 새로운 스키마도 처리할 수 있다.

• 선택적 필드 삭제가 가능하다.
• 필드 추가가 가능하다.
• 새 스키마를 사용하는 소비자가 이전 스키마를 사용하여 생성된 데이터를 읽을 수 있다는 보장이 없다. 모든 생산자를 새 스키마를 사용하도록 업데이트 한 후 소비자를 업그레이드한다.

forward

 

FULL

새 스키마는 가장 최근에 등록된 스키마와 FORWARD, BACKWARD 호환이 가능하다.

• 선택적 필드 추가가 가능하다.
• 선택적 필드 삭제가 가능하다.
• 새 스키마를 사용하는 소비자가 이전 스키마를 사용하여 생성된 데이터를 읽을 수 있다는 보장이 있다. 생산자와 스키마를 독립적으로 업그레이드 할 수 있다.

NONE

스키마 호환성을 확인하지 않는다.

 

{OPTION}_TRANSITIVE

• transitive
  • 호환성 보장 
    • X-2 <==> X-1
    • X-1 <==> X
    • X-2 <==> X
• non-transitive
  • 호환성 보장
    • X-2 <==> X-1
    • X-1 <==> X
  • 호환성 보장 안함
    • X-2 <==> X