Potongan gambar dari film “Our Secret Universe: The Hidden Life of the Cell”

Bisnis investasi merupakan salah satu bidang yang paling kompleks dalam dunia perbankan, karena tidak hanya pinjaman, peminjaman dan simpanan, tetapi juga surat berharga, mata uang, komoditas, derivatif dan segala macam kompleksitas dalam bentuk produk terstruktur.

Baru-baru ini, kita telah melihat peningkatan literasi keuangan masyarakat. Semakin banyak orang terlibat dalam perdagangan di pasar sekuritas. Rekening investasi individu muncul belum lama ini. Mereka memungkinkan Anda untuk berdagang di pasar sekuritas dan menerima pengurangan pajak atau menghindari pembayaran pajak. Dan semua klien yang datang kepada kami ingin mengelola portofolionya dan melihat pelaporan secara real time. Apalagi portofolio ini paling sering bersifat multiproduk, yaitu klien dari berbagai lini bisnis.

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

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

Beberapa statistik. Usaha investasi Alfa-Bank menyediakan jasa perantara bagi perorangan dan badan hukum untuk memberikan kesempatan berdagang di berbagai pasar surat berharga, jasa penyimpanan untuk penyimpanan surat berharga, jasa pengelolaan perwalian bagi perorangan yang bermodal swasta dan besar, jasa penerbitan surat berharga bagi perusahaan lain. . Bisnis investasi Alfa-Bank mencakup lebih dari 3 ribu kutipan per detik, yang diunduh dari berbagai platform perdagangan. Selama hari kerja, lebih dari 300 ribu transaksi diselesaikan di pasar atas nama bank atau kliennya. Hingga 5 ribu eksekusi order per detik terjadi pada platform eksternal dan internal. Pada saat yang sama, semua klien, baik internal maupun eksternal, ingin melihat posisi mereka secara real time.

prasejarah

Sejak awal tahun 2000-an, bidang bisnis investasi kami berkembang secara mandiri: perdagangan bursa, layanan pialang, perdagangan mata uang, perdagangan sekuritas over-the-counter, dan berbagai derivatif. Akibatnya, kita terjerumus ke dalam perangkap sumur fungsional. Apa itu? Setiap lini bisnis mempunyai sistem tersendiri yang menduplikasi fungsi masing-masing. Setiap sistem memiliki model datanya sendiri, meskipun beroperasi dengan konsep yang sama: transaksi, instrumen, pihak lawan, kuotasi, dan sebagainya. Dan seiring dengan berkembangnya masing-masing sistem secara independen, beragam teknologi bermunculan.

Selain itu, basis kode sistem sudah cukup ketinggalan jaman, karena beberapa produk berasal dari pertengahan tahun 1990an. Dan di beberapa daerah, hal ini memperlambat proses pembangunan dan menimbulkan masalah kinerja.

Persyaratan untuk solusi baru

Dunia usaha telah menyadari bahwa transformasi teknologi sangat penting untuk pengembangan lebih lanjut. Kami diberi tugas:

1. Kumpulkan semua data bisnis dalam satu penyimpanan cepat dan dalam satu model data.
2. Kita tidak boleh kehilangan atau mengubah informasi ini.
3. Data perlu dibuat versinya, karena sewaktu-waktu regulator dapat meminta statistik tahun-tahun sebelumnya.
4. Kita tidak hanya harus menghadirkan DBMS baru yang modis, tetapi juga menciptakan platform untuk memecahkan masalah bisnis.

Selain itu, arsitek kami menetapkan ketentuannya sendiri:

1. Solusi baru harus berkelas perusahaan, yaitu harus sudah diuji di beberapa perusahaan besar.
2. Mode operasi solusi harus menjadi misi penting. Artinya kita harus hadir di beberapa data center secara bersamaan dan dengan tenang bertahan jika terjadi pemadaman di satu data center.
3. Sistem harus dapat diskalakan secara horizontal. Faktanya adalah bahwa semua sistem kami saat ini hanya dapat diskalakan secara vertikal, dan kami sudah mencapai puncaknya karena rendahnya pertumbuhan kekuatan perangkat keras. Oleh karena itu, saatnya telah tiba ketika kita perlu memiliki sistem yang dapat diskalakan secara horizontal agar dapat bertahan.
4. Antara lain, kami diberitahu bahwa solusinya harus murah.

