▲

GN⁺: Uber의 원장 데이터를 DynamoDB에서 LedgerStore로 마이그레이션

 (uber.com)
2P by neo 6달전 | favorite | 댓글 1개
  • 지난 주에는 Uber의 추가 전용 원장 스타일 데이터베이스인 LedgerStore(LSG)를 탐구했음.
  • 이번 주에는 Uber의 비즈니스에 중요한 원장 데이터를 LSG로 마이그레이션한 방법을 다룰 것
  • 1조 개 이상의 항목(몇 페타바이트의 데이터)을 투명하게 이동시키고 중단 없이 수행한 방법과 그 과정에서 배운 점을 논의

역사

  • Gulfstream은 Uber의 결제 플랫폼으로, 2017년에 DynamoDB를 사용하여 출시되었음.
  • Uber의 규모에서는 DynamoDB가 비싸졌고, 따라서 12주간의 데이터(핫 데이터)만 DynamoDB에 보관하고 오래된 데이터(콜드 데이터)는 Uber의 blobstore인 TerraBlob에 저장하기 시작했음.
  • 장기적인 솔루션으로 LSG를 사용하고자 했음. LSG는 결제 스타일 데이터를 저장하기 위해 목적에 맞게 설계되었음.
  • LSG의 주요 기능:
    • 검증 가능한 불변성 (암호화 서명을 사용하여 기록이 변경되지 않았음을 확인할 수 있음)
    • 비용 관리를 위한 계층형 스토리지 (핫 데이터는 요청을 처리하기 좋은 곳에, 콜드 데이터는 저장에 최적화된 곳에 보관)
    • 결국 일관성 있는 보조 인덱스의 지연 시간 개선
  • 2021년까지 Gulfstream은 DynamoDB, TerraBlob, LSG의 조합을 사용하여 데이터를 저장했음.
    • DynamoDB: 최근 12주간의 데이터
    • TerraBlob: 콜드 데이터
    • LSG: 데이터를 기록하고 마이그레이션하려는 대상

왜 마이그레이션을 해야 했는가?

  • LSG는 불변성 때문에 원장 스타일 데이터를 저장하는 데 더 적합함.
  • LSG로 이동함으로써 반복적인 비용 절감이 상당했음.
  • 세 가지 스토리지에서 하나의 스토리지로 전환하면 Gulfstream 서비스의 코드와 설계를 단순화할 수 있음.
  • LSG는 짧은 인덱싱 지연 시간을 약속했으며, Uber의 데이터 센터 내에서 온프레미스로 실행되기 때문에 더 빠른 네트워크 지연 시간을 제공함.

데이터의 특성과 관련된 위험

  • 마이그레이션하는 데이터는 2017년 이후 Uber의 모든 비즈니스 원장 데이터임:
    • 불변 기록: 압축된 크기 1.2 PB
    • 보조 인덱스: 압축되지 않은 크기 0.5 PB
  • 불변 기록은 수정할 수 없으며, 보조 인덱스 데이터는 문제를 수정하기 위해 수정할 수 있는 유연성이 있음.

검증

  • 백필이 모든 면에서 올바르고 수용 가능한지 확인하기 위해 현재 트래픽을 처리할 수 있는지와 현재 액세스되지 않는 데이터가 올바른지 확인해야 함.
  • 검증 기준:
    • 완전성: 모든 기록이 백필되었는지
    • 정확성: 모든 기록이 정확한지
    • 부하: LSG가 현재 부하를 처리할 수 있는지
    • 지연 시간: LSG의 P99 지연 시간이 허용 가능한 범위 내에 있는지
    • 지연: 보조 인덱스 생성 지연 시간이 허용 가능한 범위 내에 있는지

섀도우 검증

  • 마이그레이션 전후의 응답을 비교하여 현재 트래픽이 데이터 마이그레이션 문제나 코드 버그로 인해 방해받지 않도록 함.
  • 섀도우 검증을 통해 백필이 최소 99.99% 완전하고 정확한지 확인했으며, 상한선은 99.9999%로 설정함.
  • 섀도우 검증은 LSG가 프로덕션 트래픽을 처리할 수 있는지 확인하고, 데이터 접근 코드에 대한 신뢰를 제공함.
  • 섀도우 검증은 현재 액세스 중인 데이터의 완전성과 정확성에 대한 신뢰를 제공함.

오프라인 검증 및 증분 백필

  • LSG의 전체 데이터를 DynamoDB의 데이터 덤프와 비교함.
  • 오프라인 검증은 데이터 백필이 올바르게 수행되었는지 확인하고, 전체 데이터를 다룸.
  • 오프라인 검증은 섀도우 검증과 함께 수행되어야 함.

백필 문제

  • 모든 백필은 위험함. Uber의 Apache Spark를 사용하여 백필을 수행함.
  • 문제 해결 방법:
    • 확장성: 작은 규모로 시작하여 점진적으로 확장함.
    • 증분 백필: 데이터를 작은 배치로 나누어 백필함.
    • 속도 제어: 백필 작업의 속도를 조절함.
    • 동적 속도 제어: 현재 시스템 상태를 모니터링하여 속도를 조절함.
    • 긴급 중지: 과부하가 의심될 경우 백필을 빠르게 중지할 수 있는 기능을 제공함.
    • 데이터 파일 크기: 데이터 덤프 파일 크기를 적절하게 유지함.
    • 내결함성: 데이터 품질/손상 문제를 처리함.
    • 로깅: 로그를 제한하여 로깅 인프라에 부담을 주지 않음.

