Couchbase di Telecom

Transformasi digital adalah tren global untuk bisnis besar dan sangat penting untuk mengadaptasi suatu perusahaan dengan kebutuhan pelanggan modern. Selain masalah biasa dari sistem pemusatan untuk perusahaan besar dan menggabungkan sistem penagihan dan database pelanggan, persyaratan untuk ketersediaan tinggi dan mode operasi real-time ditambahkan ke mana pelanggan sudah terbiasa dengan para pemimpin industri (Google, Amazon, Netflix).

Tantangan baru membutuhkan teknologi dan pendekatan baru yang diperlukan untuk mengurangi waktu untuk memperkenalkan fungsi yang nyaman bagi klien, penawaran komersial yang dipersonalisasi, respons cepat terhadap penawaran pesaing, serta mengendalikan biaya untuk sistem, infrastruktur TI, pusat data, dan personel yang berkualifikasi. Tren ini juga minus besar: kompleksitas arsitektur dan database transaksional yang membengkak yang tidak dapat mengatasi aliran dan pemrosesan informasi. Teknologi generasi sebelumnya memiliki langit-langit penskalaan vertikal. Sebagai contoh, sebuah instance Oracle DBMS berjalan pada batas server paling kuat pada prosesor x86 dengan beban satu miliar transaksi per hari.

Untuk menahan beban yang serupa yang telah lama dihadapi industri Internet, tumpukan teknologi baru digunakan, seperti cache In-Memory dan database NoSQL. Jadi, Apple menggunakan Cassandra, Sberbank - Ignite (GridGain), di MegaFon kami menggunakan Couchbase dan Tarantool.

MegaFon menggunakan pola arsitektur yang berbeda untuk DBMS Dalam Memori:

1. Cache sederhana, diperbarui sesuai jadwal atau berdasarkan peristiwa dari database dan aplikasi
2. Semua perubahan pada database dilakukan melalui cache (skrip tulis-tulis), misalnya, menghubungkan klien Oracle ke DCP Couchbase

Untuk salah satu sistem pengambilan keputusan kami untuk kehidupan pelanggan, kami menggunakan templat pertama, karena hanya satu aplikasi pada totalitas data yang membuat keputusan dan mengirimkannya ke semua sistem, termasuk basis data Oracle. Salah satu kasus paling cerdas dalam menggunakan siklus hidup pelanggan adalah mengunci dan membuka keseimbangan negatif. Lagi pula, semua pelanggan operator seluler setelah mengisi saldo ingin segera menghubungi kami dan melakukan panggilan. Berkat aplikasi dan Couchbase yang terpisah, kami dapat mengurangi waktu untuk keluar dari kunci dari 90 detik menjadi 30 dan ini bukan batasnya. Hanya catatan tentang perubahan status pelanggan yang akan masuk ke basis data utama (Gbr. 1)

Dengan menggunakan teknologi baru, kami dapat 3 kali mengurangi waktu untuk keluar dari kunci finansial. Tetapi untuk mendapatkan hasil saat ini, kami telah menempuh perjalanan panjang dalam transformasi arsitektur dari sirkuit penagihan dan dalam memilih database NoSQL.

Mengapa kami memilih Couchbase? Ada beberapa alasan untuk ini.

Persyaratan kinerja

1. Memproses hingga 200.000 permintaan per detik.
2. Waktu respons rata-rata (50%) hingga 5 ms (dalam satu pusat data tunggal).
3. Waktu respons maksimum (99%) hingga 15 ms (dalam satu pusat data).
4. Kinerja penyisipan maksimum 500 MB / detik
5. Jumlah maksimum operasi penyisipan 100.000 / dtk
6. Jumlah maksimum operasi perubahan (pembaruan dokumen) 100.000 / dtk
7. Kinerja maksimum perubahan (pembaruan dokumen) 500 MB / detik
8. Jumlah maksimum operasi baca 100.000 / dtk
9. Kecepatan baca maksimum 500 MB / detik

Pencarian kunci berkinerja tinggi dan akses data