Kami mengikuti jalur standar: kami merumuskan persyaratan dan menghubungi departemen pembelian. Dari situ kami mendapat daftar perusahaan yang secara umum siap melakukan ini untuk kami. Kami memberi tahu semua orang tentang masalahnya, dan menerima penilaian atas solusi dari enam orang di antaranya.

Di bank, kami tidak mempercayai kata-kata siapa pun; kami ingin menguji semuanya sendiri. Oleh karena itu, syarat wajib kompetisi tender kami adalah lulus uji beban. Kami merumuskan tugas uji beban, dan tiga dari enam perusahaan telah setuju untuk menerapkan solusi prototipe berdasarkan teknologi dalam memori dengan biaya sendiri untuk mengujinya.

Saya tidak akan memberi tahu Anda bagaimana kami menguji semuanya dan berapa lama waktu yang dibutuhkan, saya hanya akan meringkas: kinerja terbaik dalam pengujian beban ditunjukkan oleh solusi prototipe berdasarkan Tarantool dari tim pengembangan Grup Mail.ru. Kami menandatangani perjanjian dan memulai pengembangan. Ada empat orang dari Mail.ru Group, dan dari Alfa-Bank ada tiga pengembang, tiga analis sistem, seorang arsitek solusi, seorang pemilik produk dan seorang master Scrum.

Selanjutnya saya akan memberi tahu Anda tentang bagaimana sistem kami berkembang, bagaimana sistem berkembang, apa yang kami lakukan, dan mengapa hal ini terjadi.

Pembangunan

Pertanyaan pertama yang kami tanyakan pada diri kami adalah 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 dengan mengirimkan XML atau JSON melalui HTTP.

Kami menggunakan server HTTP yang dibangun di Tarantool karena kami tidak perlu menghentikan sesi SSL, dan kinerjanya cukup bagi kami.

Seperti yang sudah saya katakan, semua sistem kita hidup dalam model data yang berbeda, dan sebagai masukan kita perlu membawa objek ke model yang kita gambarkan sendiri. Diperlukan bahasa yang memungkinkan data diubah. Kami memilih Lua imperatif. Kami menjalankan semua kode konversi data di kotak pasir - ini adalah tempat aman di mana kode yang sedang berjalan tidak dapat dilewati. Untuk melakukan ini, kita cukup memuat kode yang diperlukan, menciptakan lingkungan dengan fungsi yang tidak dapat memblokir atau menghapus apa pun.

Setelah konversi, data harus diperiksa kesesuaiannya dengan model yang kita buat. Kami sudah lama berdiskusi tentang model apa yang seharusnya dan bahasa apa yang digunakan untuk mendeskripsikannya. Kami memilih Apache Avro karena bahasanya sederhana dan mendapat dukungan dari Tarantool. Versi baru model dan kode khusus dapat dioperasikan beberapa kali sehari, bahkan saat dimuat atau tanpa beban, kapan saja sepanjang hari, dan beradaptasi dengan perubahan dengan sangat cepat.

Setelah verifikasi, data harus disimpan. Kami melakukan ini menggunakan vshard (kami memiliki replika pecahan yang tersebar secara geografis).

Selain itu, kekhususannya sedemikian rupa sehingga sebagian besar sistem yang mengirimkan data kepada kami tidak peduli apakah kami menerimanya atau tidak. Itu sebabnya kami menerapkan antrian perbaikan sejak awal. Apa itu? Jika karena alasan tertentu suatu objek tidak mengalami transformasi data atau verifikasi, kami tetap mengkonfirmasi penerimaan, tetapi pada saat yang sama menyimpan objek tersebut dalam antrian perbaikan. Itu konsisten dan terletak di gudang data bisnis utama. Kami segera menulis antarmuka administrator untuknya, berbagai metrik dan peringatan. Hasilnya, kami tidak kehilangan data. Kalaupun ada yang berubah pada sumbernya, namun jika model datanya berubah, kami akan segera mendeteksinya dan bisa beradaptasi.

