Mtandao wa kisasa ni karibu haufikiriki bila maudhui ya vyombo vya habari: karibu kila bibi ana smartphone, kila mtu yuko kwenye mitandao ya kijamii, na kupungua kwa matengenezo ni gharama kubwa kwa makampuni. Hapa kuna nakala ya hadithi ya kampuni kuhusu jinsi alivyopanga uwasilishaji wa picha kwa kutumia suluhisho la vifaa, ni shida gani za utendaji alizokutana nazo katika mchakato huo, ni nini kilisababisha, na jinsi shida hizi zilitatuliwa kwa kutumia suluhisho la programu kulingana na Nginx, huku akihakikisha uvumilivu wa makosa katika viwango vyote () Tunawashukuru waandishi wa hadithi ya Oleg Efimova na Alexandra Dymova, ambao walishiriki uzoefu wao katika mkutano huo .
- Wacha tuanze na utangulizi mdogo juu ya jinsi tunavyohifadhi na kuhifadhi picha. Tuna safu ambapo tunazihifadhi, na safu ambapo tunahifadhi picha. Wakati huo huo, ikiwa tunataka kufikia kiwango cha juu cha hila na kupunguza mzigo kwenye hifadhi, ni muhimu kwetu kwamba kila picha ya mtumiaji binafsi iko kwenye seva moja ya caching. Vinginevyo, tungelazimika kusakinisha diski mara nyingi zaidi kama vile tuna seva nyingi zaidi. Kiwango chetu cha ujanja ni karibu 99%, ambayo ni, tunapunguza mzigo kwenye hifadhi yetu kwa mara 100, na ili kufanya hivyo, miaka 10 iliyopita, wakati haya yote yanajengwa, tulikuwa na seva 50. Kwa hivyo, ili kutoa picha hizi, tulihitaji kimsingi vikoa 50 vya nje ambavyo seva hizi hutumikia.
Kwa kawaida, swali liliibuka mara moja: ikiwa moja ya seva zetu zitashuka na haipatikani, ni sehemu gani ya trafiki tunapoteza? Tuliangalia kile kilichokuwa kwenye soko na tukaamua kununua kipande cha vifaa ili kutatua matatizo yetu yote. Chaguo lilianguka kwenye suluhisho la kampuni ya F5-mtandao (ambayo, kwa njia, hivi karibuni ilinunua NGINX, Inc): Meneja wa Trafiki wa Mitaa wa BIG-IP.
Kipengee hiki cha maunzi (LTM) hufanya nini: ni kipanga njia cha chuma ambacho hufanya upungufu wa chuma kwenye bandari zake za nje na hukuruhusu kuelekeza trafiki kulingana na topolojia ya mtandao, kwenye baadhi ya mipangilio, na kufanya ukaguzi wa afya. Ilikuwa muhimu kwetu kwamba kipande hiki cha vifaa kinaweza kupangwa. Ipasavyo, tunaweza kuelezea mantiki ya jinsi picha za mtumiaji maalum zilitolewa kutoka kwa kache maalum. Je, inaonekana kama nini? Kuna kipande cha maunzi kinachoangalia Mtandao kwenye kikoa kimoja, IP moja, hupakia ssl, huchanganua maombi ya http, huchagua nambari ya kache kutoka IRule, wapi pa kwenda, na kuruhusu trafiki kwenda huko. Wakati huo huo, hufanya ukaguzi wa afya, na ikiwa mashine fulani haipatikani, wakati huo tuliifanya ili trafiki iende kwa seva moja ya chelezo. Kutoka kwa mtazamo wa usanidi, kuna, kwa kweli, nuances kadhaa, lakini kwa ujumla kila kitu ni rahisi sana: tunasajili kadi, mawasiliano ya nambari fulani kwa IP yetu kwenye mtandao, tunasema kwamba tutasikiliza kwenye bandari 80. na 443, tunasema kwamba ikiwa seva haipatikani, basi unahitaji kutuma trafiki kwa chelezo, katika kesi hii ya 35, na tunaelezea rundo la mantiki juu ya jinsi usanifu huu unapaswa kugawanywa. Shida pekee ilikuwa kwamba lugha ambayo vifaa vilipangwa ilikuwa Tcl. Ikiwa kuna mtu yeyote atakumbuka hili kabisa... lugha hii ni ya kuandika tu kuliko lugha inayofaa kwa utayarishaji:
Tulipata nini? Tulipokea kipande cha maunzi ambacho kinahakikisha upatikanaji wa juu wa miundombinu yetu, njia za trafiki yetu yote, hutoa manufaa ya afya na inafanya kazi tu. Kwa kuongezea, inafanya kazi kwa muda mrefu sana: zaidi ya miaka 10 iliyopita hakujawa na malalamiko juu yake. Kufikia mwanzoni mwa 2018, tayari tulikuwa tunatuma takriban picha 80k kwa sekunde. Hii ni mahali pengine karibu gigabiti 80 za trafiki kutoka kwa vituo vyetu vyote viwili vya data.
Lakiniβ¦
Mwanzoni mwa 2018, tuliona picha mbaya kwenye chati: wakati ilichukua kutuma picha ilikuwa imeongezeka wazi. Na iliacha kutufaa. Shida ni kwamba tabia hii ilionekana tu wakati wa kilele cha trafiki - kwa kampuni yetu hii ni usiku kutoka Jumapili hadi Jumatatu. Lakini muda uliobaki mfumo ulifanya kama kawaida, hakuna dalili za kushindwa.
Hata hivyo, tatizo lilipaswa kutatuliwa. Tuligundua vikwazo vinavyowezekana na tukaanza kuziondoa. Kwanza kabisa, bila shaka, tulipanua viungo vya nje, tulifanya ukaguzi kamili wa viungo vya ndani, na tukapata vikwazo vyote vinavyowezekana. Lakini yote haya hayakutoa matokeo dhahiri, tatizo halikupotea.
Kikwazo kingine kinachowezekana kilikuwa utendaji wa kache za picha zenyewe. Na tuliamua kwamba labda shida iko kwao. Kweli, tulipanua utendaji - haswa bandari za mtandao kwenye kache za picha. Lakini tena hakuna uboreshaji dhahiri ulioonekana. Mwishoni, tulizingatia sana utendaji wa LTM yenyewe, na hapa tuliona picha ya kusikitisha kwenye grafu: mzigo kwenye CPU zote huanza kwenda vizuri, lakini ghafla huja kwenye sahani. Wakati huo huo, LTM inachaacha kujibu kwa kutosha kwa ukaguzi wa afya na uplinks na huanza kuzizima kwa nasibu, ambayo inasababisha uharibifu mkubwa wa utendaji.
Yaani tumebaini chanzo cha tatizo, tumebaini kikwazo. Inabakia kuamua tutafanya nini.
Jambo la kwanza, dhahiri zaidi tunaweza kufanya ni kwa namna fulani kusasisha LTM yenyewe. Lakini kuna nuances hapa, kwa sababu vifaa hivi ni vya kipekee, hutaenda kwenye maduka makubwa ya karibu na kununua. Huu ni mkataba tofauti, mkataba wa leseni tofauti, na itachukua muda mwingi. Chaguo la pili ni kuanza kufikiria mwenyewe, kuja na suluhisho lako mwenyewe kwa kutumia vipengele vyako mwenyewe, ikiwezekana kutumia programu ya kufikia wazi. Yote iliyobaki ni kuamua ni nini hasa tutachagua kwa hili na muda gani tutatumia kutatua tatizo hili, kwa sababu watumiaji hawakupokea picha za kutosha. Kwa hiyo, tunahitaji kufanya haya yote sana, haraka sana, mtu anaweza kusema jana.
Kwa kuwa kazi ilionekana kama "fanya jambo haraka iwezekanavyo na kutumia vifaa ambavyo tunavyo," jambo la kwanza tulifikiria ni kuondoa mashine zisizo na nguvu sana kutoka mbele, kuweka Nginx hapo, ambayo tunajua jinsi ya kufanya. fanya kazi na ujaribu kutekeleza mantiki sawa na ambayo vifaa vilizoea kufanya. Hiyo ni, kwa kweli, tuliacha vifaa vyetu, tukaweka seva 4 zaidi ambazo tulipaswa kusanidi, tuliunda vikoa vya nje kwao, sawa na jinsi ilivyokuwa miaka 10 iliyopita ... Tulipoteza kidogo katika upatikanaji ikiwa mashine hizi zilianguka, lakini bado kidogo, walitatua tatizo la watumiaji wetu ndani ya nchi.
Ipasavyo, mantiki inabaki kuwa ile ile: tunasakinisha Nginx, inaweza kupakia SSL, tunaweza kupanga kwa njia fulani mantiki ya uelekezaji, ukaguzi wa afya katika usanidi na kuiga tu mantiki ambayo tulikuwa nayo hapo awali.
Hebu tuketi kuandika configs. Mara ya kwanza ilionekana kuwa kila kitu kilikuwa rahisi sana, lakini, kwa bahati mbaya, ni vigumu sana kupata miongozo kwa kila kazi. Kwa hivyo, hatupendekezi tu kuvinjari "jinsi ya kusanidi Nginx kwa picha": ni bora kurejelea hati rasmi, ambayo itaonyesha ni mipangilio gani inapaswa kuguswa. Lakini ni bora kuchagua parameter maalum mwenyewe. Naam, basi kila kitu ni rahisi: tunaelezea seva ambazo tunazo, tunaelezea vyeti ... Lakini jambo la kuvutia zaidi ni, kwa kweli, mantiki ya uelekezaji yenyewe.
Mwanzoni ilionekana kwetu kuwa tulikuwa tukielezea eneo letu, tukilinganisha na idadi ya kashe ya picha ndani yake, kwa kutumia mikono yetu au jenereta kuelezea ni mikondo mingapi ya mito tunayohitaji, katika kila mkondo wa juu tunaonyesha seva ambayo trafiki inapaswa kwenda. nenda, na seva ya chelezo - ikiwa seva kuu haipatikani:
Lakini, labda, ikiwa kila kitu kingekuwa rahisi sana, tungeenda nyumbani tu bila kusema chochote. Kwa bahati mbaya, na mipangilio ya chaguo-msingi ya Nginx, ambayo, kwa ujumla, ilifanywa kwa miaka mingi ya maendeleo na haifai kabisa kwa kesi hii ... usanidi unaonekana kama hii: ikiwa seva fulani ya mto wa juu ina hitilafu ya ombi au kuisha, Nginx daima. hubadilisha trafiki hadi inayofuata. Kwa kuongezea, baada ya kutofaulu kwa kwanza, ndani ya sekunde 10 seva pia itazimwa, kwa makosa na kwa kuisha - hii haiwezi hata kusanidiwa kwa njia yoyote. Hiyo ni, ikiwa tutaondoa au kuweka upya chaguo la kuisha katika maagizo ya juu ya mkondo, basi, ingawa Nginx haitashughulikia ombi hili na itajibu kwa hitilafu isiyo nzuri sana, seva itazima.
Ili kuepuka hili, tulifanya mambo mawili:
a) walikataza Nginx kufanya hivi kwa mikono - na kwa bahati mbaya, njia pekee ya kufanya hivyo ni kuweka tu mipangilio ya max inashindwa.
b) tulikumbuka kuwa katika miradi mingine tunatumia moduli ambayo huturuhusu kufanya ukaguzi wa afya ya chinichini - ipasavyo, tulifanya ukaguzi wa afya mara kwa mara ili wakati wa kupumzika katika tukio la ajali uwe mdogo.
Kwa bahati mbaya, hii sio yote pia, kwa sababu kwa kweli wiki mbili za kwanza za uendeshaji wa mpango huu zilionyesha kuwa ukaguzi wa afya wa TCP pia ni jambo lisilotegemewa: kwenye seva ya juu inaweza kuwa si Nginx, au Nginx katika jimbo la D, na katika. katika kesi hii kernel itakubali muunganisho, ukaguzi wa afya utapita, lakini haitafanya kazi. Kwa hiyo, mara moja tulibadilisha hii na afya-cheki http, ilifanya moja maalum, ambayo, ikiwa inarudi 200, basi kila kitu kinafanya kazi katika script hii. Unaweza kufanya mantiki ya ziada - kwa mfano, katika kesi ya seva za caching, angalia kwamba mfumo wa faili umewekwa kwa usahihi:
Na hii ingefaa kwetu, isipokuwa kwamba kwa sasa mzunguko ulirudia kabisa kile ambacho vifaa vilifanya. Lakini tulitaka kufanya vizuri zaidi. Hapo awali, tulikuwa na seva moja ya chelezo, na hii labda sio nzuri sana, kwa sababu ikiwa una seva mia, basi wakati kadhaa zinashindwa mara moja, seva moja ya chelezo haiwezekani kukabiliana na mzigo. Kwa hivyo, tuliamua kusambaza uhifadhi kwenye seva zote: tulifanya tu sehemu nyingine ya juu, tukaandika seva zote hapo na vigezo fulani kulingana na mzigo wanaoweza kuhudumia, tukaongeza ukaguzi sawa wa afya tuliokuwa nao hapo awali :
Kwa kuwa haiwezekani kwenda kwenye mkondo mwingine wa juu ndani ya mto mmoja wa juu, ilikuwa ni lazima kuhakikisha kwamba ikiwa mkondo mkuu, ambao tulirekodi kashe sahihi ya picha, muhimu, haipatikani, tulipitia error_page ili kurudi nyuma, kutoka. ambapo tulienda kwenye hifadhi rudufu ya juu:
Na kwa kuongeza seva nne, hii ndio tuliyopata: tulibadilisha sehemu ya mzigo - tuliiondoa kutoka kwa LTM hadi kwa seva hizi, tukatekelezea mantiki sawa hapo, kwa kutumia vifaa vya kawaida na programu, na mara moja tukapokea bonasi ambayo seva hizi zinaweza. kuongezwa, kwa sababu zinaweza kutolewa tu kadri inavyohitajika. Kweli, hasi pekee ni kwamba tumepoteza upatikanaji wa juu kwa watumiaji wa nje. Lakini wakati huo tulilazimika kutoa dhabihu hii, kwa sababu ilikuwa ni lazima kutatua shida mara moja. Kwa hiyo, tuliondoa sehemu ya mzigo, ilikuwa karibu 40% wakati huo, LTM ilijisikia vizuri, na kwa kweli wiki mbili baada ya tatizo kuanza, tulianza kutuma maombi si 45k kwa pili, lakini 55k. Kwa kweli, tulikua kwa 20% - hii ni wazi trafiki ambayo hatukumpa mtumiaji. Na baada ya hapo walianza kufikiri juu ya jinsi ya kutatua tatizo lililobaki - kuhakikisha upatikanaji wa juu wa nje.
Tulikuwa na pause, wakati ambao tulijadili ni suluhisho gani tutatumia kwa hili. Kulikuwa na mapendekezo ya kuhakikisha kuegemea kwa kutumia DNS, kwa kutumia maandishi yaliyoandikwa nyumbani, itifaki za uelekezaji zenye nguvu ... kulikuwa na chaguzi nyingi, lakini tayari ikawa wazi kuwa kwa uwasilishaji wa kuaminika wa picha, unahitaji kuanzisha safu nyingine ambayo itafuatilia hii. . Tuliita mashine hizi wakurugenzi wa picha. Programu tuliyoitegemea ilikuwa Keepalived:
Kwa kuanzia, Keepalived inajumuisha nini? Ya kwanza ni itifaki ya VRRP, inayojulikana sana kwa wanamtandao, iko kwenye vifaa vya mtandao ambavyo hutoa uvumilivu wa makosa kwa anwani ya nje ya IP ambayo wateja huunganisha. Sehemu ya pili ni IPVS, seva pepe ya IP, kwa kusawazisha kati ya vipanga njia vya picha na kuhakikisha uvumilivu wa makosa katika kiwango hiki. Na tatu - hundi ya afya.
Hebu tuanze na sehemu ya kwanza: VRRP - inaonekanaje? Kuna IP fulani pepe, ambayo ina ingizo katika dns badoocdn.com, ambapo wateja huunganisha. Wakati fulani, tunayo anwani ya IP kwenye seva moja. Vifurushi vilivyohifadhiwa huendesha kati ya seva kwa kutumia itifaki ya VRRP, na ikiwa bwana atatoweka kutoka kwa rada - seva imewashwa tena au kitu kingine, basi seva ya chelezo inachukua kiotomatiki anwani hii ya IP - hakuna vitendo vya mwongozo vinavyohitajika. Tofauti kati ya bwana na chelezo ni kipaumbele hasa: juu ni, nafasi kubwa zaidi kwamba mashine itakuwa bwana. Faida kubwa sana ni kwamba hauitaji kusanidi anwani za IP kwenye seva yenyewe, inatosha kuzielezea kwenye usanidi, na ikiwa anwani za IP zinahitaji sheria fulani za uelekezaji, hii inaelezewa moja kwa moja kwenye usanidi, kwa kutumia syntax sawa kama ilivyoelezewa kwenye kifurushi cha VRRP. Hutakutana na mambo yoyote usiyoyafahamu.
Je, hii inaonekanaje katika mazoezi? Ni nini hufanyika ikiwa moja ya seva itashindwa? Punde tu bwana anapotoweka, chelezo yetu itaacha kupokea matangazo na kuwa bwana kiotomatiki. Baada ya muda, tulirekebisha bwana, tukawasha upya, tukainua Keepalived - matangazo yanafika kwa kipaumbele cha juu kuliko chelezo, na nakala rudufu hurejeshwa kiotomatiki, huondoa anwani za IP, hakuna vitendo vya mwongozo vinavyohitajika kufanywa.
Kwa hivyo, tumehakikisha uvumilivu wa makosa ya anwani ya IP ya nje. Sehemu inayofuata ni kusawazisha kwa namna fulani trafiki kutoka kwa anwani ya IP ya nje hadi kwa vipanga njia vya picha ambavyo tayari vinasitisha. Kila kitu ni wazi kabisa na itifaki za kusawazisha. Hii ni aidha duru-robin rahisi, au vitu ngumu zaidi, wrr, unganisho la orodha na kadhalika. Hii inaelezewa kimsingi katika nyaraka, hakuna kitu maalum. Lakini njia ya utoaji ... Hapa tutaangalia kwa undani kwa nini tulichagua mmoja wao. Hizi ni NAT, Njia ya moja kwa moja na TUN. Ukweli ni kwamba tulipanga mara moja kutoa gigabits 100 za trafiki kutoka kwa tovuti. Ikiwa unakadiria, unahitaji kadi 10 za gigabit, sivyo? Kadi 10 za gigabit katika seva moja tayari ziko zaidi ya upeo wa, angalau, dhana yetu ya "vifaa vya kawaida". Na kisha tukakumbuka kwamba hatutoi tu trafiki fulani, tunatoa picha.
Nini maalum? - Tofauti kubwa kati ya trafiki zinazoingia na zinazotoka. Trafiki inayoingia ni ndogo sana, trafiki inayotoka ni kubwa sana:
Ukiangalia grafu hizi, unaweza kuona kwamba kwa sasa mkurugenzi anapokea kuhusu MB 200 kwa sekunde, hii ni siku ya kawaida sana. Tunarudisha MB 4,500 kwa sekunde, uwiano wetu ni takriban 1/22. Tayari ni wazi kwamba ili kutoa trafiki inayotoka kwa seva 22 za wafanyikazi, tunahitaji moja tu inayokubali muunganisho huu. Hapa ndipo kanuni ya uelekezaji wa moja kwa moja inakuja kutusaidia.
Je, inaonekana kama nini? Mkurugenzi wetu wa picha, kulingana na jedwali lake, hupitisha miunganisho kwa vipanga njia vya picha. Lakini ruta za picha hutuma trafiki ya kurudi moja kwa moja kwenye mtandao, tuma kwa mteja, hairudi kupitia mkurugenzi wa picha, kwa hiyo, kwa idadi ndogo ya mashine, tunahakikisha uvumilivu kamili wa kosa na kusukuma trafiki yote. Katika usanidi inaonekana kama hii: tunataja algorithm, kwa upande wetu ni rr rahisi, toa njia ya uelekezaji wa moja kwa moja na kisha tuanze kuorodhesha seva zote halisi, ni ngapi kati yao tunazo. Ambayo itaamua trafiki hii. Ikiwa tuna seva moja au mbili zaidi hapo, au seva kadhaa, hitaji kama hilo linatokea - tunaongeza tu sehemu hii kwenye usanidi na usijali sana. Kutoka upande wa seva halisi, kutoka upande wa router ya picha, njia hii inahitaji usanidi mdogo zaidi, imeelezwa kikamilifu katika nyaraka, na hakuna vikwazo huko.
Kinachopendeza zaidi ni kwamba suluhisho kama hilo halimaanishi muundo mpya wa mtandao wa ndani; hii ilikuwa muhimu kwetu; tulilazimika kutatua hili kwa gharama ndogo. Ukiangalia , basi tutaona jinsi inavyoonekana. Hapa tuna seva fulani ya kawaida, kwenye bandari 443, inasikiliza, inakubali uunganisho, seva zote zinazofanya kazi zimeorodheshwa, na unaweza kuona kwamba uunganisho ni, kutoa au kuchukua, sawa. Ikiwa tutaangalia takwimu kwenye seva ya mtandaoni sawa, tuna pakiti zinazoingia, viunganisho vinavyoingia, lakini hakuna kabisa zinazotoka. Viunganisho vinavyotoka huenda moja kwa moja kwa mteja. Sawa, tuliweza kusawazisha. Sasa, nini kitatokea ikiwa mojawapo ya vipanga njia vyetu vya picha itashindwa? Baada ya yote, chuma ni chuma. Inaweza kuingia kwenye hofu ya kernel, inaweza kuvunja, usambazaji wa umeme unaweza kuwaka. Chochote. Ndiyo maana uchunguzi wa afya unahitajika. Zinaweza kuwa rahisi kama kuangalia jinsi bandari imefunguliwa, au kitu ngumu zaidi, hadi hati zilizoandikwa nyumbani ambazo zitaangalia mantiki ya biashara.
Tulisimama mahali fulani katikati: tuna ombi la https kwa eneo maalum, hati inaitwa, ikiwa inajibu kwa jibu la 200, tunaamini kuwa kila kitu kiko sawa na seva hii, kwamba iko hai na inaweza kuwashwa kabisa. kwa urahisi.
Je, hii, tena, inaonekanaje katika mazoezi? Hebu tuzime seva kwa ajili ya matengenezo - kuangaza BIOS, kwa mfano. Katika magogo, mara moja tuna wakati wa kuisha, tunaona mstari wa kwanza, kisha baada ya majaribio matatu ni alama ya "imeshindwa", na imeondolewa tu kwenye orodha.
Chaguo la pili la tabia pia linawezekana, wakati VS imewekwa kwa sifuri, lakini ikiwa picha imerejeshwa, hii haifanyi kazi vizuri. Seva inakuja, Nginx huanza huko, angalia afya mara moja inaelewa kuwa uunganisho unafanya kazi, kwamba kila kitu ni sawa, na seva inaonekana kwenye orodha yetu, na mzigo huanza kutumika mara moja kwa hiyo. Hakuna vitendo vya mwongozo vinavyohitajika kutoka kwa msimamizi wa wajibu. Seva ilianza tena usiku - idara ya ufuatiliaji haituita kuhusu hili usiku. Wanakujulisha kuwa hii ilifanyika, kila kitu kiko sawa.
Kwa hiyo, kwa njia rahisi, kwa msaada wa idadi ndogo ya seva, tulitatua tatizo la uvumilivu wa makosa ya nje.
Yote ambayo inabakia kusema ni kwamba yote haya, bila shaka, yanahitaji kufuatiliwa. Kando, inapaswa kuzingatiwa kuwa Keepalivede, kama programu iliyoandikwa muda mrefu uliopita, ina rundo la njia za kuifuatilia, zote mbili kwa kutumia hundi kupitia DBus, SMTP, SNMP, na Zabbix ya kawaida. Zaidi ya hayo, yeye mwenyewe anajua jinsi ya kuandika barua kwa karibu kila kupiga chafya, na kuwa waaminifu, wakati fulani tulifikiri hata kuizima, kwa sababu anaandika barua nyingi kwa kubadili yoyote ya trafiki, kuwasha, kwa kila uhusiano wa IP. Nakadhalika . Kwa kweli, ikiwa kuna seva nyingi, basi unaweza kujisumbua na barua hizi. Tunafuatilia nginx kwenye vipanga njia vya picha kwa kutumia njia za kawaida, na ufuatiliaji wa vifaa haujaondoka. Kwa kweli, tungeshauri mambo mawili zaidi: kwanza, ukaguzi wa nje wa afya na upatikanaji, kwa sababu hata ikiwa kila kitu kitafanya kazi, kwa kweli, labda watumiaji hawapati picha kwa sababu ya shida na watoa huduma wa nje au kitu ngumu zaidi. Inafaa kila wakati kuweka mahali pengine kwenye mtandao mwingine, huko Amazon au mahali pengine, mashine tofauti inayoweza kubandika seva zako kutoka nje, na inafaa pia kutumia ugunduzi wa hitilafu, kwa wale wanaojua jinsi ya kufanya ujifunzaji wa hila wa mashine, au ufuatiliaji rahisi. , angalau ili kufuatilia ikiwa maombi yamepungua kwa kasi, au, kinyume chake, yameongezeka. Inaweza pia kuwa na manufaa.
Wacha tufanye muhtasari: sisi, kwa kweli, tulibadilisha suluhisho la vazi la chuma, ambalo wakati fulani lilikoma kutufaa, na mfumo rahisi ambao hufanya kila kitu sawa, ambayo ni, hutoa kukomesha trafiki ya HTTPS na njia nzuri zaidi na ukaguzi wa afya unaohitajika. Tumeongeza uthabiti wa mfumo huu, yaani, bado tunayo upatikanaji wa hali ya juu kwa kila safu, pamoja na kwamba tunayo bonasi ambayo ni rahisi sana kuiweka kwenye kila safu, kwa sababu ni vifaa vya kawaida na programu ya kawaida, ambayo ni. , tumerahisisha utambuzi wa matatizo yanayowezekana.
Tulimaliza na nini? Tulikuwa na tatizo wakati wa likizo ya Januari 2018. Katika miezi sita ya kwanza, tulipoweka mpango huu, tuliupanua kwa trafiki yote ili kuondoa trafiki yote kutoka kwa LTM, tulikua tu katika trafiki katika kituo kimoja cha data kutoka gigabits 40 hadi gigabits 60, na wakati huo huo kwa mwaka mzima wa 2018 waliweza kutuma karibu picha mara tatu zaidi kwa sekunde.
Chanzo: mapenzi.com