Kita semua menyukai cerita. Kami suka duduk di dekat api dan berbicara tentang kemenangan masa lalu kami, pertempuran, atau hanya tentang pengalaman kerja kami.
Hari ini adalah hari seperti itu. Dan bahkan jika Anda tidak sedang berada di depan api sekarang, tapi kami punya cerita untuk Anda. Kisah tentang bagaimana kami mulai bekerja dengan penyimpanan di Tarantool.
Suatu ketika di perusahaan kami ada beberapa "monolit" dan satu "langit-langit" untuk semua, di mana monolit ini perlahan tapi pasti mendekat, membatasi penerbangan perusahaan kami, perkembangan kami. Dan ada pemahaman yang tidak ambigu: suatu hari kita akan sulit melawan langit-langit ini.
Sekarang kita didominasi oleh ideologi membagi segalanya dan semua orang, dari peralatan hingga logika bisnis. Akibatnya, kami, misalnya, memiliki dua DC yang praktis independen di tingkat jaringan. Dan kemudian semuanya benar-benar berbeda.
Saat ini, ada banyak alat dan alat untuk membuat perubahan dalam bentuk CI / CD, K8S, dll. Di masa "monolitik", kami tidak membutuhkan begitu banyak kata asing. Cukup dengan memperbaiki "penyimpanan" di database.
Tetapi waktu terus berjalan, dan jumlah permintaan terus berlanjut, terkadang mengaktifkan RPS di luar kemampuan kami. Dengan masuknya pasar negara-negara CIS, beban pada prosesor basis data dari monolit pertama tidak turun di bawah 90%, dan RPS tetap di level 2400. Dan ini bukan hanya penyeleksi kecil, tetapi kueri yang kuat dengan sekumpulan pemeriksaan dan GABUNG yang dapat berjalan hampir setengah data di latar belakang IO besar.
Ketika penjualan penuh pada Black Friday mulai muncul di atas panggung - dan Wildberry mulai menahannya sebagai salah satu yang pertama di Rusia - situasinya menjadi sangat menyedihkan. Bagaimanapun, beban pada hari-hari seperti itu tiga kali lipat.
Oh, "masa monolitik" ini! Saya yakin Anda juga mengalami hal serupa, dan masih tidak dapat memahami bagaimana ini bisa terjadi pada Anda.
Apa yang dapat Anda lakukan - fashion melekat pada teknologi. 5 tahun yang lalu, kami harus memikirkan kembali salah satu mod ini dalam bentuk situs yang ada di .NET dan MS SQL-server, yang dengan hati-hati menyimpan semua logika situs itu sendiri. Dia menyimpannya dengan sangat hati-hati sehingga memotong monolit seperti itu ternyata menjadi kesenangan yang panjang dan cukup sulit.
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, paling tidak, mereka lebih murah untuk diukur. Dan pemahaman bahwa kami harus mengukur (dan banyak) adalah 100%. Memang pada saat itu ternyata sudah memasuki pasar negara tetangga, dan jumlah registrasi serta jumlah pesanan mulai bertambah lagi.
Setelah menganalisis pelamar pertama yang meninggalkan monolit di layanan mikro, kami menyadari bahwa di 80% dari mereka, 99% dari mereka menulis dari sistem back office, dan membaca dari sistem front-end. Pertama-tama, ini menyangkut beberapa subsistem penting bagi kami - data pengguna dan sistem untuk menghitung biaya akhir barang berdasarkan informasi tentang diskon dan kupon tambahan dari klien.
Indentasi. Sekarang menakutkan untuk dibayangkan, tetapi selain subsistem yang disebutkan di atas, katalog produk, keranjang pengguna, sistem pencarian produk, sistem penyaringan untuk katalog produk, dan berbagai sistem rekomendasi juga dikeluarkan dari monolit kami. Untuk pengoperasian masing-masing, ada kelas terpisah dari sistem yang diasah secara sempit, tetapi pada satu waktu mereka semua tinggal di satu "rumah kecil".
Kami berencana mentransfer data tentang klien kami ke sistem pecahan. Penghapusan fungsionalitas untuk menghitung harga akhir barang memerlukan skalabilitas baca yang baik, karena ini menciptakan beban RPS terbesar dan paling sulit untuk diterapkan untuk database (banyak data yang terlibat dalam proses penghitungan).
Hasilnya, kami memiliki skema yang bekerja dengan baik dengan Tarantool.
Pada saat itu, untuk pengoperasian layanan mikro, skema kerja 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 ada 24 shard, yang masing-masing memiliki 2 instans (satu untuk setiap DC), semuanya dalam mode master-master.
Di atas database adalah 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 master untuk membaca dan menulis. Bahkan, ini mengimplementasikan model set replika, yang menambahkan logika untuk memilih replika, melakukan percobaan ulang, pemutus sirkuit, dan batas kecepatan.
Pada saat yang sama, dimungkinkan untuk mengonfigurasi kebijakan memilih replika dalam konteks pecahan. Misalnya, roundrobin.
Arsitektur. Opsi 2. Layanan untuk menghitung harga akhir barang
Beberapa bulan yang lalu, sebagian besar permintaan untuk menghitung harga akhir barang pergi ke layanan baru, yang pada prinsipnya bekerja tanpa database, tetapi beberapa waktu lalu 100% diproses oleh layanan dengan Tarantool di bawah tenda.
Database layanan adalah 4 master tempat penyinkron mengumpulkan data, dan masing-masing master replikasi ini mendistribusikan data ke replika hanya baca. Setiap master memiliki sekitar 15 baris seperti itu.
Baik di skema pertama dan kedua, jika satu DC tidak tersedia, aplikasi dapat menerima data di skema kedua.
Perlu dicatat bahwa replikasi di Tarantool cukup fleksibel dan dapat dikonfigurasi saat runtime. Di sistem lain, ada kesulitan. Misalnya, mengubah parameter max_wal_senders dan max_replication_slots di PostgreSQL memerlukan wizard untuk direstart, yang dalam beberapa kasus dapat menyebabkan pemutusan antara aplikasi dan DBMS.
Cari dan Anda akan menemukannya!
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 di Redis. Yang pertama adalah cache, dan yang kedua adalah penyimpanan persisten untuk data yang tidak terlalu penting. Cukup sulit bersamanya, sebagian karena kesalahan kami. Terkadang volume yang cukup besar berada di kunci, dan dari waktu ke waktu situs tersebut terasa buruk. Kami menggunakan sistem ini dalam versi master-slave. Dan ada banyak kasus ketika sesuatu terjadi pada master dan replikasi rusak.
Artinya, Redis bagus untuk tugas tanpa kewarganegaraan, bukan tugas negara. Pada prinsipnya, ini memungkinkan penyelesaian sebagian besar masalah, tetapi hanya jika ini adalah solusi nilai kunci dengan sepasang indeks. Tetapi pada saat itu, Redis cukup sedih dengan kegigihan dan replikasi. Selain itu, ada keluhan tentang kinerja.
Berpikir tentang MySQL dan PostgreSQL. Tetapi yang pertama entah bagaimana tidak mengakar bersama kami, dan yang kedua itu sendiri adalah produk yang agak canggih, dan tidak pantas untuk membangun layanan sederhana di atasnya.
Kami mencoba RIAK, Cassandra, bahkan database grafik. Semua ini adalah solusi khusus yang tidak sesuai dengan peran alat universal umum untuk membuat layanan.
Akhirnya, kami memilih Tarantool.
Kami menghubunginya ketika dia di versi 1.6. Kami tertarik pada simbiosis nilai kunci dan fungsionalitas database relasional. Ada indeks sekunder, transaksi dan spasi, mereka seperti tabel, tetapi tidak sederhana, Anda dapat menyimpan jumlah kolom yang berbeda di dalamnya. Tapi fitur pembunuh Tarantool adalah indeks sekunder yang dikombinasikan dengan nilai kunci dan transaksional.
Komunitas penutur bahasa Rusia yang responsif juga berperan, siap membantu dalam obrolan. Kami secara aktif menggunakan ini dan langsung hidup dalam obrolan. Dan jangan lupa tentang persisten yang layak tanpa kesalahan dan tiang tembok yang jelas. Jika Anda melihat sejarah kami dengan Tarantool, kami mengalami banyak kesulitan dan kesalahan dengan replikasi, tetapi kami tidak pernah kehilangan data karena kesalahannya!
Penerapannya dimulai dengan keras
Pada saat itu, tumpukan pengembangan utama kami adalah .NET, yang tidak memiliki konektor untuk Tarantool. Kami segera mulai melakukan sesuatu di Go. Lua juga bekerja dengan cukup baik. Masalah utama pada saat itu adalah dengan debugging: di .NET semuanya indah dengan ini, dan setelah itu sulit untuk terjun ke dunia Lua yang disematkan, ketika Anda, selain log, tidak memiliki debugging, sulit. Selain itu, replikasi karena alasan tertentu secara berkala berantakan, jadi saya harus mempelajari struktur mesin Tarantool. Obrolan membantu dalam hal ini, pada tingkat yang lebih rendah - dokumentasi, terkadang melihat kode. Saat itu, dokumentasinya biasa-biasa saja.
Jadi, dalam beberapa bulan, saya berhasil mengisi kerucut dan mendapatkan hasil yang lumayan saat bekerja dengan Tarantool. Kami memformalkan pengembangan referensi di git, yang membantu pembentukan layanan mikro baru. Misalnya, ketika tugas muncul: untuk membuat layanan mikro lain, pengembang melihat kode sumber dari solusi referensi di repositori, dan tidak lebih dari seminggu untuk membuat yang baru.
Ini adalah waktu spesial. Secara konvensional, maka dimungkinkan untuk mendekati administrator di meja berikutnya dan bertanya: "Beri saya mesin virtual." Tiga puluh menit kemudian Anda sudah memiliki mobil. Anda sendiri terhubung, menginstal semuanya, dan Anda mendapatkan lalu lintas ke sana.
Hari ini tidak akan berfungsi seperti itu: Anda perlu mengakhiri pemantauan, masuk ke layanan, menutupi fungsionalitas dengan tes, memesan mesin virtual atau memasok ke Kuber, dll. Secara umum, itu akan lebih baik, meski lebih lama dan lebih merepotkan.
Bagilah dan kuasai. Bagaimana dengan Lua?
Ada dilema yang serius: beberapa tim tidak dapat secara andal meluncurkan perubahan dalam layanan dengan banyak logika di Lua. Ini sering kali disertai dengan ketidakmampuan layanan.
Artinya, para pengembang sedang mempersiapkan semacam perubahan. Tarantool memulai migrasi, dan replikanya masih memiliki kode lama; beberapa DDL, sesuatu yang lain, tiba di sana melalui replikasi, dan kodenya berantakan, karena tidak diperhitungkan. Akibatnya, prosedur pembaruan untuk admin dijadwalkan pada lembar A4: hentikan replikasi, perbarui, aktifkan replikasi, matikan di sini, perbarui di sana. Mimpi buruk!
Akibatnya, sekarang kami paling sering mencoba tidak melakukan apa-apa di Lua. Hanya menggunakan iproto (protokol biner untuk berkomunikasi dengan server), dan hanya itu. Mungkin ini adalah kurangnya pengetahuan di antara para pengembang, tetapi dari sudut pandang ini, sistemnya rumit.
Kami tidak selalu mengikuti skenario ini secara membabi buta. Hari ini kami tidak memiliki hitam dan putih: baik semuanya ada di Lua, atau semuanya ada di Go. Kami sudah memahami bagaimana Anda dapat menggabungkannya sehingga Anda tidak mendapatkan masalah dengan migrasi nantinya.
Dimana Tarantool sekarang?
Tarantool digunakan dalam layanan untuk menghitung harga akhir barang, dengan mempertimbangkan kupon diskon alias "Promotor". Seperti yang saya katakan sebelumnya, sekarang sudah pensiun: digantikan oleh layanan katalog baru dengan harga yang telah dihitung sebelumnya, tetapi enam bulan lalu, semua perhitungan dilakukan di Promotor. Sebelumnya, separuh logikanya ditulis dalam Lua. Dua tahun lalu, sebuah penyimpanan dibuat dari layanan tersebut, dan logikanya ditulis ulang menjadi Go, karena mekanisme diskon sedikit berubah dan kinerja layanan tersebut kurang.
Salah satu layanan terpenting adalah profil pengguna. Artinya, semua pengguna Wildberry disimpan di Tarantool, dan ada sekitar 50 juta dari mereka.Sebuah sistem yang dipisahkan oleh ID pengguna, didistribusikan melalui beberapa DC dengan koneksi ke layanan Go.
Menurut RPS, "Promotor" pernah menjadi pemimpin, mencapai 6 ribu permintaan. Pada satu titik, kami memiliki 50-60 eksemplar. Sekarang pemimpin di RPS adalah profil pengguna, sekitar 12 ribu.Layanan ini menggunakan sharding kustom dengan pembagian rentang ID pengguna. Layanan ini melayani lebih dari 20 mesin, tetapi ini terlalu banyak, kami berencana untuk mengurangi sumber daya yang dialokasikan, karena kapasitas 4-5 mesin sudah cukup untuk itu.
Layanan sesi adalah layanan pertama kami di vshard dan Cartridge. Mengonfigurasi vshard dan memperbarui Cartridge memerlukan beberapa pekerjaan dari kami, tetapi pada akhirnya semuanya berhasil.
Layanan untuk menampilkan berbagai spanduk di situs web dan di aplikasi seluler adalah salah satu yang pertama dirilis langsung di Tarantool. Layanan ini terkenal karena usianya 6-7 tahun, masih dalam layanan dan tidak pernah di-boot ulang. Replikasi adalah master-master. Tidak pernah merusak apapun.
Ada contoh penggunaan Tarantool untuk fungsionalitas referensi cepat di sistem gudang untuk memeriksa ulang informasi dengan cepat dalam beberapa kasus. Kami mencoba menggunakan Redis untuk ini, tetapi data di memori menggunakan lebih banyak ruang daripada Tarantool.
Layanan daftar tunggu, langganan klien, cerita trendi, dan barang rak juga bekerja dengan Tarantool. Layanan terakhir di memori sekitar 120 GB. Ini adalah layanan paling ekstensif di atas.
Kesimpulan
Indeks sekunder yang dikombinasikan dengan nilai kunci dan properti transaksional menjadikan Tarantool bagus untuk arsitektur layanan mikro. Namun, kami mengalami kesulitan saat meluncurkan perubahan ke layanan dengan banyak logika di Lua - layanan sering berhenti bekerja. Kami tidak berhasil mengalahkan ini, dan seiring waktu kami menemukan kombinasi Lua dan Go yang berbeda: kami tahu di mana menggunakan satu bahasa, dan di mana - bahasa lain.
Apa lagi yang harus dibaca tentang topik ini
- Kami membuat dari awal aplikasi yang sangat dimuat di Tarantool habr.com/ru/company/mailru/blog/510440
- Pilihan pemimpin tepercaya Tarantool Cartridge habr.com/ru/company/mailru/blog/513912
- Saluran Tarantool Telegram dengan berita produk t.me/tarantool_news
- Diskusikan Tarantool di obrolan komunitas t.me/tarantoolru