Sekarang Anda perlu mempelajari cara mengambil data yang disimpan. Kami menganalisis sistem kami dengan cermat dan melihat bahwa tumpukan klasik Java dan Oracle tentu berisi semacam ORM yang mengubah data dari relasional menjadi objek. Lalu mengapa tidak segera memberikan objek ke sistem dalam bentuk grafik? Jadi kami dengan senang hati mengadopsi GraphQL, yang memenuhi semua kebutuhan kami. Ini memungkinkan Anda menerima data dalam bentuk grafik dan hanya mengeluarkan apa yang Anda perlukan saat ini. Anda bahkan dapat membuat versi API dengan cukup banyak fleksibilitas.

Kami segera menyadari bahwa data yang kami ekstrak tidaklah cukup. Kami membuat fungsi yang dapat ditautkan ke objek dalam model - pada dasarnya bidang terhitung. Artinya, kami melampirkan fungsi tertentu ke bidang, yang, misalnya, menghitung harga penawaran rata-rata. Dan konsumen eksternal yang meminta data bahkan tidak mengetahui bahwa ini adalah bidang terhitung.

Menerapkan sistem otentikasi.

Kemudian kami memperhatikan bahwa beberapa peran mengkristal dalam keputusan kami. Peran adalah sejenis agregator fungsi. Biasanya, peran memiliki profil penggunaan peralatan yang berbeda:

• T-Connect: menangani koneksi masuk, CPU terbatas, konsumsi memori rendah, tanpa kewarganegaraan.
• IB-Core: mengubah data yang diterimanya melalui protokol Tarantool, yaitu beroperasi dengan tabel. Itu juga tidak menyimpan status dan dapat diskalakan.
• Penyimpanan: hanya menyimpan data, tidak menggunakan logika apapun. Peran ini mengimplementasikan antarmuka paling sederhana. Dapat diskalakan berkat vshard.

Artinya, dengan menggunakan peran, kami memisahkan bagian-bagian cluster yang berbeda satu sama lain, yang dapat diskalakan secara independen satu sama lain.

Jadi, kami telah membuat rekaman aliran data transaksional asinkron dan antrian perbaikan dengan antarmuka admin. Pencatatannya tidak sinkron dari sudut pandang bisnis: jika kami dijamin akan menulis data ke diri kami sendiri, di mana pun, maka kami akan mengonfirmasinya. Jika tidak dikonfirmasi, berarti ada yang tidak beres dan data perlu dikirim. Ini adalah rekaman asinkron.

Pengujian

Sejak awal proyek, kami memutuskan untuk mencoba menerapkan pengembangan yang didorong oleh pengujian. Kami menulis pengujian unit di Lua menggunakan kerangka tarantool/tap, dan pengujian integrasi dengan Python menggunakan kerangka pytest. Pada saat yang sama, kami melibatkan pengembang dan analis dalam penulisan tes integrasi.

Bagaimana kita menggunakan pengembangan yang didorong oleh pengujian?

Jika kami menginginkan fitur baru, kami mencoba menulis pengujian terlebih dahulu. Saat kami menemukan bug, kami pastikan untuk menulis pengujian terlebih dahulu, baru kemudian memperbaikinya. Awalnya sulit bekerja seperti ini, ada kesalahpahaman di pihak karyawan, bahkan ada sabotase: “Ayo cepat perbaiki sekarang, lakukan sesuatu yang baru, lalu tutupi dengan tes.” Hanya saja kata “nanti” ini hampir tidak pernah datang.

Oleh karena itu, Anda perlu memaksakan diri untuk menulis tes terlebih dahulu dan meminta orang lain melakukannya. Percayalah, pengembangan yang didorong oleh pengujian membawa manfaat bahkan dalam jangka pendek. Anda akan merasa hidup Anda menjadi lebih mudah. Kami merasa bahwa 99% kode sekarang tercakup dalam pengujian. Tampaknya banyak, tetapi kami tidak mempunyai masalah apa pun: pengujian dijalankan pada setiap penerapan.

Namun, yang paling kami sukai adalah pengujian beban; kami menganggapnya paling penting dan melakukannya secara rutin.

Saya akan menceritakan sedikit cerita tentang bagaimana kami melakukan pengujian beban tahap pertama dari salah satu versi pertama. Kami menginstal sistem di laptop pengembang, menyalakan beban dan mendapatkan 4 ribu transaksi per detik. Hasil yang bagus untuk sebuah laptop. Kami menginstalnya di bangku beban virtual empat server, lebih lemah daripada di produksi. Dikerahkan seminimal mungkin. Kami menjalankannya, dan kami mendapatkan hasil yang lebih buruk daripada di laptop dalam satu thread. Konten kejutan.