Inti dari Couchbase adalah Distributed Key Vault (KV). Repositori KV adalah pendekatan manajemen data yang sangat sederhana yang menyimpan pengidentifikasi unik (kunci) bersama dengan sepotong informasi sewenang-wenang. Repositori KV itu sendiri dapat menerima data apa pun, apakah itu biner gumpalan atau dokumen JSON. Karena kesederhanaan implementasi KV, akses data dipastikan dengan penundaan minimal. Seperti yang ditunjukkan oleh pengalaman kami, latensi jaringan lebih sering 2-3 kali lebih tinggi daripada memberikan data utama di sisi Couchbase.

Skema Penyimpanan Dinamis ( JSON)

Dokumen disimpan di server Couchbase dalam format JSON. Format mendukung kedua tipe data dasar, seperti angka, string dan tipe kompleks, serta kamus dan array bawaan.

Skema data di Couchbase adalah konstruksi logis yang ditentukan oleh aplikasi dan pengembang. Karena fleksibilitas dan kemampuan untuk menggunakan beberapa opsi, kita dapat menggunakan tag di dokumen, misalnya, dengan informasi versi. Ini memungkinkan aplikasi untuk menentukan dalam mode mana dokumen akan diproses, serta untuk memastikan kelancaran migrasi database ke skema data baru.

Ketersediaan tinggi

Salah satu parameter penyusun sistem informasi adalah ketersediaannya. Couchbase menyediakan ketersediaan data tinggi dengan banyak fitur berbeda. Salah satunya adalah replikasi data (distribusi beberapa salinan data pada server cluster yang berbeda), yang memungkinkan Anda untuk menyediakan layanan selama pemeliharaan rutin atau kegagalan beberapa server.

Fitur penting kedua untuk ketersediaan tinggi adalah DCP internal (Database Change Protocol). Ini memberikan transfer perubahan kecepatan tinggi ke semua salinan data, indeks sekunder (GSI), replikasi lintas-kluster (XDCR) dan konsumen eksternal.

Replikasi dua arah

Praktik yang baik dalam perusahaan adalah menggunakan redundansi untuk semua proses dan peralatan bisnis. Idealnya, ini adalah cadangan dalam mode Active-Active, ketika pergantian antar node bermasalah terjadi secara otomatis. Replikasi dua arah dalam Couchbase memungkinkan mode AA. Tetapi pengujian replikasi telah menunjukkan bahwa itu hanya efektif di pusat data terdekat. Dengan jarak lebih dari 100 km, konflik muncul. Couchbase memiliki mekanisme resolusi konflik: berdasarkan pada Timestamp dan Sequence Number. Namun, karena keterlambatan waktu pada jaringan, data yang ketinggalan zaman masuk ke dalam basis data. Kami meninggalkan penggunaan replikasi dua arah (konsistensi lintas-kluster). Semua perubahan dilakukan hanya pada satu cluster. Ketersediaan data dalam mode baca disediakan di semua pusat data (AA).

Penskalaan horisontal

Salah satu karakteristik penting dari kebanyakan database NoSQL adalah penskalaan horizontal (Gbr. 3). Perbedaan utama Couchbase adalah dukungan penskalaan multidimensi, ketika kita di cluster hanya dapat meningkatkan kinerja layanan yang diinginkan. Misalnya, game Pokemon GO menggunakan arsitektur split. Pada awal proyek, 5 server dengan layanan gabungan digunakan. Setelah menambah beban, mereka menggunakan arsitektur yang beragam: 5 server data dan 55 server untuk memproses kueri dan indeks. Salah satu kelemahan dari penskalaan dengan Couchbase adalah bahwa orkestra memiliki masalah ketika ada lebih dari 50 node tanggal dalam cluster.

Gambar 3 MDS

Persyaratan IS

