1. Kafka에서 취급하는 데이터 형태
- kafka에서 취급하는 데이터 형태는 producer와 consumer에서 일치해야 한다.
- producer에서 송신되는 메시지의 key, value의 데이터 형태는 각각 producer 앱에서 지정되고, 데이터를 직렬화해서 송신함.
- consumer는 미리 producer에서 보낸 멧지ㅣ의 key, value 데이터 형태를 포함한 데이터를 감안하고 설계해야 함.
kafka에서는 데이터 형태를 관리하고 있지 않기 때문에, kafka cluster에서 데이터 형태가 다른 것을 확인하지 못함. 따라서 데이터 형태를 인식해 데이터를 관리하고 처리하는 RDBMS에 비해 주의가 필요함.
2. 항상 실행 상태로 데이터를 처리하는 특징
- producer에서 메시지 데이터 형태에도 주의가 필요함.
- consumer가 사용하는 시리얼라이저는 key, value마다 1개씩이며, 데이터에 따라 구분해서 사용하기 어려움.
- 따라서 producer에서 보낸 메시지의 데이터 형태를 변경하려면 그에 해당하는 consumer도 변경해야 함.
- 하지만 앱은 항상 데이터를 처리하고 있어, 쉽게 중단하기 어려움.
- 이러한 데이터의 불일치를 방지하기 위해 데이터 형태 관리나, 향후 확장을 위한 변경 방법이 필요함.
- 스키마 구조를 갖는 데이터 형태를 사용하는 것이 대책 중 하나임.
3. 스키마 구조를 갖는 데이터 형태
- 하나의 메시지에 여러 값을 포함시키고 싶은 경우, JSON이나 Apache Avro와 같은 구조화된 데이터가 사용됨.
- 이를 통해 여러 칼럼을 가진 스키마를 정의하여 하나의 메시지 안에 여러 값을 포함할 수 있게 됨.
- 스키마 정의는 producer 앱에서 설계되지만, consumer 앱에 미치는 영향이 크기 때문에 확장성을 고려하여 신중하게 결정해야 함.
4. 스키마 에볼루션
- 스키마 정의는 신중하게 고려해야 하지만, 앱의 수정이나 기능 추가에 따라 정의를 변경해야 하는 경우가 발생할 수 있음.
- 스키마 에볼루션: 스키마 정의를 운용 중 변경하는 것
- 데이터 파이프라인의 스트림 처리에서는 계속적으로 발생하는 데이터를 처리하기 때문에, 앱을 마음대로 중지시킬 수 없는 경우가 많음.
- 이러한 문제에 대한 대응으로, 스키마 에볼루션을 진행할 때 스키마 변경 전후의 호환성을 고려함.
- 새로운 칼럼을 추가하는 스키마 변경에서는, 호환성 있게 스키마 에볼루션이 일어남.
- 하지만 기존 칼럼을 제거하거나 바꾸는 방식의 스키마 변경에서는, 호환성이 없는 스키마 에볼루션이 일어남.
- Apache Avro는 호환성을 고려할 수 있는 데이터 형태임. 따라서 확장성을 고려해야 하는 경우 이러한 데이터 형태를 선택할 수 있다.
5. Schema Registry
- 컨플루언트가 오픈소스로 개발하고 있는 스키마 정보 관리 도구.
- Apache Avro 이용을 전제로 한 스키마 관리 기능을 제공.
- 제공되는 전용 시리얼라이저/디시리얼라이저와 kafka REST Proxy를 사용.
- producer에서 메시지가 직렬화될 때 스키마 정보가 schema Registry에 등록되며, consumer에서 직렬화할 때 참조됨.
- 데이터 허브처럼 여러 스키마 정의를 관리해야 하는 환경에서 사용됨.
- 스키마 정의를 일괄적으로 관리하고, 호환성 없는 메시지의 송수신을 방지함으로써 예상치 못한 오류를 방지함.
출처
사사키 도루, 『실전 아파치 카프카』, 정인식, 한빛미디어(2020)
handsome