작성자: 구글BD팀 김진욱
Twitter는 광고 플랫폼에서 일상적인 비즈니스 운영의 일환으로 수십억 개의 광고 참여 이벤트를 제공하며, 각 이벤트는 잠재적으로 수백 개의 다운스트림 집계 메트릭에 영향을 미칩니다. 광고주가 사용자 참여를 측정하고 광고 캠페인 효율성을 추적할 수 있도록 Twitter는 거의 실시간으로 초당 수백만 개의 메트릭을 집계할 수 있는 다양한 분석 도구, API 및 대시보드를 제공합니다.
마이그레이션 결정
지난 10년 동안 Twitter는 전 세계적으로 계속 증가하는 사용자 기반의 로드를 처리하기 위해 강력한 데이터 변환 파이프라인을 개발했습니다. 이러한 파이프라인의 첫 번째 배포는 처음에 모두 Twitter의 자체 데이터 센터에서 실행되었습니다. 입력 데이터는 Elephant Bird 컨테이너 형식의 LZO 압축 Thrift 파일 로 다양한 소스에서 HDFS(Hadoop Distributed File System)로 스트리밍됩니다 . 그런 다음 Scalding 데이터 변환 파이프라인을 통해 데이터를 일괄 처리하고 집계했습니다 . 그런 다음 집계 결과가 맨해튼 으로 출력되었습니다., Twitter의 자체 개발 분산 키-값 저장소, 제공용. 또한 Twitter의 자체 개발 시스템인 Eventbus( DistributedLog 위에 구축된 메시징 도구 ), Heron (스트림 처리 엔진) 및 Nighthawk(샤드된 Redis 배포)를 사용하는 스트리밍 시스템은 Twitter가 제공해야 하는 실시간 분석을 지원했습니다.
이 시스템은 지속적으로 대규모 규모를 유지했지만 원래 설계 및 구현은 어느 정도 한계에 도달하기 시작했습니다. 특히, 수년에 걸쳐 유기적으로 성장한 시스템의 일부는 새로운 기능으로 구성 및 확장하기가 어려웠습니다. 일부 복잡하고 오래 실행되는 작업도 신뢰할 수 없어 산발적인 오류가 발생했습니다. 레거시 최종 사용자 지원 시스템은 실행하는 데 비용이 많이 들었고 대규모 쿼리를 지원할 수 없었습니다.
향후 몇 년간 예상되는 사용자 참여 증가를 수용하고 새로운 기능 개발을 간소화하기 위해 Twitter Revenue Data Platform 엔지니어링팀은 아키텍처를 재고하고 Google Cloud에서 더 유연하고 확장 가능한 시스템을 배포하기로 결정했습니다.
플랫폼 현대화: 첫 번째 반복
2017년 중반에 Steve와 그의 팀은 광고 데이터 플랫폼 현대화의 첫 번째 재설계 반복 작업에 착수하여 Twitter와 Google Cloud 의 협력을 이끌어 냈습니다.
처음에 팀은 데이터 집계 레거시 Scalding 파이프라인을 변경하지 않은 상태로 두고 Twitter의 데이터 센터에서 계속 실행했습니다. 그러나 배치 레이어의 출력은 맨해튼에서 Google Cloud의 두 개의 개별 스토리지 위치로 전환되었습니다.
- BigQuery — 애드혹 및 일괄 쿼리를 지원하는 Google의 확장성이 뛰어난 서버리스 데이터 웨어하우스입니다.
- Cloud Bigtable – Google의 지연 시간이 짧은 완전 관리형 NoSQL 데이터베이스로 온라인 대시보드 및 소비자 API의 백엔드 역할을 합니다.
Scalding 파이프라인의 출력 집계는 먼저 Hadoop 시퀀스 파일 에서 Avro 온프레미스로 트랜스코딩되고 4시간 배치로 Cloud Storage 로 스테이징된 다음 BigQuery에 로드되었습니다. Google Cloud의 완전 관리형 스트리밍 및 일괄 분석 서비스인 Dataflow 에 배포된 간단한 파이프라인은 BigQuery에서 데이터를 읽고 약간의 변환을 적용했습니다. 마지막으로 Dataflow 파이프라인은 결과를 Bigtable에 기록했습니다.
팀은 Bigtable에서 집계된 값을 가져오고 최종 사용자 쿼리를 처리하기 위해 새로운 쿼리 서비스를 구축했습니다. 데이터 액세스 지연 시간을 최적화하기 위해 Bigtable 인스턴스와 동일한 지역의 Google Kubernetes Engine(GKE) 클러스터 에 이 쿼리 서비스를 배포했습니다.
아키텍처를 살펴보면 다음과 같습니다.
이 첫 번째 반복은 이미 많은 중요한 이점을 가져왔습니다.
- 전체 마이그레이션 작업의 위험을 제거하여 Twitter가 집계 비즈니스 로직과 스토리지를 동시에 마이그레이션하지 않도록 했습니다.
- 최종 사용자 서비스 시스템의 성능이 크게 향상되었습니다. Bigtable의 선형 확장성과 매우 낮은 데이터 액세스 대기 시간 덕분에 서빙 시스템의 P99 대기 시간이 2초 이상에서 300ms로 감소했습니다.
- 신뢰도가 크게 높아졌습니다. 이제 팀은 더 이상 서빙 시스템에 대한 페이징을 거의 받지 않습니다.
플랫폼 현대화: 두 번째 반복
2019년에 Twitter 팀은 새로운 제공 시스템을 구축하면서 Google Cloud 기술을 사용하여 나머지 데이터 분석 파이프라인을 재설계하기 시작했습니다. 재설계를 통해 기존의 몇 가지 문제점을 해결하고자 했습니다.
- 배치 및 스트리밍 레이어가 서로 다른 시스템에서 실행되었기 때문에 많은 로직이 시스템 간에 복제되었습니다.
- 서빙 시스템이 클라우드로 이동했지만 Hadoop 집계 프로세스의 기존 문제점은 여전히 존재했습니다.
- 실시간 계층은 실행하는 데 비용이 많이 들고 상당한 운영상의 주의가 필요했습니다.
이러한 문제점을 염두에 두고 팀은 이를 해결하는 데 도움이 될 수 있는 기술을 평가하기 시작했습니다. 처음에는 Apache Flink , Apache Kafka Streams 및 Apache Beam 과 같은 여러 오픈 소스 스트림 처리 프레임워크를 고려했습니다 . 가능한 모든 옵션을 평가한 후 팀은 다음과 같은 몇 가지 주요 이유로 Apache Beam을 선택했습니다.
- Beam은 여러 클러스터에서 매우 큰 규모로 정확히 한 번만 작업을 지원합니다.
- Bigtable, BigQuery, Google Cloud의 완전 관리형 실시간 메시징 서비스인 Pub/Sub 와 같은 다른 Google Cloud 제품과 긴밀하게 통합됩니다.
- 일괄 처리와 스트리밍을 통합하고 단일 작업이 일괄 입력(Cloud Storage) 또는 스트리밍 입력(Pub/Sub)에서 작동하도록 하는 Beam의 프로그래밍 모델입니다.
- Dataflow의 완전 관리형 서비스에 Beam 파이프라인을 배포하는 기능
Dataflow의 완전 관리형 접근 방식과 Beam의 포괄적인 기능 조합을 통해 Twitter는 데이터 변환 파이프라인의 구조를 단순화하고 전반적인 데이터 처리 용량과 안정성을 높일 수 있습니다.
두 번째 반복 이후의 아키텍처는 다음과 같습니다.
이 두 번째 반복에서 Twitter 팀은 배치 레이어를 다음과 같이 다시 구현했습니다. 데이터는 먼저 온프레미스 HDFS에서 Cloud Storage로 스테이징됩니다. 그런 다음 일괄 Dataflow 작업은 Cloud Storage에서 데이터를 정기적으로 로드하고, 집계를 처리하고, 임시 분석을 위해 BigQuery에, 제공 시스템을 위해 Bigtable에 결과를 이중으로 씁니다.
Twitter팀은 또한 Google Cloud에 완전히 새로운 스트리밍 레이어를 배포했습니다. 데이터 수집을 위해 온프레미스 서비스는 이제 Avro 형식 메시지의 두 가지 다른 스트림을 Pub/Sub로 푸시합니다. 각 메시지에는 여러 원시 이벤트 묶음이 포함되어 있으며 100~1,000개의 집계에 영향을 미칩니다. 이로 인해 4개의 Dataflow 작업(위 다이어그램의 J0-3)에서 초당 300만 개 이상의 집계가 수행됩니다. 모든 Dataflow 작업은 동일한 토폴로지를 공유하지만 각 작업은 서로 다른 스트림 또는 주제의 메시지를 사용합니다.
중요한 데이터가 포함된 하나의 스트림은 초당 200,000개의 메시지 속도로 시스템에 들어가고 두 개의 개별 Pub/Sub 주제로 분할됩니다. Dataflow 작업(다이어그램의 J3)은 이 두 스트림을 사용하고 초당 400,000개의 집계를 수행하며 결과를 Bigtable의 테이블로 출력합니다.
덜 중요하지만 더 많은 양의 데이터를 포함하는 다른 스트림은 초당 약 80,000개의 메시지 속도로 시스템에 입력되며 6개의 별도 주제로 분할됩니다. 3개의 Dataflow 작업(J0, J1, J2)은 이 더 큰 스트림의 처리를 공유하며, 각 작업은 사용 가능한 6개 주제 중 2개를 병렬로 처리한 다음 결과를 Bigtable의 테이블로 출력합니다. 전체적으로 이 세 가지 작업은 초당 200만 개 이상의 집계를 처리합니다.
대용량 스트림을 여러 주제로 분할하면 여러 가지 이점이 있습니다.
- 분할은 집계 키에 해시 함수를 적용한 다음 함수 결과를 사용 가능한 분할 수(이 경우 6개)로 나누어 구성됩니다. 이렇게 하면 다운스트림 파이프라인의 모든 키별 그룹화 작업이 일관된 집계 결과에 필요한 단일 파티션으로 범위가 지정됩니다.
- Dataflow 작업에 업데이트를 배포할 때 관리자는 각 작업을 순서대로 개별적으로 비우고 다시 시작할 수 있으므로 나머지 파이프라인이 중단 없이 계속되고 최종 사용자에게 미치는 영향을 최소화할 수 있습니다.
- 3개의 작업은 각각 현재 문제 없이 2개의 주제를 처리할 수 있으며 필요한 경우 최대 6개의 작업까지 수평으로 확장할 여지가 여전히 있습니다. 주제 수(6개)는 임의적이지만 현재 요구 사항과 잠재적인 트래픽 급증을 기준으로 적절한 균형을 유지합니다.
작업 구성을 지원하기 위해 Twitter는 초기에 Dataflow 파이프라인을 런타임에 구성할 수 있는 반복 가능한 템플릿으로 캡슐화할 수 있는 강력한 기능인 Dataflow의 템플릿 시스템 사용을 고려했습니다. 그러나 Twitter는 시간이 지남에 따라 변경될 수 있는 토폴로지가 있는 작업을 배포해야 했기 때문에 팀은 대신 개발자가 pystachio DSL에서 작업에 대한 다양한 매개 변수(조정 매개 변수, 작동할 데이터 소스, 싱크, 싱크)를 지정할 수 있는 맞춤형 선언 시스템을 구현하기로 결정했습니다 . 집계 출력용 테이블 및 작업의 소스 코드 위치. Flex 템플릿이라고 하는 Dataflow 템플릿의 새로운 주요 버전은 템플릿 아키텍처의 이전 제한 사항 중 일부를 제거하고 모든 Dataflow 작업을 템플릿화할 수 있습니다.
작업 조정을 위해 Twitter 팀은 구성 파일을 처리하여 Dataflow API를 호출하고 작업을 제출하는 커스텀 명령줄 도구를 구축했습니다. 또한 이 도구를 사용하면 개발자가 다음과 같은 다단계 프로세스를 자동으로 수행하여 작업 업데이트를 제출할 수 있습니다.
- 이전 작업 비우기:
- Dataflow API를 호출하여 작업에서 사용되는 데이터 소스(예: Pub/Sub 주제 리더)를 식별합니다.
- 배수 요청을 시작합니다.
- 드레이닝 작업이 완료되었음을 나타내는 최대 워터마크에 도달할 때까지 식별된 소스의 워터마크에 대해 Dataflow API를 폴링합니다.
- 업데이트된 코드로 새 작업을 시작합니다.
이 간단하고 유연하며 강력한 시스템을 통해 개발자는 작업 오케스트레이션 또는 기본 인프라 세부 사항에 대해 걱정할 필요 없이 데이터 변환 코드에 집중할 수 있습니다.
앞을 내다보며
광고 분석 데이터 플랫폼을 Google Cloud로 완전히 전환한 지 6개월 만에 Twitter는 이미 엄청난 이점을 얻었습니다. Twitter의 개발자는 기존 데이터 파이프라인을 보다 쉽게 구성하고 새로운 기능을 훨씬 빠르게 구축할 수 있으므로 민첩성이 향상되었습니다. 실시간 데이터 파이프라인은 또한 Beam의 정확히 1회 시맨틱과 Pub/Sub, Dataflow 및 Bigtable에서 지원하는 향상된 처리 속도 및 수집 용량 덕분에 안정성과 정확성이 크게 향상되었습니다.
Twitter 엔지니어는 버전 2.2부터 몇 년 동안 Dataflow 및 Beam과 함께 작업하는 것을 즐겼으며 계속해서 사용을 확장할 계획입니다. 가장 중요한 것은 곧 배치 및 스트리밍 레이어를 신뢰할 수 있는 단일 스트리밍 레이어로 병합할 것입니다.
이 프로젝트를 진행하는 동안 Twitter 팀은 Google 엔지니어와 매우 긴밀하게 협력하여 피드백을 교환하고 제품 개선 사항에 대해 논의했습니다. Twitter에서 진행 중인 여러 대규모 클라우드 마이그레이션 프로젝트에서 이 공동 기술 노력을 계속할 수 있기를 기대합니다. 더 많은 업데이트를 기대해 주세요!