Delta: 데이터 동기화 및 강화 플랫폼

새로운 흐름의 출시를 기대하면서 데이터 엔지니어 흥미로운 자료의 번역을 준비했습니다.

검토

우리는 애플리케이션이 여러 데이터 저장소를 사용하는 매우 일반적인 패턴에 대해 이야기할 것입니다. 여기서 각 저장소는 표준 형식의 데이터(MySQL 등)를 저장하고 고급 검색 기능(ElasticSearch, etc.) .), 캐싱(Memcached 등) 및 기타. 일반적으로 여러 데이터 저장소를 사용하는 경우 그 중 하나는 기본 저장소 역할을 하고 다른 저장소는 파생 저장소 역할을 합니다. 유일한 문제는 이러한 데이터 저장소를 동기화하는 방법입니다.

우리는 이중 쓰기, 분산 트랜잭션 등과 같은 여러 저장소 동기화 문제를 해결하기 위해 시도한 다양한 패턴을 살펴보았습니다. 그러나 이러한 접근 방식은 실제 사용, 신뢰성 및 유지 관리 측면에서 상당한 한계를 가지고 있습니다. 데이터 동기화 외에도 일부 애플리케이션은 외부 서비스를 호출하여 데이터를 강화해야 합니다.

Delta는 이러한 문제를 해결하기 위해 개발되었습니다. Delta는 궁극적으로 데이터 동기화 및 강화를 위한 일관된 이벤트 중심 플랫폼을 제공합니다.

기존 솔루션

이중 항목

두 개의 데이터 저장소를 동기화된 상태로 유지하려면 한 저장소에 쓴 후 즉시 다른 저장소에 쓰는 이중 쓰기를 사용할 수 있습니다. 첫 번째 녹음을 다시 시도할 수 있으며, 시도 횟수가 소진된 후 첫 번째 녹음이 실패하면 두 번째 녹음이 중단될 수 있습니다. 그러나 두 번째 저장소에 쓰기가 실패하면 두 데이터 저장소가 동기화되지 않을 수 있습니다. 이 문제는 일반적으로 첫 번째 저장소에서 두 번째 저장소로 데이터를 주기적으로 재전송할 수 있는 복구 절차를 생성하거나 데이터에서 차이점이 발견된 경우에만 이를 수행함으로써 해결됩니다.

문제 :

복구 절차를 수행하는 것은 재사용할 수 없는 특정 작업입니다. 또한 복원 절차가 수행될 때까지 저장 위치 간의 데이터가 동기화되지 않은 상태로 유지됩니다. 세 개 이상의 데이터 저장소를 사용하면 솔루션이 더 복잡해집니다. 마지막으로 복원 절차는 원래 데이터 소스에 로드를 추가할 수 있습니다.

변경 로그 테이블

테이블 집합에 변경 사항(예: 레코드 삽입, 업데이트, 삭제 등)이 발생하면 변경 레코드가 동일한 트랜잭션의 일부로 로그 테이블에 추가됩니다. 다른 스레드나 프로세스는 지속적으로 로그 테이블의 이벤트를 요청하고 이를 하나 이상의 데이터 저장소에 기록합니다. 필요한 경우 모든 저장소에서 기록이 확인된 후 로그 테이블에서 이벤트를 제거합니다.

문제 :

이 패턴은 라이브러리로 구현되어야 하며 이상적으로는 이를 사용하는 애플리케이션의 코드를 변경하지 않아야 합니다. 다중 언어 환경에서는 이러한 라이브러리의 구현이 필요한 언어로 존재해야 하지만 언어 전반에 걸쳐 기능과 동작의 일관성을 보장하는 것은 매우 어렵습니다.

또 다른 문제는 MySQL과 같이 트랜잭션 스키마 변경을 지원하지 않는 시스템[1][2]에서 스키마 변경을 얻는 데 있습니다. 따라서 변경(예: 스키마 변경)을 수행하고 이를 변경 로그 테이블에 트랜잭션 방식으로 기록하는 패턴이 항상 작동하는 것은 아닙니다.

분산 트랜잭션

분산 트랜잭션을 사용하면 트랜잭션을 여러 이기종 데이터 저장소로 분할하여 작업이 사용된 모든 데이터 저장소에 커밋되거나 그 중 어느 것에도 커밋되지 않도록 할 수 있습니다.

