Terima kasih khusus kepada Özgür Karakaya yang bersama saya menulis postingan blog ini.

PDP (Halaman Detail Produk) di Trendyol adalah tim yang bertanggung jawab untuk memberikan informasi tentang produk tertentu. Informasi ini mencakup harga produk, ukuran, warna, atau informasi relevan lainnya yang ingin diketahui pelanggan sebelum melakukan pembelian. Informasi dapat disajikan dalam dua cara berbeda, yang pertama adalah dalam bentuk satu halaman detail produk, terutama saat Anda mengklik suatu produk dan diarahkan ke halaman yang menampilkan informasi produk tertentu. Tim juga bertanggung jawab untuk memberikan data detail produk ke tampilan lain di situs web, yaitu daftar favorit Anda, produk yang direkomendasikan, dan checkout. Kedua cara tersebut ditangani oleh satu layanan bernama Product Detail API yang didukung oleh database NoSQL couchbase yang melayani permintaan tunggal (halaman detail produk tunggal) serta permintaan dalam jumlah besar (daftar favorit, dll.).

Sebelum acara Black Friday 2021, tim telah menetapkan sasaran untuk menangani 8 juta Permintaan Per Menit untuk permintaan massal. Satu masalah adalah bahwa layanan tersebut berkinerja buruk dalam bentuk penggunaan memori yang meningkat dan sejumlah besar kesalahan saat menerima throughput yang tinggi. Tantangannya adalah mencari cara untuk mengoptimalkan layanan.

Jadi inilah perjalanannya.

Brainstorming & Analisis

Selama fase analisis, Tim PDP menemukan bahwa — berdasarkan domain — klien yang mengirim permintaan massal tidak menggunakan semua bidang dalam dokumen basis data. Poin pengoptimalan pertama adalah memperkenalkan model dokumen baru tanpa bidang yang tidak perlu tersebut. Keuntungan dari restrukturisasi ini adalah:

• optimalisasi ukuran data
• fokus domain konten massal

Di bawah ini adalah diagram arsitektur yang ada dan yang baru pada saat itu:

Kotak luar bertitik menentukan batas-batas layanan. Perhatikan bahwa dalam ilustrasi pertama ini, satu layanan bertanggung jawab untuk menangani seluruh alur operasi. Optimalisasi itu sendiri adalah untuk membagi pipa konversi menjadi dua proses terpisah seperti yang terlihat pada arsitektur kedua: Proses Konversi Waktu Indeks dan Layanan Konten Massal. Yang terakhir adalah layanan Baca yang menangani permintaan HTTP. Yang pertama ternyata merupakan proses yang digerakkan oleh peristiwa yang membaca data dari ProductContent CB (Source Of Truth), memproses sebagian, lalu menyimpannya di Counchbase Bucket untuk digunakan yang terakhir. Tapi lebih dari itu nanti.
Di bawah arsitektur baru yang diusulkan keuntungan utama adalah bahwa proses runtime akan dioptimalkan, yang pada gilirannya akan mengurangi waktu respon layanan.

Di blog ini, kami akan berfokus pada proses waktu Indeks. Untuk informasi lebih lanjut tentang "Layanan Konten Massal", periksa posting ini oleh Enes Turgut

PS Saya menggunakan istilah runtime di sini agak longgar. Dalam konteks blog ini, kami mendefinisikan runtime sebagai urutan operasi yang dipicu oleh permintaan HTTP yang masuk.

Solusi yang Ada

Sejauh ini tim telah menetapkan arsitektur baru. Sekarang saatnya untuk menerapkannya. Apa yang kami coba capai adalah solusi konversi couchbase-to-couchbase hampir real-time. Couchbase sudah menawarkan replikasi di seluruh cluster, namun, bentuk data perlu diubah sehingga replikasi normal jelas bukan cara yang tepat. Bukankah akan luar biasa jika ada cara untuk memanipulasi data selama proses replikasi? saat menelusuri dokumentasi Couchbase, kami menemukan Couchbase Eventing Service. Apakah kita baru saja mendapatkan jackpot?

Acara Couchbase:

Layanan Couchbase Eventing adalah kerangka kerja untuk beroperasi pada perubahan data secara real time. Peristiwa adalah perubahan pada data di cluster Couchbase

Couchbase Eventing tampaknya cocok untuk kami karena Anda dapat :

