Программалык камсыздоодогу туруктуулук, күтүлбөгөн маселелерге же мүчүлүштүктөргө карабастан, тиркеменин үзгүлтүксүз жана ишенимдүү иштешин улантуу мүмкүнчүлүгүн билдирет. Fintech долбоорлорунда туруктуулук бир нече себептерден улам өзгөчө маанилүү. Биринчиден, компаниялар ченемдик талаптарга жооп берүүгө милдеттүү жана каржылык жөнгө салуучулар системанын ичинде туруктуулукту сактоо үчүн ыкчам туруктуулукту баса белгилешет. Мындан тышкары, санариптик инструменттердин көбөйүшү жана үчүнчү тараптын кызмат көрсөтүүчүлөрүнө таянуу Fintech бизнесин коопсуздуктун коркунучуна дуушар кылат. Туруктуулук ошондой эле киберкоркунучтар, пандемия же геосаясий окуялар сыяктуу ар кандай факторлордон келип чыккан үзгүлтүктөр коркунучун азайтууга, негизги бизнес операцияларын жана маанилүү активдерди коргоого жардам берет.

Туруктуулуктун үлгүлөрү менен биз программалык камсыздоо үзгүлтүккө туруштук бере аларын жана анын иштешин камсыз кылуу үчүн иштелип чыккан мыкты тажрыйбалардын жана стратегиялардын жыйындысын түшүнөбүз. Бул үлгүлөр каталарды башкаруу, жүктү башкаруу жана каталарды калыбына келтирүү механизмдерин камсыз кылуучу коопсуздук торлору сыяктуу иштешет, ошону менен тиркемелер жагымсыз шарттарда бекем жана ишенимдүү бойдон калышын камсыздайт.

Эң кеңири таралган ийкемдүүлүк стратегияларына капкак, кэш, резерв, кайра аракет жана автоматтык өчүргүч кирет. Бул макалада мен аларды чечүүгө жардам бере турган көйгөйлөрдүн мисалдары менен кененирээк талкуулайм.

Бөлмө

Келгиле, жогорудагы орнотууну карап көрөлү. Бизде кээ бир маалыматтарды алуу үчүн артыбызда бир нече аркалары бар кадимки колдонмо бар. Бул серверлерге туташкан бир нече HTTP кардарлары бар. Көрсө, алардын баары бирдей байланыш бассейнин бөлүшөт! Ошондой эле CPU жана RAM сыяктуу башка ресурстар.

Эгерде серверлердин бири суроо-талаптын кечигүүсүнө алып келген кандайдыр бир көйгөйлөргө туш болсо, эмне болот? Жооп берүү убактысы жогору болгондуктан, бүт туташуунун бассейни толугу менен backend1ден жооп күткөн сурамдарга ээ болот. Натыйжада, дени сак backend2 жана backend3 үчүн арналган суроо-талаптар улана албайт, анткени бассейн түгөнүп калган. Бул биздин серверлерибиздин бириндеги мүчүлүштүк бүтүндөй тиркемеде катага алып келиши мүмкүн дегенди билдирет. Идеалында, биз тиркеменин калган бөлүгү кадимкидей иштешин улантып жатканда, иштебей калган бэкенд менен байланышкан функциянын деградацияга дуушар болушун каалайбыз.

Бул көйгөйдү чечүү үчүн биз кантип колдонсок болот?

Bulkhead үлгүсү тиркеме ичиндеги ресурстардын ар кандай түрлөрүн обочолонтуу үчүн колдонулушу мүмкүн, бул бир бөлүгүндөгү мүчүлүштүктүн бүткүл системага таасирин тийгизбестен. Бул жерде биз аны көйгөйүбүзгө кантип колдонсок болот:

