Bidikan dari film "Our Secret Universe: The Hidden Life of the Cell"

Bisnis investasi adalah salah satu bidang yang paling sulit di dunia perbankan, karena tidak hanya pinjaman, pinjaman dan simpanan, tetapi juga sekuritas, mata uang, barang, turunan dan segala macam kesulitan dalam bentuk produk struktural.

Baru-baru ini, kita telah melihat peningkatan literasi keuangan populasi. Semakin banyak orang terlibat dalam perdagangan di pasar sekuritas. Akun investasi individu muncul belum lama ini. Mereka memungkinkan Anda untuk berdagang di pasar sekuritas dan pada saat yang sama menerima potongan pajak atau tidak membayar pajak. Dan semua pelanggan yang datang kepada kami ingin mengelola portofolio mereka dan melihat pelaporan waktu nyata. Selain itu, paling sering portofolio ini adalah multi-produk, yaitu, orang adalah pelanggan dari berbagai lini bisnis.

Selain itu, persyaratan regulator, baik Rusia maupun asing, semakin meningkat.

Untuk memenuhi kebutuhan saat ini dan meletakkan dasar untuk peningkatan di masa depan, kami telah mengembangkan inti dari bisnis investasi berdasarkan Tarantool.

Beberapa statistik. Bisnis investasi Alfa-Bank menyediakan layanan broker untuk perorangan dan badan hukum untuk memberikan peluang perdagangan di berbagai pasar sekuritas, layanan penyimpanan untuk penyimpanan sekuritas, layanan manajemen kepercayaan untuk individu dengan modal besar dan swasta, layanan penerbitan sekuritas untuk perusahaan lain. Bisnis investasi Alfa-Bank lebih dari 3 ribu penawaran per detik, yang diunduh dari berbagai platform perdagangan. Selama hari kerja, lebih dari 300 ribu transaksi diselesaikan di pasar atas nama bank atau pelanggannya. Pada platform eksternal dan internal, hingga 5 ribu pesanan dieksekusi per detik. Pada saat yang sama, semua pelanggan, baik internal maupun eksternal, ingin melihat posisi mereka secara real time.

Latar Belakang

Di suatu tempat dari awal tahun 2000-an, bidang bisnis investasi kami telah berkembang secara independen: perdagangan pertukaran, layanan perantara, perdagangan mata uang, perdagangan bebas di sekuritas dan berbagai derivatif. Akibatnya, kami jatuh ke dalam perangkap sumur fungsional. Apa itu? Setiap lini bisnis memiliki sistem sendiri yang menduplikasi fungsi masing-masing. Setiap sistem memiliki model datanya sendiri, meskipun mereka beroperasi pada konsep yang sama: transaksi, instrumen, rekanan, penawaran dan banyak lagi. Dan karena setiap sistem dikembangkan secara independen, beragam kebun binatang teknologi muncul.

Selain itu, basis kode sistem sudah usang, karena beberapa produk berasal pada pertengahan 1990-an. Dan di beberapa daerah, memperlambat proses pengembangan, ada masalah dengan produktivitas.

Persyaratan Solusi Baru

Bisnis menyadari bahwa pengembangan teknologi sangat penting untuk pengembangan lebih lanjut. Kami diberi tugas:

Kumpulkan semua data bisnis dalam satu penyimpanan cepat dan dalam model data tunggal.
Kami tidak boleh kehilangan atau mengubah informasi ini.
Diperlukan versi data, karena setiap saat regulator dapat meminta statistik untuk tahun-tahun sebelumnya.
Kita seharusnya tidak hanya membawa beberapa DBMS baru yang modis, tetapi menciptakan platform untuk memecahkan masalah bisnis.

Selain itu, arsitek kami menetapkan kondisinya:

Solusi baru harus kelas perusahaan, yaitu harus sudah diuji di beberapa perusahaan besar.
Cara pengoperasian solusi harus kritis misi. Ini berarti bahwa kita harus hadir pada saat yang sama di beberapa pusat data dan dengan tenang mengalami pemutusan satu pusat data.
. , , - . , .
, .

Kami menggunakan cara standar: merumuskan persyaratan dan menghubungi departemen pengadaan. Dari sana kami mendapat daftar perusahaan yang, secara umum, siap untuk kami lakukan. Mereka memberi tahu semua orang tentang tugas itu, dan enam dari mereka menerima penilaian solusi.

