인프런 커뮤니티 질문&답변

그런데 내용을 보아하니 쓰기 스키마가 변경되면 읽기 스키마도 변경되는 구조 아닌가요?

제가 말하는 스키마는 스미카 레지스트리에 저장되는 스키마를 말씀드리는 것 입니다.

테이블 스키마가 아니구요.

그러니까 제 질문은 V1, V2를 말씀하시는게 말 그대로 테이블의 스키마를 뜻하고 그것이 변경된 것을 V1, V2로 의미하신 것인지...궁금해서요

스키마 레지스트리 서버에 요청해서 스키마를 변경할 수 있게 되는데 보통 프로듀서에서 스키마 변경감지를 하여 레지스트리 서버에 저장하므로 컨슈머는 스키마 레지스트리를 변경하는 입장이 아닌 그냥 읽어서 데이터를 처리하는 영역으로만 보여지고 결국 두 프로듀서, 컨슈머는 레지스트리 스키마에서 항상 같은 스키마를 사용한다고 이해해도 되는지 질문이였습니다

강의를 보았을 때 consumer에서 레지스트리 스키마를 변경하는 것은 없던 것 같아서요

질문에 답변 드리기 전에 먼저 아래 사항에 대해서 다시 정리드리겠습니다.

본 강의에서 말씀드리는 스키마는 기본적으로 Avro 스키마 입니다(테이블 스키마 아닙니다)

제가 스키마 레지스트리 이해 섹션에서 처음에 Avro 스키마에 대해서 말씀드리고 이어서 스키마 레지스트리에 대해서 말씀 드립니다.

이유는 스키마 레지스트리가 Avro의 스키마 처리 로직에 기반하고 있기 때문입니다.

Avro의 스키마가 읽기 스키마, 쓰기 스키마가 따로 있는 이유는

첫째로 읽기용 프로그램, 쓰기용 프로그램이 따로 프로세스로 분리되어 있거나 아예 분산 노드로 따로 읽기 때문에 공유하지 못하는 경우가 생기기 때문입니다.

둘째로 Avro는 파일기반의 데이터 저장소를 기반으로 하기 때문에 스키마가 달라지면 과거 저장된 스키마 기반의 데이터를 어떻게 변경해야 할지 이슈가 발생하게 됩니다.

RDBMS의 경우 테이블 스키마를 변경하면 자동으로 DB 파일에 이를 반영해 주지만, 파일 기반에서는 어렵기 때문입니다. 때문에 상하위 호환성이라는 개념또한 도입이 된것입니다.

스키마 레지트리는 이런 문제를 해결하기 위해서 공용의 스키마 관리 체계를 갖춘 서버이지만 여전히 스키마 변경시 상하위 호환성의 개념을 가지고 있습니다.

그리고 스키마 레지스트리는 커넥트만 사용하는 것이 아닙니다. Producer, Consumer 애플리케이션도 이용 가능합니다(커넥트 보다 스키마 레지스트리가 먼저 출시 되었습니다).

아래는 질문의 답변입니다.

1. 그런데 내용을 보아하니 쓰기 스키마가 변경되면 읽기 스키마도 변경되는 구조 아닌가요?

=> (강의에서도 말씀드리지만)상하위 호환성이 설정되어 있고, 상하위 호환성에 맞지 않은 변경이면 쓰기 스키마 자체도 변경되지 않으며 읽기 스키마도 이를 반영하지 않습니다.

2. 제가 말하는 스키마는 스미카 레지스트리에 저장되는 스키마를 말씀드리는 것 입니다.

테이블 스키마가 아니구요.

그러니까 제 질문은 V1, V2를 말씀하시는게 말 그대로 테이블의 스키마를 뜻하고 그것이 변경된 것을 V1, V2로 의미하신 것인지...궁금해서요

=> 앞에서 답변 드린 대로 강의에서 설명드린 스키마는 Avro 스키마 입니다. 물론 테이블의 스키마가 변경되면 이 스키마를 기반으로 신규 Avro 스키마를 생성합니다. v1, v2는 업데이트 버전 순이며 v2가 더 최신의 의미입니다.

