Baru-baru ini, VTB telah mengubah beberapa komponen perangkat keras dan perangkat lunak dari sistem alur kerja. Perubahan itu terlalu signifikan untuk terus bekerja tanpa pengujian beban skala penuh: masalah dengan sistem pendukung dokumen (LMS) penuh dengan kerugian besar.
Spesialis Intertrust menguji VTB SDO pada peralatan Huawei - sebuah komplek server farm, jaringan data, dan penyimpanan yang didasarkan pada solid-state drive. Untuk pengujian, kami menciptakan lingkungan yang mereproduksi skenario nyata dengan beban maksimum yang mungkin. Hasil dan kesimpulan - di bawah potongan.
Mengapa kita membutuhkan sistem alur kerja di bank dan mengapa mengujinya
LMS di VTB adalah paket perangkat lunak yang kompleks, di mana semua proses manajemen utama diikat. Sistem ini menyediakan layanan dokumentasi umum, interaksi elektronik, analitik. Peredaran dokumen yang terorganisasi dengan baik mempercepat keputusan manajemen, menjadikan prosedur untuk adopsi mereka transparan dan terkendali, meningkatkan kualitas manajemen dan meningkatkan daya saing bank.
LMS harus memastikan implementasi keputusan yang jelas sesuai dengan peraturan yang berlaku. Ini membutuhkan kinerja tinggi, toleransi kesalahan, penskalaan fleksibel. Sistem memiliki persyaratan tinggi untuk kontrol akses, volume dokumen yang diproses secara bersamaan, dan jumlah pengguna. Sekarang ada 65 ribu di antaranya di VTB SDO, dan jumlah ini terus bertambah.
Sistem ini terus berkembang: arsitektur berubah, teknologi yang ketinggalan zaman digantikan oleh yang modern. Dan baru-baru ini, beberapa komponen sistem diganti dengan yang independen-impor, tanpa perangkat lunak berpemilik. Apakah arsitektur SDO baru yang didasarkan pada perangkat lunak CompanyMedia dan kompleks perangkat keras Huawei menangani peningkatan beban? Jelas menjawab pertanyaan ini, tanpa menunggu situasi yang sama dalam kenyataan, itu hanya mungkin dengan bantuan stress testing.
Selain menguji produk perangkat lunak baru untuk ketahanan terhadap stres, kami memiliki tugas-tugas berikut:
- menentukan parameter yang tepat untuk ukuran horizontal dan vertikal server untuk profil beban bank;
- memeriksa komponen untuk toleransi kesalahan dalam kondisi beban tinggi;
- untuk mengidentifikasi koefisien entropi interaksi interkluster dengan penskalaan horizontal;
- coba ubah permintaan baca saat menggunakan penyeimbang platform;
- menentukan faktor penskalaan horizontal semua node dan komponen sistem;
- menentukan parameter perangkat keras maksimum yang mungkin dari server untuk berbagai keperluan fungsional (penskalaan vertikal);
- untuk mempelajari profil beban aplikasi pada infrastruktur teknis, untuk memperkirakan hasil untuk perencanaan pengembangan sistem informasi;
- Selidiki dampak konsolidasi data aplikasi pada sistem penyimpanan data tunggal pada optimalisasi sumber daya, meningkatkan keandalan dan kinerja.
Metodologi dan peralatan
Pengujian beban sistem manajemen dokumen elektronik sering dilakukan sesuai dengan skenario yang disederhanakan. Mereka mensimulasikan penemuan cepat dan pembukaan kartu dokumen yang tidak terkait dengan file lain dan tidak memiliki riwayat siklus hidup. Dalam hal ini, sebagai suatu peraturan, tidak ada yang memperhitungkan hak akses akun dan faktor-faktor konsumsi sumber daya lainnya yang merupakan karakteristik kondisi riil.
Seringkali, tes cerai ini dilakukan oleh penyedia solusi. Dapat dimengerti: penting bagi vendor untuk menunjukkan kepada klien potensial kinerja tinggi dan kecepatan sistem. Tidak mengherankan bahwa model pengujian yang disederhanakan menunjukkan waktu respons sistem rekaman, bahkan jika jumlah pengguna dan dokumen meningkat secara signifikan.
Kami perlu mereproduksi kondisi operasi yang sebenarnya. Karena itu, pada awalnya, kami mengumpulkan statistik selama sebulan: kami mencatat aktivitas pengguna, menyaksikan pekerjaan latar belakang semua layanan. Sistem pemantauan yang terintegrasi dalam LMS menjadi sangat membantu dalam hal ini. Karyawan bank membantu untuk mengoreksi data yang dihasilkan pada arus dokumen, sementara kami membuat penyesuaian untuk proyeksi pertumbuhan arus.
Hasilnya adalah metodologi pengujian, dengan bantuan yang memungkinkan untuk mensimulasikan proses yang terjadi dalam sistem, dengan mempertimbangkan semua beban nyata. Di bangku tes, kami mereproduksi - secara individu dan dalam berbagai kombinasi - operasi bisnis yang paling umum, serta permintaan yang paling memakan waktu. Selama pengujian kinerja, semua komponen mengalami stres. Operasi dilakukan untuk menghitung hak akses pengguna ke objek sistem, membuka dokumen dengan hierarki bercabang kompleks dan sejumlah besar tautan, mencari sistem, dan sebagainya.
Profil pengujian beban:
- pengguna terdaftar: 65 ribu dengan peningkatan hingga 150 ribu;
- frekuensi login pengguna (otentikasi): 50 ribu per jam;
- pengguna secara bersamaan bekerja di sistem: 10 ribu;
- dokumen terdaftar: 10 juta per tahun;
- volume lampiran file: 1 TB per tahun;
- dokumen proses persetujuan: 1,5 juta per tahun;
- visa para pihak dalam perjanjian: 7,5 juta per tahun;
- resolusi dan instruksi: 15 juta per tahun;
- laporan tentang resolusi dan instruksi: 15 juta per tahun;
- tugas pengguna: 18 juta per tahun.
Aplikasi ini dikonsolidasikan pada sistem penyimpanan tunggal Huawei OceanStor Dorado 6000 V3 dengan 117 drive SSD masing-masing 3,6 TB, total volume yang dapat digunakan lebih dari 300 TB. Daya komputasi ditempatkan pada sistem server modular Huawei E9000, dan data ditransmisikan melalui jaringan berdasarkan sakelar tingkat pusat data seri Huawei CE. Selama pengujian, kami setiap saat mengamati semua indikator sistem. Semua hasil, termasuk data historis, direkam dalam bentuk grafik dan tabel untuk analisis selanjutnya.
Server Infrastruktur Perangkat Keras Uji Beban
Karena kinerja tinggi sistem penyimpanan Huawei OceanStor Dorado 6000 V3, keterlambatan saat melakukan permintaan pengguna jarang melebihi 1 ms. Kecepatan subsistem disk aplikasi ini menginspirasi kami untuk penelitian lebih lanjut. Kami memutuskan, dengan menganalisis data historis, untuk menentukan pengaruh berbagai jenis beban kerja pada infrastruktur teknis. Hasil yang diperoleh memungkinkan kami untuk secara fleksibel dan akurat merencanakan pengembangan sistem sesuai dengan persyaratan untuk platform perangkat keras.
Dalam hal penskalaan, kami memeriksa:
- batas skala vertikal server aplikasi (CMJ) , sumber daya kritikalitas: jumlah core dan frekuensi, jumlah RAM;
- dukungan untuk penskalaan horizontal dari server aplikasi (CMJ) dengan menduplikasi layanan yang identik secara fungsional dan menyeimbangkannya;
- batas penskalaan vertikal dan horizontal dari server klien (Web-GUI) ;
- batas penskalaan vertikal penyimpanan file (FS) , sumber daya kritikalitas: bandwidth jaringan, kecepatan disk;
- dukungan untuk penskalaan horizontal penyimpanan file (FS) karena sistem file terdistribusi - CEPH, GLUSTERFS;
- batas skala vertikal dari database (PostgreSQL) , sumber daya sesuai dengan tingkat kekritisan: kapasitas RAM, kecepatan disk, jumlah core dan frekuensi;
- dukungan untuk penskalaan basis data horizontal (PostgreSQL) : penskalaan beban baca pada server slave, penskalaan beban penulisan berdasarkan prinsip pembagian menjadi modul fungsional;
- batas penskalaan vertikal dan horizontal dari pialang pesan (Apache Artemis) ;
- batas penskalaan vertikal dan horizontal dari server pencarian (Apache Solr) .
Masalah dan Solusi
Salah satu tugas utama adalah untuk mengidentifikasi kemungkinan masalah dengan kinerja LMS. Selama pekerjaan, hambatan berikut diidentifikasi dan cara untuk mengatasinya ditemukan.
Mengunci logging yang sinkron. Operasi pencatatan dalam konfigurasi WildFly standar dilakukan secara serempak dan sangat memengaruhi kinerja. Diputuskan untuk beralih ke logger asinkron, dan pada saat yang sama menulis bukan ke disk, tetapi ke sistem agregasi log ELK.
Inisialisasi sesi yang tidak perlu ketika bekerja dengan data warehouse. Setiap utas yang menerima data dari repositori dua kali menginisialisasi sesi untuk otentikasi dalam mode SSO. Operasi ini intensif sumber daya dan sangat meningkatkan waktu pelaksanaan permintaan pengguna, dan juga mengurangi throughput keseluruhan server.
Mengunci ketika bekerja dengan objek cache aplikasi. Aplikasi ini menggunakan kunci reentrantLock yang agak berat (Java 7), yang mempengaruhi kecepatan eksekusi query. Jenis kunci diubah menjadi stampedLock, yang secara signifikan mengurangi waktu yang dihabiskan untuk bekerja dengan objek cache.
Setelah itu, kami kembali meluncurkan pengujian beban untuk menentukan waktu rata-rata operasi tipikal dalam sistem LMS dengan penyimpanan relasional pada profil bank. Kami mendapat hasil sebagai berikut:
- otorisasi pengguna dalam sistem - 400 ms;
- melihat kemajuan rata-rata - 2,5 detik;
- pembuatan kartu registrasi dan kontrol - 1.4 dtk;
- registrasi dan registrasi kartu kendali - 600 ms;
- pembuatan resolusi - 1 p.
Kesimpulan
Selain mengidentifikasi masalah, stress testing telah mengkonfirmasi beberapa asumsi kami.
- Fungsi sistem jauh lebih baik di keluarga Linux OS.
- Prinsip-prinsip yang dinyatakan untuk memastikan toleransi kesalahan berfungsi pada level setiap komponen dalam mode "panas".
- Komponen utama - layanan logika bisnis (menerima permintaan pengguna) - memiliki penskalaan horizontal "mirror" dan penskalaan throughput yang hampir linier dengan peningkatan jumlah instance.
- Ukuran optimal layanan logika bisnis untuk 1200 pengguna simultan - 8 vCPU untuk layanan dan 1,5 vCPU untuk DBMS.
- Konsolidasi data aplikasi pada sistem penyimpanan tunggal secara signifikan meningkatkan produktivitas dan keandalan, meningkatkan skalabilitas.
Kami akan dengan senang hati menjawab pertanyaan Anda di komentar - mungkin Anda tertarik untuk mempelajari lebih lanjut tentang beberapa aspek pengujian.