Kami di bank tidak percaya dengan kata-kata siapa pun, kami senang menguji semuanya sendiri. Karena itu, prasyarat kompetisi tender kami adalah lulus tes stres. Kami merumuskan tugas pengujian untuk beban, dan sudah tiga dari enam perusahaan sepakat dengan biaya mereka sendiri untuk mengimplementasikan prototipe solusi berdasarkan pada teknologi dalam memori untuk mengujinya.

Saya tidak akan memberi tahu bagaimana kami menguji semuanya dan berapa lama, saya hanya akan meringkas: kinerja terbaik dalam uji beban ditunjukkan oleh prototipe solusi berbasis Tarantool dari tim pengembangan Grup Mail.ru. Kami menandatangani kontrak dan memulai pengembangan. Empat orang berasal dari Mail.ru Group, dan dari Alfa-Bank ada tiga pengembang, tiga analis sistem, arsitek solusi, pemilik produk, dan master Scrum.

Selanjutnya, saya akan berbicara tentang bagaimana sistem kami tumbuh, bagaimana itu berkembang, apa yang kami lakukan dan mengapa.

Pengembangan

Pertama-tama, kami bertanya-tanya bagaimana cara mendapatkan data dari sistem kami saat ini. Kami memutuskan bahwa HTTP cukup cocok untuk kami, karena semua sistem saat ini berkomunikasi satu sama lain, mengirimkan XML atau JSON melalui HTTP.

Kami menggunakan server HTTP Tarantool bawaan, karena kami tidak perlu mengakhiri sesi SSL, dan kinerjanya cukup bagi kami.

Seperti yang sudah saya katakan, kita memiliki semua sistem yang hidup dalam model data yang berbeda, dan pada input kita perlu membawa objek ke model yang akan kita gambarkan di rumah. Diperlukan bahasa untuk mengubah data. Kami memilih Lua imperatif. Kami menjalankan semua kode untuk konversi data di kotak pasir - ini adalah tempat yang aman, di luar itu kode yang berjalan tidak melampaui. Untuk melakukan ini, cukup lakukan loadstring dari kode yang diperlukan, menciptakan lingkungan dengan fungsi yang tidak dapat memblokir apa pun atau menjatuhkan sesuatu.

Setelah konversi, data harus diperiksa untuk kesesuaian dengan model yang kami buat. Kami sudah lama berdiskusi tentang model apa, bahasa apa yang digunakan untuk menggambarkannya. Kami berhenti di Apache Avro, karena bahasanya sederhana dan mendapat dukungan dari Tarantool. Versi baru model dan kode pengguna dapat dioperasikan beberapa kali sehari, bahkan di bawah beban, bahkan tanpa, kapan saja, dan sangat cepat beradaptasi dengan perubahan.

Setelah verifikasi, data harus disimpan. Kami melakukan ini dengan vshard (kami memiliki replika pecahan geo-spaced).

Selain itu, spesifikasinya sedemikian rupa sehingga bagi sebagian besar sistem yang mengirimkan data kepada kami, tidak masalah apakah kami menerimanya atau tidak. Karena itu, sejak awal kami menerapkan jalur perbaikan. Apa itu? Jika karena alasan tertentu objek tidak lulus transformasi data atau verifikasi, maka kami masih mengkonfirmasi tanda terima, tetapi pada saat yang sama kami menyimpan objek dalam antrian perbaikan. Itu konsisten, terletak di repositori utama dengan data bisnis. Kami segera menulis antarmuka admin untuk itu, berbagai metrik, dan peringatan. Akibatnya, kami tidak kehilangan data. Bahkan jika sesuatu telah berubah di sumbernya, jika model data telah berubah, kami akan segera menemukannya dan dapat beradaptasi.

Sekarang Anda perlu belajar cara mengambil data yang tersimpan. Kami dengan hati-hati menganalisis sistem kami dan melihat bahwa pada tumpukan klasik dari Java dan Oracle selalu ada semacam ORM yang mengubah data dari tampilan relasional ke objek. Jadi mengapa tidak segera memberikan objek ke sistem dalam bentuk grafik? Karena itu, kami dengan senang hati mengambil GraphQL, yang memenuhi semua kebutuhan kami. Ini memungkinkan Anda untuk menerima data dalam bentuk grafik, hanya untuk menarik apa yang Anda butuhkan saat ini. Anda bahkan dapat membuat versi API dengan fleksibilitas yang cukup.