3. 스키마 레지스트리 서버에 요청해서 스키마를 변경할 수 있게 되는데 보통 프로듀서에서 스키마 변경감지를 하여 레지스트리 서버에 저장하므로

컨슈머는 스키마 레지스트리를 변경하는 입장이 아닌 그냥 읽어서 데이터를 처리하는 영역으로만 보여지고 결국 두 프로듀서, 컨슈머는 레지스트리 스키마에서 항상 같은 스키마를 사용한다고 이해해도 되는지 질문이였습니다

강의를 보았을 때 consumer에서 레지스트리 스키마를 변경하는 것은 없던 것 같아서요

=> 커넥트의 경우는 말씀하신대로 sink connector(즉 consumer)에서 레지스트리내의 스키마를 스스로 변경하지는 않습니다.

하지만 스키마 레지스트리에 스키마 생성/변경/등록은 단순히 API 호출만으로도 가능합니다. 즉 Producer나 Consumer 모두 자신이 사용한 스키마를 등록할 수 있습니다.

정리드리자면 DB 소스 커넥트는 테이블 스키마가 변경되면 이를 감지해서 새로운 스키마로 스키마를 등록 시도하되 상하위 호환성에 맞지 않으면 오류가 발생합니다.

스키마 레지스트리에서는 상하위 호환성이 중요하며, 커넥트내에서의 프로듀서, 컨슈머는 상하위 호환성에 기반하여 서로 다른 버전의 스키마를 사용할 수 있습니다.

이는 카프카 토픽 역시 파일에 기반하고 있기 때문에 스키마가 변경 될 경우 상하위 호환성에 대한 규칙 적용이 필요할 수 있습니다.

질문 답변 외에 한가지 부탁 말씀드리고 싶습니다.

질문시 어떤 강의의 몇분 몇초의 설명인지 기재를 부탁드립니다.

이전 질문시 교재에 있는 v1, v2 스키마에 대해서 질문하셨는데, 강의 교재에 v1, v2 스키마에 대한 부분이 매우 많습니다.

웬만하면 제가 추론해서 답변을 드리는데, 하하호호님의 경우 시스템에도 일가견이 있고, 경력도 꽤 되시는것 같아 질문 난이도가 있어서, 제가 추론이 어렵습니다. 꼭 부탁드립니다.

감사합니다.

제가 질문을 어리석게 하여 너무 많은 것을 글을 쓰게 해서 죄송합니다!

하위호환성에서 읽기 스키마가 버전이 더 높은 경우가 하위호환성을 가지게 되는데

• 183 page

그 케이스가 강의에 없던걸로 기억해서 그게 좀 혼란스러웠습니다 그래서 질문드린 것이

source와 sink가 레지스트리를 따로 가져갈 수 있다면 서로 버전을 지정하던가 이름을 지정하는 것이 있어야 하는데 그냥 단순히 키, 밸류에 스키마 레지스트리 url만 존재하여

각각 버전을 지정할 수 없는건가? 싶었습니다 읽기가 V2가 되고 쓰기가 V1이 되려면 각각 지정을 하던지 아니면 각각의 테이블에 따라서 변경이 되어야 한다고 제가 생각했는데 그게 아닌 쓰기 스키마에 의해서 스키마 레지스트리가 정해지고 읽기 스키마는 쓰기 스키마에 의해서 자동으로 정해지는 구조이니까 결국 읽기 스키마는 쓰기 스키마에 의해 정해지는데 어떻게 읽기 스키마가 V2가 될 수 있을까? 그게 궁금했던 것 입니다!

좀 그게 혼란스러워서 질문드렸습니다.

제가 질문을 잘못해서 고급인력을 낭비하게 만들었군요 죄송합니다

감사합니다

별 말씀을요. 질문은 언제든 환영입니다. 감사합니다