Mengapa perusahaan seperti MegaFon, Tarantool dalam penagihan? Dari luar tampaknya vendor biasanya datang, membawa beberapa kotak besar, colokkan colokan ke soket - inilah tagihannya! Dulu, tapi sekarang kuno, dan dinosaurus seperti itu telah punah atau punah. Awalnya, penagihan adalah sistem penagihan - pembaca atau kalkulator. Dalam telekomunikasi modern, ini adalah
sistem untuk mengotomatisasi seluruh siklus interaksi dengan pelanggan dari akhir kontrak hingga pemutusan , termasuk penagihan real-time, penerimaan pembayaran, dan banyak lagi. Penagihan di perusahaan telekomunikasi mirip dengan robot tempur - besar, kuat, dan digantung dengan senjata.
Dan ini Tarantool?
Oleg Ivlev dan
Andrey Knyazev akan membicarakan hal ini. Oleg adalah kepala arsitek
MegaFon dengan pengalaman luas bekerja di perusahaan asing, Andrey adalah direktur sistem bisnis. Dari transkrip laporan mereka di
Tarantool Conference 2018, Anda akan belajar mengapa R&D diperlukan di perusahaan, seperti apa Tarantool, bagaimana jalan buntu untuk penskalaan vertikal dan globalisasi menjadi prasyarat munculnya database ini di perusahaan, tentang tantangan teknologi, transformasi arsitektur, dan bagaimana technostek MegaFon menyerupai Netflix, Google dan Amazon.
Proyek Penagihan Tunggal
Proyek yang akan dibahas disebut "Penagihan Tunggal." Di dalam dirinya itulah Tarantool menunjukkan kualitas terbaiknya.
Pertumbuhan kinerja peralatan Hi-End tidak mengimbangi dengan pertumbuhan basis pelanggan dan peningkatan jumlah layanan, pertumbuhan lebih lanjut dalam jumlah pelanggan dan layanan karena M2M, IoT diharapkan, dan fitur-fitur cabang menyebabkan penurunan waktu-ke-pasar. Perusahaan memutuskan untuk membuat sistem bisnis terpadu dengan arsitektur modular kelas dunia yang unik, alih-alih 8 sistem penagihan berbeda saat ini.
MegaFon adalah delapan perusahaan dalam satu . Pada tahun 2009, reorganisasi selesai: cabang di seluruh Rusia bergabung menjadi satu perusahaan MegaFon OJSC (sekarang PJSC). Dengan demikian, perusahaan memiliki 8 sistem penagihan dengan solusi "kebiasaan" sendiri, fitur cabang dan struktur organisasi yang berbeda, TI dan pemasaran.
Semuanya baik-baik saja sampai saya harus meluncurkan satu produk federal yang umum. Banyak kesulitan muncul di sini: untuk beberapa, penetapan tarif dengan pembulatan, untuk yang lain pada tingkat lebih rendah, dan untuk yang lain - sesuai dengan rata-rata aritmatika. Ada ribuan momen seperti itu.
Terlepas dari kenyataan bahwa versi sistem penagihan adalah sama, satu pemasok, pengaturannya berbeda sehingga lem untuk waktu yang lama. Kami mencoba mengurangi jumlah mereka, dan menemukan masalah kedua yang akrab bagi banyak perusahaan.
Penskalaan vertikal . Bahkan besi paling keren saat itu tidak memenuhi kebutuhan. Kami menggunakan peralatan Hewlett-Packard, jalur Hi-End Superdome, tetapi tidak menarik bahkan untuk dua cabang. Saya ingin penskalaan horizontal tanpa biaya transaksi besar dan investasi modal.
Ekspektasi pertumbuhan jumlah pelanggan dan layanan . Para konsultan telah lama membawa cerita tentang IoT dan M2M ke dunia telekomunikasi: akan tiba saatnya ketika setiap telepon dan besi memiliki kartu SIM, dan dua di lemari es. Hari ini kami memiliki satu jumlah pelanggan, dan dalam waktu dekat akan ada urutan lebih besar.
Tantangan teknologi
Keempat alasan ini mendorong kami untuk melakukan perubahan besar. Ada pilihan antara meningkatkan sistem dan mendesain dari awal. Mereka berpikir untuk waktu yang lama, membuat keputusan serius, bermain tender. Akibatnya, mereka memutuskan untuk merancang sejak awal, dan mengambil tantangan menarik - tantangan teknologi.
Skalabilitas
Jika sebelumnya ada, katakanlah,
8 akun penagihan untuk 15 juta pelanggan , dan sekarang
100 juta pelanggan dan lebih seharusnya berubah - bebannya adalah urutan besarnya lebih tinggi.
Kami telah menjadi sebanding dalam skala dengan pemain Internet utama seperti Mail.ru atau Netflix.
Namun pergerakan lebih lanjut untuk meningkatkan beban dan basis pelanggan merupakan tantangan serius bagi kami.
Geografi negara kita yang luas
Antara Kaliningrad dan Vladivostok
7500 km dan 10 zona waktu . Kecepatan cahaya terbatas dan pada jarak tunda seperti itu sudah signifikan. 150 ms pada saluran optik modern paling keren agak banyak untuk penagihan real-time, terutama seperti sekarang di telekomunikasi di Rusia. Selain itu, Anda perlu memperbarui dalam satu hari kerja, dan dengan zona waktu yang berbeda - ini merupakan masalah.
Kami tidak hanya menyediakan layanan dengan biaya bulanan, kami memiliki tarif yang kompleks, paket, berbagai pengubah. Kita tidak hanya perlu mengizinkan atau melarang pelanggan untuk berbicara, tetapi untuk memberinya kuota tertentu - untuk menghitung panggilan dan tindakan secara real time sehingga dia tidak menyadarinya.
Toleransi kesalahan
Ini adalah sisi lain dari sentralisasi.
Jika kami mengumpulkan semua pelanggan dalam satu sistem, maka setiap peristiwa darurat dan bencana adalah bencana bagi bisnis. Oleh karena itu, kami merancang sistem sedemikian rupa untuk mengecualikan efek kecelakaan pada seluruh basis pelanggan.
Sekali lagi ini adalah konsekuensi dari penolakan penskalaan vertikal. Ketika kami masuk ke penskalaan horizontal, kami meningkatkan jumlah server dari ratusan menjadi ribuan. Mereka perlu dikelola dan dipertukarkan, secara otomatis didukung infrastruktur TI dan sistem terdistribusi yang dipulihkan.
Tantangan menarik seperti itu menghadang kami. Kami merancang sistem, dan pada saat itu kami mencoba menemukan praktik terbaik dunia untuk memeriksa seberapa banyak kami dalam tren, seberapa banyak kami mengikuti teknologi canggih.
Pengalaman dunia
Anehnya, di dunia telekomunikasi kami tidak menemukan satu pun referensi.
Eropa jatuh oleh jumlah pelanggan dan skala, Amerika Serikat - oleh pesawat tarifnya. Kami melihat sesuatu di Cina, tetapi menemukan sesuatu di India dan mengambil spesialis dari Vodafone India.
Untuk menganalisis arsitektur, Tim Impian berkumpul, dipimpin oleh IBM, arsitek dari berbagai bidang. Orang-orang ini dapat secara memadai mengevaluasi apa yang kami lakukan dan membawa pengetahuan tertentu ke arsitektur kami.
Skala
Beberapa angka untuk diilustrasikan.
Kami merancang sistem untuk
80 juta pelanggan dengan cadangan satu miliar . Jadi kami menghapus ambang batas masa depan. Ini bukan karena kita akan mengambil alih Cina, tetapi karena tekanan dari IoT dan M2M.
300 juta dokumen diproses secara real time . Meskipun kami memiliki 80 juta pelanggan, kami bekerja dengan pelanggan potensial dan mereka yang telah meninggalkan kami jika kami perlu menagih piutang. Karena itu, volume nyata jauh lebih besar.
2 miliar transaksi setiap hari mengubah saldo - ini adalah pembayaran, biaya, panggilan dan acara lainnya.
200 TB perubahan data aktif ,
8 PB perubahan
data sedikit lebih lambat, dan ini bukan arsip, tetapi data langsung dalam satu tagihan. Skala
pusat data adalah
5 ribu server di 14 situs .
Tumpukan teknologi
Ketika kami merencanakan arsitektur dan mulai merakit sistem, kami mengimpor teknologi yang paling menarik dan canggih. Hasilnya adalah tumpukan teknologi yang akrab bagi setiap pemain Internet dan perusahaan yang membuat sistem yang sangat dimuat.
Tumpukan ini mirip dengan tumpukan pemain utama lainnya: Netflix, Twitter, Viber. Ini terdiri dari 6 komponen, tetapi kami ingin mengurangi dan menyatukannya.
Fleksibilitas itu baik, tetapi di perusahaan besar tidak ada jalan tanpa penyatuan.
Kami tidak akan mengubah Oracle yang sama ke Tarantool. Dalam realitas perusahaan besar, ini adalah utopia, atau perang salib selama 5-10 tahun dengan hasil yang tidak dapat dipahami. Tapi Cassandra dan Couchbase dapat diganti dengan Tarantool, dan kami berkomitmen untuk ini.
Mengapa Tarantool?
Ada 4 kriteria sederhana mengapa kami memilih basis data ini.
Kecepatan . Kami melakukan stress test pada sistem industri MegaFon. Tarantool menang - ini menunjukkan kinerja terbaik.
Ini bukan untuk mengatakan bahwa sistem lain tidak memenuhi kebutuhan MegaFon. Solusi memori saat ini sangat produktif sehingga stok perusahaan ini lebih dari cukup. Tapi kami tertarik berurusan dengan pemimpin, dan bukan dengan orang yang menjalin ekor, termasuk uji beban.
Tarantool memenuhi kebutuhan perusahaan bahkan dalam jangka panjang.
Biaya TCO . Dukungan untuk Couchbase pada volume MegaFon membutuhkan uang ruang, dengan Tarantool situasinya jauh lebih baik, dan dalam hal fungsionalitas mereka dekat.
Fitur bagus lain yang sedikit memengaruhi pilihan kami - Tarantool berfungsi lebih baik daripada basis data lainnya dengan memori. Ini menunjukkan
efisiensi maksimum .
Keandalan MegaFon diinvestasikan dalam keandalan, mungkin tidak seperti yang lain. Karena itu, ketika kami melihat Tarantool, kami menyadari apa yang perlu dilakukan agar memenuhi persyaratan kami.
Kami menginvestasikan waktu dan keuangan kami, dan bersama dengan Mail.ru kami membuat versi perusahaan, yang sekarang digunakan oleh beberapa perusahaan lain.
Tarantool-enterprise sepenuhnya memuaskan kami dengan keamanan, keandalan, dan pencatatan.
Kemitraan
Yang paling penting bagi saya adalah
kontak langsung dengan pengembang . Inilah yang disuap orang-orang Tarantool.
Jika Anda datang ke pemain, terutama yang bekerja dengan anchor client, dan mengatakan bahwa Anda memerlukan database untuk dapat melakukan ini, ini dan itu, biasanya jawabannya:
- Nah, letakkan persyaratan di bawah tumpukan itu - suatu hari nanti, mungkin, kita akan mendapatkannya.Banyak yang memiliki peta jalan untuk 2-3 tahun ke depan, dan hampir mustahil untuk berintegrasi di sana, dan pengembang Tarantool menyuap dengan keterbukaan, dan tidak hanya dengan MegaFon, dan menyesuaikan sistem mereka dengan pelanggan. Ini keren dan kami sangat menyukainya.
Di mana kami menerapkan Tarantool
Di AS, Tarantool digunakan dalam beberapa elemen.
Yang pertama ada di pilot , yang kami buat pada sistem direktori alamat. Pada suatu waktu, saya ingin itu menjadi sistem yang mirip dengan Yandex.Maps dan Google Maps, tetapi ternyata sedikit berbeda.
Misalnya, direktori alamat di antarmuka penjualan. Di Oracle, menemukan alamat yang Anda butuhkan memakan waktu 12-13 s. - angka tidak nyaman. Ketika kami beralih ke Tarantool, ganti Oracle dengan database lain di konsol, dan melakukan pencarian yang sama, kami mendapatkan akselerasi 200 kali! Kota muncul setelah huruf ketiga. Sekarang kami mengadaptasi antarmuka sehingga ini terjadi setelah yang pertama. Namun, kecepatan responsnya sangat berbeda - sudah milidetik alih-alih detik.
Aplikasi kedua adalah topik trendi yang disebut IT dua kecepatan . Ini karena konsultan dari masing-masing besi mengatakan bahwa perusahaan harus pergi ke sana.
Ada lapisan infrastruktur, domain di atasnya, misalnya, sistem penagihan, seperti telekomunikasi, sistem perusahaan, pelaporan perusahaan. Inilah inti yang tidak perlu disentuh. Itu, tentu saja, mungkin, tetapi paranoid dalam memberikan kualitas, karena membawa uang kepada perusahaan.
Berikutnya adalah lapisan layanan microser - yang membedakan operator atau pemain lain. Layanan Microsoft dapat dengan cepat dibuat berdasarkan cache tertentu, mengangkat data dari domain yang berbeda di sana. Ini adalah
bidang percobaan - jika ada yang tidak berhasil, tutup satu microservice, buka lainnya. Ini memberikan waktu ke pasar yang benar-benar ditingkatkan dan meningkatkan keandalan dan kecepatan perusahaan.
Microservices mungkin adalah peran utama Tarantool di MegaFon.
Di mana kami berencana untuk menerapkan Tarantool
Jika kami membandingkan proyek penagihan kami yang sukses dengan program transformasi di Deutsche Telekom, Svyazkome, Vodafone India, ini sangat dinamis dan kreatif. Dalam proses pelaksanaan proyek ini, tidak hanya MegaFon dan strukturnya diubah, tetapi juga Tarantool-enterprise muncul di Mail.ru, dan vendor kami Nexign (sebelumnya Peter-Service) memiliki BSS Box (solusi penagihan kotak).
Dalam arti tertentu, ini adalah proyek historis untuk pasar Rusia. Ini dapat dibandingkan dengan apa yang dijelaskan dalam buku Frederick Brooks “Mythical Man-Month”. Kemudian, di tahun 60an, IBM menarik 5.000 orang untuk mengembangkan sistem operasi OS / 360 baru untuk mainframe. Kami memiliki kurang - 1.800, tetapi kami berada dalam rompi, dan dengan mempertimbangkan penggunaan open source dan pendekatan baru, kami bekerja lebih produktif.
Domain penagihan atau, yang lebih luas, sistem bisnis ditampilkan di bawah ini. Orang-orang di perusahaan mengenal CRM dengan sangat baik. Setiap orang seharusnya sudah memiliki sistem lain: API Terbuka, API Gateway.
API terbuka
Mari kita lihat lagi angka-angkanya dan bagaimana Open API bekerja sekarang. Bebannya adalah
10.000 transaksi per detik . Karena kami berencana untuk secara aktif mengembangkan lapisan layanan-mikro dan membangun API publik MegaFon, kami mengharapkan lebih banyak pertumbuhan di masa depan di bagian khusus ini.
100.000 transaksi pasti akan terjadi .
Saya tidak tahu apakah SSO sebanding dengan Mail.ru - orang-orang, seperti, memiliki 1.000.000 transaksi per detik. Kami sangat tertarik dengan solusi mereka dan kami berencana untuk belajar dari pengalaman mereka - misalnya, untuk membuat cadangan SSO fungsional menggunakan Tarantool. Sekarang pengembang dari Mail.ru melakukan ini bersama kami.
CRM
CRM - ini adalah 80 juta pelanggan yang ingin kami bawa ke satu miliar, karena sudah ada 300 juta dokumen yang mencakup sejarah tiga tahun. Kami benar-benar menantikan layanan baru, dan di sini
titik pertumbuhannya adalah layanan yang terhubung . Ini adalah bola yang akan tumbuh, karena akan ada semakin banyak layanan. Oleh karena itu, sebuah cerita akan dibutuhkan, kami tidak ingin tersandung pada ini.
Penagihan itu sendiri dalam hal penagihan, bekerja dengan piutang pelanggan
diubah menjadi domain terpisah . Untuk memaksimalkan kinerja,
template arsitektur arsitektur domain diterapkan .
Sistem ini dibagi menjadi beberapa domain, beban didistribusikan dan toleransi kesalahan disediakan. Selain itu, kami bekerja dengan arsitektur terdistribusi.
Yang lainnya adalah solusi tingkat perusahaan. Di toko panggilan -
2 miliar per hari , 60 miliar per bulan. Kadang-kadang Anda harus menghitung ulang selama sebulan, dan lebih cepat lebih baik.
Pemantauan keuangan adalah persis 300 juta yang terus tumbuh dan berkembang: pelanggan sering berjalan di antara operator, meningkatkan bagian ini.
Komponen komunikasi seluler yang paling telekomunikasi adalah
tagihan online . Ini adalah sistem yang memungkinkan Anda untuk menelepon atau tidak menelepon, membuat keputusan secara real time. Di sini, bebannya adalah 30.000 transaksi per detik, tetapi dengan mempertimbangkan pertumbuhan transfer data, kami merencanakan
250.000 transaksi , dan oleh karena itu kami sangat tertarik dengan Tarantool.
Gambar sebelumnya adalah domain tempat kita akan menggunakan Tarantool. CRM itu sendiri, tentu saja, lebih luas dan kami akan menerapkannya dalam inti itu sendiri.
Perkiraan TTX 100 juta pelanggan kami membingungkan saya sebagai arsitek - bagaimana jika 101 juta? Untuk mengulang semuanya lagi? Untuk mencegah hal ini, kami menggunakan cache, sekaligus meningkatkan aksesibilitas.
Secara umum, ada dua pendekatan untuk menggunakan Tarantool. Yang pertama adalah
membangun semua cache di tingkat layanan-mikro . Seperti yang saya pahami, VimpelCom mengikuti jalur ini, membuat cache klien.
Kami kurang tergantung pada vendor, kami mengubah inti BSS, jadi kami memiliki indeks kartu klien tunggal di luar kotak. Tapi kami ingin menyulamnya. Oleh karena itu, kami menggunakan pendekatan yang sedikit berbeda -
kami membuat cache di dalam sistem .
Jadi ada kurang dari rassynchron - satu sistem bertanggung jawab atas cache dan sumber master utama.
Metode ini sangat cocok dengan pendekatan kerangka transaksional Tarantool, ketika hanya bagian yang terkait dengan pembaruan, mis. Perubahan data, yang diperbarui. Segala sesuatu yang lain dapat disimpan di tempat lain. Tidak ada danau data besar, cache global tidak dikelola. Cache dirancang untuk sistem, baik untuk produk, atau untuk pelanggan, atau untuk membuat hidup lebih mudah untuk layanan ini. Ketika seorang pelanggan merasa kesal dengan kualitas, saya ingin melayaninya secara kualitatif.
RTO dan RPO
Ada dua istilah dalam IT -
RTO dan
RPO .
Sasaran waktu pemulihan adalah waktu untuk memulihkan layanan setelah kegagalan. RTO = 0 berarti bahwa bahkan jika sesuatu jatuh, layanan tetap berfungsi.
Tujuan titik pemulihan adalah waktu untuk memulihkan data, berapa banyak data yang bisa hilang selama periode waktu tertentu. RPO = 0 berarti kita tidak kehilangan data.
Tantangan Tarantool
Mari kita coba selesaikan masalah untuk Tarantool.
Diberikan : semua orang memahami keranjang aplikasi, misalnya, di Amazon atau di tempat lain. Keranjang
diharuskan untuk bekerja 24 jam 7 hari seminggu, atau 99,99% dari waktu. Pesanan yang datang kepada kami harus tetap tertib, karena kami tidak dapat mengaktifkan atau menonaktifkan komunikasi untuk pelanggan secara acak - semuanya harus sangat konsisten. Langganan sebelumnya mempengaruhi berikutnya, sehingga datanya penting - tidak ada yang harus hilang.
Solusi Anda dapat mencoba menyelesaikannya langsung dan bertanya kepada pengembang database, tetapi masalahnya tidak terpecahkan secara matematis. Seseorang dapat mengingat teorema, hukum konservasi, fisika kuantum, tetapi mengapa - itu tidak dapat diselesaikan pada tingkat DB.
Pendekatan arsitektur lama yang baik bekerja di sini - Anda perlu mengetahui area subjek dengan baik dan dengan biayanya menyelesaikan rebus ini.
Solusi kami: buat daftar aplikasi terdistribusi untuk Tarantool - sebuah cluster yang didistribusikan secara geografis . Dalam diagram, ini adalah tiga pusat data yang berbeda - dua ke Ural, satu di luar Ural, dan kami mendistribusikan semua aplikasi ke pusat ini.
Netflix, yang sekarang dianggap sebagai salah satu pemimpin di bidang TI, hanya memiliki satu pusat data hingga 2012. Menjelang Natal Katolik pada 24 Desember, pusat data ini runtuh. Pengguna Kanada dan Amerika Serikat dibiarkan tanpa film favorit mereka, sangat kesal dan menulis tentang ini di jejaring sosial. Netflix sekarang memiliki tiga pusat data di pantai barat-timur dan satu di Eropa barat.
Kami awalnya membangun solusi geo-didistribusikan - toleransi kesalahan penting bagi kami.
Jadi, kami memiliki cluster, tetapi bagaimana dengan RPO = 0 dan RTO = 0? Solusinya sederhana, yang tergantung pada subjek.
Apa yang penting dalam aplikasi? Dua bagian: melempar keranjang
SEBELUM membuat keputusan pembelian, dan
SETELAH . Bagian dari DO dalam telekomunikasi biasanya disebut
perintah penangkapan atau
negosiasi pesanan . Dalam telekomunikasi, ini bisa jauh lebih rumit daripada di toko online, karena di sana Anda perlu melayani klien, menawarkan 5 opsi, dan ini semua terjadi untuk sementara waktu, tetapi keranjangnya penuh. Pada titik ini, kegagalan adalah mungkin, tetapi itu tidak menakutkan, karena itu terjadi dalam mode interaktif di bawah pengawasan seseorang.
Jika pusat data Moskow tiba-tiba gagal, maka secara otomatis beralih ke pusat data lain, kami akan terus bekerja. Secara teoritis, satu produk dalam keranjang mungkin hilang, tetapi Anda melihat ini, menambah keranjang lagi dan terus bekerja. Dalam hal ini, RTO = 0.
Pada saat yang sama, ada opsi kedua: ketika kami mengklik "kirim", kami ingin data tidak hilang. Mulai saat ini, otomatisasi mulai berfungsi - ini sudah RPO = 0. Aplikasi dari dua pola yang berbeda ini dalam satu kasus dapat menjadi hanya sebuah cluster yang didistribusikan secara geografis dengan satu master yang dapat dialihkan, dalam kasus lain semacam entri kuorum. Pola dapat bervariasi, tetapi kami menyelesaikan masalahnya.
Selain itu, dengan memiliki daftar aplikasi yang terdistribusi, kami juga dapat mengatur skala semuanya - untuk memiliki banyak operator dan kontraktor yang mengakses registri ini.
Cassandra dan Tarantool bersama
Ada kasus lain -
"showcase of balance .
" Ini hanya kasus menarik dari penggunaan bersama Cassandra dan Tarantool.
Kami menggunakan Cassandra, karena 2 miliar panggilan per hari bukan batasnya, dan akan ada lebih banyak. Pemasar suka mewarnai lalu lintas berdasarkan sumber, ada semakin banyak detail di jejaring sosial, misalnya. Ini semua menambah cerita.
Cassandra memungkinkan Anda untuk skala secara horizontal ke volume apa pun.
Kami merasa nyaman dengan Cassandra, tetapi ia memiliki satu masalah - ia tidak pandai membaca. , 30 000 —
.
, : , - , Cassandra. , IBM manager file transfer — , , UDP, , TCP. , , , - , — .
,
. Kafka Tarantool, , , ,
, , , 100 2 .
, 2 , , .
Kesimpulan
Tarantool. Mail.ru, .
BCG McKinsey, Accenture IBM - — , , , , . , Tarantool . .
— Tarantool Conference , 17 T+ Conference 2019 « Tarantool Enterprise» . « Tarantool Oracle» . , , . — , . : , Tarantool, , , .