Persyaratan keamanan informasi memengaruhi pilihan kami pada tingkat yang lebih rendah, tetapi kehadiran mereka dalam sistem membuat argumen tambahan yang mendukung satu atau database lain. Karena cache dapat berisi data pribadi, kita harus mengikuti persyaratan regulator tanpa gagal. Layak untuk diputuskan: apakah kita akan menggunakan peralatan tambahan atau bisakah kita menyediakan ini dengan database itu sendiri ?!

Dalam versi perusahaan, Couchbase mendukung enkripsi lalu lintas, enkripsi data, dan akses yang dipersonalisasi. Ini menghemat uang untuk peralatan seperti Cisco ASA.

Upgrade mudah

Salah satu kekuatan signifikan Couchbase adalah mekanisme pembaruan yang transparan dan dukungan untuk versi API yang lebih lama. Selama pemutakhiran klaster, ia bekerja dalam mode kompatibilitas. Mekanisme baru hanya akan berfungsi setelah peningkatan cluster lengkap. Efek pada menjalankan aplikasi minimal karena dukungan untuk API lama.

PS: Upgrade / downgrade hanya diperbolehkan pada versi utama yang berdekatan

Fungsionalitas tambahan

Distribusi logis

Fitur lain yang menarik adalah kombinasi server dalam sebuah cluster menjadi grup logis, dengan replika yang melekat padanya. Ini memungkinkan Anda untuk mendistribusikan salinan penuh dari replika dari cluster yang sama ke autogate yang berbeda. Itu memungkinkan kegagalan salah satu dealer mobil untuk memiliki salinan lengkap data di yang kedua

Cadangkan & Kembalikan

Couchbase berisi alat cadangan dan pemulihan yang sudah jadi. Proses pencadangan dapat bekerja dalam tiga mode: penuh, diferensial, dan kumulatif. Dalam beberapa kasus ini memungkinkan untuk menghemat ruang disk dan sumber daya prosesor.

Couchbase vs mongo

Sulit untuk menjawab pertanyaan tentang memilih database NoSQL alternatif, dan seringkali, Unix terbaik adalah yang diketahui oleh admin Anda. Mari kita coba merumuskan mengapa kita lebih suka Couchbase, dan bukan platform lain yang sangat populer - MongoDB.

Sangat sulit untuk membandingkan dua proyek berbeda dengan arsitektur dan fungsionalitas yang berbeda. Salah satu parameter yang kami perhatikan adalah kemudahan pemeliharaan dan kemampuan untuk dengan cepat mengkonfigurasi ulang sistem untuk memenuhi kebutuhan bisnis.

Tabel 1 Perbandingan

Tabel 2 Perbandingan Replikasi

Secara keseluruhan, Couchbase lebih fleksibel dan lebih sederhana dalam pengaturan yang diperlukan untuk tugas kami dan arsitektur hybrid yang berubah dengan cepat.

Pengalaman operasi

Untuk mulai dengan, kami ingin memberikan angka-angka dimana sistem dan cluster sekarang beroperasi di Couchbase.

1. Lebih dari 80 juta pelanggan [i]
2. 380 juta dokumen informasi pelanggan JSON
3. HDD 3,5 TB (kami menggunakan memcached, informasi pada disk disimpan untuk memulai dengan cepat)
4. RAM 3 TB
5. 50 ribu operasi per detik (Gbr. 5)
6. 50 layanan microser yang memproses seluruh aliran pesan

Tonggak pertama dari transformasi kami mulai dengan Couchbase versi ketiga. Pada tahap pertama, pada awal proyek, semua aplikasi bekerja secara stabil. Tetapi ketika menerjemahkan logika tambahan ke mekanisme baru, kami dihadapkan dengan fakta bahwa mekanisme Tampilan mulai bekerja tanpa terduga. Yaitu pada titik tertentu, proses membeku dan pandangan-pandangan ini dari simpul seperti itu berhenti kembali. Pada saat yang sama, akses ke data dan pemrosesan mereka tidak terganggu. Masalahnya diperbaiki dengan cukup mudah - dengan me-restart node, yang umumnya mengurangi ketersediaan layanan. Selama berkomunikasi dengan dukungan teknis Couchbase, kami ditawari perintah tidak berdokumen yang hanya memulai ulang proses tampilan

