Get best of the week

Evaluasi Metrik Muat Server Terpadu

Bekerja di salah satu bank terbesar di negara ini, saya harus berurusan dengan tugas mengevaluasi efisiensi penggunaan sumber daya sekitar 16 ribu server. Tugas ini dirumuskan dengan sangat sederhana - perlu mengembangkan metodologi untuk mengevaluasi metrik beban server untuk suatu periode. Idealnya, beban server per periode harus diperkirakan menggunakan satu atau beberapa (tidak lebih dari 8) angka.

Beberapa kata tentang fitur menggunakan server virtual


Organisasi besar (terutama bank) memiliki kebun binatang beraneka ragam aplikasi warisan yang digunakan pada server yang berbeda menggunakan berbagai teknologi virtualisasi. Cloud pribadi adalah teknologi yang menjanjikan, tetapi pada kenyataannya, organisasi besar akan lama menggunakan berbagai platform virtualisasi untuk menyebarkan berbagai aplikasi.

Sebagai platform virtualisasi berkembang, ada saatnya ketika tidak ada seorang pun di perusahaan dapat memahami seberapa efisien sumber daya yang digunakan. Bahkan alat pemantauan yang paling canggih tidak memberikan jawaban untuk pertanyaan ini karena berbagai skenario penggunaan server. Misalnya, departemen mungkin memiliki server laporan yang akan dimuat sepenuhnya hanya untuk jangka waktu terbatas. Katakan 3-4 jam di akhir bulan. Dalam skenario kehidupan nyata, tidak ada yang mengalokasikan sumber daya dinamis untuk server tersebut - ini sulit secara teknis dan organisasi. Sumber daya dialokasikan secara khusus untuk beban server periodik maksimum, meskipun jarang terjadi.

Sebagai ringkasan, dalam organisasi besar, sumber daya pertanian virtual dihabiskan dengan sangat tidak efisien.

Di bawah ini saya mengusulkan metodologi yang dengannya Anda dapat dengan mudah membenarkan peningkatan dan penurunan sumber daya yang dialokasikan ke server virtual, terlepas dari skenario.

Metodologi


Untuk menilai beban sumber daya, perlu untuk mengumpulkan statistik berbagai penghitung, untuk menilai beban sumber daya, berbagai metrik akan digunakan. Secara konvensional, penghitung dapat dibagi menjadi 2 jenis (sesuai dengan tingkat perubahan): "cepat" dan "lambat". Contoh penghitung "cepat" yang bagus adalah penghitung beban prosesor (% CPU). Contoh penghitung lambat adalah persentase ruang hard disk kosong (% FreeSpace).
Evaluasi penghitung lambat terdiri dari penghitungan nilai ekstrim (minimum atau maksimum) metrik untuk periode tersebut. Pendekatan ini memungkinkan (misalnya, ketika menilai ruang bebas disk) untuk memperkirakan sumber daya gratis dan, jika perlu, mengalokasikan volume tambahan atau mengurangi yang sekarang.

Untuk penghitung cepat, pendekatan yang berbeda digunakan. Kerugian menggunakan metrik integral sederhana (rata-rata, maksimum, minimum, dan median) untuk menilai dinamika penghitung tersebut dijelaskan dengan baik di sini . Kerugian umum termasuk kurangnya informasi tentang peningkatan beban (sedang dan puncak). Jika kita mengambil nilai maksimum untuk periode tersebut sebagai metrik integral, maka keberadaan pencilan (misalnya, pemuatan instan CPU hingga 100% saat program dimulai) tidak akan memberikan informasi yang objektif.

Dalam artikel ituDiusulkan untuk menggunakan 0,9 kuantil untuk memperkirakan metrik cepat (ini adalah nilai yang menunjukkan tingkat di bawah mana nilai yang diamati dalam 90% dari sampel terletak). Dengan beban server yang seragam menurut metrik ini, kami dapat memperkirakan secara memadai rata-rata beban prosesor. Tetapi pendekatan ini memiliki kelemahan yang sama - kurangnya informasi tentang peningkatan beban (sedang dan puncak).

Di bawah ini, sebagai ilustrasi, grafik mingguan dan harian dari penghitung% CPU. Nilai counter maksimum pada grafik adalah 100%.





Grafik menunjukkan bahwa selama periode yang ditunjukkan ada ledakan beban, yang berlangsung sekitar 3 jam. Untuk penghitung ini, berbagai metrik dihitung untuk minggu itu. Gambar 2 menunjukkan bahwa median (garis hijau, nilai 5%), rata-rata (kuning, nilai 12%) dan 0,9 kuantil (merah, nilai 27%) menyaring perubahan beban dan informasi tentang itu hilang.

Sebagai pengembangan dari gagasan kuantil, saya ingin mengusulkan gagasan kuantil geser. Ini adalah analog dari moving average.tetapi quantile 0,9 digunakan sebagai fungsi jendela. Selain itu, kami akan menggunakan 2 kuantil geser untuk memperkirakan tingkat penghitung - cepat dengan periode pendek (1 jam) dan lambat dengan periode panjang (24 jam). Kuantil cepat akan menyaring emisi instan dan memberikan informasi beban puncak. Kuantil lambat akan memungkinkan Anda memperkirakan beban rata-rata.