Hampir segera, kami menyadari bahwa data yang diekstraksi tidak cukup bagi kami. Kami membuat fungsi yang dapat dilampirkan ke objek dalam model - pada kenyataannya, bidang yang dihitung. Artinya, kami melampirkan fungsi tertentu ke bidang, yang, misalnya, mempertimbangkan harga rata-rata penawaran. Dan konsumen eksternal yang meminta data bahkan tidak tahu bahwa bidang ini dihitung.

Menerapkan sistem otentikasi.

Kemudian mereka memperhatikan bahwa beberapa peran mengkristal dalam solusi kami. Peran adalah sejenis agregator fungsi. Sebagai aturan, peran memiliki profil penggunaan peralatan yang berbeda:

T-Connect: menangani koneksi yang masuk, dibatasi oleh prosesor, menghabiskan sedikit memori, tidak menyimpan status.
IB-Core: mengubah data yang diterimanya melalui protokol Tarantool, yaitu, beroperasi dengan tablet. Juga tidak menyimpan status dan dapat diskalakan.
Penyimpanan: hanya menyimpan data, tidak menggunakan logika apa pun. Antarmuka paling sederhana diimplementasikan dalam peran ini. Terukur berkat vshard.

Yaitu, dengan bantuan peran, kami melepaskan ikatan satu sama lain dari bagian berbeda dari gugus yang dapat ditingkatkan secara independen satu sama lain.

Jadi, kami membuat catatan asinkron dari aliran data transaksional dan antrian perbaikan dengan antarmuka administrator. Perekaman tidak sinkron dari sudut pandang bisnis: jika kami dijamin untuk merekam data kepada diri kami sendiri, di mana pun, maka kami akan mengonfirmasi hal ini. Jika tidak dikonfirmasi, maka ada yang tidak beres, data perlu dikirim. Ini adalah rekaman asinkron.

Pengujian

Sejak awal proyek diputuskan bahwa kami akan mencoba menanamkan pengembangan yang digerakkan oleh pengujian. Kami menulis tes unit dalam Lua menggunakan kerangka tarantool / tap, tes integrasi dengan Python menggunakan kerangka pytest. Pada saat yang sama, baik pengembang dan analis terlibat dalam penulisan tes integrasi.

Bagaimana kita menerapkan pengembangan yang digerakkan oleh tes?

Jika kita menginginkan beberapa fitur baru, pertama-tama kita mencoba menulis tes untuk itu. Setelah menemukan bug, pertama-tama kita harus menulis tes, dan baru kemudian memperbaikinya. Pada awalnya, sulit untuk bekerja seperti itu, ada kesalahpahaman di pihak karyawan, bahkan sabotase: "Mari kita perbaiki dengan cepat, lakukan sesuatu yang baru, dan kemudian tutup dengan tes." Hanya ini "nanti" hampir tidak pernah terjadi.

Karena itu, pertama-tama Anda harus memaksakan diri untuk menulis tes, meminta orang lain untuk melakukannya. Percayalah, pengembangan yang digerakkan oleh tes bermanfaat bahkan dalam jangka pendek. Anda akan merasa bahwa hidup Anda menjadi lebih mudah. Menurut perasaan kami, 99% kode dilindungi oleh tes sekarang. Sepertinya banyak, tapi kami tidak punya masalah: tes dijalankan pada setiap komit.

Namun, yang paling penting dari kami adalah stress testing, kami menganggapnya yang paling penting dan secara teratur melakukannya.

Saya akan menceritakan kepada Anda sebuah cerita pendek tentang bagaimana kami melakukan pengujian beban tahap pertama dari salah satu versi pertama. Kami menempatkan sistem pada laptop pengembang, menyalakan beban dan menerima 4 ribu transaksi per detik. Hasil yang bagus untuk laptop. Kami memakai virtual load stand empat server, lebih lemah dari pada produksi. Digunakan seminimal mungkin. Kami memulainya, dan kami mendapatkan hasil yang lebih buruk daripada di laptop dalam satu utas. Konten kejutan.