위험 완화

  • 다양한 검증 및 백필 통계 데이터를 분석하고 LSG의 롤아웃을 보수적으로 진행함.
  • 초기에는 백필이 실패할 경우 DynamoDB에서 데이터를 가져오는 폴백을 사용함.
  • 폴백 로그를 확인하여 LSG에서 데이터가 실제로 누락되지 않았는지 확인함.

결론

  • 이 기사에서는 대규모 비즈니스에 중요한 원장 데이터를 한 데이터 저장소에서 다른 데이터 저장소로 마이그레이션하는 과정을 다루었음.
  • 마이그레이션 기준, 검증, 백필 문제 및 안전성 등 다양한 측면을 다루었음.
  • 2년 동안 중단이나 장애 없이 마이그레이션을 완료했음.

GN⁺의 의견

  • 데이터 마이그레이션의 중요성: 대규모 데이터 마이그레이션은 복잡하고 위험이 따르지만, 비용 절감과 시스템 단순화를 통해 장기적으로 큰 이점을 제공함.
  • 섀도우 검증의 유용성: 섀도우 검증은 실제 트래픽에 영향을 주지 않으면서 데이터의 완전성과 정확성을 확인할 수 있는 강력한 도구임.
  • 오프라인 검증의 필요성: 섀도우 검증만으로는 드러나지 않는 문제를 발견할 수 있기 때문에 오프라인 검증도 필수적임.
  • 백필의 단계적 접근: 백필 작업은 작은 배치로 나누어 단계적으로 수행하는 것이 시스템 과부하를 방지하는 데 효과적임.
  • 긴급 중지 기능: 백필 작업 중 문제가 발생할 경우 빠르게 중지할 수 있는 기능은 시스템 안정성을 유지하는 데 중요함.
▲
neo 6달전  [-]
Hacker News 의견

해커뉴스 댓글 모음 요약

  • 2 billion rides per quarter

    • Uber가 분기마다 20억 건의 라이드를 처리함. 이는 초당 약 1000건의 거래로 환산될 수 있음. 인프라 확장에 왜 그렇게 신경 쓰는지 이해하기 어려움.

  • Using DynamoDB poorly

    • Uber가 DynamoDB를 잘못 사용하고 있었음. 특정 중요한 사용자 여정(CUJ)에는 강력한 일관성이 필요하고, 과거 거래를 위한 데이터 웨어하우징이 필요함. DynamoDB와 Redshift 아키텍처로 전환하지 않은 것이 이상함.

  • Google rejects

    • Uber가 구글에서 실패한 프로젝트를 가져온 것 같음. 이런 프로젝트는 보통 큰 승진을 목표로 함. "자체 시스템 설계 및 구축으로 $Xm 절감! 승진해줘!" 같은 식으로. 하지만 구축 비용이 더 많이 들고, 몇 년 후에는 폐기될 가능성이 큼.

  • SQLite on a single server

    • 1.7 페타바이트의 데이터(1조 개의 인덱스된 레코드)를 한 대의 고성능 베어메탈 서버에 SQLite로 저장할 수 있을지 궁금함. 예시 링크 제공.

  • LedgerStore not open source

    • LedgerStore는 오픈 소스가 아님. 관련 정보를 찾으려면 Uber 블로그 게시물을 따라가야 함. 2021년 게시물 링크 제공.

  • Era of custom infrastructure

    • 2015년경 넷플릭스, 스포티파이, 사운드클라우드, 우버 등 많은 기술 회사들이 인프라와 데이터베이스 도구를 많이 구축했음. 요즘은 AWS/클라우드 용어로 이야기하는 엔지니어들이 많음. 여전히 도구를 구축하는 조직을 보는 것이 신선함.

  • Expensive proprietary cloud

    • 독점 클라우드 기반 데이터 저장소가 얼마나 비싼지 잘 보여주는 예시임. 다른 것으로 마이그레이션하는 것이 가능함.

  • Considered TigerBeetle?

    • TigerBeetle을 고려했는지 궁금함.

  • DynamoDB is expensive

    • 이 프로젝트의 경제성은 모르겠지만, DynamoDB는 정말 비쌈. 다른 사람들이 잘못 사용하고 있다고 생각했지만, 분산 해시 테이블로 사용해도 여전히 큰 비용이 듦.

  • Cost of running the team

    • 프로젝트 팀 운영 비용이 절감액(600만 달러)과 크게 다르지 않을 것 같음. 유지보수 비용도 추가됨. 결제 시스템은 장기적인 베팅이 아닐 가능성이 큼. 왜 이런 프로젝트를 진행하는지 흥미로움. 이미 있는 엔지니어링 팀과 관련된 매몰 비용일 수도 있음.
답변달기