1. Туташуу бассейндерин изоляциялоо Биз ар бир сервер үчүн өзүнчө байланыш бассейндерин түзө алабыз (backend1, backend2, backend3). Бул эгер backend1 жогорку жооп берүү убакыттарын же каталарды баштан кечирип жатса, анын туташуу пулу өз алдынча түгөнүп, backend2 жана backend3 үчүн туташуу бассейндери таасирин тийгизбей турганын камсыздайт. Бул обочолонуу дени сак серверлерге суроо-талаптарды кадимкидей иштетүүгө мүмкүндүк берет.
2. Фондук иш-аракеттер үчүн ресурстарды чектөө Бөлмөлөрдү колдонуу менен, биз пакеттик иштетүү же пландаштырылган тапшырмалар сыяктуу фондо иш-чаралар үчүн атайын ресурстарды бөлүштүрө алабыз. Бул бул иш-аракеттер реалдуу убакыт операциялары үчүн зарыл болгон ресурстарды керектөөсүнө жол бербейт. Мисалы, биз фондук тапшырмаларга арналган жиптердин санын же CPU колдонулушун чектей алабыз, келип түшкөн суроо-талаптарды аткаруу үчүн жетиштүү ресурстардын жеткиликтүү болушун камсыздай алабыз.
3. Кирүүчү суроо-талаптарга чектөөлөрдү коюу Колдонмонун ар кайсы бөлүктөрүнө келип түшкөн суроо-талаптардын санын чектөө үчүн да колдонсо болот. Мисалы, биз ар бир жогорку кызмат үчүн бир эле учурда иштетиле турган суроо-талаптардын санына максималдуу чек коё алабыз. Бул ар бир жалгыз бэкенддин тутумду басып кетишине жол бербейт жана башка серверлердин бири оор жүктө болсо дагы иштей беришин камсыздайт.

Сache

Келгиле, биздин сервердик системаларыбызда каталарды жекече кабыл алуу ыктымалдыгы аз деп коёлу. Бирок, операция бардык бул серверлерди параллелдүү суроону камтыса, ар бири өз алдынча ката кайтара алат. Бул каталар өз алдынча пайда болгондуктан, биздин тиркемедеги катанын жалпы ыктымалдыгы кандайдыр бир сервердин ката ыктымалдыгынан жогору. Каталардын жыйынды ыктымалдыгын P_total=1−(1−p)^n формуласынын жардамы менен эсептөөгө болот, мында n – сервердик системалардын саны.

Мисалы, бизде ар биринин ката ыктымалдыгы p=0,001 болгон (99,9% SLAга туура келген) он арткы чектер болсо, натыйжада ката ыктымалдыгы:

P_total=1−(1−0,001)^10=0,009955

Бул биздин бириккен SLA болжол менен 99% га төмөндөйт дегенди билдирет, бул параллелдүү бир нече бэкенддерди сураганда жалпы ишенимдүүлүк кандайча азаятын көрсөтүп турат. Бул маселени азайтуу үчүн, биз эстутумдагы кэшти ишке ашырсак болот.

Аны эстутумдагы кэш менен кантип чечсек болот

Эстутумдагы кэш жогорку ылдамдыктагы берилиштер буфери катары кызмат кылып, тез-тез кирүүчү маалыматтарды сактайт жана аны ар бир жолу потенциалдуу жай булактардан алуу зарылдыгын жокко чыгарат. Эстутумда сакталган кэштер тармак аркылуу берилиштерди алууга салыштырмалуу 0% ката мүмкүнчүлүгүнө ээ болгондуктан, алар биздин тиркеменин ишенимдүүлүгүн кыйла жогорулатат. Мындан тышкары, кэштөө түйүн трафигин азайтып, каталардын пайда болуу мүмкүнчүлүгүн дагы азайтат. Демек, эстутумдагы кэшти колдонуу менен, биз сервердик системаларыбызга салыштырмалуу биздин тиркемеде каталардын дагы төмөн деңгээлине жетише алабыз. Кошумчалай кетсек, эстутумдагы кэштер тармакка негизделген алып келүүгө караганда тезирээк маалыматтарды издөөнү сунуштайт, ошону менен колдонмонун кечигүү убактысын азайтат - көрүнүктүү артыкчылык.