Kami sangat sedih. Kami melihat beban server, dan ternyata tidak digunakan.

Kami memanggil pengembang, dan mereka menjelaskan kepada kami, orang-orang yang datang dari dunia Java, bahwa Tarantool adalah single-threaded. Itu dapat secara efektif digunakan oleh hanya satu inti prosesor yang sedang di-load. Kemudian kami menggunakan jumlah maksimum yang mungkin dari instance Tarantool di setiap server, menyalakan beban dan menerima sudah 14,5 ribu transaksi per detik.

Saya akan menjelaskannya lagi. Karena pembagian ke peran yang menggunakan sumber daya berbeda, peran kami yang bertanggung jawab untuk memproses koneksi dan transformasi data hanya memuat prosesor, dan itu benar-benar sebanding dengan beban.

Selain itu, memori hanya digunakan untuk memproses koneksi masuk dan objek sementara.

Sebaliknya, pada server penyimpanan, beban prosesor tumbuh, tetapi jauh lebih lambat daripada pada server yang menangani koneksi.

Dan konsumsi memori tumbuh dalam proporsi langsung ke jumlah data yang dimuat.

Jasa

Untuk mengembangkan produk baru kami secara khusus sebagai platform aplikasi, kami membuat komponen untuk menyebarkan layanan dan perpustakaan di atasnya.

Layanan bukan hanya potongan kecil kode yang beroperasi di beberapa bidang. Mereka dapat berupa desain yang cukup besar dan kompleks yang merupakan bagian dari cluster, periksa data referensi, memutar logika bisnis dan memberikan jawaban. Kami juga mengekspor skema layanan ke GraphQL, dan konsumen menerima titik akses data universal, dengan introspeksi seluruh model. Sangat nyaman.

Karena layanan mengandung lebih banyak fungsi, kami memutuskan bahwa harus ada perpustakaan tempat kami akan mengeluarkan kode yang sering digunakan. Kami menambahkannya ke lingkungan yang aman, setelah memeriksa bahwa ini tidak merusak apa pun bagi kami. Dan sekarang kita dapat mengatur fungsi untuk lingkungan tambahan dalam bentuk perpustakaan.

Kami ingin kami memiliki platform tidak hanya untuk penyimpanan, tetapi juga untuk komputasi. Dan karena kami sudah memiliki banyak replika dan pecahan, kami menerapkan kemiripan komputasi terdistribusi dan menyebutnya sebagai pengurangan peta, karena ternyata itu seperti pengurangan peta asli.

Sistem lama

Tidak semua sistem lama kami dapat menghubungi kami melalui HTTP dan menggunakan GraphQL, meskipun mereka mendukung protokol ini. Oleh karena itu, kami membuat mekanisme untuk mereplikasi data ke sistem ini.

Jika ada perubahan bagi kami, pemicu khusus berfungsi dalam peran Penyimpanan dan pesan dengan perubahan masuk ke antrean pemrosesan. Ini dikirim ke sistem eksternal menggunakan peran replikator yang terpisah. Peran ini tidak menyimpan status.

Perbaikan baru

Seingat Anda, dari perspektif bisnis, kami membuat rekaman tidak sinkron. Tetapi kemudian mereka menyadari bahwa itu tidak akan cukup, karena ada kelas sistem yang perlu segera menerima jawaban tentang status operasi. Oleh karena itu, kami telah memperluas GraphQL kami dan menambahkan mutasi. Mereka secara organik cocok dengan paradigma yang ada bekerja dengan data. Kami memiliki satu titik baik membaca dan menulis untuk kelas sistem lain.

Kami juga menyadari bahwa layanan saja tidak akan cukup bagi kami, karena ada laporan yang cukup berat yang perlu dibangun sekali sehari, seminggu, sebulan. Ini bisa memakan waktu lama, dan laporan bahkan dapat memblokir loop acara Tarantool. Karenanya, kami membuat peran terpisah: scheduler dan runner. Pelari tidak menyimpan status. Mereka meluncurkan tugas-tugas sulit, yang tidak bisa kita andalkan dengan cepat. Dan peran penjadwal memonitor jadwal untuk meluncurkan tugas-tugas ini, yang dijelaskan dalam konfigurasi. Tugas itu sendiri disimpan di tempat yang sama dengan data bisnis. Ketika waktu yang tepat tiba, scheduler mengambil tugas, memberikannya kepada beberapa pelari, ia mempertimbangkannya dan menyimpan hasilnya.

