Tulip: Meta의 데이터 플랫폼 현대화

마이그레이션은 어렵습니다. 게다가 다음과 같은 이유로 Meta에서는 훨씬 더 어려워집니다.

마이그레이션 이야기의 세부 사항을 살펴보기 전에 한발 물러서서 이 마이그레이션에 대한 동기와 근거를 설명하려고 합니다.

시간이 지남에 따라 데이터 플랫폼은 회사의 요구 사항이 증가함에 따라 다양한 형태로 변형되었습니다. 초기에는 작은 규모의 데이터 플랫폼이 엑사바이트 규모의 플랫폼으로 성장했습니다. 더 작은 규모로 서비스를 제공하는 일부 시스템은 늘어나는 요구 사항에 비해 부족하다는 징후를 보이기 시작했습니다. 가장 주목할 만한 점은 데이터 (역)직렬화와 관련된 몇 가지 구체적인 안정성 및 효율성 문제에 직면했다는 점입니다. 이로 인해 데이터를 기록하는 방식을 다시 생각하고 이러한 시급한 문제를 해결하기 위한 첫 번째 원칙의 아이디어를 다시 검토하게 되었습니다.

로거는 데이터 플랫폼의 핵심입니다. 이 시스템은 Scribe를 통해 Scuba, Hive 및 스트림 처리 파이프라인에 분석 및 운영 데이터를 기록하는 데 사용됩니다. 모든 제품 및 데이터 플랫폼 팀은 로깅과 상호 작용합니다. 로깅을 위한 데이터 형식은 레거시 이유로 인해 Hive Text Delimited 또는 JSON이었습니다. 이러한 형식의 제한 사항은 Tulip에 대한 이전 기사에 설명되어 있습니다.

이러한 제한 사항을 해결하기 위해 기존 대상별 직렬화 형식을 대체하기 위해 튤립 직렬화 형식이 개발되었습니다.

아래 차트는 다양한 단계와 마일스톤의 진행 상황을 보여주기 위해 일련화 형식을 튤립으로 변환하는 마이그레이션 과정을 그래픽으로 보여줍니다.

로깅 스키마의 수는 거의 동일하게 유지되었지만(또는 약간의 유기적 증가를 보였지만) 직렬화 형식의 변경으로 인해 기록된 바이트가 크게 감소했음을 알 수 있습니다. 형식별 바이트 절약과 관련된 세부 정보는 아래 섹션에 표로 정리되어 있습니다.

참고: 차트 2의 수치는 (볼륨 기준) 가장 큰 5개 로깅 스키마에 대해 관찰된 실제 절감액을 기준으로 (전체 트래픽에 대해) 추정되었습니다.

우리는 마이그레이션 여정을 각자의 관점을 지닌 두 가지 별개의 단계로 제시하고 싶습니다.

마이그레이션을 염두에 두고 시스템을 설계하면 마이그레이션이 훨씬 쉬워집니다. 다음 엔지니어링 솔루션은 팀이 유선 형식을 안전하게 전환하고 마이그레이션 단계에서 발생할 수 있는 문제를 확장 가능한 방식으로 디버그하는 데 필요한 도구 및 인프라 지원을 갖추도록 개발되었습니다.

솔루션은 대략 다음과 같은 버킷으로 분류됩니다.

과제: 데이터 생산자와 소비자가 직렬화 형식을 원자적으로 전환하도록 요구하지 않음으로써 어떻게 마이그레이션을 쉽게 하고 위험을 줄일 수 있습니까?

솔루션: 페이로드를 작성하기 위해 새로운 Tulip 직렬화 프로토콜을 사용하기 위해 단일 로깅 스키마를 뒤집을 때, 새로운 형식을 사용하기 위해 모든 데이터 생산자를 "원자적으로" 전환하는 것이 불가능하기 때문에 단일 스크라이브 스트림에서 혼합 모드 페이로드를 지원해야 했습니다. . 이를 통해 팀은 새로운 형식 직렬화의 출시 속도를 제한할 수도 있었습니다.

혼합 모드 와이어 형식은 대규모 출시 이전에 종단 간 승인 테스트에 광범위하게 사용된 섀도우 로거의 개념을 지원하는 데 중요했습니다.

혼합 모드 와이어 형식의 주요 과제는 Hive 텍스트 또는 JSON 형식의 기존 페이로드 직렬화를 변경할 수 없다는 것이었습니다. 이 제한 사항을 해결하기 위해 모든 Tulip 직렬 페이로드에는 잘못된 utf-8 시퀀스인 2바이트 시퀀스 0x80 0x00이 접두어로 붙습니다.

과제: 일부 시스템에서는 Hive Text(또는 JSON) 직렬화 형식이 페이로드를 소비하기 위해 이 형식에 의존하게 된 애플리케이션 코드에 영향을 미쳤습니다. 이는 소비자가 직렬화 형식 추상화를 깨뜨린 결과입니다.

솔루션: 두 가지 솔루션이 이 문제를 해결했습니다.

리더(데이터 역직렬화를 위한 로거 대응)

Reader는 직렬화된 페이로드를 구조화된 객체로 변환하는 라이브러리입니다. 리더(로거와 유사)는 (a) 생성된 코드와 (b) 일반의 두 가지 형태로 제공됩니다. 리더 개체는 Tulip, Hive Text, JSON 등 세 가지 형식 중 하나로 데이터를 사용하고 구조화된 개체를 생성합니다. 이를 통해 팀은 마이그레이션이 시작되기 전에 소비자를 리더기로 전환할 수 있었습니다. 원시 직렬화 라인 대신 이 구조화된 객체를 사용하려면 애플리케이션 코드를 업데이트해야 했습니다. 이는 데이터 소비자로부터 유선 형식을 추상화했습니다.