728x90 반응형 데이터파이프라인42 [Schema Registry] 스키마 레지스트리 소개 목적 cdc의 인프라 확장 시 스키마 레지스트리의 도입을 검토하기 위함 도입 배경 Kafka와 같은 메시지 시스템에서는 데이터 형식을 명시적으로 정의하지 않으면 생산자와 소비자 간의 데이터 해석이 일관되지 않을 수 있음특히 메시지가 다양한 버전으로 진화하면서, 메타데이터와 데이터의 일관성을 유지하는 것이 복잡해짐 장단점장점메시지 크기 감소: 스키마를 분리해 중앙에서 관리함으로써 메시지 자체에 스키마를 포함할 필요가 없어지기 때문에 메시지 크기 감소스키마 진화 지원: 스키마 레지스트리는 각 스키마의 버전을 관리하므로, 데이터 구조가 진화할 때도 호환성 문제가 발생하지 않도록 지원함 예를 들어, 새로운 필드를 추가하거나 제거할 때 이전 버전과의 호환성을 유지생산자-소비자 간의 독립성: 스키마 레지스트리를.. 2024. 11. 13. [Debezium] Creation of replication slot failed 에러 조치 에러내용[2024-11-03 19:36:44,277] ERROR [june_test_01|task-0] WorkerSourceTask{id=june_test_01-0} Task threw an uncaught and unrecoverable exception. Task is being killed and will not recover until manually restarted (org.apache.kafka.connect.runtime.WorkerTask:212)io.debezium.DebeziumException: Creation of replication slot failed at io.debezium.connector.postgresql.PostgresConnectorTask.star.. 2024. 11. 11. [Kraft] Kraft 소개 목적 Kraft 도입에 대한 니즈를 소개하기 위함 등장 배경 기존 아파치 주키퍼의 경우 아래의 문제점이 있었음성능적인 부분브로커는 모든 토픽과 파티션에 대한 메타데이터를 주키퍼에서 읽어야 하며, 메타데이터의 업데이터는 주키퍼에서 동기방식으로 일어나고, 브로커에는 비동기방식으로 전달됨. 이 때문에 토픽과 파티션이 많은 대규모 카프카 클러스터에서는 지연이 등의 병목현상이 발생하게 됨관리적인 부분주키퍼와 카프카는 완전히 다른 애플리케이션으로 서로 다른 구성 파일, 환경, 서비스 데몬을 가지고 있음. 결국 관리자는 동시에 서로 다른 애플리케이셩늘 운영해야 함모니터링 등서로 다른 애플리케이션인 만큼 모니터링을 적용하는 방법과 주요 메트릭도 다름 Kraft의 주요 목적 카프카의 구조를 단순화하고 확장성을 향.. 2024. 11. 2. [Zookeeper] Ver. 3.8.1 Release note 요약 ImprovementPrometheus 메트릭의 성능 영향을 감소시킴 Sub-taskConnectionMetricsTest.testRevalidateCount에서 NPE 수정함 참고전체 Release note docIndex of /doc (apache.org)특정 버전 Release note docZooKeeper: Because Coordinating Distributed Systems is a Zoo (apache.org) 2024. 10. 28. 이전 1 2 3 4 ··· 11 다음 728x90 반응형