문제 :

분산 트랜잭션은 이기종 데이터 저장소에 매우 큰 문제입니다. 본질적으로 관련 시스템의 가장 낮은 공통 분모에만 의존할 수 있습니다. 예를 들어, 준비 단계에서 애플리케이션 프로세스가 실패하면 XA 트랜잭션이 실행을 차단합니다. 또한 XA는 교착 상태 감지 기능을 제공하지 않거나 낙관적 동시성 제어 체계를 지원하지 않습니다. 또한 ElasticSearch와 같은 일부 시스템은 XA 또는 기타 이기종 트랜잭션 모델을 지원하지 않습니다. 따라서 다양한 데이터 저장 기술에서 쓰기 원자성을 보장하는 것은 애플리케이션에 있어 매우 어려운 작업으로 남아 있습니다[3].

델타

Delta는 기존 데이터 동기화 솔루션의 한계를 해결하고 즉각적인 데이터 강화를 지원하도록 설계되었습니다. 우리의 목표는 애플리케이션 개발자가 비즈니스 기능 구현에 전적으로 집중할 수 있도록 이러한 모든 복잡성을 추상화하는 것이었습니다. 다음으로 Netflix Delta의 실제 사용 사례인 "Movie Search"에 대해 설명하겠습니다.

Netflix는 마이크로서비스 아키텍처를 널리 사용하며 각 마이크로서비스는 일반적으로 한 가지 유형의 데이터를 제공합니다. 영화에 대한 기본 정보는 Movie Service라는 마이크로서비스에 포함되어 있으며, 제작자, 배우, 공급업체 등에 대한 정보와 같은 관련 데이터는 다른 여러 마이크로서비스(즉, Deal Service, Talent Service 및 Vendor Service)에서 관리됩니다.
Netflix Studios의 비즈니스 사용자는 다양한 영화 기준을 검색해야 하는 경우가 많으므로 모든 영화 관련 데이터를 검색할 수 있는 것이 매우 중요합니다.

Delta 이전에는 영화 검색 팀이 영화 데이터를 인덱싱하기 전에 여러 마이크로서비스에서 데이터를 가져와야 했습니다. 또한 팀은 변경 사항이 전혀 없더라도 다른 마이크로서비스에 변경 사항을 요청하여 주기적으로 검색 색인을 업데이트하는 시스템을 개발해야 했습니다. 이 시스템은 빠르게 복잡해지고 유지 관리가 어려워졌습니다.

그림 1. Delta에 대한 폴링 시스템
Delta를 사용한 후 시스템은 다음 그림과 같이 이벤트 중심 시스템으로 단순화되었습니다. CDC(Change-Data-Capture) 이벤트는 Delta-Connector를 사용하여 Keystone Kafka 주제로 전송됩니다. Delta 스트림 처리 프레임워크(Flink 기반)를 사용하여 구축된 Delta 애플리케이션은 주제에서 CDC 이벤트를 수신하고, 다른 마이크로서비스를 호출하여 이를 강화하고, 마지막으로 강화된 데이터를 Elasticsearch의 검색 인덱스에 전달합니다. 전체 프로세스는 거의 실시간으로 이루어집니다. 즉, 데이터 웨어하우스에 변경 사항이 적용되자마자 검색 색인이 업데이트됩니다.

그림 2. Delta를 사용한 데이터 파이프라인
다음 섹션에서는 스토리지에 연결하고 CDC 이벤트를 Kafka 주제로 라우팅하는 실시간 데이터 전송 인프라인 전송 계층에 CDC 이벤트를 게시하는 Delta-Connector의 작동에 대해 설명합니다. 그리고 마지막에는 애플리케이션 개발자가 데이터 처리 및 강화 논리에 사용할 수 있는 Delta 스트림 처리 프레임워크에 대해 설명하겠습니다.

CDC(변경 데이터 캡처)

