전문가의 인사이트를 바탕으로 한 최신 기술 뉴스
Think 뉴스레터를 통해 AI, 자동화, 데이터 등 가장 중요하고 흥미로운 업계 동향에 대한 최신 소식을 받아보세요. IBM 개인정보 보호정책을 참조하세요.
스키마 레지스트리는 Apache Kafka를 통해 교환되는 데이터의 직렬화 및 역직렬화에 사용되는 스키마를 저장, 관리 및 검증하는 중앙 집중식 서비스입니다. 스키마 레지스트리는 각 생산자와 소비자 애플리케이션이 메시지 형식을 독립적으로 정의할 수 있도록 하는 대신, 이벤트 데이터가 구조화되는 방식에 대한 공유된 '신뢰할 수 있는 소스'를 제공합니다.
Kafka에서는 많은 경우 이벤트가 Apache Avro, JSON 스키마 또는 프로토콜 버퍼(종종 protobuf로 축약됨)와 같은 형식으로 직렬화됩니다. 스키마 레지스트리는 이러한 형식의 정의를 저장하고 각 스키마에 고유 식별자를 할당합니다. 이를 스키마 ID라고 합니다.
생산자가 Kafka 주제에 메시지를 작성할 때는 일반적으로 모든 메시지에 전체 스키마를 임베딩하는 대신 직렬화된 데이터와 함께 스키마 ID를 포함합니다. 메시지 소비자는 레지스트리에서 해당 스키마를 검색하여 이를 사용해 데이터를 올바르게 역직렬화하고 해석합니다.
이벤트 기반 시스템에서 스키마 레지스트리는 교환되는 데이터 구조에 생산자와 소비자가 합의하도록 보장하는 데 도움이 되므로 중요합니다. 이는 데이터 품질과 데이터 무결성을 지원합니다.
중앙 집중식 레지스트리가 없으면 애플리케이션이 메시지 스키마를 독립적으로 관리해야 합니다. 이로 인해 이벤트 소비자가 실패하거나 데이터를 잘못 해석할 수 있는 호환되지 않는 변경 사항이 발생할 위험이 높아집니다.
스키마 레지스트리는 스키마 진화라고도 불리는 기능 또한 지원합니다. 이를 통해 개발자는 기존 애플리케이션과의 호환성을 유지하면서 시간 경과에 따라 이벤트 구조를 수정할 수 있습니다.
예를 들어, 많은 경우 기존 Kafka 소비자가 기대하는 형식을 손상시키지 않고 새로운 선택적 필드를 추가할 수 있습니다. 호환성 규칙은 배포 전에 안전한 스키마 변경을 적용하는 데 도움이 됩니다.
Think 뉴스레터를 통해 AI, 자동화, 데이터 등 가장 중요하고 흥미로운 업계 동향에 대한 최신 소식을 받아보세요. IBM 개인정보 보호정책을 참조하세요.
또 다른 중요한 이점은 데이터 거버넌스가 향상된다는 것입니다. 스키마는 중앙 리포지토리에 저장되므로 조직은 이벤트 데이터의 구조를 문서화하고, 검토하고, 버전을 관리하고, 감사할 수 있습니다.
이 접근 방식을 통해 개발팀이 다음을 더 쉽게 수행할 수 있습니다.
또한 최신 데이터 플랫폼에서 스키마 레지스트리는 Kafka 생산자와 Kafka 소비자 간의 데이터 계약을 지원할 수 있습니다. 이러한 계약은 데이터의 구조뿐만 아니라 시간이 지날수록 해당 데이터가 어떻게 발전해야 하는지에 대한 기대치도 정의합니다.
스키마 레지스트리는 스키마 변경이 공개되기 전에 이를 검증함으로써 호환성을 손상시키는 변경 사항이 프로덕션에 도달하는 일을 방지하고 이벤트 기반 아키텍처의 신뢰성을 향상할 수 있습니다.
스키마 레지스트리는 이벤트 스키마를 관리하고, 이러한 스키마 간의 호환성을 구현하며, 스키마에 대한 변경을 지원하는 중앙 집중식 메커니즘을 제공합니다.
레지스트리를 사용하면 개발자가 기존 스키마 위에 새로운 스키마를 구축하여 스키마에서 구조화된 구성을 만들고 주체 이름 전략으로 이벤트 이름을 표준화할 수 있습니다.
이러한 방법은 시스템 및 요구 사항이 변경됨에 따라 애플리케이션의 데이터 교환에 도움이 됩니다.
스키마 레지스트리는 이벤트 생산자와 소비자 간 교환되는 이벤트 데이터의 구조를 정의하는 스키마를 저장하고 관리하는 방식으로 작동합니다. 생산자가 Kafka 주제에 데이터를 전송할 때, 생산자는 등록된 스키마에 따라 메시지를 직렬화하고 해당 스키마를 식별할 수 있는 정보를 포함합니다. 그러면 소비자가 해당 스키마를 사용하여 메시지를 역직렬화하고 올바르게 해석할 수 있습니다. 스키마가 시간이 지날수록 변화함에 따라, 레지스트리는 새로운 스키마 버전이 등록되기 전에 이에 호환성 검사를 적용할 수 있으며, 이를 통해 생산자와 소비자가 진화하는 데이터 구조를 계속 사용하여 작업할 수 있도록 돕습니다.
e-commerce 웹사이트, 모바일 앱, 추천 엔진, 재고 관리 시스템, 배송 플랫폼, 고객 분석 플랫폼 등 데이터를 생성하고 사용하는 여러 시스템을 갖춘 대규모 온라인 소매업체를 상상해 보세요. 이러한 시스템 각각은 Confluent Cloud를 사용해 Apache Kafka 클러스터를 통해 이벤트를 게시하고 소비하며, 데이터 파이프라인에서 Kafka Connect를 통해 이러한 이벤트를 데이터 웨어하우스로 스트리밍합니다.
웹사이트에서 행동이 발생할 때마다 소매업체 시스템 전반에서 여러 이벤트가 생성됩니다. 고객이 주문을 발주하면 웹사이트가
여러 다운스트림 애플리케이션이 동일한 이벤트를 사용합니다. 재고 관리 시스템은 구매한 품목을 예약하고, 결제 시스템은 거래를 확인하며, 창고는 주문 이행을 시작합니다. 추천 엔진은 고객 선호도를 업데이트하고, 분석 플랫폼은 판매 내역을 기록하며, 고객 알림 서비스는 이메일로 구매 확인을 보냅니다.
초기에는
이제 몇 달 후 이 비즈니스가 해외 판매를 지원하기로 결정했다고 상상해 보세요. 개발자들은 이제 각 주문에 새로운 두 필드인
스키마 레지스트리가 없으면 이러한 변경 사항을 조정할 수 있는 중앙 집중식 메커니즘이 없습니다. 일부 이벤트 데이터 소비자는 새 필드를 기대하지만, 다른 소비자는 그렇지 않습니다. 개발자가 실수로
그렇다면 스키마 관리에 도움이 되는 Confluent Schema Registry를 사용하면 동일한 시나리오가 어떻게 될까요?
개발팀은 업데이트된 생산자를 배포하기 전에
제안된 변경 사항이 해당 호환성 규칙을 준수하는 경우 새 스키마 버전을 등록할 수 있습니다. 변경 사항이 구성된 호환성 정책을 위반하는 경우 애플리케이션이 호환되지 않는 스키마를 사용하기 전에 레지스트리에서 이를 거부할 수 있습니다.
즉, 개발자는 배포 후가 아닌 개발 중에 호환성을 손상시키는 스키마 변경 사항을 발견할 수 있습니다. 기존 소비자는 호환되는 변경 사항을 적용하여 계속 작동할 수 있으며, 개발팀은 준비가 되면 새 필드를 사용하도록 애플리케이션을 점진적으로 업데이트할 수 있습니다.
스키마 레지스트리의 이점은 회사가 성장할수록 더욱 중요해집니다. 수많은 엔지니어링 팀이 개발한 수백 개의 애플리케이션은 수천 개의 서로 다른 이벤트 유형을 통해 데이터를 교환할 수 있습니다.
스키마 레지스트리가 없으면 모든 팀이 수기 문서, 회의 또는 시행착오를 통해 스키마 변경 사항을 수동으로 조정해야 합니다. 이러한 수동 프로세스는 개발을 지체시키고 호환되지 않는 변경 사항이 프로덕션에 도달할 가능성을 높일 수 있습니다.
스키마 레지스트리를 갖추면 이벤트 스키마는 중앙에서 관리되는 자산이 됩니다. 생산자는 등록된 스키마에 따라 데이터를 공개할 수 있고, 소비자는 그러한 스키마 정의를 사용해 수신되는 이벤트를 해석할 수 있으며, 호환성 검사를 통해 호환되지 않는 스키마 변경을 식별할 수 있습니다.
또한 신규 팀은 메시지 형식을 역엔지니어링하는 대신 기존 이벤트 정의를 검색할 수 있으므로, 새 애플리케이션을 구축하고 새 시스템을 통합하기가 더 쉬워집니다.
소매업체의 규모가 커짐에 따라 스키마 레지스트리는 생산자와 소비자 전반에 걸쳐 진화하는 이벤트 스키마를 관리하는 중앙 집중식 방법을 제공합니다.
스키마 호환성은 스키마가 발전함에 따라 서로 다른 버전의 스키마를 사용하는 애플리케이션이 계속해서 데이터를 교환하고 올바르게 해석할 수 있는지 여부를 결정합니다. 주요 호환성 모드는 하위 호환성, 상위 호환성, 완전한 호환성입니다.
일부 스키마 레지스트리는 이러한 호환성 모드의 전이적 버전도 지원합니다. 전이적 호환성 검사는 새로운 스키마 버전을 직전 버전과 비교하는 대신 관련된 이전 버전과 비교합니다. 정확한 호환성 규칙과 허용되는 스키마 변경 사항은 스키마 형식과 레지스트리의 호환성 설정에 따라 다릅니다.
상위 호환성은 이전 생산자가 계속 작동해야 하는 한편 신규 소비자가 이러한 이전 생산자들의 데이터를 중단 없이 처리해야 하는 경우에 유용합니다. 이러한 상황에서는 새로 배포된 애플리케이션이 이전 버전의 생산자 소프트웨어에서 생성되는 메시지와 계속 호환되도록 하는 것이 중요합니다.
스마트 전력망을 운영하는 전국적인 전기 회사를 상상해 보세요. 이러한 전력망은 가정과 사업장에 설치된 수백만 개의 스마트 미터로 구성됩니다. 각 스마트 미터는 Apache Kafka에 전기 사용량 이벤트를 게시합니다. 이러한 미터는 수년간 계속 사용되며, 예정된 유지보수 기간에만 펌웨어 업데이트를 받을 수 있습니다. 이는 많은 미터가 최신 버전의 소프트웨어가 출시된 후에도 오래된 스키마를 사용해 이벤트를 계속 생성함을 의미합니다.
한편, 해당 전기 회사는 중앙 모니터링 및 분석 애플리케이션을 정기적으로 업그레이드합니다. 분석 플랫폼의 새 버전이 전력 품질 지표 및 재생 에너지 발전과 같은 추가 정보의 지원을 도입합니다. 이러한 새로운 필드는 있으면 유용하지만, 플랫폼은 이를 전송하지 않는 이전 미터의 데이터를 계속 처리해야 합니다.
이 시나리오에서는 이전 버전과의 호환성보다 상위 호환성이 더 중요한데, 이는 소비자가 먼저 업데이트되는 반면 많은 생산자는 이전 스키마 버전에 머무르기 때문입니다. 새로운 소비자 소프트웨어는 새로 도입된 필드가 없더라도 이전 스키마로 작성된 이벤트를 올바르게 읽을 수 있어야 합니다. 애플리케이션은 누락된 필드를 선택 사항으로 처리하거나 기본 기능을 계속 수행하면서 기본값을 할당할 수 있습니다.
만약 하위 호환성이 주된 관심사라면, 개발자들은 새로운 소비자가 이전 생산자 스키마로 작성된 데이터를 읽을 수 있도록 하는 데 집중했을 것입니다. 그러나 이 조직의 당면 과제는 중앙 처리 시스템을 현대화하는 동시에 오래 사용되어온 구형 장치를 지원하는 것입니다.
적절한 호환성 규칙이 있는 스키마 레지스트리를 사용하면 이 유틸리티는 배포된 수백만 개의 계량기에 대한 동시 펌웨어 업데이트 없이도 이벤트 스키마를 발전시킬 수 있습니다. 이를 통해 생산자와 소비자가 조직의 구성된 호환성 요구 사항 내에서 서로 다른 시간에 업데이트될 수 있는 단계적 롤아웃이 가능해집니다.
스키마 레지스트리는 일반 데이터 보호 규정(GDPR)과 California Consumer Privacy Act와 같은 데이터 프라이버시 규정과 관련된 준수 노력에 도움이 될 수 있습니다.
스키마 레지스트리는 그 자체로는 규정 준수를 제공하지 않지만, 조직이 규제 요구 사항을 충족하는 데 사용되는 데이터 거버넌스, 일관성 및 감사 관행을 구현하는 데 도움이 될 수 있습니다.
주요 이점 중 하나는 처리 중인 데이터에 대한 가시성이 향상된다는 것입니다.
모든 이벤트 스키마는 중앙 리포지토리에 저장되며, 해당 리포지토리에는 스키마에 표현된 필드가 문서화되어 있습니다. 이는 존재하는 데이터, 특정 필드가 나타내는 사항, 애플리케이션이 생산하거나 소비하는 데이터를 구조화하는 방법에 대한 정보 소스를 제공합니다.
이를 통해 조직은 이름, 이메일 주소 또는 계좌번호와 같은 개인 식별 정보(PII)가 포함된 스키마를 식별할 수 있습니다.
스키마 레지스트리는 GDPR의 원칙 중 하나인 데이터 최소화도 지원할 수 있습니다.
개발자와 데이터 거버넌스 팀은 스키마가 승인되기 전에 모든 필드가 의도한 비즈니스 목적에 필요한지를 검토할 수 있습니다. 이러한 검토 과정을 통해 애플리케이션이 불필요한 개인 정보를 수집하거나 공유하는 일을 방지할 수 있습니다.
스키마 검증은 또한 무단 변경이나 우발적인 변경으로 인해 새로운 민감한 데이터가 생산 시스템에 유입되는 일을 방지하는 데 도움이 됩니다.
예를 들어 개발자가 기존 Kafka 이벤트에 고객의 사회보장번호 또는 운전면허증 번호를 추가하려고 하는 경우 제안된 스키마를 배포하기 전에 이를 검토할 수 있습니다.
이 접근 방식은 일반적인 애플리케이션 테스트와 함께 추가적인 거버넌스 체크포인트를 생성합니다.
버전 관리 및 스키마 기록은 감사 기능을 제공합니다.
모든 스키마 진화는 기록되므로, 조직은 필드가 추가, 수정 또는 제거된 시기를 확인할 수 있습니다.
이러한 내역은 규정 준수 감사 과정에서 데이터 구조가 통제되고 추적 가능한 방식으로 관리되고 있음을 입증하는 데 도움이 될 수 있습니다.
스키마 레지스트리는 여러 시스템 간 일관성을 향상할 수도 있습니다.
생산자와 소비자는 공유된 스키마 정의에 의존하므로, 애플리케이션은 공통의 구조적 정의에 따라 필드를 해석할 수 있습니다.
이를 통해 애플리케이션 간 일관성 없는 데이터 처리를 줄일 수 있습니다.
많은 조직은 데이터 계약 구현의 일부로 스키마 레지스트리를 사용합니다.
이러한 계약은 이벤트의 구조뿐만 아니라 이벤트에 포함된 데이터에 대한 메타데이터도 정의합니다.
자동 유효성 검사를 통해 새 스키마 버전이 정의된 요구 사항을 계속 충족하는지 확인할 수 있습니다.
스키마 레지스트리는 더 광범위한 데이터 거버넌스 및 보안 도구와 통합할 수도 있습니다.
스키마와 함께 저장된 메타데이터는 다음과 같은 시스템에서 사용할 수 있습니다.
따라서 스키마 레지스트리는 보다 광범위한 거버넌스 아키텍처의 구성 요소가 될 수 있습니다.
암호화, 액세스 제어, 데이터 보존 정책 및 감사 로깅과 결합된 스키마 관리는 조직이 개인 데이터를 수집, 처리 및 공유하는 방법을 관리하는 데 도움이 될 수 있습니다.
여러 플랫폼이 Kafka 및 관련 데이터 시스템을 위한 스키마 레지스트리 기능을 제공합니다.
Confluent Schema Registry는 널리 사용되는 Kafka 전용 스키마 레지스트리입니다.
이 레지스트리는 Confluent 시스템의 일부이며, Confluent 플랫폼의 자체 관리 구성 요소로도, Confluent Cloud의 관리형 서비스로도 제공됩니다.
Avro, Protobuf 및 JSON 스키마를 지원하며 스키마 버전 관리, 호환성 규칙, 유효성 검사, Kafka 생산자 및 소비자와의 통합을 제공합니다.
Amazon Web Services는 AWS Glue Schema Registry를 제공합니다.
이 레지스트리는 Apache Kafka, Amazon Managed Streaming for Apache Kafka(MSK), Amazon Kinesis, Amazon Managed Service for Apache Flink 및 AWS Lambda와 통합되는 관리형 스키마 레지스트리입니다.
Avro, JSON Schema 및 Protobuf를 지원합니다.
Apicurio Registry는 Kafka와 함께 사용할 수 있는 오픈 소스 스키마 및 API 아티팩트 레지스트리입니다.
Avro, JSON Schema 및 Protobuf를 포함한 형식을 지원하며 Kubernetes와 같은 환경에 배포할 수 있습니다.
Apicurio는 또한 Confluent Schema Registry API와의 호환성을 제공하므로 Confluent의 스키마 레지스트리 인터페이스를 중심으로 설계된 Kafka 애플리케이션과 함께 사용하기가 더욱 용이합니다.
Redpanda는 Kafka 호환 스트리밍 플랫폼의 일부로 스키마 레지스트리 호환 서비스도 포함합니다.
스키마 관리가 스트리밍 플랫폼 자체의 일부로 제공될 수 있으므로, 이 접근 방식은 Apache Kafka를 직접 사용하지 않고 Redpanda를 사용하는 조직에서 유용할 수 있습니다.
Redpanda 레지스트리는 대체 Kafka 호환 스트리밍 플랫폼에 더 긴밀하게 통합되어 있습니다.
아니요. 스키마 레지스트리는 Apache Kafka 소프트웨어 코어의 일부가 아닙니다. Kafka는 레코드를 저장하고 전송합니다. 스키마 레지스트리는 해당 레코드에 포함된 데이터에 대한 스키마를 저장하고 관리하는 별도의 서비스입니다. 스키마 레지스트리는 생산자와 소비자가 구조화된 이벤트 데이터를 일관성 있게 해석할 수 있도록 일반적으로 Kafka와 함께 사용됩니다.
스키마 ID는 특정 스키마 정의를 식별하는 식별자입니다. 스키마 버전은 특정 스키마 또는 주체에 대해 유지 관리되는 버전 순서에서 해당 스키마가 나타나는 위치를 나타냅니다. 정확한 구현은 레지스트리에 따라 다릅니다. 예를 들어 Confluent Schema Registry에서 스키마 ID는 레지스트리에서 스키마를 고유하게 식별하는 반면, 버전은 주체에 속합니다. 따라서 동일한 스키마가 동일한 스키마 ID를 가지면서도 서로 다른 주체 아래 rkrrl 다른 버전과 연관될 수 있습니다.
스키마 레지스트리는 주로 애플리케이션이 데이터 구조를 이해하는 데 사용하는 기계 판독 가능한 스키마를 저장하고 관리합니다. 또한 스키마 버전 관리 및 호환성 검사와 같은 기능을 제공할 수도 있습니다.
데이터 카탈로그는 조직 전체의 데이터 자산을 사람과 시스템이 검색하고 이해하고 관리할 수 있도록 돕는다는 보다 광범위한 목적에 중점을 둡니다. 카탈로그에는 비즈니스 설명, 소유권 정보, 분류 및 데이터 세트와 데이터 시스템에 관한 기타 메타데이터가 포함될 수 있습니다. 따라서 스키마 레지스트리와 데이터 카탈로그는 서로를 보완할 수 있습니다. 레지스트리는 애플리케이션이 사용하는 스키마를 관리하며, 카탈로그는 조직의 데이터 자산에 관한 광범위한 정보를 제공합니다.
스키마는 필드 및 데이터 유형과 같은 요소를 포함한 데이터의 구조를 정의합니다. 데이터 계약은 스키마를 포함할 뿐만 아니라 데이터 생산자와 소비자 간의 보다 광범위한 기대치도 정의할 수 있습니다. 스키마는 무결성 제약, 메타데이터 및 정책과 함께 데이터 계약의 구성 요소일 수 있습니다.
올바른 스키마 레지스트리는 조직의 기술 요구 사항과 기존 데이터 아키텍처에 따라 달라집니다. 고려해야 할 요소에는 레지스트리가 지원하는 스키마 형식, 호환성 규칙, Apache Kafka 및 기타 데이터 시스템과의 통합, API 및 클라이언트 지원, 보안 및 인증 기능, 서비스가 관리형인지 자체 관리형인지 여부가 포함됩니다.
조직은 레지스트리가 스키마 진화, 데이터 거버넌스, 메타데이터 및 데이터 계약을 지원하는 방법과 기존 생산자, 소비자 및 데이터 파이프라인과의 호환성도 고려할 수 있습니다. 여러 레지스트리 제품은 이러한 기능의 다양한 조합을 제공하므로, 일반적으로 레지스트리가 지원해야 하는 시스템 및 요구 사항에 따라 선택해야 합니다.