Tidak semua tugas harus dijalankan sesuai jadwal. Beberapa laporan harus dibaca sesuai permintaan. Begitu persyaratan ini tiba, tugas dibentuk di kotak pasir dan dikirim ke pelari untuk dieksekusi. Setelah beberapa saat, pengguna menerima jawaban secara tidak sinkron bahwa semuanya telah dihitung, laporannya siap.

Awalnya, kami berpegang pada paradigma menyimpan semua data, membuat versi dan tidak menghapusnya. Namun dalam kehidupan, dari waktu ke waktu, Anda masih harus menghapus sesuatu, terutama beberapa informasi mentah atau perantara. Berdasarkan kedaluwarsa, kami membuat mekanisme untuk membersihkan penyimpanan data yang sudah usang.

Kami juga memahami bahwa cepat atau lambat suatu situasi akan datang ketika tidak akan ada cukup ruang untuk menyimpan data dalam memori, namun demikian data tersebut harus disimpan. Untuk keperluan ini, kami akan segera membuat penyimpanan disk.

Kesimpulan

Kami mulai dengan tugas memuat data ke dalam model tunggal, menghabiskan waktu tiga bulan untuk pengembangannya. Kami memiliki enam sistem penyedia data. Seluruh kode transformasi menjadi model tunggal adalah sekitar 30 ribu baris dalam Lua. Dan sebagian besar pekerjaan belum datang. Kadang-kadang ada kurangnya motivasi untuk tim tetangga, banyak yang menyulitkan pekerjaan keadaan. Jika Anda pernah menghadapi masalah yang sama, maka waktu yang Anda anggap normal untuk implementasinya, kalikan tiga, atau bahkan empat.

Juga ingat bahwa masalah yang ada dalam proses bisnis tidak dapat diselesaikan dengan bantuan DBMS baru, bahkan jika itu sangat produktif. Apa yang saya maksud? Pada awal proyek kami, kami menciptakan kesan di antara pelanggan bahwa sekarang kami akan membawa database cepat baru dan hidup! Proses akan berjalan lebih cepat, semuanya akan baik-baik saja. Padahal, teknologi tidak menyelesaikan masalah yang ada dalam proses bisnis, karena proses bisnis adalah manusia. Dan Anda perlu bekerja dengan orang, bukan teknologi.

Pengembangan melalui pengujian pada tahap awal dapat menyakitkan dan memakan waktu. Tetapi efek positifnya akan terlihat bahkan dalam jangka pendek, ketika Anda tidak perlu melakukan apa pun untuk melakukan pengujian regresi.

Sangat penting untuk melakukan pengujian beban di semua tahap pengembangan. Semakin cepat Anda melihat beberapa jenis cacat dalam arsitektur, semakin mudah untuk memperbaikinya, ini akan menghemat banyak waktu di masa depan.

Tidak ada yang salah dengan Lua. Siapa pun dapat belajar menulis di atasnya: pengembang Java, pengembang JavaScript, pengembang Python, front-end atau back-end. Kami bahkan memiliki analis yang menuliskannya.

Ketika kita berbicara tentang fakta bahwa kita tidak memiliki SQL, ini menakutkan orang. "Bagaimana Anda mendapatkan data tanpa SQL?" Apakah itu mungkin? " Tentu saja. Pada sistem kelas OLTP, SQL tidak diperlukan. Ada alternatif dalam bentuk bahasa yang segera mengembalikan Anda tampilan berorientasi dokumen. Misalnya, GraphQL. Dan ada alternatif dalam bentuk komputasi terdistribusi.

Jika Anda memahami bahwa Anda perlu melakukan penskalaan, maka rancang solusi Anda di Tarantool, segera sehingga dapat bekerja secara paralel pada puluhan instance Tarantool. Jika tidak, maka akan sulit dan menyakitkan, karena Tarantool dapat secara efisien menggunakan hanya satu inti prosesor.

Bagaimana kami melakukan inti bisnis investasi Alfa-Bank berdasarkan Tarantool