우리는 데이터 저장소에서 커밋된 변경 사항을 실시간으로 캡처하여 스트림에 쓸 수 있는 Delta-Connector라는 CDC 서비스를 개발했습니다. 실시간 변경 사항은 트랜잭션 로그 및 스토리지 덤프에서 가져옵니다. 덤프는 일반적으로 트랜잭션 로그가 전체 변경 내역을 저장하지 않기 때문에 사용됩니다. 변경 사항은 일반적으로 델타 이벤트로 직렬화되므로 수신자는 변경 사항이 어디서 오는지 걱정할 필요가 없습니다.

Delta-Connector는 다음과 같은 몇 가지 추가 기능을 지원합니다.

• Kafka 이후에 사용자 정의 출력 데이터를 작성하는 기능.
• 모든 테이블, 특정 테이블 또는 특정 기본 키에 대해 언제든지 수동 덤프를 활성화하는 기능.
• 덤프는 청크로 검색할 수 있으므로 실패 시 처음부터 다시 시작할 필요가 없습니다.
• 테이블에 잠금을 설정할 필요가 없습니다. 이는 데이터베이스 쓰기 트래픽이 우리 서비스에 의해 차단되지 않도록 하는 데 매우 중요합니다.
• AWS 가용 영역의 중복 인스턴스로 인한 고가용성.

현재 AWS RDS 및 Aurora 배포를 포함하여 MySQL 및 Postgres를 지원합니다. Cassandra(다중 마스터)도 지원합니다. 여기에서 Delta-Connector에 대한 자세한 내용을 확인할 수 있습니다. 블로그.

Kafka와 전송 계층

Delta의 이벤트 전송 계층은 플랫폼의 메시징 서비스를 기반으로 구축되었습니다. 요지.

역사적으로 Netflix에 게시하는 것은 수명보다는 접근성에 최적화되었습니다(아래 참조). 이전 기사). 다양한 에지 시나리오에서 잠재적인 브로커 데이터 불일치가 발생했습니다. 예를 들어, 부정한 지도자 선거 이벤트가 중복되거나 손실될 가능성이 있는 수신자에 대한 책임이 있습니다.

Delta를 통해 우리는 파생 매장에 CDC 이벤트를 전달할 수 있도록 더 강력한 내구성 보장을 원했습니다. 이를 위해 우리는 특별히 설계된 Kafka 클러스터를 일급 객체로 제안했습니다. 아래 표에서 일부 브로커 설정을 확인할 수 있습니다.

Keystone Kafka 클러스터에서는 부정한 지도자 선거 일반적으로 게시자 접근성을 보장하기 위해 포함됩니다. 동기화되지 않은 복제본이 리더로 선택되면 메시지가 손실될 수 있습니다. 새로운 고가용성 Kafka 클러스터의 경우 옵션 부정한 지도자 선거 메시지 손실을 방지하기 위해 꺼졌습니다.

우리도 늘었어요 복제 인자 2에서 3까지 그리고 최소 비동기 복제본 1 대 2. 이 클러스터에 쓰는 게시자는 다른 모든 것의 응답이 필요하므로 복제본 2개 중 3개가 게시자가 보낸 최신 메시지를 갖도록 해야 합니다.

브로커 인스턴스가 종료되면 새 인스턴스가 이전 인스턴스를 대체합니다. 그러나 새 브로커는 동기화되지 않은 복제본을 따라잡아야 하며 이는 몇 시간이 걸릴 수 있습니다. 이 시나리오의 복구 시간을 줄이기 위해 로컬 브로커 디스크 대신 블록 데이터 스토리지(Amazon Elastic Block Store)를 사용하기 시작했습니다. 종료된 브로커 인스턴스를 새 인스턴스가 교체하면 종료된 인스턴스에 있던 EBS 볼륨을 연결하고 새 메시지를 따라잡기 시작합니다. 이 프로세스는 새 인스턴스가 더 이상 빈 상태에서 복제할 필요가 없기 때문에 백로그 정리 시간을 몇 시간에서 몇 분으로 줄여줍니다. 전반적으로 별도의 스토리지 및 브로커 수명 주기는 브로커 전환의 영향을 크게 줄입니다.

데이터 전달 보장을 더욱 높이기 위해 우리는 메시지 추적 시스템 극단적인 조건(예: 파티션 리더의 시계 비동기화)에서 메시지 손실을 감지합니다.

스트림 처리 프레임워크

