💇🏼 👩🏽‍💼 🤞🏻 Bagaimana kami membantu sekolah beralih ke pembelajaran jarak jauh dan mengatasi bebannya ⏲️ 🤷 👨🏿‍🎓

Halo, Habr! Nama saya Alexey Vakhov, saya direktur teknis Uchi.ru. Pada pertengahan Maret, ketika sekolah mulai beralih ke pembelajaran jarak jauh, kami memberikan beberapa layanan kepada guru dan siswa untuk kelas online. Menurut perhitungan kami, kami memiliki margin keselamatan untuk bertahan maksimal 1,5-2 kali beban. Pada pertengahan April, lalu lintas kami tumbuh 8 kali. Saya harus melakukan banyak hal untuk tetap bertahan. Mungkin seseorang akan membutuhkan pengalaman kita untuk selamat dari krisis ini atau masa depan.

Kami tidak mengharapkan kejutan seperti itu dan tidak siap untuk mereka, mungkin tidak ada satu perusahaan pun di Rusia, atau di dunia, yang siap untuk ini. Biasanya pada bulan Maret, aktivitas di Uchi.ru relatif lebih rendah dibandingkan dengan musim gugur karena liburan musim semi dan musim panas mendatang, di mana saat ini kami sudah bersiap untuk bulan September: kami menggergaji fitur, melakukan refactoring, melakukan perubahan arsitektur skala besar, dan melakukan rutinitas menyenangkan lainnya. Namun, kali ini berbeda.

Jumlah puncak pengguna unik di situs pada satu waktu mencapai 240 ribu, kami mencatat maksimum tahun sekolah saat ini pada 30 ribu orang. Pada titik ini, beban bertambah setiap hari, dan kami bekerja sepanjang waktu untuk menstabilkan situs.

Ketika beban seperti itu jatuh di situs, sebagai aturan, aplikasi, layanan, penyeimbang, pangkalan, web, saluran terbentuk. Semua "kemacetan" infrastruktur terpapar. Dalam kondisi seperti itu, sulit untuk mendiagnosis masalah - secara simtomatis semuanya bermasalah. Sangat mudah untuk memperbaiki ketika lalu lintas tumbuh dengan lancar dan satu hal rusak. Ketika beban mengalir dalam kebingungan, salah satu masalah besar adalah memahami penyebab kegagalan.

Strategi untuk bekerja dalam kondisi seperti ini adalah menghilangkan apa yang paling menghantam situs, kemudian menemukan titik paling menyakitkan berikutnya, pada saat yang sama mencari potensi masalah dan memperbaikinya, dan sebagainya. Berikut adalah beberapa hal penting yang kami lakukan untuk menstabilkan platform.

Bergantung pada diri mereka sendiri

Selama krisis sebelum lalu lintas, Anda sebagai satu tim menjadi satu. Itu akan tergantung pada karyawan Anda apakah Anda akan menemukan solusi, mengatasi krisis, atau tidak.

Tidak ada orang di industri yang akan datang, melihat ke dalam sistem Anda yang kompleks, segera melakukan sesuatu dan semuanya akan baik-baik saja. Tentu saja, di dunia ada cukup banyak spesialis yang akan mengatasi tugas jika ada waktu. Tetapi ketika solusi mendasar diperlukan saat ini, Anda hanya dapat mengandalkan tim Anda, yang mengetahui sistem dan spesifiknya. Hasil dan tanggung jawab untuk bisnis terletak pada tim. Pemeriksaan eksternal disarankan untuk menghubungkan secara langsung.

Koordinasi operasional tim anti-krisis dalam obrolan khusus di Slack membantu kami dengan cepat menavigasi dan membangun pekerjaan - semua masalah diselesaikan di sini dan sekarang. Kami membagi area tanggung jawab antara karyawan sehingga tidak ada persimpangan dan orang-orang tidak melakukan pekerjaan ganda. Pada hari-hari yang paling sulit, saya harus berhubungan secara harfiah sepanjang waktu.

Cloud yang diperluas

Anda tidak dapat mengasuransikan diri dari semua krisis, tetapi penting untuk fleksibel. Tumpukan cloud memberi kami plastisitas dan kesempatan untuk tetap bertahan meski dengan peningkatan beban yang dramatis.

Awalnya, kami meningkatkan sumber daya di bawah peningkatan beban, tetapi pada beberapa titik kami berlari ke kuota wilayah penyedia cloud kami. Masalah muncul pada tingkatnya: server virtual kami dipengaruhi oleh tetangga, di mana lalu lintas juga tumbuh, yang menyebabkan kegagalan dalam pengoperasian aplikasi kami. Ini diharapkan: kami bergantung pada penyedia dan infrastrukturnya, yang pada gilirannya juga mengalami beban yang tinggi. Kami telah merilis beberapa sumber daya dari mesin virtual non-prioritas untuk situs utama. Dengan penyedia, kami menyetujui sumber daya khusus.

Alat pemantauan yang ditingkatkan