Эстутумдагы кэш: Жекелештирилген кэштер

Колдонуучунун профилдери же сунуштары сыяктуу жекелештирилген маалыматтар үчүн эстутумдагы кэштерди колдонуу да абдан натыйжалуу болушу мүмкүн. Бирок биз колдонуучунун бардык суроо-талаптары жабышчаак сеанстарды талап кылган, алар үчүн кэштелген маалыматтарды колдонуу үчүн бир эле колдонмо инстанциясына ырааттуу барып турушун камсыз кылышыбыз керек. Жабышкак сессияларды ишке ашыруу кыйын болушу мүмкүн, бирок бул сценарий үчүн бизге татаал механизмдердин кереги жок. Кичинекей трафикти кайра теңдөө алгылыктуу, андыктан ырааттуу хэшинг сыяктуу туруктуу жүктү тең салмактоо алгоритми жетиштүү болот.

Андан тышкары, түйүн иштебей калган учурда, ырааттуу хэширлөө иштебей калган түйүн менен байланышкан колдонуучулар гана системанын үзгүлтүккө учурашын азайтып, тең салмактуулуктан өтүшүн камсыздайт. Бул ыкма жекелештирилген кэштерди башкарууну жеңилдетет жана биздин колдонмонун жалпы туруктуулугун жана иштешин жакшыртат.

Эстутумдагы кэш: жергиликтүү маалыматтардын репликациясы

Эгер биз кэштей турган маалыматтар маанилүү болсо жана системабыз иштеткен ар бир суроо-талапта, мисалы, кирүү саясаттары, жазылуу пландары же биздин домендеги башка маанилүү объектилер сыяктуу колдонулса, бул маалыматтардын булагы системабызда олуттуу ката кетириши мүмкүн. Бул көйгөйдү чечүү үчүн, бир ыкма толугу менен биздин колдонмонун эсине түздөн-түз бул маалыматтарды көчүрүү болуп саналат.

Бул сценарийде, булактагы берилиштердин көлөмү башкарылса, биз колдонмобуздун башталышында бул маалыматтардын сүрөтүн жүктөп алуу менен процессти баштасак болот. Кийинчерээк, кэштелген дайындардын булак менен синхрондолуп калышын камсыздоо үчүн жаңыртуу окуяларын ала алабыз. Бул ыкманы колдонуу менен биз бул маанилүү маалыматтарга жетүүнүн ишенимдүүлүгүн жогорулатабыз, анткени ар бир издөө 0% ката ыктымалдыгы менен түз эле эстутумдан ишке ашат. Кошумчалай кетсек, эстутумдан маалыматтарды алуу өзгөчө тез, ошону менен биздин колдонмонун иштешин оптималдаштыруу. Бул стратегия тышкы маалымат булагына таянуу менен байланышкан тобокелдиктерди эффективдүү азайтып, биздин колдонмонун иштеши үчүн маанилүү маалыматка ырааттуу жана ишенимдүү жетүүнү камсыз кылат.

Кайра жүктөлүүчү конфигурация

Бирок, тиркемени ишке киргизүү боюнча маалыматтарды жүктөө зарылчылыгы, ошону менен ишке киргизүү процессин кечеңдетүү, тиркемени тез баштоону жактаган "12 фактордук колдонмонун" принциптеринин бирин бузат. Бирок, биз кэшти колдонуунун артыкчылыктарынан ажырагыбыз келбейт. Бул дилемманы чечүү үчүн, келгиле, мүмкүн болуучу чечимдерди изилдеп көрөлү.