• Menyebarkan perubahan ke sistem lain
• Memperkaya dokumen secara real-time
• Tidak memerlukan perawatan

Tidak ada jackpot.

Solusi Kami (Konverter Data Konten Massal)

Terinspirasi oleh Konektor CB Elasticsearch .

Couchbase Elasticsearch Connector mereplikasi dokumen Anda dari Couchbase Server ke Elasticsearch hampir secara waktu nyata. Konektor menggunakan Protokol Perubahan Database (DCP) berkinerja tinggi untuk menerima pemberitahuan saat dokumen berubah di Couchbase.

Ganti Elasticsearch dengan Couchbase dan Anda mendapatkan apa yang kami butuhkan. Yang perlu kita lakukan hanyalah menerima mutasi dokumen (pembaruan) dari antrean DCP, memprosesnya, lalu menuliskannya ke dalam keranjang baru.

Ingatlah bahwa solusinya harus dapat:

• Skala seiring bertambahnya jumlah dokumen dan mutasi.
• Lakukan proses end-to-end (menerima pesan dari antrean, mengonversi model data, dan menulisnya ke dalam bucket baru) hampir secara real-time.
• Memanipulasi yang sudah ada dan bukan hanya dokumen baru saat bidang baru ditambahkan atau dihapus dari model dokumen.
• Menyediakan mekanisme untuk membuat ulang dokumen dari bawah ke atas jika terjadi kerusakan data yang parah.

Nah, banyak yang harus dibongkar di sini, mari kita rangkum dulu:

Arsitektur di atas menunjukkan solusi akhir. Pada akhirnya, Layanan Detail Produk akan menangani permintaan tunggal, sementara Layanan Konten Massal akan menangani permintaan secara massal. Layanan ini didukung oleh berbagai sumber couchbase. Sementara ProductContent CB mewakili Sumber Kebenaran, ProductSummary CB mewakili versi pra-pemrosesan yang diringkas. Konversi akan ditangani di Pengonversi Data Konten Massal hampir secara waktu nyata dengan menerima mutasi dokumen dari antrean DCP. Setiap mutasi dokumen mewakili keadaan dokumen setelah pembaruan terjadi. Ini adalah cara lain untuk mengatakan bahwa konverter akan secara otomatis mendapatkan seluruh dokumen yang diperbarui dari ProductContent CBpada setiap pembaruan.

Untuk memahami bagaimana solusi ini menskalakan dengan tepat, Anda harus melihat file konfigurasi konverter:

{
  "group": {
    "name": "v20220909", 
    "membership": {
      "memberNumber": 1, 
      "totalMembers": n
    },
    "limit": {
      "bytes": "5m",
      "actions": 100,
      "timeout": "1m",
      "concurrency": 2
    },
    "version": 1,
    "ignoreDelete": false
  },
  "dcp": {
    "sourceConfig": {
      "hosts": ["source_couchbase_host"],
      "network": "auto",
      "bucket": "bucketName",
      "metadataBucket": "metadataBucketName",
      "scope": "",
      "collections": [],
      "compression": true,
      "flowControlBuffer": "16m",
      "persistencePollingInterval": "100ms"
    },
    "targetConfig": {
      "hosts": ["taget_couchbase_host"],
      "bucket": "targetBucketName"
    }
  }
}

Bagian penting lainnya dari konfigurasi adalah group.name yang mewakili grup konsumen tempat offset disimpan, pikirkan seperti grup konsumen Kafka. Mengubah konfigurasi ini akan menyetel ulang indeks offset yang berarti seluruh status database akan dikirim melalui antrean DCP. Ini sangat praktis ketika pembaruan pada model dokumen diperlukan, menambah atau menghapus bidang baru dari keranjang target memerlukan seluruh pembaruan pada semua dokumen yang disimpan, ini termasuk dokumen yang biasanya tidak diperbarui di keranjang target. karena tidak akan terjadi mutasi pada dokumen sumber. Itu juga dapat berfungsi sebagai seluruh mekanisme regenerasi basis data jika terjadi kerusakan data yang parah.

Untuk informasi lebih lanjut tentang konfigurasi, silakan periksa tautan dokumentasi .