Seperti yang dapat Anda lihat dari grafik, kuantil bergerak 0,9 adalah karakteristik dinamis (coklat - cepat, ungu - lambat). Untuk mempermudah, mengevaluasi status penghitung sebagai metrik disarankan untuk digunakan:

  • nilai kuantil maksimum dengan periode 1 jam, yang menunjukkan beban server kontinu maksimum untuk periode tersebut,
  • nilai kuantil rata-rata dengan periode 24 jam, yang menunjukkan beban server rata-rata untuk periode tersebut.

Pada grafik, nilai maksimum kuantil cepat adalah garis hitam 85%, nilai rata-rata kuantil lambat adalah garis merah muda 30%.

Jadi, ketika menganalisis beban sumber daya server (menurut penghitung% CPU), jika kita mengambil rata-rata untuk bulan tersebut (12%) sebagai metrik, kita dapat membuat keputusan yang salah untuk mengurangi sumber daya yang dialokasikan. Metrik kuantil ganda cepat / lambat bergerak (85 dan 30%) menunjukkan bahwa ada cukup sumber daya yang dialokasikan, tetapi tidak ada surplus.

Keputusan


Implementasi penilaian efisiensi penggunaan sumber daya telah didekomposisi menjadi 3 tugas:

  1. pengumpulan data
  2. pengembangan metodologi penilaian
  3. implementasi metodologi dalam arsitektur saat ini

Di atas, saya memeriksa tugas 2 dari implementasi ini, di bawah ini kita akan berbicara sedikit tentang tugas ketiga.

Data dikumpulkan di database ClickHouse. Kolom DBMS ini sangat ideal untuk menyimpan data deret waktu. Ini dibahas secara rinci di ClickHouse Meetup pada 5 September 2019. Perbandingan ClickHouse dengan DBMS time-series lainnya dapat ditemukan di sini .
Sebagai hasil dari pengumpulan data, kami membentuk beberapa tabel di mana data disusun baris demi baris (nilai setiap penghitung ditulis dalam baris terpisah). Dan, tentu saja, ada masalah dengan data mentah.

Masalah pertama adalah ketidakmerataan interval antara entri penghitung. Misalnya, jika periode perekaman penghitung standar adalah 5 menit, kadang-kadang ada kesenjangan dan catatan berikutnya lebih dari 5 menit (hingga 20 menit) dari yang sebelumnya.

Masalah kedua adalah bahwa kadang-kadang data penghitung datang 2 kali atau lebih (dengan nilai yang berbeda) dengan cap waktu yang sama.

Dan masalah ketiga - ClickHouse tidak memiliki fungsi jendela.

Untuk mengatasi masalah pertama, Anda dapat menggunakan ASOF JOIN. Idenya cukup sederhana - untuk setiap penghitung dari setiap server untuk membuat tabel secara merata dengan interval waktu yang diisi secara merata. Menggunakan ASOF BERGABUNG memungkinkan mengisi nilai-nilai dalam tabel baru dengan nilai-nilai terdekat dari tabel data mentah (opsi mengisi mirip dengan ffill dan bfill dapat dikonfigurasi).

Solusi untuk masalah kedua adalah agregasi dengan pilihan nilai maksimum pada waktu tertentu.

Untuk mengatasi masalah ketiga, beberapa solusi dipertimbangkan. Pertama, skrip Python ditolak karena kinerja yang tidak memadai. Solusi kedua - menyalin data mentah ke database MSSQL, menghitung metrik, dan menyalin kembali - tampaknya terlalu rumit untuk diterapkan. MSSQL juga memiliki fungsi jendela, tetapi tidak ada fungsi agregat yang diperlukan. Orang mungkin bingung dan menulis fungsi SQL CLR Anda sendiri. Tetapi opsi ini ditolak karena kompleksitas yang berlebihan.

Solusi yang berfungsi bisa berupa skrip SQL untuk ClickHouse. Contoh skrip ini diberikan di bawah ini. Untuk kesederhanaan, saya hanya menghitung penghitungan cepat untuk penghitung tunggal untuk beberapa server. Solusinya tidak terlihat sangat sederhana dan tidak terlalu nyaman, tetapi berhasil.

Akibatnya, laporan pengujian dibuat di PowerBI untuk menunjukkan metodologi.





Kesimpulan


Sebagai kesimpulan, saya ingin berspekulasi tentang pengembangan solusi. Jika Anda melihat solusi dari sudut pandang gudang data, Anda dapat melihat bahwa dengan cara ini tugas membuat gudang data (Data Warehouse) dari lapisan data mentah (Staging Area) diselesaikan. Anda dapat membahas arsitekturnya, tetapi untuk ClickHouse sebagai basis data kolom, normalisasi tidak penting (atau bahkan mungkin berbahaya).

Pengembangan lebih lanjut dari repositori terlihat dalam pembuatan tabel agregat (hari \ minggu \ bulan) dengan masa hidup yang berbeda (TTL). Ini akan menghindari pembengkakan penyimpanan yang berlebihan.
Langkah selanjutnya mungkin menggunakan data untuk analitik prediktif.

PS

Kode dan data untuk pengujian diposting di sini .

More articles:


All Articles