Salve, Habr! Per ultimos duos menses condicionem perquam interessantem experti sumus, et fabulam nostram de amplificatione infrastructurae vobiscum communicare velim. Hoc tempore, numerus mandatorum SberMarket quadruplicatus est et servitium in septemdecim novis urbibus emisimus. Incrementum vehemens in postulatione cibariorum adferendi nos ad amplificandam infrastructuram nostram coegit. Perge legendo ut invenias res maxime interessantes et utiles.
Nomen mihi est Dima Bobylev, et sum CTO (Censor Technologicus) SberMarket. Cum haec prima inscriptio in nostro diario electronico sit, pauca de me et societate dicam. Autumno proximo, in certamine Young RuNet Leaders participavi. Pro certamine, ego... Disputavi quomodo nos apud SberMarket culturam nostram internam et modum progressionis servitiorum conspicimus. Quamquam certamen non vici, principia clavis ad systema IT evolvendum elaboravi.
Cum manipulum administras, interest intellegere et aequare necessitates negotii cum necessitatibus singulorum programmatorum. SberMarket nunc tredecim vicibus crescit quotannis, quod productum afficit, augmentum continuum in volumine et celeritate progressionis postulans. Nihilominus, satis temporis programmatoribus dedicamus ad analysin praeliminarem et scripturam codicis altae qualitatis. Haec ratio stabilita non solum adiuvat ad creandum productum functionale, sed etiam ad eius amplificationem et progressionem futuram. Propter hoc incrementum, SberMarket iam princeps factus est inter officia traditionis cibariorum: circiter XVIII milia mandatorum quotidie tradimus, cum circiter III milia et quingenti initio Februarii essent.
Olim, emptor a nuntio SberMarket rogavit ut merces cibarias sine contactu — usque ad maenianum suum — adferret.
Sed ad res specificas veniamus. Per menses proximos, structuram societatis nostrae active amplificavimus. Haec necessitas et a factoribus externis et internis impulsa est. Una cum clientela crescente, numerus tabernarum connexarum a nonaginta initio anni ad plus quam ducentas medio Maio crevit. Nos, scilicet, paraveramus, structuram principalem sustentantes, et in facultate amplificandi omnes machinas virtuales in nube Yandex positas freti. Tamen experientia demonstravit "quidquid male ire potest, male ire." Hodie, aliquas ex rebus maxime curiosis quae per ultimas hebdomades acciderunt communicare velim. Spero nostram experientiam vobis utilem fore.
Servus in plena paratione pugnae est
Etiam ante pandemiam, augmentum petitionum ad servos nostros posteriores experiebamur. Mos cibaria ad domum tradenda iubendi impetum capiebat, et cum primis mensuris clausurae propter COVID-19 introductis, onus per diem vehementer augebatur. Necessitas orta est ut celeriter onus in servos principales basis datorum minueretur et nonnullas petitiones legendi ad servos replicatos (servos) transferrentur.
Hoc iam antea paraveramus, et duo servi secundarii iam ad hoc opus admissi erant. Hi plerumque opera per vices gerebant, informationes generantes ad notitias cum sociis commutandas. Hae operationes onus laboris inutile creabant et iure ante duos menses neglecta sunt.
Cum replicatio in Servo fieret, notioni adhaesimus applicationes cum eis in modo "solae lectionis" operari posse. Ratio Recuperationis post Calamitatem supponebat nos, si calamitas accidisset, Servum simpliciter loco Magistri collocare et omnes petitiones legendi et scribendi ad Servum transferre posse. Attamen, replicationes etiam pro sectione analytica uti voluimus, ita servi non omnino in modo "solae lectionis" constituti erant. Quisque hospes suum gregem utentium habebat, nonnullis cum iure scribendi ad eventus calculorum intermedios servandos.
Usque ad certum oneris gradum, satis copiarum habuimus et ad scribendas et ad legendas petitiones HTTP. Medio Martio, cum Sbermarket decrevisset omnino remotum operari, dramaticum RPS incrementum experti sumus. Plures ac plures clientes nostri se ipsos separabant aut domi laborabant, quod indices oneris nostri affecit.
Cum domini effectus iam non sufficeret, nonnullas ex gravissimis petitionibus lectionis ad exemplar transferre coepimus. Ut petitiones scriptionis ad dominum et petitiones lectionis ad servum perspicue dirigeremus, gemmam Rubinam " usi sumus.""Usorem specialem cum suffixo `_readonly` sine permissione scribendi creavimus. Attamen, propter errorem configurationis in uno ex machinis, quaedam petitiones scribendi ad servum servientem sub nomine usoris, qui permissiones congruas habebat, missae sunt."
Problema non statim se manifestavit, cum onus auctum moram servi auxisset. Inconstantia datorum mane detecta est, cum, post importationes nocturnas, servi dominum "consequi" non potuerunt. Hoc oneri magno in ipso servitio et importationi cum inceptione novorum repositoriorum coniunctae tribuimus. Attamen, traditio datorum cum mora aliquot horarum non tolerabilis erat, itaque processus ad secundum servum analyticum translati sumus, cum...оmaioribus opibus praeditum erat neque petitionibus lectionis onustum erat (quo modo nobis absentiam morae replicationis explicavimus).
Cum causas "repentis" servi primarii intellexissemus, iam servus analyticus eadem de causa defecerat. Quamquam duo servi additi erant, quibus onus transferre constitueramus si dominus deficeret, error infelix effecit ut tempore critico neutrum praesto esset.
Sed cum non solum basem datorum effuderimus (restitutio eo tempore circiter quinque horas sumpsit) sed etiam servi principalis imaginem momenti habuimus, replicationem intra duas horas incipere potuimus. Post hoc autem, longam accumulationem diarii replicationis experti sumus (quia processus uno filo utitur, sed haec res omnino alia est).
conclusioni, Post hoc incidentum, manifestum factum est nos debere ab usu restrictionis accessus scribendi usoribus relinquere et totum servitorem "legere tantum" declarare. Haec methodus efficit ut exemplaria momentis criticis praesto sint.
Etiam una interrogatione gravi optimizata basim datorum ad vitam revocare potest.
Quamquam catalogum situs interretialis perpetuo renovabamus, interrogationes quas ad servos subditos mittebamus paulum post dominos segniter relinquebantur. Tempus quod ad detegendum et corrigendum problema cum servis subito ex servitio deficientibus insumpsit longius erat quam "limita psychologica" (mutationes pretiorum hoc tempore fieri potuerunt, et clientes data obsoleta vidissent), et coacti sumus omnes interrogationes ad servum principalem datorum transferre. Quam ob rem, situs lente currebat... sed saltem operabatur. Et dum servus subditus se recuperabat, nullam aliam optionem habebamus nisi optimizare.
Dum servi secundarii se recuperabant, minuta tarde praeteribant, servus principalis oneratus manebat, et omnes conatus nostros in optimizandis operibus activis secundum Principium Paretoni intendimus: interrogationes maximas, quae maiorem partem oneris sustinebant, delegimus et aptationem coepimus. Hoc ex tempore factum est.
Eventum interesting fuit exemplum MySQL plene onustum etiam minoribus emendationibus processus respondere. Duabus interrogationibus optimizatis, quae tantum 5% oneris totius constituebant, iam notabilem reductionem oneris CPU demonstravimus. Propterea, potuimus reservationem opum acceptabilem pro basi datorum principali praestare et tempus necessarium ad exemplaria restituenda obtinere.
conclusioni, Etiam optimizationes minores nobis permittunt onerationem per aliquot horas superare. Hoc tantum sufficiebat nobis ad servos nostros replicatos recuperandos. Obiter, de aspectibus technicis optimizationis interrogationum in articulo futuro disseremus. Itaque, si hoc utile inveneris, nostro diario subscribe.
Monitorium effectuum ministeriorum sociorum ordina.
Mandata clientium tractamus, ita officia nostra perpetuo cum APIs tertiarum partium interagunt—portalibus SMS, suggestis solutionum, systematibus itinerum, geocodificatoribus, Servitio Tributario Foederali, et multis aliis systematibus. Et cum onus celeriter crescere coepit, in limitationes API officiorum sociorum nostrorum incidere coepimus, quas antea ne cogitaveramus quidem.
Superatio improvisa quotarum servitiorum sociorum potest ad tempus inoperabile pro tuis ducere. Multae API clientes qui limites suos excedunt prohibent, et interdum, petitiones superfluae systema productionis socii obruere possunt.
Exempli gratia, cum numerus traditionum augeretur, officia comitantia munera distributionis itinerumque determinationis suscipere non poterant. Quam ob rem, mandata data sunt, sed officium itinera creans non functionabat. Dicendum est turmam nostram logisticalem rem paene impossibilem sub his condicionibus perfecisse, et claram communicationem turmae interruptiones temporarias servitii compensasse. Attamen, tantum volumen mandatorum manu continuo tractare impossibile est, et post aliquod tempus, intervallum intolerabile inter mandata et eorum exsecutionem experti essemus.
Plura consilia organizationalia adhibita sunt, et opus coordinatum turmae nobis tempus acquirere adiuvit dum novas condiciones tractabamus et exspectabamus dum nonnulli socii officia sua emendarent. Aliae API sunt quae excellenti firmitate gloriantur et pretia exorbitantia pro magno commeatu offerunt. Exempli gratia, initio, API mapparum notam ad inscriptionem puncti traditionis determinandam usi sumus. Sed ante finem mensis, gravem summam fere duorum milionum rublorum accepimus. Post hoc, eam celeriter substituere decrevimus. Non dicam, sed dicam sumptus nostros insigniter imminutos esse.
conclusioni, Necesse est condiciones et stipulationes omnium servitiorum sociorum observare et eas in mente habere. Etiamsi hodie "pretia ampla" videantur, non tamen impedimentum incrementi cras non futuras esse significat. Et, scilicet, optimum est condiciones pecuniarias pro aucta servitiorum postulatione antea pacisci.
Interdum evenit ut ""(c) non iuvat"
Adsueti sumus impedimentis in principalibus datorum vel servitoribus applicationum, sed cum amplificatur, problemata oriri possunt ubi minime exspectas. Machinam Apache Solr ad investigationem textus pleni in situ nostro interretiali utimur. Cum onus cresceret, diminutionem temporis responsionis animadvertimus, et usus CPU servitoris ad 100% pervenit. Quid simplicius esse posset? Tantum receptaculo Solr plures opes damus.
Pro incremento exspectato perfunctionis, servus simpliciter exstinctus est. Statim ad centum centesimas oneratus est et etiam tardius respondit. Initio, duos nucleos et duo gigabytes memoriae RAM habuimus. Constituimus facere quod plerumque fit — servum ad octo nucleos et triginta duo gigabytes augere. Res multo peiores factae sunt (quomodo et cur accurate in articulo separato explicabimus).
Intra paucos dies, subtilitates huius problematis intelleximus et optimam efficaciam cum octo nucleis et triginta duobus gigabytis memoriae consecuti sumus. Haec configuratio nobis permittit onus augere, quod magni momenti est quia incrementum non solum in clientibus sed etiam in numero tabernarum connexarum est—quarum numerus duobus mensibus duplicatus est.
conclusioni, Methodi consuetae, velut "plus apparatus addere", non semper valent. Ergo, cum quodlibet ministerium amplificas, diligenter intellegere debes quomodo opes utatur et eius efficaciam sub novis condicionibus antea probare.
Clavis ad facilem scaling horizontalem est status sine statu.
Turma nostra plerumque rationem bene notam sequitur: officia sine statu esse debent et ab ambitu executionis independentes. Hoc nobis permisit ut oneri aucto occurreremus simpliciter horizontaliter amplificando. Attamen unam exceptionem habuimus: tractatorem operum in curriculo diu currentem. Epistulas electronicas et nuntios breves (SMS), eventuum tractationem, generationem fluxuum, importationem pretiorum et copiarum, et imaginum tractationem curabat. Forte a repositorio fasciculorum locali pendebat et una instantia erat.
Cum numerus operum in ordine operationum augeretur (quod naturaliter cum incremento mandatorum accidit), effectus machinae quae processorem et repositorium fasciculorum tenebat limitans factus est. Propterea, renovationes inventarii et pretiorum, notificationes usorum, et multae aliae functiones criticae propter accumulationem rerum impeditae sunt. Turma operationum celeriter repositorium fasciculorum ad repositorium retiale simile S3 migravit, nobis permittens ut plures machinas potentes ad operationes in curriculo amplificandas disponeremus.
conclusioni, Regula "Stateless" omnibus componentibus sine exceptione sequenda est, etiamsi videatur nos ad limitem nostrum non perventuros esse. Melius est paulisper temporis impendere ut omnia systemata recte operentur quam festinanter codicem rescribere et servitium onustum corrigere.
Septem Principia ad Incrementum Intensivum
Quamquam capacitas aucta nobis praesto est, pluribus difficultatibus occurrimus dum crescebamus. Hoc tempore, numerus mandatorum plus quam quadruplicatus est. Nunc plus quam XVII milia mandatorum per diem in LXII urbibus tradimus et in animo habemus ulterius extendere fines nostros geographicos — exspectamus nos officium nostrum per Russiam in prima parte anni MMXX incipere. Ut cum crescente onere laboris et difficultatibus quas iam experti sumus occurramus, septem principia clavis ad operationes nostras administrandas in contextu constantis incrementi elaboravimus:
- Administratio incidentiumTabula Jira creavimus ubi quaeque res in casu ut tessera notatur. Hoc nobis auxilium feret ad ordinandas prioritates et perficiendas res ad rem pertinentes. Non enim agitur de errore faciendo, sed de eodem errore bis faciendo. In iis casibus ubi res recurrunt antequam causa principalis corrigi possit, actiones necessarias parare debemus, quia temporibus magni laboris, celeriter respondere necesse est.
- Cras Hoc requiritur omnibus elementis infrastructurae sine exceptione. Propter hoc ipsum augmentum oneris praedicere et impedimenta recte cognoscere potuimus ut solutionem prioritizemus. Probabile est, sub magno onere, omnia quae numquam cogitasti frangi aut tardare. Quare optimum est novas admonitiones creare statim postquam prima incidentia evenerunt, ut ea observes et anticipes.
- Monita correcta Necesse est haec subitane oneris augmento. Primo, clare indicare debent quid fractum sit. Secundo, non nimis multae admonitiones esse debent, quia nimis multae non criticae omnes notificationes negleguntur.
- Applicationes sine statu esse debent. Persuasum nobis est nullas exceptiones huic regulae esse debere. Plena independentia ab ambitu executionis necessaria est. Ad hoc assequendum, notitias communes in basi datorum vel, exempli gratia, directe in S3 servare potes. Melius adhuc, regulas sequere.Subito temporis incremento, nullum tempus ad codicem optimizandum est, et onus administrari debet per directas augmentationes opum computandi et horizontaliter amplificationem.
- Quotae et exsecutio ministeriorum externorum. Cum celeriter crescit, problemata non solum in infrastructura tua sed etiam in officiis externis oriri possunt. Res maxime frustrans est cum hoc non propter defectum, sed quia quotas vel limites attinguntur, accidit. Ergo, officia externa aeque bene ac tu crescere debent.
- Processus et ordines separa. Hoc perutile est cum una ex portis impedimentum experitur. Moras in translatione datorum non experti essemus nisi plenae series nuntiorum SMS commutationem notificationum inter systemata informationis impedivissent. Praeterea, facilius fuisset numerum operariorum augere si separatim currerent.
- Res pecuniariae. Cum fluxus datorum explodant, nullum tempus est de portoriis et subscriptionibus sollicitandi. Sed haec memoriā tenenda sunt, praesertim si parva societas es. Dominus cuiuslibet API, necnon provisor hospitii tui, tibi gravem sumptum imponere possunt. Itaque, contractus tuos diligenter lege.
conclusio,
Non sine damnis, sed hanc aetatem superavimus, et hodie omnibus principiis quae invenimus adhaerere conamur, et unaquaeque machina facultatem habet facile augendi productivitatem x4 ut quibuslibet eventibus improvisis occurrat.
In futuris nuntiis, experientiam nostram in investigandis decrementis perfunctionis in Apache Solr communicabimus, de optimizatione interrogationum disseremus, et quomodo collaboratio cum Servitio Tributario Foederali societati pecuniam servare adiuvet disseremus. Ad nostrum blog subscribe ut certior fias, et in commentariis nobis nuntia si similia problemata durante incremento frequentiae expertus es.
Tantum usores descripserunt in aliquet participare possunt. Te gratissimum esse.
Numquamne expertus es retardationem/detrimentum in servitio propter subitam oneris augmentationem ob:
55,6%Incapacitas ad celeriter addendae facultates computandi10
16,7%Limites infrastructurae provisoris hospitii3
33,3%Limites API tertiae partis6
27,8%Violationes principiorum sine civitate applicationum eorum5
88,9%Non-optimalitas codicis servitiorum propriorum16
18 utentes censuerunt. 6 Utentes abstinuerunt.
Source: www.habr.com
