Chapter 10. 스키마 레지스트리

[minkukjo]

끄적 끄적

• RDB에 있는 스키마, 메시지큐인 카프카 역시도 이런 스키마를 제공한다.
• 우리팀은 Avro를 사용하는 듯 하다.
• 스키마 레지스트리가 별도로 구성된 독립 애플리케이션인 줄은 몰랐다.
• Avro는 카프카에서 쓰이는 가장 보편적이고 유명한 스키마인데, 이는 JSON과 매핑되며 간단하고 바이너리 형태여서 매우 빠르다고 한다.
• 스키마 레지스트리에서는 몇 개의 API들을 제공하는데, 이 API를 통해 현재 스키마 레지스트리 애플리케이션에 저장된 스키마의 조회나 등록, 변경, 삭제 등이 가능하다.
• 프로듀서와 컨슈머는 직접 통신하진 않지만, 로컬캐시를 통해 스키마를 각각의 로컬 메모리에서 관리한다.
• JSON을 사용하게 되면 KEY:VALUE 형태로 전체 메시지를 전송해야하지만, Avro를 사용하면 스키마 ID와 Value만 메시지로 보내게 되어 카프카로 전송하는 전체 메시지의 크기를 줄일 수 있으며 이는 매우 효율적이다.
• 결국 Arvo는 아래와 같은 로직으로 동작함.

1. `Avro` 프로듀서는 스키마의 유효성 여부를 체크한다. 스키마가 없다면 `Avro` 프로듀서는 스키마를 등록하고, 로컬 메모리에 캐시한다.

2. 스키마 레지스트리는 현 스키마가 저장소에 저장된 스키마와 동일한지, 바뀌었는지를 확인한다. 각 스키마는 고유 ID를 갖고 있으며 이는 순차적으로 1씩 증가하지만 연속적이진 않다.  ( 아마도 이 연속적이지 않다의 의미는, 이 스키마가 진화했을 때 연속적이지 않음을 의미하는 듯, 전체 스키마 ID가 연속적이지 않다는건 말이 안됨 )

3. 프로듀서는 스키마 전체가 아닌, 스키마 ID만 보낸다.

4. 컨슈머는 스키마 ID로 역직렬화를 사용해 카프카의 토픽에 저장된 메시지를 읽는다. 만약 컨슈머가 해당 스키마 ID를 로컬 캐시로 갖고 있지 않으면 스키마 레지스트리로부터 가져온다.

• https://medium.com/@stephane.maarek/introduction-to-schemas-in-apache-kafka-with-the-confluent-schema-registry-3bf55e401321 ( 요 Avro 관련해서는 아티클이 꽤나 유명한 듯 )

• 스키마 레지스트리는 버전별로스키마에 대한 관리를 효율적으로 해준다.

• 가령 스키마의 버전이 바뀌더라도 버전 호환성을 제공해주는데 BACKWARD, FORWARD, FULL 등이 있다.

• BACKWARD 호환성은 스키마를 적용한 컨슈머가 진화 전의 적용된 프로듀서가 보낸 메시지를 보낼 수 있도록 호환성을 제공하는 것을 말한다.

• BACKWARD 호환성은 자신과 동일하거나, 한 단계 낮은 버전까지도 처리해준다.

• BACKWARD_TRANSITIVE 호환성은 자기와 동일한 버전을 포함한 모든 하위 버전을 지원해준다.

• FORWARD 호환성은 반대로 프로듀서에 먼저 스키마를 업데이트하게 된다. 만약 컨슈머가 한단계 낮은 스키마를 사용하고 있더라도 FORWARD 호환성의 추가 기능으로 한단계 낮은 메시지도 처리할 수 있다.

• 동일하게 모든 버전을 처리해주는 FORWARD_TRANSITIVE가 존재한다.

• 마지막으로는 FULL인데, BACKWARD + FORWARD로 보면 된다.

• FULL 가장 무난한 것 같은데 의외로 호환성 디폴트는 BACKWARD라고 한다.

[LOG-INFO]

끄적끄적

• 스키마가 _schema 토픽에 저장되는군!

궁금궁금

• p336. 이 때 주의 깊게 살펴봐야 할 토픽 설정은 cleanup.policy가 compact로 설정된 부분입니다 -> 왜?
  • 이전 스키마가 지워지면 안되기 때문일것 같긴 한데, 또 다른 이유가 있을까? default는 delete
• p336. 스키마 관리 목적으로 사용되는 메시지들은 순서가 중요하기 때문에 _schemas 토픽의 파티션 수는 항상 1입니다
  • 같은 스키마에 대해서만 순서를 보장하면 되니까 스키마 이름을 파티션 키로 잡으면 파티션을 늘려도 상관 없지 않나?

[MinJunKweon]

끄적끄적

• 스키마(Schema) : 정보 구성 및 해석을 도와주는 프레임워크 혹은 개념
• 데이터베이스의 구조를 정희하고 표현 방법이나 전반적인 명세와 제약 조건을 기술하는 표준 언어
• 카프카 또한 메시지에 대해 미리 스키마를 정의한 후 전송하여 관리 효율성을 높이고, 데이터 충돌을 방지할 수 있음

스키마 개념과 유용성

• 관계형 DB에 스키마가 없다면? 기존과 다른 형식의 데이터가 입력되면 파싱 에러가 나면서 대형 장애가 발생할 수 있음
• 다른 토픽으로 메시지를 잘못 전송하는 경우, 토픽을 구독하고 있는 모든 컨슈머에 에러가 발생할 수 있음
• 컨슈머에게 매번 데이터 구조를 설명해야하고, 데이터 구조가 자주 변경된다면 매번 설명해야하는데 이는 쉬운 일이 아님

스키마 레지스트리 개요

• 프로듀서가 등록한 스키마는 내부 토픽에 저장
• 스키마 레지스트리가 지원하는 대표적인 데이터 포맷은 에이브로(Avro)
• 에이브로는 데이터 교환을 도와주는 오픈소스 직렬화 시스템

카프카 스키마 포맷으로 JSON 대신 Avro를 권장하는 이유

• Avro는 JSON과 매핑됨
• Avro는 매우 간결한 데이터 포맷
• JSON은 메시지마다 필드 네임들이 포함되어 비효율적
• Avro는 바이너리 형태이므로 매우 빠름

Avro 예제

{"namespace": "student.avro",
 "type": "record",
 "doc": "This is an example of Avro.",
 "name": "Student",
 "fields": [
   {"name": "name", "type": "string", "doc": "Name of the student"},
   {"name": "class", "type": "int", "doc": "Class of the student"}
 ]
}

• namespace : 이름을 식별하는 문자열
• type : Avro는 record, enums, arrays, maps 등을 지원하며, 여기서는 record 타입으로 정의
• doc : 스키마 정의에 대한 주석
• name : 레코드 이름을 나타내는 문자열 (required)
• fields : JSON 배열로서, 필드들의 리스트를 뜻함
• name : 필드의 이름
  • type : boolean, int, long, string 등의 데이터 타입 정의
  • doc : 필드에 대한 주석