Selama krisis, waspada sebenarnya tidak memenuhi fungsinya. Semua anggota tim sudah memantau semua sistem sepanjang waktu, dan manajemen insiden dikurangi menjadi pekerjaan konstan di semua lini. Untuk sepenuhnya mendiagnosis masalah yang kami temui, kami memiliki terlalu sedikit data. Misalnya, untuk memantau mesin virtual, kami menggunakan Node Eksportir standar untuk Prometheus. Dia baik melihat gambaran besar, karena melihat lebih dekat pada satu mesin virtual mulai menggunakan NetData.

Penyimpanan cache yang dioptimalkan

Masalah juga muncul dengan penyimpanan nilai kunci. Dalam salah satu aplikasi, Redis tidak dapat mengatasinya - dalam satu salinan, itu dapat bekerja hanya pada satu inti. Oleh karena itu, mereka menggunakan garpu Redis yang disebut KeyDB, yang dapat bekerja di banyak utas.

Untuk meningkatkan bandwidth di aplikasi lain, kami telah mengumpulkan 10 Redis'ov independen. Mereka diproksi dengan Service Mesh kami, yang juga memberikan kunci. Bahkan jika satu atau dua Redis crash, ini tidak akan menyebabkan masalah karena hashing yang konsisten. Plus, mereka secara praktis tidak perlu diberikan.

Memperluas jaringan

Seperti yang Anda ketahui, 640 Kb sudah cukup untuk semua orang. Kami selalu menggunakan subnet pribadi / 24, tetapi dengan latar belakang karantina kami harus segera memperluas ke / 22. Sekarang jaringan menampung empat kali lebih banyak server, kami berharap itu akan cukup untuk memastikan.

PgBouncer dilakukan secara terpisah

Sebagai basis data relasional, kami menggunakan PostgreSQL di mana-mana, di suatu tempat contoh virtual kecil, dan di suatu tempat - instalasi beberapa server khusus besar untuk master dan replika. Hambatan yang jelas dari arsitektur ini adalah master, yang dalam kasus ideal hanya digunakan untuk merekam dan tidak skala secara horizontal. Dengan pertumbuhan lalu lintas, kami mulai beristirahat pada CPU.

Pada saat yang sama, kami menggunakan PgBouncer, yang diinstal pada wizard dan pada setiap replika, untuk mengelola koneksi. Pada satu port, dapat menggunakan tidak lebih dari satu inti prosesor, jadi pada setiap server kami memiliki beberapa penjaga. Pada titik tertentu, menjadi jelas bahwa PgBouncer sendiri mengambil bagian nyata dari CPU dari pangkalan, dan pada beban maksimum kami mengalami peningkatan rata-rata beban yang cepat dan penurunan kinerja sistem.

Kami memindahkan penjaga ke server terpisah, yang membantu kami menghemat 20-25% CPU di setiap server basis data.

Menghadapi kejutan

Hanya satu alat yang tidak dapat dipercaya, terutama di saat krisis. Sebaliknya, redundansi alat membantu, karena memungkinkan untuk melihat gambar yang lebih objektif. Alat yang familier mulai gagal karena berbagai alasan. Misalnya, biasanya untuk memperkirakan jumlah orang di situs, kami biasanya menggunakan laporan Google Analytics real-time, yang merupakan metrik sensitif dan akurat. Tetapi kadang-kadang sulit dan kali ini kami harus melihat metrik internal seperti jumlah acara tampilan halaman dan jumlah permintaan per detik.

Untuk logging terpusat kami menggunakan ELK. Pipa pengiriman log kami didasarkan pada Apache Kafka dan Elastic Filebeat. Di bawah beban tinggi, konveyor pengiriman log berhenti mengelola, log mulai hilang atau tertinggal. Kami meningkatkan kecepatan pengindeksan log dan penyimpanan log dengan memanipulasi indeks Elasticsearch, meningkatkan jumlah partisi di Kafka dan Filebeat, dan kompresi yang lebih baik pada semua tahap. Karena kenyataan bahwa pipa untuk mengumpulkan kayu bulat terpisah dari produksi, masalah dengan peningkatan lalu lintas kayu bulat tidak berpengaruh pada fungsi situs.

Menerima aturan main

Tidak mungkin untuk mempersiapkan setiap krisis sebelumnya, tetapi Anda awalnya dapat mencoba membangun sistem yang fleksibel. Perusahaan rintisan atau perusahaan yang secara bertahap berhenti menjadi perusahaan rintisan, dalam waktu tenang, tidak selalu rasional untuk mempersiapkan pertumbuhan lalu lintas yang tidak normal: sumber daya tim terbatas. Jika kita menyisihkan persiapan mereka untuk sesuatu yang mungkin tidak pernah terjadi, tidak akan ada kekuatan tersisa untuk produk utama. Jauh lebih penting untuk bereaksi dengan benar saat ini dan tidak takut dengan keputusan berani. Sebagai aturan, jalan keluar dari krisis mereka adalah jalan keluar ke tingkat yang secara kualitatif baru.

Inilah musim semi yang menyenangkan tahun ini. Ketika tampaknya segala sesuatu yang mungkin telah dilakukan, kadang-kadang ternyata ini hanya permulaan.

Bagaimana kami membantu sekolah beralih ke pembelajaran jarak jauh dan mengatasi bebannya