Poin pengoptimalan lainnya adalah mengurangi ukuran dokumen target dengan memiliki singkatan atau karakter tunggal sebagai node JSON. Pakar domain dan PM tidak diharapkan untuk memahami dokumen ini dan inilah mengapa kami dapat lolos dari peretasan jahat seperti itu. Di bawah ini adalah contoh dokumennya:

Dan pada tanggal 31 Oktober, hasilnya adalah…

Peretasan sederhana ini memungkinkan kami mengurangi ukuran Bucket dari 2,92 TB menjadi 595 GB! Pengurangan ukuran pukulan sekitar 80%!
Orang juga harus memperhatikan bahwa jumlah dokumen dalam DB target berkurang sekitar 12 juta. Alasannya adalah kami mengecualikan produk yang kehabisan stok yang belum diperbarui selama 12 bulan. Di keranjang sumber, kami mungkin masih membutuhkan dokumen-dokumen itu tetapi tidak masuk akal untuk memilikinya di sini, oleh karena itu hitungannya berbeda.

Pemantauan & Kinerja

Sejauh ini kami memiliki solusi dan berjalan. Tapi bagaimana tepatnya kita bisa tahu apakah itu cukup berkinerja? bagaimana jika, secara hipotetis, melakukan konversi tetapi tertinggal, katakanlah, 2 detik di belakang? Itu akan menjadi bencana total! konsistensi akhirnya seperti itu akan bocor ke UI situs web dan sangat memengaruhi pengalaman pengguna. Memicu perubahan pada basis data produksi secara manual tidak mungkin dan seharusnya tidak menjadi cara untuk menguji sejak awal. Pendekatan sistematis diperlukan untuk menentukan sumber kelambatan jika itu terjadi. Apakah lag terjadi karena kemacetan di antrian DCP? Atau karena konverter memiliki semacam bug?

Untuk menjawab pertanyaan ini kami memperkenalkan tiga metrik seperti yang ditunjukkan pada gambar di bawah ini:

Dokumen sumber berisi stempel waktu pembaruan terakhir, kami menyebutnya LMD (Tanggal Modifikasi Terakhir). Setelah mutasi diterima oleh konverter, “ Waiting in DCP queue” Waktu dapat dihitung dengan mudah dengan mengurangkan LMD dari time.now() . Metrik kemudian diekspos ke Prometheus seperti yang ditunjukkan pada grafik di bawah ini:

Keterbatasan:

Ingat ketika saya mengatakan sebelumnya bahwa penskalaan hanyalah masalah meningkatkan jumlah konverter? Nah, ini datang dengan sedikit peringatan: Konfigurasi solusinya sedikit terprogram dengan infrastruktur yang digunakannya; Penyeimbangan ulang otomatis konsumen pada antrean DCP dan distribusi konsumen di seluruh vBuckets terhubung ke konfigurasi statis yang dimiliki konsumen saat memulai. Untuk mengubahnya, seseorang perlu mengubah file konfigurasi itu sendiri yang memerlukan penerapan baru. Selain itu, setiap konsumen memerlukan file konfigurasi statisnya sendiri yang berarti setiap konsumen perlu — dalam terminologi Kubernetes — untuk memiliki file sumber daya penerapannya sendiri. Di Trendyol kami banyak menggunakan ArgoCD dengan Kustomize untuk mengelola penerapan kami, penskalaan solusi memerlukan penambahan — dalam terminologi ArgoCD — ApplicationSet baru.
Namun, sejauh ini skala 8 konsumen kami menangani beban besar dengan efisiensi waktu nyata. Tetapi karena keranjang sumber semakin besar dan jumlah mutasi bertambah, maka diperlukan konfigurasi ulang konsumen secara manual.

Penggunaan Tim Lain In-House

Merasa yakin dengan konektor CB-ke-CB yang dikembangkan, Tim PDP memutuskan untuk mempresentasikannya ke tim lain dalam Trendyol. Tim mendapat banyak umpan balik positif, dan sebelum kami menyadarinya, Tim Pencarian memutuskan untuk memotong proyek dan menggunakannya di domain mereka tempat mereka menyimpan peristiwa domain di basis data sofa dan menggunakan konektor CB-ke-CB untuk menghasilkan model dokumen lain untuk digunakan nanti. Adopsi solusi yang dikembangkan In-House menginspirasi kita semua untuk bergerak maju dan terus meningkatkan dan menyempurnakan penggunaan teknologi kita.

Terapkan untuk posisi terbuka kami di sini !