- Stripe mempertahankan uptime 99,999% sambil memproses total volume pembayaran sebesar 1 triliun dolar pada 2023
- Tim infrastruktur database Stripe menyediakan DocDB, sebuah database as a service (DBaaS), sebagai lapisan dasar untuk API
- DocDB adalah versi yang diperluas dari MongoDB Community, yang terdiri dari berbagai layanan yang dibangun secara internal di Stripe
- Menangani lebih dari 5 juta kueri per detik, dan menyimpan data finansial penting berskala petabyte yang didistribusikan ke lebih dari 2.000 shard database dan disimpan dalam lebih dari 5.000 collection
- Alasan memilih MongoDB Community adalah karena fleksibilitas model dokumennya dan kemampuannya menangani data real-time dalam skala besar
- Pada 2011, MongoDB Atlas belum ada, jadi Stripe membangun klaster instance MongoDB self-managed yang berjalan di cloud
- Inti dari DocDB adalah Data Movement Platform
- Awalnya dibangun sebagai solusi scale-out horizontal untuk mengatasi batas scale-up vertikal MongoDB, tetapi kemudian dikustomisasi untuk berbagai tujuan
- Termasuk menggabungkan shard database yang tidak terpakai untuk meningkatkan utilisasi dan efisiensi, upgrade major version engine database untuk meningkatkan keandalan, serta transisi dari multi-tenant ke single-tenant bagi pengguna besar
- Data Movement Platform memungkinkan perpindahan dari sejumlah kecil shard database berukuran besar ke banyak shard database berukuran kecil
- Platform ini juga menyediakan migrasi yang transparan bagi klien dan zero downtime, sehingga memungkinkan penyediaan DBaaS yang sangat elastis
- DocDB dapat membagi shard database saat lalu lintas melonjak, dan saat trafik rendah dapat mengonsolidasikan ribuan database melalui bin packing
Cara membangun infrastruktur database
- Saat peluncuran pada 2011, Stripe memilih MongoDB sebagai database online karena produktivitas pengembangnya lebih tinggi dibanding database relasional standar
- Stripe ingin menjalankan infrastruktur database yang kokoh di atas MongoDB dengan memprioritaskan stabilitas API, tetapi tidak menemukan DBaaS siap pakai yang memenuhi kebutuhannya
- Memenuhi standar tertinggi untuk availability, durability, dan performance
- Mengekspos fitur database seminimal mungkin untuk mencegah masalah yang berasal dari kueri aplikasi klien yang tidak dioptimalkan
- Mendukung skalabilitas horizontal melalui sharding
- Menyediakan dukungan kelas satu untuk multi-tenancy dengan kuota yang ditegakkan
- Menyediakan keamanan kuat melalui penegakan kebijakan otorisasi
- Solusinya adalah membangun DocDB dengan MongoDB sebagai storage engine dasar—sebuah DBaaS yang benar-benar elastis dan skalabel, dengan migrasi data online sebagai inti
- Aplikasi produk Stripe mengakses data database melalui armada server proxy database yang dikembangkan secara internal dengan Go untuk menegakkan masalah reliabilitas, skalabilitas, kontrol izin, dan kontrol akses
- Di sinilah diambil keputusan arsitektural penting untuk menggunakan sharding sebagai mekanisme scale-out horizontal
- Ribuan shard database yang masing-masing menyimpan potongan kecil data akumulatif kini menjadi fondasi semua produk Stripe
- Saat aplikasi mengirim kueri ke server proxy database, proxy akan mem-parsing kueri, mengarahkannya ke satu atau lebih shard, lalu menggabungkan hasil dari shard dan mengembalikannya ke aplikasi
- Server proxy database mengandalkan layanan metadata chunk untuk memetakan chunk ke shard database, sehingga shard yang relevan untuk suatu kueri dapat dicari dengan mudah
- Event perubahan akibat write ke database dikirim ke sistem perangkat lunak streaming, lalu akhirnya disimpan di object storage melalui pipeline change data capture (CDC)
- Tim Stripe memprovisikan kontainer logis data yang disebut logical database, yang mencakup satu atau lebih collection DocDB berisi dokumen dengan tujuan terkait, menggunakan control plane database dokumen internal di tingkat aplikasi produk
- Data dalam collection DocDB ini didistribusikan ke beberapa database (database fisik) yang masing-masing menyimpan chunk kecil dari collection tersebut
- Database fisik DocDB berada pada shard yang di-deploy sebagai replica set yang terdiri dari node primary dan beberapa node secondary dengan replikasi serta automatic failover
Cara merancang Data Movement Platform
- Untuk membangun produk DBaaS yang dapat diskalakan secara horizontal dan sangat elastis, yang bisa scale up dan scale down sesuai kebutuhan aplikasi produk, dibutuhkan kemampuan untuk memigrasikan data antar-shard database dengan zero downtime secara transparan bagi klien
- Ini adalah masalah sistem terdistribusi yang kompleks, dan menjadi lebih rumit karena kebutuhan unik data finansial yang sangat penting
- Konsistensi dan integritas data: Harus dipastikan bahwa data yang dimigrasikan tetap konsisten dan utuh baik di shard sumber maupun shard target
- Ketersediaan: Downtime berkepanjangan selama migrasi data tidak dapat diterima, karena jutaan bisnis bergantung pada Stripe untuk menerima pembayaran pelanggan 24 jam sehari
- Tujuannya adalah menjaga langkah inti proses migrasi lebih singkat daripada waktu failover primary database yang direncanakan (biasanya beberapa detik), dan menyesuaikannya dengan anggaran retry aplikasi produk
- Granularitas dan adaptabilitas: Pada skala Stripe, harus dimungkinkan memigrasikan sejumlah chunk data secara arbitrer dari sejumlah sumber secara arbitrer ke shard target
- Tidak boleh ada batasan pada jumlah migrasi chunk database yang sedang berlangsung di dalam fleet, maupun jumlah migrasi yang dapat melibatkan shard tertentu pada saat tertentu
- Selain itu, karena sebagian besar shard database memuat data berskala terabyte, chunk dengan berbagai ukuran harus dapat dimigrasikan dengan throughput tinggi
- Tanpa dampak performa pada shard sumber: Saat memigrasikan chunk database antar-shard, tujuannya adalah menjaga performa dan throughput shard sumber agar tidak berdampak negatif pada performa dan throughput yang tersedia untuk kueri pengguna
- Untuk memenuhi kebutuhan ini, Stripe membangun platform perpindahan data yang memanggil layanan purpose-built guna mengelola migrasi data online antar-shard database
- Komponen Coordinator dalam platform perpindahan data bertanggung jawab mengorkestrasi berbagai langkah yang terkait dengan migrasi data online, dan memanggil layanan terkait untuk menjalankan tiap tahap konfigurasi yang dijelaskan di bawah
Langkah 1: Mendaftarkan migrasi chunk
- Pertama, intent untuk memigrasikan chunk database dari shard sumber ke shard target arbitrer didaftarkan di layanan metadata chunk
- Setelah itu, index dibangun pada shard target untuk chunk yang sedang dimigrasikan
Langkah 2: Import data massal
- Berikutnya, data dimuat ke satu atau lebih shard database menggunakan snapshot chunk shard sumber pada waktu T
- Layanan yang melakukan import data massal mendukung berbagai filter data, dan hanya mengimpor chunk data yang memenuhi kriteria filter
- Awalnya terlihat sederhana, tetapi Stripe menghadapi batas throughput saat memuat data secara massal ke shard DocDB
- Mereka mencoba melakukan batch pada write dan menyesuaikan parameter engine DocDB untuk intake data massal yang optimal, tetapi tidak terlalu berhasil
- Namun, terobosan besar terjadi ketika mereka memanfaatkan fakta bahwa DocDB menggunakan struktur data B-tree untuk mengurutkan data, lalu mencari cara mengoptimalkan urutan insert
- Dengan mengurutkan data berdasarkan properti index yang paling umum dalam collection dan meng-insert-nya dalam urutan yang telah diurutkan, mereka sangat meningkatkan locality write dan menaikkan throughput write hingga 10x
Langkah 3: Replikasi asinkron
- Setelah data diimpor ke shard target, replikasi write dari shard sumber ke shard target dimulai untuk chunk database yang sedang dimigrasikan, mulai dari waktu T
- Sistem replikasi asinkron membaca perubahan yang berasal dari write ke shard sumber dalam sistem CDC dan mengeksekusi write ke shard target
- Operation log atau oplog adalah collection khusus di setiap shard DocDB yang menyimpan catatan semua operasi yang mengubah data dalam database shard tersebut
- Oplog dari semua shard DocDB dikirim ke Kafka, platform event streaming, lalu diarsipkan ke layanan cloud object storage seperti Amazon S3
- Stripe membangun layanan yang mereplikasi perubahan dari satu atau lebih shard sumber DocDB ke satu atau lebih shard target DocDB menggunakan event oplog dari Kafka dan Amazon S3
- Dengan mengandalkan event oplog dari sistem CDC, mereka menghindari konsumsi throughput baca yang seharusnya tersedia untuk kueri pengguna di shard sumber, sehingga tidak memperlambat kueri pengguna dan tidak terkendala oleh ukuran oplog shard sumber
- Layanan ini dirancang tetap elastis bahkan jika shard target tidak tersedia, serta dapat memulai sinkronisasi, menjeda, dan melanjutkannya kapan saja dari checkpoint
- Layanan replikasi juga menyediakan kemampuan untuk mengambil replication lag
- Perubahan pada chunk yang sedang dimigrasikan direplikasi dua arah dari shard sumber ke shard target dan sebaliknya, dan layanan replikasi memberi tag pada write yang diterbitkannya untuk mencegah replikasi asinkron sirkular
- Ini adalah pilihan desain yang disengaja untuk memberi fleksibilitas mengembalikan trafik ke shard sumber jika terjadi masalah saat trafik diarahkan ke shard target
Langkah 4: Verifikasi akurasi
- Setelah replikasi antara shard sumber dan shard target sinkron, Stripe melakukan verifikasi menyeluruh atas integritas dan akurasi data dengan membandingkan snapshot point-in-time
- Ini adalah pilihan desain yang sengaja diambil agar tidak memengaruhi throughput shard
Langkah 5: Pengalihan trafik
- Setelah data chunk diimpor dari sumber ke shard target dan perubahan direplikasi secara aktif, pengalihan trafik diorkestrasi oleh Coordinator
- Untuk mengarahkan ulang jalur baca dan tulis untuk chunk data yang sedang dimigrasikan, trafik ke shard sumber terlebih dahulu dijeda sebentar, rute di layanan metadata chunk diperbarui, lalu server proxy harus mengarahkan baca dan tulis ke shard target
- Protokol pengalihan trafik didasarkan pada gagasan version gating
- Dalam steady state, setiap server proxy menambahkan nomor version token pada request ke shard DocDB
- Stripe menambahkan patch kustom ke MongoDB agar shard dapat memeriksa apakah nomor version token pada request dari server proxy lebih baru daripada nomor version token yang diketahuinya, dan hanya memproses request yang memenuhi kriteria ini
- Untuk memperbarui rute chunk, Coordinator menjalankan langkah-langkah berikut:
- Pertama, menaikkan nomor version token pada shard sumber DocDB. Nomor version token disimpan dalam dokumen di collection khusus DocDB, dan pada titik ini semua read dan write untuk chunk di shard sumber akan ditolak
- Lalu menunggu hingga layanan replikasi mereplikasi semua write yang masih tertunda dari shard sumber
- Terakhir, memperbarui rute chunk di layanan metadata chunk agar menunjuk ke shard target dan nomor version token tersebut
- Setelah selesai, server proxy mengambil rute chunk yang telah diperbarui beserta nomor version token terbaru dari layanan metadata chunk
- Server proxy kemudian menggunakan rute chunk yang telah diperbarui untuk mengarahkan read dan write untuk chunk tersebut ke shard target
- Seluruh protokol pengalihan trafik membutuhkan waktu kurang dari 2 detik untuk dijalankan, dan semua read serta write yang gagal saat dikirim ke shard sumber akan berhasil saat di-retry
Langkah 6: Membatalkan pendaftaran migrasi chunk
- Terakhir, migrasi ditandai selesai di layanan metadata chunk dan data chunk dihapus dari shard sumber untuk mengakhiri proses migrasi
Pemanfaatan platform perpindahan data
- Kemampuan memigrasikan chunk data secara online antar-shard DocDB membantu Stripe menskalakan infrastruktur databasenya secara horizontal seiring laju pertumbuhan perusahaan
- Engineer di tim infrastruktur database dapat membagi shard DocDB hanya dengan klik tombol berdasarkan ukuran dan throughput, sehingga menciptakan ruang kapasitas storage dan throughput database untuk tim produk
- Pada 2023, Stripe meningkatkan utilisasi infrastruktur databasenya menggunakan platform perpindahan data
- Secara spesifik, mereka memigrasikan 1,5 petabyte data secara transparan bagi aplikasi produk untuk melakukan bin-pack ribuan database yang kurang dimanfaatkan, dan mengurangi total shard DocDB dasar hingga sekitar tiga perempat dari jumlah sebelumnya
- Mereka juga menggunakan platform perpindahan data untuk meng-upgrade fleet infrastruktur database dengan forklifting data ke versi MongoDB yang lebih baru dalam satu langkah, tanpa melalui major maupun minor version perantara
- Tim infrastruktur database Stripe berfokus membangun fondasi yang kokoh dan andal, yang dapat berkembang seiring pertumbuhan ekonomi internet
- Saat ini mereka sedang membuat prototipe sistem heat management yang secara proaktif menyeimbangkan data antar-shard berdasarkan ukuran dan throughput, serta berinvestasi pada auto-scaling shard yang secara dinamis merespons perubahan pola trafik
Belum ada komentar.