curl -s --data 'cb_couch_sup: restart_couch ().' -U Administrator: lulus http://127.0.0.1:8091/diag/eval [ii]

Perintah ini hanya valid dalam versi 3.x.

curl -s --data 'couch_server_sup: restart_core_server ().' -u Administrator: Administrator http://127.0.0.1:8091/diag/eval

Perintah ini hanya valid dalam versi 4.x.

Masalah lain dari versi ketiga adalah mekanisme pemecahan data kompresi (pemadatan). Itu harus dimulai secara manual sesuai dengan metrik pemantauan yang dipicu. Kedua masalah terus tegang tidak hanya pergeseran tugas, tetapi juga insinyur fungsional.

Dalam hal ini, kami memutuskan untuk bermigrasi ke versi keempat. Migrasi dengan dampak minimal pada layanan ini memakan waktu sekitar dua minggu. Proses pembaruan itu sendiri tidak memerlukan tindakan dan kontrol yang kompleks, tetapi ketika menambahkan atau menghapus node, penyeimbangan diluncurkan, yang membutuhkan setidaknya dua jam. Dalam prosesnya, kami menemukan cara untuk mempercepat proses pembaruan melalui server penyangga: dalam hal ini, ia memulai bukan proses penyeimbangan ulang yang bersih, tetapi mentransfer data dari satu node ke node lainnya. Ini mengurangi proses pembaruan menjadi 30 menit.

Saat memperbarui klaster industri, nuansa berikut harus diperhitungkan: bekerja dalam mode kompatibilitas, ketika kluster beroperasi dalam mode versi termuda dari perangkat lunak. Di sisi positifnya, proses pemutakhiran berjalan dengan lancar dan tanpa rasa sakit, namun demikian, Anda tidak akan dapat menggunakan fungsi baru, seperti mekanisme kompresi baru, N1QL, hingga seluruh gugus diperbarui sepenuhnya.

Setelah pembaruan, kami berhasil memperbaiki hanya satu masalah - kompresi. Itu mulai bekerja dengan baik. Dengan mekanisme View, masalahnya masih tetap ada, meskipun itu diulang jauh lebih jarang. Itu mungkin untuk memperbaikinya hanya oleh kekuatan pengembang Couchbase di versi 4.6.4.

Sebagai bagian dari penyelesaian masalah dukungan teknis, menjadi jelas bahwa mekanisme tampilan tidak lagi diperbarui. Ini dilakukan atas dasar bahwa sebagian besar klien Couchbase tidak menggunakan tampilan untuk tujuan pembuatannya, dan Couchbase membuat mekanisme N1QL baru. Ini dijalankan oleh layanan terpisah dan sekarang tidak tergantung pada data node (Gbr. 7)

Kami menutup semua masalah kritis dengan versi 4.6.4. Tetapi karena peningkatan volume data, mereka memutuskan untuk bermigrasi ke versi kelima, di mana mereka menambahkan database baru untuk indeks dan pada data kami jumlah memori dan disk menurun satu setengah kali. Namun, sayangnya, kami tidak melihat penurunan jumlah data pada data node.

Kesimpulan

Secara umum, Couchbase terbukti menjadi sistem matang yang menahan beban tinggi, bahkan dalam kasus-kasus non-spesifik (Viber - digunakan sebagai basis data). Dalam arsitektur hybrid MegaFon, cluster dapat dengan mudah diadaptasi untuk tujuan apa pun tanpa downtime peralatan dan tanpa konfigurasi ulang server yang serius, yang umumnya memungkinkan perusahaan untuk mengurangi biaya personel dan membuat layanan untuk pelanggan senyaman mungkin.

PAO MegaFon

2018 Kovalchuk Egor

[i] Sistem tidak hanya memproses pelanggan, tetapi juga perangkat dengan kartu SIM, modem, dll.

[ii] Konsultasikan dengan spesialis sebelum digunakan