Тез баштоо, айрыкча, ар кандай физикалык түйүндөргө тиркемелерди тез миграциялоого таянган Kubernetes сыяктуу платформалар үчүн өтө маанилүү. Бактыга жараша, Kubernetes башталгыч зонддор сыяктуу функцияларды колдонуп, жай башталган колдонмолорду башкара алат.

Колдонмо иштеп жатканда конфигурацияларды жаңыртуу. Көбүнчө кэш убактысын же суроо-талаптын таймауттарын тууралоо өндүрүш маселелерин чечүү үчүн зарыл. Жаңыртылган конфигурация файлдарын колдонмобузга тез жайгаштыра алсак да, бул өзгөртүүлөрдү колдонуу адатта өчүрүп күйгүзүүнү талап кылат. Ар бир тиркеменин ишке киргизүү убактысынын узартылышы менен, кайра иштетүү биздин колдонуучуларга оңдоолорду жайылтууну кыйла кечеңдетиши мүмкүн.

Муну чечүү үчүн, бир чечим - конфигурацияларды бир эле учурда өзгөрмөдө сактоо жана аны мезгил-мезгили менен жаңыртып туруу. Бирок, HTTP сурамынын таймауттары сыяктуу кээ бир параметрлер, тиешелүү конфигурация өзгөргөндө HTTP же маалымат базасынын кардарларын кайра баштоону талап кылышы мүмкүн, бул потенциалдуу кыйынчылыктарды жаратат. Ошентсе да, кээ бир кардарлар, Java үчүн Cassandra драйвери сыяктуу, бул процессти жөнөкөйлөтүү менен конфигурацияларды автоматтык түрдө кайра жүктөөнү колдойт.

Кайра жүктөөчү конфигурацияларды ишке ашыруу колдонмону ишке киргизүүнүн узак убакыттарынын терс таасирин азайтып, өзгөчөлүктү желекче ишке ашырууну жеңилдетүү сыяктуу кошумча артыкчылыктарды сунуштайт. Бул ыкма конфигурация жаңыртууларын эффективдүү башкаруу менен бирге, тиркеменин ишенимдүүлүгүн жана жооп берүү жөндөмдүүлүгүн сактоого мүмкүндүк берет.

Fallback

Эми дагы бир көйгөйдү карап көрөлү: биздин системада колдонуучунун суроо-талабы бэкендге же маалымат базасына суроо жөнөтүү аркылуу кабыл алынган жана иштетилгенде, кээде күтүлгөн маалыматтардын ордуна ката жообу алынат. Андан кийин, биздин система колдонуучуга "ката" менен жооп берет.

Бирок, көптөгөн сценарийлерде колдонуучуну чоң кызыл ката билдирүүсү менен калтырбастан, бир аз эскирген маалыматтарды жана маалыматтарды жаңыртуу кечигүү бар экенин көрсөткөн билдирүүнү көрсөтүү жакшыраак болушу мүмкүн.

Бул маселени чечүү жана тутумубуздун жүрүм-турумун жакшыртуу үчүн биз Fallback үлгүсүн ишке ашырсак болот. Бул үлгүнүн артындагы концепция негизги булакка салыштырмалуу төмөн сапаттагы же жаңылыгы бар маалыматтарды камтышы мүмкүн болгон кошумча маалымат булагын камтыйт. Эгерде негизги маалымат булагы жеткиликсиз болсо же катаны кайтарса, система ката кабарын көрсөтүүнүн ордуна колдонуучуга маалыматтын кандайдыр бир түрүн көрсөтүүнү камсыз кылып, бул экинчи булактан маалыматтарды кайра алууга өтүшү мүмкүн.

Кайталап көрүңүз

Эгерде сиз жогорудагы сүрөттү карасаңыз, биз азыр туш болуп жаткан маселе менен кэш мисалында кездешкен көйгөйдүн ортосунда окшоштук бар экенин байкайсыз.

