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

> Clean Markdown view of GeekNews topic #14921. Use the original source for factual precision when an external source URL is present.

## Metadata

- GeekNews HTML: [https://news.hada.io/topic?id=14921](https://news.hada.io/topic?id=14921)
- GeekNews Markdown: [https://news.hada.io/topic/14921.md](https://news.hada.io/topic/14921.md)
- Type: GN+
- Author: [neo](https://news.hada.io/@neo)
- Published: 2024-05-21T09:50:46+09:00
- Updated: 2024-05-21T09:50:46+09:00
- Original source: [uber.com](https://www.uber.com/blog/migrating-from-dynamodb-to-ledgerstore/)
- Points: 2
- Comments: 1

## Topic Body

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

## Comments



### Comment 25411

- Author: neo
- Created: 2024-05-21T09:50:46+09:00
- Points: 1

###### [Hacker News 의견](https://news.ycombinator.com/item?id=40413891) 
##### 해커뉴스 댓글 모음 요약

* **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만 달러)과 크게 다르지 않을 것 같음. 유지보수 비용도 추가됨. 결제 시스템은 장기적인 베팅이 아닐 가능성이 큼. 왜 이런 프로젝트를 진행하는지 흥미로움. 이미 있는 엔지니어링 팀과 관련된 매몰 비용일 수도 있음.