Kami sangat sedih. Kami melihat beban server, tetapi ternyata mereka menganggur.

Kami memanggil pengembangnya, dan mereka menjelaskan kepada kami, orang-orang yang berasal dari dunia Java, bahwa Tarantool adalah single-threaded. Ini hanya dapat digunakan secara efektif oleh satu inti prosesor yang sedang dimuat. Kemudian kami menyebarkan instans Tarantool sebanyak mungkin di setiap server, menyalakan beban dan sudah menerima 14,5 ribu transaksi per detik.

Biar saya jelaskan lagi. Karena pembagian peran yang menggunakan sumber daya secara berbeda, peran kami yang bertanggung jawab untuk memproses koneksi dan transformasi data hanya dimuat pada prosesor, dan sangat proporsional dengan bebannya.

Dalam hal ini, memori hanya digunakan untuk memproses koneksi masuk dan objek sementara.

Sebaliknya, pada server penyimpanan, beban prosesor meningkat, namun jauh lebih lambat dibandingkan pada server yang memproses koneksi.

Dan konsumsi memori meningkat secara proporsional dengan jumlah data yang dimuat.

Layanan

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

Layanan bukan hanya potongan kecil kode yang beroperasi pada beberapa bidang. Mereka bisa berupa struktur yang cukup besar dan kompleks yang merupakan bagian dari cluster, memeriksa data referensi, menjalankan logika bisnis, dan mengembalikan respons. Kami juga mengekspor skema layanan ke GraphQL, dan konsumen menerima titik akses universal ke data, dengan introspeksi di seluruh model. Sangat nyaman.

Karena layanan berisi lebih banyak fungsi, kami memutuskan bahwa harus ada perpustakaan tempat kami akan memindahkan kode yang sering digunakan. Kami menambahkannya ke lingkungan yang aman, setelah sebelumnya memeriksa bahwa itu tidak merusak apa pun bagi kami. Dan sekarang kita dapat menetapkan lingkungan tambahan ke fungsi dalam bentuk perpustakaan.

Kami ingin memiliki platform tidak hanya untuk penyimpanan, namun juga untuk komputasi. Dan karena kami sudah memiliki banyak replika dan pecahan, kami menerapkan semacam komputasi terdistribusi dan menyebutnya pengurangan peta, karena ternyata mirip dengan pengurangan peta asli.

Sistem lama

Tidak semua sistem lama kami dapat menghubungi kami melalui HTTP dan menggunakan GraphQL, meskipun sistem tersebut mendukung protokol tersebut. Oleh karena itu, kami menciptakan mekanisme yang memungkinkan data direplikasi ke dalam sistem ini.

Jika ada perubahan bagi kami, pemicu unik dipicu dalam peran Penyimpanan dan pesan dengan perubahan tersebut berakhir di antrian pemrosesan. Itu dikirim ke sistem eksternal menggunakan peran replikator terpisah. Peran ini tidak menyimpan negara.

Perbaikan baru

Seperti yang Anda ingat, dari sudut pandang bisnis, kami melakukan perekaman asinkron. Namun kemudian mereka menyadari bahwa itu tidak akan cukup, karena ada kelas sistem yang perlu segera menerima respons mengenai status operasinya. Jadi kami memperluas GraphQL dan menambahkan mutasi. Mereka secara organik cocok dengan paradigma bekerja dengan data yang ada. Bagi kami, ini adalah satu titik membaca dan menulis untuk sistem kelas lain.

Kami juga menyadari bahwa layanan saja tidak akan cukup bagi kami, karena laporan yang cukup berat harus dibuat sehari sekali, seminggu, sebulan. Ini bisa memakan waktu lama, dan laporan bahkan dapat memblokir event loop Tarantool. Oleh karena itu, kami membuat peran terpisah: penjadwal dan pelari. Pelari tidak menyimpan status. Mereka menjalankan tugas-tugas berat yang tidak dapat kita hitung dengan cepat. Dan peran penjadwal memantau jadwal peluncuran tugas-tugas ini, yang dijelaskan dalam konfigurasi. Tugasnya sendiri disimpan di tempat yang sama dengan data bisnis. Ketika waktu yang tepat tiba, penjadwal mengambil tugas tersebut, memberikannya kepada pelari tertentu, yang menghitungnya dan menyimpan hasilnya.

