Hey Habr! Sawetara sasi pungkasan kita urip ing kahanan sing menarik banget, lan aku pengin nuduhake crita babagan skala infrastruktur. Sajrone wektu iki, SberMarket wis kaping papat pesenan lan ngluncurake layanan kasebut ing 4 kutha anyar. Panjaluk sing mbledhos kanggo kiriman grosir mbutuhake skala infrastruktur. Waca babagan kesimpulan sing paling menarik lan migunani ing potongan kasebut.
Jenengku Dima Bobylev, aku direktur teknis SberMarket. Amarga iki minangka kiriman pisanan ing blog kita, aku bakal ngomong sawetara tembung babagan aku lan perusahaan. Pungkasan musim gugur, aku melu kompetisi pimpinan enom Runet. Kanggo kontes I babagan carane kita ing SberMarket ndeleng budaya internal lan pendekatan kanggo pangembangan layanan. Lan sanajan aku ora bisa menang kompetisi, aku ngrumusake dhewe prinsip dhasar kanggo pangembangan ekosistem IT.
Nalika ngatur tim, penting kanggo ngerti lan golek keseimbangan antarane kabutuhan bisnis lan kabutuhan saben pangembang. Saiki SberMarket tuwuh 13 kaping setahun, lan iki mengaruhi prodhuk, mbutuhake terus-terusan nambah volume lan jangkah pembangunan. Senadyan mangkono, kita nyedhiyakake wektu sing cukup kanggo pangembang kanggo analisis awal lan coding berkualitas tinggi. Pendekatan sing dibentuk mbantu ora mung nggawe produk sing bisa digunakake, nanging uga ing skala lan pangembangan luwih lanjut. Minangka asil saka wutah iki, SberMarket wis dadi pimpinan ing antarane layanan pangiriman Grosir: kita ngirim udakara 18 pesenan saben dina, sanajan ana udakara 3500 ing awal Februari.
Ing sawijining dina, ana klien njaluk kurir SberMarket supaya ngirim sembako menyang dheweke tanpa kontak - langsung ing loteng.
Nanging ayo mudhun menyang spesifik. Sajrone sawetara wulan kepungkur, kita wis aktif nggedhekake infrastruktur perusahaan kita. Kebutuhan kasebut diterangake dening faktor eksternal lan internal. Bebarengan karo ekspansi basis pelanggan, jumlah toko sing disambungake mundhak saka 90 ing awal taun dadi luwih saka 200 ing pertengahan Mei. Mesthi wae, kita nyiapake awake dhewe, nyiapake infrastruktur utama, lan ngetung kemungkinan skala vertikal lan horisontal kabeh mesin virtual sing di-host ing awan Yandex. Nanging, laku wis nuduhake: "Kabeh sing bisa salah bakal salah." Lan dina iki aku pengin nuduhake kahanan sing paling aneh sing kedadeyan ing minggu iki. Mugi pengalaman kita bakal migunani kanggo sampeyan.
Abdi ing kesiapan tempur lengkap
Malah sadurunge wiwitan pandhemen, kita ngadhepi paningkatan jumlah panjaluk menyang server backend kita. Tren pesenan sembako kanthi kiriman ing omah wiwit entuk momentum, lan kanthi ngenalake langkah-langkah ngisolasi diri sing pertama ana hubungane karo COVID-19, beban kasebut saya tambah akeh ing ngarepe kita sedina muput. Ana perlu kanggo cepet mbongkar server master saka database utama lan nransfer sawetara panjalukan diwaca kanggo server tiron (budak).
Kita nyiapake langkah iki luwih dhisik, lan 2 server budak wis mlaku kanggo maneuver kasebut. Dheweke utamane nggarap tugas kumpulan kanggo ngasilake feed informasi kanggo ijol-ijolan data karo mitra. Proses kasebut nggawe beban ekstra lan kanthi bener dijupuk saka kurung sawetara wulan sadurunge.
Wiwit replikasi dumadi ing Budak, kita netepi konsep manawa aplikasi mung bisa digunakake ing mode mung diwaca. Rencana Pemulihan Bencana nganggep yen ana bencana, kita mung bisa masang Budak ing panggonan Master lan ngalih kabeh panjaluk nulis lan maca menyang Budak. Nanging, kita uga pengin nggunakake replika kanggo kabutuhan departemen analytics, supaya server ora rampung nyetel status mung maca, lan saben host duwe pangguna dhewe, lan sawetara duwe ijin nulis kanggo nyimpen asil pitungan penengah.
Nganti tingkat beban tartamtu, kita duwe master sing cukup kanggo nulis lan maca nalika ngolah panjaluk http. Ing pertengahan Maret, nalika Sbermarket mutusake kanggo ngalih menyang karya remot, kita wiwit nambah wutah RPS. Luwih akeh klien kita mandhiri utawa kerja saka omah, sing dibayangke ing indikator beban.
Kinerja "master" ora cukup maneh, mula kita wiwit nransfer sawetara panjaluk maca sing paling abot menyang replika. Kanggo ngirim panjaluk nulis kanthi transparan menyang master, lan maca panjaluk marang budak, kita nggunakake permata ruby ββββ"". Kita wis nggawe pangguna khusus karo postfix _readonly tanpa ijin nulis. Nanging amarga kesalahan ing konfigurasi salah siji saka sarwa dumadi, bagean saka panjalukan nulis menyang server budak atas jenenge pangguna sing nduweni hak sing cocog.
Masalah kasebut ora langsung katon, amarga. bebane tambah nambahi backloging budak. Inkonsistensi data ditemokake ing wayah esuk, nalika, sawise ngimpor saben wengi, para budak ora "nyekel" karo master. Iki amarga beban dhuwur ing layanan kasebut lan impor sing ana gandhengane karo peluncuran toko anyar. Nanging ora bisa ditrima kanggo menehi data kanthi wektu tundha pirang-pirang jam, lan kita ngalih proses menyang budak analitik kapindho, amarga wisΠΎSumber daya sing luwih gedhe lan ora diisi karo panjaluk diwaca (yaiku carane kita nerangake kekurangan replikasi lag).
Nalika kita ngerteni sebab-sebab "panyebaran" budak utama, analitis wis gagal amarga alasan sing padha. Senadyan ana rong server tambahan, sing direncanakake kanggo nransfer beban yen ana kacilakan master, amarga kesalahan sing ora nyenengake, ternyata ora ana siji ing wektu kritis.
Nanging amarga kita ora mung mbucal database (mulihake ing wektu iku bab 5 jam), nanging uga gambar asli seko saka server master, kita ngatur kanggo miwiti tiron ing 2 jam. Bener, sawise iku, kita padha samesthine kanggo muter log rΓ©plikasi kanggo dangu (amarga proses ing mode single-threaded, nanging iku crita temen beda).
Kesimpulan: Sawise kedadeyan kasebut, dadi cetha yen praktik mbatesi nulis kanggo pangguna kudu ditinggalake lan kabeh server kudu diumumake mung diwaca. Kanthi pendekatan iki, sampeyan bisa yakin manawa replika bakal kasedhiya ing wektu kritis.
Ngoptimalake malah siji pitakonan abot bisa nguripake database maneh
Sanajan kita terus-terusan nganyari katalog ing situs kasebut, panjaluk sing digawe kanggo server Slave diijini rada ketinggalan ing Master. Wektu nalika kita nemokake lan ngilangi masalah budak "tiba-tiba ilang" luwih akeh tinimbang "halangan psikologis" (sajrone wektu iki, rega bisa dianyari, lan klien bakal weruh data sing wis lawas), lan kita dipeksa ngalih. kabeh pitakon menyang server database utama. AkibatΓ©, situs iki alon ... nanging paling ora bisa. Lan nalika Budak pulih, ora ana apa-apa kanggo kita, nanging optimasi.
Nalika server Budak pulih, menit alon-alon nyeret, Master tetep kakehan, lan kita mbuwang kabeh upaya kanggo ngoptimalake tugas aktif miturut Aturan Pareto: kita milih pitakon TOP sing menehi beban paling akeh lan miwiti nyetel. Iki ditindakake kanthi cepet.
Efek sing menarik yaiku MySQL, sing dimuat ing eyeballs, nanggapi malah perbaikan sing sithik ing proses. Ngoptimalake sawetara pitakon sing mung menehi 5% saka total beban wis nuduhake beban CPU sing katon. AkibatΓ©, kita ngatur kanggo nyedhiyani sumber daya ditrima kanggo Master bisa karo database lan entuk wektu perlu kanggo mulihake replika.
Kesimpulan: Malah optimasi cilik ngidini sampeyan "urip" kakehan kanggo sawetara jam. Iki mung cukup kanggo kita mulihake server kanthi replika. Miturut cara, kita bakal ngrembug babagan teknis optimasi pitakon ing salah sawijining kiriman ing ngisor iki. Dadi langganan blog kita yen bisa migunani kanggo sampeyan.
Ngatur pemantauan kesehatan layanan mitra
Kita ngolah pesenan saka pelanggan, lan mulane layanan kita terus-terusan sesambungan karo API pihak katelu - iki minangka gateway kanggo ngirim SMS, platform pembayaran, sistem routing, geocoder, Layanan Pajak Federal lan akeh sistem liyane. Lan nalika beban wiwit tuwuh kanthi cepet, kita wiwit ngalami watesan API saka layanan mitra, sing durung nate dipikirake sadurunge.
Kuota layanan partner sing ora dikarepke bisa nyebabake downtime sampeyan dhewe. Akeh API mblokir klien sing ngluwihi watesan, lan ing sawetara kasus, keluwihan panjalukan bisa overloading produksi partner.
Contone, nalika tuwuhing jumlah pangiriman, layanan sing diiringi ora bisa ngatasi tugas distribusi lan penentuan rute. AkibatΓ©, ternyata pesenan digawe, nanging layanan sing nggawe rute kasebut ora bisa digunakake. Aku kudu ujar manawa para ahli logistik nindakake meh ora bisa ditindakake ing kahanan kasebut, lan interaksi sing jelas saka tim kasebut mbantu ngimbangi kegagalan layanan sementara. Nanging ora realistis kanggo ngolah volume aplikasi kasebut kanthi manual kabeh wektu, lan sawise sawetara wektu kita bakal nemoni jurang sing ora bisa ditampa ing antarane pesenan lan eksekusi.
Sawetara langkah organisasi ditindakake lan karya tim sing koordinasi kanthi apik mbantu tuku wektu nalika kita setuju karo kahanan anyar lan ngenteni modernisasi layanan saka sawetara mitra. Ana API liyane sing nawakake daya tahan sing dhuwur lan tarif sing ora sopan yen ana lalu lintas sing dhuwur. Contone, ing wiwitan, kita nggunakake API pemetaan sing kondhang kanggo nemtokake alamat titik pangiriman. Nanging ing pungkasan sasi, padha nampa tagihan babak kanggo meh 2 yuta rubles. Sawise iku, kita mutusake kanggo ngganti kanthi cepet. Aku ora bakal melu iklan, nanging aku bakal ngomong yen biaya kita wis suda banget.
Kesimpulan: Penting kanggo ngawasi kahanan kerja kabeh layanan mitra lan elinga. Malah yen dina iki misale jek sing padha "karo wates gedhe" kanggo sampeyan, iki ora ateges sing sesuk padha ora bakal dadi alangan kanggo wutah. Lan, mesthi, luwih apik kanggo nyetujoni syarat-syarat finansial kanggo nambah panjaluk layanan kasebut sadurunge.
Kadang dadi metu sing"(c) ora mbantu
Kita wis biasa "gags" ing database utama utawa ing server aplikasi, nanging nalika skala, masalah bisa katon ing endi sing ora dikarepake. Kanggo nggoleki teks lengkap ing situs kasebut, kita nggunakake mesin Apache Solr. Nalika beban tambah, kita ngeweruhi nyuda wektu nanggepi, lan beban CPU server tekan 100%. Apa sing luwih gampang - menehi wadhah Solr luwih akeh sumber daya.
Tinimbang nambah kinerja sing dikarepake, server mung "mati". Langsung dimuat 100% lan nanggapi luwih alon. Kaping pisanan, kita duwe 2 intine lan 2 GB RAM. Kita mutusakΓ© apa biasane mbantu - kita menehi server 8 intine lan 32 GB. Kabeh dadi luwih elek (kita bakal pitutur marang kowe persis carane lan ngapa ing kirim kapisah).
Ing sawetara dina, kita ngerti kerumitan masalah iki, lan entuk kinerja optimal kanthi 8 intine lan 32 GB. Konfigurasi iki ngidini kita terus nambah beban saiki, sing penting banget, amarga pertumbuhane ora mung babagan pelanggan, nanging uga ing jumlah toko sing disambungake - ing 2 sasi jumlahe wis tikel kaping pindho.
Kesimpulan: Cara standar kaya "tambah wesi" ora tansah bisa. Dadi nalika skala layanan apa wae, sampeyan kudu duwe pangerten sing apik babagan cara nggunakake sumber daya lan nyoba sadurunge, kerjane ing kahanan anyar.
Stateless minangka kunci kanggo skala horisontal sing prasaja
UmumΓ©, tim kita netepi pendekatan sing kondhang: layanan kudu ora duwe negara internal (stateless) lan kudu bebas saka lingkungan runtime. Iki ngidini kita bisa urip kanthi nambah beban kanthi skala horisontal sing sederhana. Nanging kita duwe siji pangecualian layanan - pawang kanggo tugas latar mburi sing dawa. Dheweke melu ngirim email lan sms, ngolah acara, ngasilake feed, ngimpor rega lan saham, lan ngolah gambar. Kedaden iku gumantung ing panyimpenan file lokal lan ana ing salinan siji.
Nalika jumlah tugas ing antrian prosesor tambah (lan iki alamiah kedaden karo Tambah ing nomer pesenan), kinerja inang sing tuan rumah prosesor lan panyimpenan file dadi faktor watesan. AkibatΓ©, nganyari kisaran lan rega, ngirim kabar menyang pangguna lan akeh fungsi kritis liyane sing macet ing antrian mandheg. Tim Ops kanthi cepet migrasi panyimpenan file menyang panyimpenan jaringan kaya S3, lan iki ngidini kita ngunggahake sawetara mesin sing kuat kanggo skala panangan tugas latar mburi.
Kesimpulan: Aturan Stateless kudu dituruti kanggo kabeh komponen, tanpa pangecualian, sanajan katon "sing mesthi ora bisa nolak ing kene." Luwih becik nglampahi sawetara wektu supaya kabeh sistem bisa digunakake kanthi bener tinimbang cepet-cepet nulis ulang kode lan ndandani layanan sing kakehan.
7 Prinsip kanggo Wutah Intensif
Senadyan kasedhiyan kapasitas tambahan, ing proses wutah, kita jumangkah ing sawetara rakes. Sajrone wektu iki, jumlah pesenan tambah luwih saka 4 kaping. Saiki kita wis ngirim luwih saka 17 pesenan saben dina ing 000 kutha lan rencana kanggo luwih nggedhekake geografi - ing separo pisanan 62, layanan wis samesthine bakal dibukak ing saindhenging Rusia. Kanggo ngatasi beban kerja sing saya tambah akeh, kanthi nganggep bongkahan sing wis kebak, kita wis entuk 2020 prinsip dhasar kanggo kerja ing lingkungan sing terus berkembang:
- Manajemen kedadean. Kita wis nggawe Papan ing Jira, ngendi saben kedadean dibayangke ing wangun tiket. Iki bakal mbantu sampeyan nggawe prioritas lan ngrampungake tugas sing ana gandhengane karo kedadeyan. Pancen, ing intine, ora nggegirisi kanggo nggawe kesalahan - elek nggawe kesalahan kaping pindho ing kesempatan sing padha. Kanggo kasus kasebut nalika kedadeyan kedadeyan maneh sadurunge sabab bisa didandani, instruksi tumindak kudu disiapake, amarga sajrone beban abot, penting kanggo nanggepi kanthi kacepetan kilat.
- Ngawasi dibutuhake kanggo kabeh unsur infrastruktur tanpa pangecualian. Thanks kanggo dheweke, kita bisa prΓ©dhiksi wutah beban lan kanthi bener milih "bottlenecks" kanggo ngilangi prioritas. Paling kamungkinan, ing beban dhuwur, kabeh sing sampeyan ora mikir bab bakal break utawa wiwit alon mudhun. Mula, luwih becik nggawe tandha anyar sawise kedadeyan kedadeyan pisanan supaya bisa ngawasi lan ngantisipasi.
- Tandha sing bener mung perlu karo Tambah cetha ing mbukak. Kaping pisanan, dheweke kudu nglaporake apa sing rusak. Kapindho, ora kudu akeh tandha, amarga akeh tandha sing ora kritis nyebabake ora nggatekake kabeh tandha umume.
- Aplikasi kudu stateless. Kita wis nggawe manawa ora ana pangecualian kanggo aturan iki. Sampeyan mbutuhake kamardikan lengkap saka lingkungan runtime. Kanggo nindakake iki, sampeyan bisa nyimpen data sing dienggo bareng ing database utawa, contone, langsung ing S3. Luwih apik, tindakake aturan.. Sajrone wektu sing saya tambah, ora ana cara kanggo ngoptimalake kode kasebut, lan sampeyan kudu ngatasi beban kanthi langsung nambah sumber daya komputasi lan skala horisontal.
- Kuota lan kinerja layanan eksternal. Kanthi wutah kanthi cepet, masalah bisa uga ora mung ing infrastruktur sampeyan, nanging uga ing layanan eksternal. Sing paling ngganggu yaiku nalika kedadeyan kasebut ora amarga gagal, nanging amarga tekan kuota utawa watesan. Dadi layanan eksternal kudu ukurane kaya sampeyan dhewe.
- Proses lan antrian kapisah. Iki mbantu banget nalika ana plug ing salah sawijining gateway. Kita ora bakal nemoni telat transmisi data yen antrian lengkap kanggo ngirim SMS ora ngganggu ijol-ijolan kabar antarane sistem informasi. Lan bakal luwih gampang kanggo nambah jumlah buruh yen padha makarya dhewe.
- kasunyatan financial. Nalika ana wutah mbledhos ing aliran data, ora ana wektu kanggo mikir babagan tarif lan langganan. Nanging kudu eling, utamane yen sampeyan perusahaan cilik. Tagihan gedhe bisa disetel dening pemilik API apa wae, uga panyedhiya hosting sampeyan. Dadi maca kontrak kasebut kanthi teliti.
kesimpulan
Ora tanpa losses, nanging kita slamet tataran iki, lan dina iki kita nyoba kanggo netepi kabeh prinsip ketemu, lan saben mesin nduweni kemampuan kanggo gampang nambah kinerja x4 kanggo ngrampungake karo sawetara surprises.
Ing kiriman ing ngisor iki, kita bakal nuduhake pengalaman nyelidiki kinerja kendur ing Apache Solr, uga ngomong babagan optimasi pitakon lan kepiye interaksi karo Layanan Pajak Federal mbantu perusahaan ngirit dhuwit. Langganan ing blog kita supaya ora kantun apa-apa, lan marang kita ing komentar yen sampeyan duwe alangan padha sak wutah saka lalu lintas.
Mung pangguna pangguna sing bisa melu survey. nggih.
Apa sampeyan nate ngalami kalem/mudhun layanan sajrone beban mundhak amarga:
-
55,6%Ora bisa nambah sumber daya komputasi kanthi cepet10
-
16,7%Watesan infrastruktur panyedhiya hosting3
-
33,3%Watesan API6 pihak katelu
-
27,8%Pelanggaran prinsip stateless aplikasi5
-
88,9%Kode layanan dhewe sing ora optimal16
18 pangguna milih. 6 kedhaftar abstained.
Source: www.habr.com