Аны чечүү үчүн биз кайра аракет кылуу деп аталган үлгүнү ишке ашырууну карап көрсөк болот. Кэштерге таянуунун ордуна, система ката болгон учурда сурамды автоматтык түрдө кайра жөнөтүү үчүн иштелип чыгышы мүмкүн. Бул кайра аракет үлгүсү жөнөкөйраак альтернатива сунуштайт жана биздин тиркемедеги каталардын ыктымалдыгын натыйжалуу азайтат. Дайындарды өзгөртүү үчүн кэшти жараксыз кылуунун татаал механизмдерин талап кылган кэштен айырмаланып, ишке ашпай калган сурамдарды кайра аракет кылуу салыштырмалуу оңой. Кэшти жараксыз кылуу программалык камсыздоо инженериясындагы эң татаал милдеттердин бири катары каралып жаткандыктан, кайра аракет кылуу стратегиясын кабыл алуу каталарды башкарууну жеңилдетип, системанын туруктуулугун жакшыртат.

Circuit Breaker

Бирок, мүмкүн болуучу кесепеттерди эске албастан, кайра аракет кылуу стратегиясын кабыл алуу андан аркы кыйынчылыктарга алып келиши мүмкүн.

Келгиле, биздин аркаларыбыздын бири ийгиликсиз болуп жатканын элестетип көрөлү. Мындай сценарийде иштебей калган серверге кайра аракет кылуу трафиктин көлөмүнүн олуттуу өсүшүнө алып келиши мүмкүн. Трафиктин бул капыстан көтөрүлүшү арткы тарапты басып алышы мүмкүн, бул катачылыкты күчөтүп, система боюнча каскаддык эффектти жаратышы мүмкүн.

Бул кыйынчылык менен күрөшүү үчүн, өчүргүч үлгүсү менен кайра аракет үлгүсүн толуктоо маанилүү. Автоматтык өчүргүч ылдыйкы кызматтардын ката ылдамдыгын көзөмөлдөгөн коргоо механизми катары кызмат кылат. Ката ылдамдыгы алдын ала аныкталган босогодон ашканда, автоматтык өчүргүч белгилүү бир убакытка жабыркаган кызматка суроо-талаптарды үзгүлтүккө учуратат. Бул мезгил ичинде система иштебей калган кызмат убактысын калыбына келтирүү үчүн кошумча суроо-талаптарды жөнөтүүдөн баш тартат. Белгиленген аралыктан кийин автоматтык өчүргүч этияттык менен чектелген сандагы сурамдардын өтүшүнө уруксат берип, кызмат турукташтырылганын текшерет. Кызмат калыбына келсе, кадимки трафик акырындык менен калыбына келтирилет; антпесе, чынжыр ачык бойдон калууда, кызмат нормалдуу иштөөсүн улантмайынча суроо-талаптарга бөгөт коюуну улантууда. Кайра аракет кылуу логикасы менен бирге автоматтык өчүргүчтүн үлгүсүн интеграциялоо менен биз ката кырдаалдарын эффективдүү башкара алабыз жана сервердеги каталар учурунда системанын ашыкча жүктөлүшүн алдын алабыз.

Орнотуу

Жыйынтыктап айтканда, бул туруктуулуктун үлгүлөрүн ишке ашыруу менен биз өзгөчө кырдаалдарга каршы колдонмолорубузду бекемдей алабыз, жогорку жеткиликтүүлүктү сактап, колдонуучуларга үзгүлтүксүз тажрыйба бере алабыз. Кошумчалай кетсек, телеметрия долбоордун туруктуулугун камсыз кылууда көз жаздымда калтырылбашы керек болгон дагы бир инструмент экенин баса белгилегим келет. Жакшы журналдар жана көрсөткүчтөр кызматтардын сапатын бир топ жогорулатып, алардын иштеши боюнча баалуу түшүнүктөрдү берип, аларды андан ары жакшыртуу үчүн негизделген чечимдерди кабыл алууга жардам берет.