Migrasi data ledger Uber dari DynamoDB ke LedgerStore

• Minggu lalu, Uber membahas LedgerStore (LSG), database bergaya ledger tambahan milik mereka.
• Minggu ini, pembahasan berfokus pada bagaimana Uber memigrasikan data ledger yang penting bagi bisnis mereka ke LSG.
• Dibahas bagaimana mereka memindahkan lebih dari 1 triliun entri (beberapa petabyte data) secara transparan tanpa gangguan, serta pelajaran yang didapat selama proses tersebut.

Sejarah

• Gulfstream adalah platform pembayaran Uber yang diluncurkan pada 2017 dengan menggunakan DynamoDB.
• Pada skala Uber, DynamoDB menjadi mahal, sehingga mereka mulai menyimpan hanya 12 minggu data (hot data) di DynamoDB dan menyimpan data lama (cold data) di TerraBlob, blobstore milik Uber.
• Sebagai solusi jangka panjang, mereka ingin menggunakan LSG. LSG dirancang khusus untuk menyimpan data bergaya pembayaran.
• Fitur utama LSG:
  • Immutability yang dapat diverifikasi (menggunakan tanda tangan kriptografis untuk memastikan catatan tidak diubah)
  • Penyimpanan bertingkat untuk pengelolaan biaya (hot data disimpan di tempat yang cocok untuk melayani request, cold data disimpan di tempat yang dioptimalkan untuk penyimpanan)
  • Peningkatan latensi secondary index yang pada akhirnya konsisten
• Hingga 2021, Gulfstream menyimpan data menggunakan kombinasi DynamoDB, TerraBlob, dan LSG.
  • DynamoDB: data 12 minggu terakhir
  • TerraBlob: cold data
  • LSG: tempat pencatatan data dan target migrasi

Mengapa perlu migrasi?

• LSG lebih cocok untuk menyimpan data bergaya ledger karena sifatnya yang immutable.
• Dengan berpindah ke LSG, penghematan biaya berulang yang diperoleh cukup besar.
• Beralih dari tiga storage ke satu storage dapat menyederhanakan kode dan desain layanan Gulfstream.
• LSG menjanjikan latensi indexing yang lebih singkat, dan karena berjalan on-premise di dalam data center Uber, ia juga memberikan latensi jaringan yang lebih cepat.

Risiko terkait karakteristik data

• Data yang dimigrasikan adalah seluruh data ledger bisnis Uber sejak 2017:
  • Catatan immutable: ukuran terkompresi 1.2 PB
  • Secondary index: ukuran tidak terkompresi 0.5 PB
• Catatan immutable tidak bisa dimodifikasi, sementara data secondary index memiliki fleksibilitas untuk diubah guna memperbaiki masalah.

Validasi

• Untuk memastikan backfill benar dan dapat diterima dalam segala aspek, perlu dipastikan bahwa sistem dapat menangani traffic saat ini dan bahwa data yang saat ini tidak diakses juga benar.
• Kriteria validasi:
  • Kelengkapan: apakah semua catatan sudah di-backfill
  • Akurasi: apakah semua catatan akurat
  • Beban: apakah LSG dapat menangani beban saat ini
  • Latensi: apakah latensi P99 LSG berada dalam rentang yang dapat diterima
  • Delay: apakah delay pembuatan secondary index berada dalam rentang yang dapat diterima

Shadow validation

• Respons sebelum dan sesudah migrasi dibandingkan untuk memastikan traffic saat ini tidak terganggu oleh masalah migrasi data atau bug kode.
• Melalui shadow validation, mereka memastikan backfill setidaknya 99.99% lengkap dan akurat, dengan batas atas ditetapkan pada 99.9999%.
• Shadow validation memverifikasi bahwa LSG dapat menangani traffic produksi dan memberi keyakinan pada kode akses data.
• Shadow validation memberi keyakinan terhadap kelengkapan dan akurasi data yang sedang diakses saat ini.

Validasi offline dan incremental backfill

• Seluruh data di LSG dibandingkan dengan dump data dari DynamoDB.
• Validasi offline memastikan bahwa backfill data telah dilakukan dengan benar dan mencakup keseluruhan data.
• Validasi offline harus dilakukan bersama shadow validation.

Masalah backfill

• Semua backfill memiliki risiko. Uber menjalankan backfill menggunakan Apache Spark.
• Cara mengatasi masalah:
  • Skalabilitas: mulai dari skala kecil lalu diperluas secara bertahap.
  • Incremental backfill: data dibagi ke dalam batch kecil untuk di-backfill.
  • Kontrol kecepatan: laju pekerjaan backfill diatur.
  • Kontrol kecepatan dinamis: kecepatan diatur dengan memantau kondisi sistem saat ini.
  • Emergency stop: menyediakan kemampuan untuk menghentikan backfill dengan cepat jika dicurigai terjadi overload.
  • Ukuran file data: menjaga ukuran file dump data tetap sesuai.
  • Fault tolerance: menangani masalah kualitas/kerusakan data.
  • Logging: membatasi log agar tidak membebani infrastruktur logging.