Delta의 처리 계층은 Netflix 생태계와 Apache Flink 통합을 제공하는 Netflix SPaaS 플랫폼 위에 구축되었습니다. 이 플랫폼은 Titus 컨테이너 관리 플랫폼을 기반으로 Flink 작업 배포와 Flink 클러스터 조정을 관리하는 사용자 인터페이스를 제공합니다. 또한 이 인터페이스는 작업 구성을 관리하고 사용자가 Flink 작업을 다시 컴파일하지 않고도 동적으로 구성을 변경할 수 있도록 해줍니다.

Delta는 Flink 및 SPaaS를 기반으로 하는 스트림 처리 프레임워크를 제공합니다. 주석 기반 기술적 세부 사항을 추상화하는 DSL(도메인 특정 언어)입니다. 예를 들어 외부 서비스를 호출하여 이벤트가 강화되는 단계를 정의하려면 사용자는 다음 DSL을 작성해야 하며 프레임워크는 이를 기반으로 Flink에서 실행되는 모델을 생성합니다.

그림 3. Delta의 DSL 강화 예

처리 프레임워크는 학습 곡선을 줄일 뿐만 아니라 중복 제거, 스키마화, 유연성 및 탄력성과 같은 일반적인 스트림 처리 기능을 제공하여 일반적인 운영 문제를 해결합니다.

델타 스트림 처리 프레임워크는 DSL 및 API 모듈과 런타임 모듈이라는 두 가지 핵심 모듈로 구성됩니다. DSL & API 모듈은 사용자가 자체 처리 로직(예: 필터링 또는 변환)을 작성할 수 있도록 DSL 및 UDF(사용자 정의 기능) API를 제공합니다. 런타임 모듈은 DAG 모델의 처리 단계에 대한 내부 표현을 구축하는 DSL 파서 구현을 제공합니다. 실행 구성요소는 DAG 모델을 해석하여 실제 Flink 문을 초기화하고 궁극적으로 Flink 애플리케이션을 실행합니다. 프레임워크의 아키텍처는 다음 그림에 설명되어 있습니다.

그림 4. 델타 스트림 처리 프레임워크 아키텍처

이 접근 방식에는 다음과 같은 몇 가지 장점이 있습니다.

• 사용자는 Flink 또는 SPaaS 구조의 세부 사항을 조사할 필요 없이 비즈니스 로직에 집중할 수 있습니다.
• 최적화는 사용자에게 투명한 방식으로 수행될 수 있으며, 사용자 코드(UDF)를 변경하지 않고도 오류를 수정할 수 있습니다.
• 플랫폼은 기본적으로 유연성과 탄력성을 제공하고 경고에 사용할 수 있는 다양하고 자세한 지표를 수집하므로 Delta 애플리케이션 환경은 사용자에게 단순화됩니다.

생산용

Delta는 XNUMX년 넘게 제작되어 왔으며 많은 Netflix Studio 애플리케이션에서 핵심적인 역할을 담당하고 있습니다. 그녀는 팀이 검색 인덱싱, 데이터 저장, 이벤트 기반 워크플로와 같은 사용 사례를 구현하도록 도왔습니다. 다음은 Delta 플랫폼의 상위 수준 아키텍처에 대한 개요입니다.

그림 5. Delta의 상위 수준 아키텍처

감사의 말

Netflix에서 Delta의 제작 및 개발에 참여한 다음 분들께 감사의 말씀을 전합니다. Allen Wang, Charles Zhao, 윤재빈, Josh Snyder, Kasturi Chatterjee, Mark Cho, Olof Johansson, Piyush Goyal, Prashanth Ramdas, Raghuram Onti Srinivasan, Sandeep Gupta, Steven Wu, Tharanga Gamaethige, Yun Wang 및 Zhenzhong Xu.

소스

1. dev.mysql.com/doc/refman/5.7/en/implicit-commit.html
2. dev.mysql.com/doc/refman/5.7/en/cannot-roll-back.html
3. Martin Kleppmann, Alastair R. Beresford, Boerge Svingen: 온라인 이벤트 처리. 커뮤니케이터 ACM 62(5): 43–49(2019). DOI: doi.org/10.1145/3312527

무료 웨비나에 등록하세요: “Amazon Redshift Storage용 데이터 구축 도구.”

출처 : habr.com