Tidak semua tugas harus dijalankan sesuai jadwal. Beberapa laporan perlu dibaca sesuai permintaan. Segera setelah persyaratan ini tiba, tugas dibuat di kotak pasir dan dikirim ke runner untuk dieksekusi. Setelah beberapa waktu, pengguna menerima respons asinkron bahwa semuanya telah dihitung dan laporan sudah siap.

Awalnya, kami menganut paradigma menyimpan semua data, membuat versi, dan tidak menghapusnya. Namun dalam kehidupan, dari waktu ke waktu Anda masih harus menghapus sesuatu, kebanyakan informasi mentah atau perantara. Berdasarkan kadaluarsa, kami membuat mekanisme untuk membersihkan penyimpanan dari data usang.

Kami juga memahami bahwa cepat atau lambat akan muncul situasi ketika tidak ada cukup ruang untuk menyimpan data di memori, namun data tetap harus disimpan. Untuk keperluan tersebut, kami akan segera membuat penyimpanan disk.

Kesimpulan

Kami memulai dengan tugas memuat data ke dalam satu model dan menghabiskan waktu tiga bulan untuk mengembangkannya. Kami memiliki enam sistem pasokan data. Seluruh kode transformasi menjadi satu model adalah sekitar 30 ribu baris di Lua. Dan sebagian besar pekerjaan masih harus dilakukan. Terkadang motivasi dari tim tetangga kurang, dan banyak keadaan yang mempersulit pekerjaan. Jika Anda pernah menghadapi tugas serupa, kalikan waktu yang menurut Anda normal untuk menyelesaikannya dengan tiga, atau bahkan empat.

Ingat juga bahwa masalah yang ada dalam proses bisnis tidak dapat diselesaikan dengan menggunakan DBMS baru, bahkan yang sangat produktif sekalipun. Apa yang saya maksud? Pada awal proyek kami, kami menciptakan kesan di antara pelanggan bahwa sekarang kami akan menghadirkan database cepat baru dan kami akan hidup! Prosesnya akan berjalan lebih cepat, semuanya akan baik-baik saja. Faktanya, teknologi tidak menyelesaikan permasalahan yang dihadapi proses bisnis, karena proses bisnis adalah manusia. Dan Anda perlu bekerja dengan manusia, bukan teknologi.

Pengembangan yang didorong oleh pengujian bisa jadi menyulitkan dan memakan waktu pada tahap awal. Namun dampak positifnya akan terlihat bahkan dalam jangka pendek, ketika Anda tidak perlu melakukan apa pun untuk melakukan pengujian regresi.

Sangatlah penting untuk melakukan pengujian beban pada semua tahap pengembangan. Semakin cepat Anda menyadari adanya kekurangan pada arsitektur, semakin mudah untuk memperbaikinya, yang akan menghemat banyak waktu Anda di masa depan.

Tidak ada yang salah dengan Lua. Siapa pun dapat belajar menulis di dalamnya: pengembang Java, pengembang JavaScript, pengembang Python, front-end atau back-end. Bahkan analis kami menulis tentang hal itu.

Ketika kita berbicara tentang fakta bahwa kita tidak memiliki SQL, hal itu membuat orang takut. “Bagaimana cara mendapatkan data tanpa SQL? Apakah itu mungkin? Tentu. Dalam sistem kelas OLTP, SQL tidak diperlukan. Ada alternatif dalam bentuk beberapa jenis bahasa yang segera mengembalikan Anda ke tampilan berorientasi dokumen. Misalnya, GraphQL. Dan ada alternatif berupa komputasi terdistribusi.

Jika Anda memahami bahwa Anda perlu melakukan penskalaan, maka rancang solusi Anda di Tarantool sedemikian rupa sehingga dapat berjalan secara paralel di lusinan instans Tarantool. Jika tidak dilakukan, nantinya akan sulit dan menyakitkan, karena Tarantool hanya dapat menggunakan satu inti prosesor secara efektif.

Sumber: www.habr.com