Mitigasi risiko

• Mereka menganalisis berbagai data statistik validasi dan backfill, lalu melakukan rollout LSG secara konservatif.
• Pada tahap awal, mereka menggunakan fallback untuk mengambil data dari DynamoDB jika backfill gagal.
• Dengan memeriksa log fallback, mereka memastikan bahwa data benar-benar tidak hilang di LSG.

Kesimpulan

• Artikel ini membahas proses migrasi data ledger yang sangat penting bagi bisnis dalam skala besar dari satu data store ke data store lainnya.
• Berbagai aspek dibahas, termasuk kriteria migrasi, validasi, masalah backfill, dan keamanan.
• Migrasi berhasil diselesaikan selama 2 tahun tanpa gangguan atau outage.

Opini GN⁺

• Pentingnya migrasi data: Migrasi data skala besar itu kompleks dan berisiko, tetapi dalam jangka panjang memberikan manfaat besar melalui penghematan biaya dan penyederhanaan sistem.
• Kegunaan shadow validation: Shadow validation adalah alat yang kuat untuk memverifikasi kelengkapan dan akurasi data tanpa memengaruhi traffic nyata.
• Pentingnya validasi offline: Validasi offline juga penting karena dapat menemukan masalah yang tidak terlihat hanya dengan shadow validation.
• Pendekatan bertahap untuk backfill: Membagi pekerjaan backfill ke dalam batch kecil dan melakukannya secara bertahap efektif untuk mencegah sistem kelebihan beban.
• Fitur emergency stop: Kemampuan untuk menghentikan pekerjaan backfill dengan cepat saat terjadi masalah penting untuk menjaga stabilitas sistem.

[GN⁺]

Komentar Hacker News

Ringkasan kumpulan komentar Hacker News

• 2 billion rides per quarter

  • Uber memproses 2 miliar perjalanan per kuartal. Ini bisa dikonversi menjadi sekitar 1000 transaksi per detik. Sulit memahami mengapa mereka begitu fokus pada penskalaan infrastruktur.

• Using DynamoDB poorly

  • Uber menggunakan DynamoDB dengan kurang tepat. Beberapa perjalanan pengguna penting (CUJ) memerlukan konsistensi kuat, dan dibutuhkan data warehousing untuk transaksi historis. Aneh bahwa mereka tidak beralih ke arsitektur DynamoDB dan Redshift.

• Google rejects

  • Uber tampaknya mengambil proyek yang gagal di Google. Proyek seperti ini biasanya ditujukan untuk promosi besar. Semacam, "Hemat $Xm dengan merancang dan membangun sistem sendiri! Tolong promosikan saya!" Namun biaya pembangunannya justru lebih besar, dan kemungkinan akan dibuang beberapa tahun kemudian.

• SQLite on a single server

  • Ada yang penasaran apakah 1,7 petabyte data (1 triliun record terindeks) bisa disimpan di SQLite pada satu server bare metal berperforma tinggi. Tautan contoh disertakan.

• LedgerStore not open source

  • LedgerStore bukan open source. Untuk menemukan informasi terkait, perlu menelusuri posting blog Uber. Tautan ke posting tahun 2021 disertakan.

• Era of custom infrastructure

  • Sekitar tahun 2015, banyak perusahaan teknologi seperti Netflix, Spotify, SoundCloud, dan Uber banyak membangun infrastruktur dan alat database mereka sendiri. Sekarang lebih banyak engineer yang berbicara dalam istilah AWS/cloud. Masih terasa segar melihat organisasi yang tetap membangun alat sendiri.

• Expensive proprietary cloud

  • Ini contoh yang jelas tentang betapa mahalnya penyimpanan data berbasis cloud proprietari. Migrasi ke sesuatu yang lain memang memungkinkan.

• Considered TigerBeetle?

  • Ada yang penasaran apakah mereka mempertimbangkan TigerBeetle.

• DynamoDB is expensive

  • Tidak yakin soal keekonomian proyek ini, tetapi DynamoDB memang sangat mahal. Saya pikir orang lain hanya menggunakannya dengan cara yang salah, tetapi bahkan ketika dipakai sebagai distributed hash table pun biayanya tetap besar.

• Cost of running the team

  • Biaya menjalankan tim proyek tampaknya tidak jauh berbeda dari penghematan yang diklaim (6 juta dolar). Ada juga biaya pemeliharaan tambahan. Sistem pembayaran mungkin bukan pertaruhan jangka panjang. Menarik mengapa proyek seperti ini dijalankan. Bisa jadi ini juga terkait sunk cost dari tim engineering yang sudah ada.