Kita semua menyukai cerita. Kami suka duduk di sekitar api unggun dan berbicara tentang kemenangan, perjuangan, atau sekadar pengalaman kerja kami di masa lalu.
Hari ini adalah hari yang seperti itu. Dan bahkan jika Anda tidak sedang berada di dekat api saat ini, kami punya cerita untuk Anda. Kisah bagaimana kami mulai bekerja dengan penyimpanan di Tarantool.
Dahulu kala, perusahaan kami memiliki beberapa "monolit" dan satu "langit-langit" untuk semua, di mana monolit ini perlahan tapi pasti mendekat, membatasi pergerakan perusahaan kami, perkembangan kami. Dan ada pemahaman yang jelas: suatu hari kita akan mencapai batas ini dengan keras.
Saat ini, ideologi yang berlaku adalah memisahkan segalanya dan semua orang, mulai dari peralatan hingga logika bisnis. Sebagai contoh, kita mempunyai dua DC yang secara praktis independen pada tingkat jaringan. Dan kemudian segalanya menjadi sangat berbeda.
Saat ini sudah banyak sekali tools dan alat untuk melakukan perubahan baik berupa CI/CD, K8S, dll. Di masa “monolitik”, kita tidak membutuhkan begitu banyak kata asing. Cukup dengan memperbaiki “penyimpanan” di database.
Namun waktu terus bergerak maju, dan jumlah permintaan pun ikut bergerak maju, terkadang menghasilkan RPS di luar kemampuan kami. Dengan masuknya negara-negara CIS ke pasar, beban pada prosesor database monolit pertama tidak turun di bawah 90%, dan RPS tetap di level 2400. Dan ini bukan hanya penyeleksi kecil, tetapi permintaan besar dan kuat dengan sejumlah besar sekumpulan pemeriksaan dan GABUNG yang dapat menjalankan hampir setengah data dengan latar belakang IO besar.
Ketika penjualan penuh Black Friday mulai terlihat - dan Wildberry adalah salah satu yang pertama mengadakannya di Rusia - situasinya menjadi sangat menyedihkan. Memang, beban pada hari-hari seperti itu meningkat tiga kali lipat.
Oh, “masa monolitik” ini! Saya yakin Anda pernah mengalami hal serupa, dan Anda masih tidak mengerti bagaimana hal ini bisa terjadi pada Anda.
Apa yang bisa Anda lakukan - fashion melekat pada teknologi. Sekitar 5 tahun yang lalu, kami harus memikirkan kembali salah satu mod ini dalam bentuk situs yang ada di .NET dan server MS SQL, yang dengan hati-hati menyimpan seluruh logika situs itu sendiri. Saya menyimpannya dengan sangat hati-hati sehingga melihat monolit seperti itu ternyata merupakan kesenangan yang lama dan sama sekali tidak mudah.
Penyimpangan kecil.
Di berbagai acara saya berkata: “jika Anda tidak melihat monolit, maka Anda tidak tumbuh!” Saya tertarik dengan pendapat Anda tentang masalah ini, silakan tulis di komentar.
Suara Guntur
Mari kita kembali ke "api unggun" kita. Untuk mendistribusikan beban fungsionalitas “monolitik”, kami memutuskan untuk membagi sistem menjadi layanan mikro berdasarkan teknologi sumber terbuka. Karena, setidaknya, skalanya lebih murah. Dan kami memiliki pemahaman 100% bahwa kami harus melakukan peningkatan (dan banyak lagi). Memang, pada saat itu sudah dimungkinkan untuk memasuki pasar negara-negara tetangga, dan jumlah pendaftaran, serta jumlah pesanan, mulai tumbuh semakin kuat.
Setelah menganalisis kandidat pertama untuk beralih dari monolit ke layanan mikro, kami menyadari bahwa 80% tulisan di dalamnya berasal dari sistem back office, dan pembacaan dari front office. Pertama-tama, ini menyangkut beberapa subsistem penting bagi kami - data pengguna dan sistem untuk menghitung harga pokok barang berdasarkan informasi tentang diskon dan kupon pelanggan tambahan.
Bertakuk. Menakutkan untuk dibayangkan sekarang, tetapi selain subsistem yang disebutkan di atas, katalog produk, keranjang belanja pengguna, sistem pencarian produk, sistem pemfilteran katalog produk, dan berbagai jenis sistem rekomendasi juga telah dihapus dari monolit kami. Untuk pengoperasian masing-masing dari mereka, ada kelas-kelas terpisah dari sistem yang dirancang secara sempit, tetapi pada suatu waktu mereka semua tinggal di satu “rumah”.
Kami segera berencana untuk mentransfer data tentang klien kami ke sistem sharded. Penghapusan fungsionalitas untuk menghitung harga pokok akhir memerlukan skalabilitas yang baik untuk membaca, karena ini menciptakan beban RPS terbesar dan paling sulit diterapkan untuk database (banyak data yang terlibat dalam proses perhitungan).
Hasilnya, kami menemukan skema yang cocok dengan Tarantool.
Pada saat itu, untuk pengoperasian layanan mikro, skema untuk bekerja dengan beberapa pusat data pada mesin virtual dan perangkat keras dipilih. Seperti yang ditunjukkan pada gambar, opsi replikasi Tarantool diterapkan dalam mode master-master dan master-slave.
Arsitektur. Opsi 1. Layanan pengguna
Saat ini, terdapat 24 shard, masing-masing memiliki 2 instance (satu untuk setiap DC), semuanya dalam mode master-master.
Di atas database terdapat aplikasi yang mengakses replika database. Aplikasi bekerja dengan Tarantool melalui perpustakaan khusus kami, yang mengimplementasikan antarmuka driver Tarantool Go. Dia melihat semua replika dan dapat bekerja dengan masternya untuk membaca dan menulis. Pada dasarnya, ini mengimplementasikan model kumpulan replika, yang menambahkan logika untuk memilih replika, melakukan percobaan ulang, pemutus sirkuit, dan batas kecepatan.
Dalam hal ini, dimungkinkan untuk mengonfigurasi kebijakan pemilihan replika dalam konteks pecahan. Misalnya, roundrobin.
Arsitektur. Opsi 2. Layanan untuk menghitung harga pokok barang
Beberapa bulan yang lalu, sebagian besar permintaan untuk menghitung harga pokok akhir barang masuk ke layanan baru, yang pada prinsipnya bekerja tanpa database, tetapi beberapa waktu lalu semuanya diproses 100% oleh layanan dengan Tarantool di bawah tenda.
Basis data layanan terdiri dari 4 master tempat sinkronisasi mengumpulkan data, dan masing-masing master replikasi ini mendistribusikan data ke replika hanya baca. Setiap master memiliki sekitar 15 replika tersebut.
Baik pada skema pertama atau kedua, jika satu DC tidak tersedia, aplikasi dapat menerima data pada skema kedua.
Perlu dicatat bahwa replikasi di Tarantool cukup fleksibel dan dapat dikonfigurasi saat runtime. Di sistem lain, kesulitan muncul. Misalnya, mengubah parameter max_wal_senders dan max_replication_slots di PostgreSQL memerlukan restart wizard, yang dalam beberapa kasus dapat menyebabkan terputusnya koneksi antara aplikasi dan DBMS.
Cari dan temukan!
Mengapa kita tidak melakukannya “seperti orang normal”, tetapi memilih cara yang tidak biasa? Itu tergantung pada apa yang dianggap normal. Banyak orang umumnya membuat cluster dari Mongo dan menyebarkannya ke tiga DC yang terdistribusi secara geografis.
Saat itu, kami sudah memiliki dua proyek Redis. Yang pertama adalah cache, dan yang kedua adalah penyimpanan persisten untuk data yang tidak terlalu penting. Itu cukup sulit dengannya, sebagian karena kesalahan kami. Terkadang ada volume yang cukup besar di kuncinya, dan dari waktu ke waktu situs menjadi tidak sehat. Kami menggunakan sistem ini dalam versi master-slave. Dan ada banyak kasus di mana sesuatu terjadi pada master dan replikasinya terhenti.
Artinya, Redis cocok untuk tugas-tugas tanpa kewarganegaraan, bukan tugas-tugas berstatus. Pada prinsipnya, ini memungkinkan penyelesaian sebagian besar masalah, tetapi hanya jika masalah tersebut merupakan solusi nilai kunci dengan sepasang indeks. Namun Redis saat itu cukup sedih dengan kegigihan dan replikasinya. Selain itu, ada keluhan mengenai kinerja.
Kami memikirkan tentang MySQL dan PostgreSQL. Namun yang pertama entah bagaimana tidak menarik bagi kami, dan yang kedua adalah produk yang cukup canggih, dan tidak pantas untuk membangun layanan sederhana di atasnya.
Kami mencoba RIAK, Cassandra, bahkan database grafik. Ini semua adalah solusi khusus yang tidak cocok untuk peran alat universal umum untuk menciptakan layanan.
Akhirnya kami memilih Tarantool.
Kami menggunakannya saat masih dalam versi 1.6. Kami tertarik padanya karena simbiosis nilai kunci dan fungsionalitas database relasional. Ada indeks sekunder, transaksi dan spasi, ini seperti tabel, tetapi tidak sederhana, Anda dapat menyimpan jumlah kolom yang berbeda di dalamnya. Namun fitur mematikan Tarantool adalah indeks sekunder yang dikombinasikan dengan nilai kunci dan transaksionalitas.
Komunitas berbahasa Rusia yang responsif dan siap membantu dalam obrolan juga berperan. Kami aktif menggunakan ini dan langsung mengobrol. Dan jangan lupa tentang kegigihan yang layak tanpa kesalahan dan kesalahan yang jelas. Jika Anda melihat sejarah kami dengan Tarantool, kami mengalami banyak kesulitan dan kegagalan dalam replikasi, tetapi kami tidak pernah kehilangan data karena kesalahannya!
Implementasinya dimulai dengan awal yang buruk
Pada saat itu, tumpukan pengembangan utama kami adalah .NET, yang tidak memiliki konektor untuk Tarantool. Kami segera mulai melakukan sesuatu di Go. Ini juga bekerja dengan baik pada Lua. Masalah utama pada saat itu adalah dengan debugging: di .NET semuanya baik-baik saja dengan ini, tetapi setelah itu sulit untuk terjun ke dunia Lua yang tertanam, ketika Anda tidak memiliki debugging kecuali log. Selain itu, karena alasan tertentu, replikasi gagal secara berkala, jadi saya harus mempelajari struktur mesin Tarantool. Obrolan membantu dalam hal ini, dan pada tingkat lebih rendah, dokumentasi; terkadang kami melihat kodenya. Saat itu, dokumentasinya biasa-biasa saja.
Jadi, selama beberapa bulan, saya berhasil mendapatkan hasil yang layak dari bekerja dengan Tarantool. Kami mengumpulkan referensi perkembangan di git yang membantu pembentukan layanan mikro baru. Misalnya, ketika muncul tugas: untuk membuat layanan mikro lain, pengembang melihat kode sumber solusi referensi di repositori, dan tidak lebih dari seminggu untuk membuat yang baru.
Ini adalah saat-saat yang istimewa. Secara konvensional, Anda dapat menemui admin di meja berikutnya dan bertanya: “Beri saya mesin virtual.” Sekitar tiga puluh menit kemudian mobil itu sudah bersamamu. Anda menghubungkan diri Anda sendiri, menginstal semuanya, dan lalu lintas dikirimkan kepada Anda.
Saat ini hal ini tidak lagi berfungsi: Anda perlu menambahkan pemantauan dan logging ke layanan, mencakup fungsionalitas dengan pengujian, memesan mesin virtual atau pengiriman ke Kuber, dll. Secara umum, cara ini akan lebih baik, meskipun akan memakan waktu lebih lama dan lebih merepotkan.
Bagilah dan kuasai. Ada apa dengan Lua?
Terdapat dilema yang serius: beberapa tim tidak dapat menerapkan perubahan pada layanan dengan banyak logika di Lua. Hal ini sering kali disertai dengan layanan yang tidak berfungsi.
Artinya, para pengembang sedang mempersiapkan semacam perubahan. Tarantool mulai melakukan migrasi, tetapi replikanya masih dengan kode lama; Beberapa DDL atau sesuatu yang lain tiba di sana melalui replikasi, dan kodenya berantakan karena tidak diperhitungkan. Hasilnya, prosedur pembaruan untuk administrator dituangkan pada lembar A4: hentikan replikasi, perbarui ini, aktifkan replikasi, matikan di sini, perbarui di sana. Mimpi buruk!
Sebagai hasilnya, sekarang kita paling sering mencoba untuk tidak melakukan apa pun di Lua. Cukup gunakan iproto (protokol biner untuk berinteraksi dengan server), dan selesai. Mungkin ini karena kurangnya pengetahuan di kalangan pengembang, tetapi dari sudut pandang ini sistemnya rumit.
Kami tidak selalu mengikuti skrip ini begitu saja. Saat ini kita tidak memiliki warna hitam dan putih: semuanya ada di Lua, atau semuanya ada di Go. Kita sudah paham bagaimana cara menggabungkannya agar tidak terjadi masalah migrasi nantinya.
Dimana Tarantool sekarang?
Tarantool digunakan dalam layanan untuk menghitung harga pokok akhir barang dengan memperhitungkan kupon diskon, juga dikenal sebagai "Promotor". Seperti yang saya katakan sebelumnya, dia sekarang pensiun: dia digantikan oleh layanan katalog baru dengan harga yang telah dihitung sebelumnya, tetapi enam bulan lalu semua perhitungan dilakukan di Promotizer. Sebelumnya, setengah dari logikanya ditulis dalam Lua. Dua tahun lalu, layanan ini diubah menjadi fasilitas penyimpanan, dan logikanya ditulis ulang di Go, karena mekanisme diskon sedikit berubah dan kinerja layanan kurang.
Salah satu layanan paling penting adalah profil pengguna. Artinya, semua pengguna Wildberry disimpan di Tarantool, dan ada sekitar 50 juta di antaranya.Sebuah sistem yang dibagi berdasarkan ID pengguna, didistribusikan ke beberapa DC yang terhubung ke layanan Go.
Menurut RPS, Promotor pernah menjadi yang terdepan, mencapai 6 ribu permintaan. Pada satu titik kami memiliki 50-60 eksemplar. Sekarang pemimpin dalam RPS adalah profil pengguna, sekitar 12 ribu Layanan ini menggunakan sharding khusus, dibagi berdasarkan rentang ID pengguna. Layanan ini melayani lebih dari 20 mesin, tetapi ini terlalu banyak, kami berencana mengurangi sumber daya yang dialokasikan, karena kapasitas 4-5 mesin sudah cukup.
Layanan sesi adalah layanan pertama kami di vshard dan Cartridge. Menyiapkan vshard dan memperbarui Kartrid memerlukan upaya dari kami, tetapi pada akhirnya semuanya berhasil.
Layanan untuk menampilkan berbagai spanduk di situs web dan aplikasi seluler adalah salah satu yang pertama dirilis langsung di Tarantool. Layanan ini terkenal karena sudah berumur 6-7 tahun, masih beroperasi dan belum pernah di-boot ulang. Replikasi master-master digunakan. Tidak ada yang rusak.
Ada contoh penggunaan Tarantool untuk fungsi referensi cepat dalam sistem gudang untuk memeriksa ulang informasi dengan cepat dalam beberapa kasus. Kami mencoba menggunakan Redis untuk ini, namun data di memori memakan lebih banyak ruang daripada Tarantool.
Layanan daftar tunggu, langganan klien, cerita modis saat ini, dan barang yang ditangguhkan juga berfungsi dengan Tarantool. Layanan terakhir dalam memori memakan waktu sekitar 120 GB. Ini adalah layanan terlengkap di atas.
Kesimpulan
Berkat indeks sekunder yang dikombinasikan dengan nilai kunci dan transaksionalitas, Tarantool sangat cocok untuk arsitektur berbasis layanan mikro. Namun, kami mengalami kesulitan ketika meluncurkan perubahan pada layanan dengan banyak logika di Lua - layanan tersebut sering kali berhenti bekerja. Kami tidak dapat mengatasi hal ini, dan seiring waktu kami sampai pada kombinasi Lua dan Go yang berbeda: kami tahu di mana harus menggunakan satu bahasa dan di mana harus menggunakan bahasa lain.
Apa lagi yang harus dibaca tentang topik tersebut
- Membuat aplikasi dengan beban tinggi dari awal menggunakan Tarantool
- Pilihan pemimpin tepercaya dalam Tarantool Cartridge
- Saluran Telegram Tarantool dengan berita tentang produk
- Diskusikan Tarantool di obrolan komunitas
Sumber: www.habr.com