Fintech жобаларына арналған нақты әлемдегі тұрақты стратегиялар

Бағдарламалық құралдағы тұрақтылық қолданбаның күтпеген мәселелер немесе сәтсіздіктер жағдайында да біркелкі және сенімді жұмысын жалғастыру мүмкіндігін білдіреді. Fintech жобаларында тұрақтылық бірнеше себептерге байланысты ерекше маңызды. Біріншіден, компаниялар реттеуші талаптарды орындауға міндетті және қаржылық реттеушілер жүйедегі тұрақтылықты сақтау үшін операциялық тұрақтылыққа баса назар аударады. Сонымен қатар, цифрлық құралдардың таралуы және үшінші тарап провайдерлеріне сенім артуы Fintech бизнесін қауіпсіздіктің жоғары қауіптеріне ұшыратады. Тұрақтылық сонымен қатар киберқауіптер, пандемия немесе геосаяси оқиғалар сияқты әртүрлі факторлардың әсерінен болатын үзілістер қаупін азайтуға, негізгі бизнес операциялары мен маңызды активтерді қорғауға көмектеседі. Тұрақтылық үлгілері арқылы біз бағдарламалық жасақтаманың үзілістерге төтеп бере алатынын және оның жұмысын сақтай алатынын қамтамасыз ету үшін жасалған ең жақсы тәжірибелер мен стратегиялардың жиынтығын түсінеміз. Бұл үлгілер қателерді өңдеу, жүктемені басқару және сәтсіздіктерден қалпына келтіру механизмдерін қамтамасыз ететін қауіпсіздік торлары сияқты әрекет етеді, осылайша қолданбалардың қолайсыз жағдайларда берік және сенімді болып қалуын қамтамасыз етеді. Ең көп тараған тұрақтылық стратегияларына аралық, кэш, резерв, қайталау және автоматты ажыратқыш кіреді. Бұл мақалада мен оларды шешуге көмектесетін мәселелердің мысалдарымен толығырақ талқылаймын. Бөлме Жоғарыдағы параметрді қарастырайық. Бізде кейбір деректерді алу үшін артымызда бірнеше серверлері бар өте қарапайым қолданба бар. Бұл серверлерге қосылған бірнеше HTTP клиенттері бар. Олардың барлығы бірдей қосылым пулын бөліседі екен! Сондай-ақ CPU және RAM сияқты басқа ресурстар. Егер серверлердің бірінде сұраудың кешігуі жоғары болатын қандай да бір мәселелер туындаса, не болады? Жауап беру уақыты жоғары болғандықтан, бүкіл қосылым пулы толығымен backend1 жауаптарын күтетін сұраулармен толтырылады. Нәтижесінде сау сервер2 және сервер3 үшін арналған сұраулар жалғастыра алмайды, себебі пул таусылған. Бұл біздің серверлеріміздің біріндегі сәтсіздік бүкіл қолданбада сәтсіздікке әкелуі мүмкін дегенді білдіреді. Ең дұрысы, қолданбаның қалған бөлігі қалыпты жұмысын жалғастыра бергенде, ақаулы сервермен байланысты функцияның ғана деградацияға ұшырауын қалаймыз. Бөлме үлгісі дегеніміз не? «Balkhead үлгісі» термині кеме жасаудан шыққан, ол кеме ішінде бірнеше оқшауланған бөліктерді жасауды қамтиды. Егер бір бөлікте ағып кету орын алса, ол суға толады, бірақ басқа бөліктерге әсер етпейді. Бұл оқшаулау бір рет бұзылғандықтан бүкіл кеменің батып кетуіне жол бермейді. Бұл мәселені шешу үшін аралық қалқан үлгісін қалай пайдалана аламыз? Бөлме үлгісін қолданбадағы ресурстардың әртүрлі түрлерін оқшаулау үшін пайдалануға болады, бұл бір бөліктегі ақаулықтың бүкіл жүйеге әсер етуіне жол бермейді. Міне, біз оны мәселемізге қалай қолдана аламыз: Қосылым пулдарын оқшаулау Біз әр сервер (backend1, backend2, backend3) үшін бөлек қосылым пулдарын жасай аламыз. Бұл backend1 жоғары жауап уақыттарын немесе сәтсіздіктерді бастан кешірсе, оның қосылым пулы тәуелсіз таусылып, backend2 және backend3 үшін қосылым пулдарын әсер етпейтінін қамтамасыз етеді. Бұл оқшаулау сау серверлерге сұрауларды қалыпты түрде өңдеуді жалғастыруға мүмкіндік береді. Фондық әрекеттер үшін ресурстарды шектеу Бөлшектерді пайдалану арқылы біз пакеттік өңдеу немесе жоспарланған тапсырмалар сияқты фондық әрекеттер үшін арнайы ресурстарды бөле аламыз. Бұл осы әрекеттердің нақты уақыттағы операцияларға қажетті ресурстарды тұтынуына жол бермейді. Мысалы, кіріс сұрауларын өңдеу үшін жеткілікті ресурстар қолжетімді болуын қамтамасыз ете отырып, фондық тапсырмаларға арналған ағындар санын немесе CPU пайдалануын шектей аламыз. Кіріс сұрауларына шектеулерді орнату Бөлмелерді қолданбаның әртүрлі бөліктеріне кіріс сұраулар санын шектеу үшін де қолдануға болады. Мысалы, біз әрбір жоғары ағын қызметі үшін бір уақытта өңделетін сұраулар санына максималды шектеу қоя аламыз. Бұл кез келген жалғыз сервердің жүйені басып кетуіне жол бермейді және басқа серверлердің біреуі ауыр жүктеме астында болса да жұмыс істей беруін қамтамасыз етеді. Сах Біздің серверлік жүйелерде қателерді жеке кездестіру ықтималдығы төмен делік. Дегенмен, операция осы серверлердің барлығын параллельді сұрауды қамтитын кезде, әрқайсысы қатені дербес қайтара алады. Бұл қателер тәуелсіз орын алатындықтан, біздің қолданбадағы қатенің жалпы ықтималдығы кез келген жалғыз сервердің қате ықтималдығынан жоғары. Жиынтық қате ықтималдығын P_total=1−(1−p)^n формуласы арқылы есептеуге болады, мұндағы n – серверлік жүйелердің саны. Мысалы, егер бізде әрқайсысының қате ықтималдығы p=0,001 (SLA 99,9% сәйкес) бар он сервер болса, нәтижесінде қате ықтималдығы: P_total=1−(1−0,001)^10=0,009955 Бұл біздің біріктірілген SLA шамамен 99%-ға дейін төмендейтінін білдіреді, бұл параллельде бірнеше серверлерді сұрау кезінде жалпы сенімділіктің қалай төмендейтінін көрсетеді. Бұл мәселені азайту үшін біз жадтағы кэшті іске асыра аламыз. Оны жадтағы кэшпен қалай шешуге болады Жадтағы кэш жоғары жылдамдықты деректер буфері ретінде қызмет етеді, жиі қол жетімді деректерді сақтайды және оны ықтимал баяу көздерден әр уақытта алу қажеттілігін болдырмайды. Жадта сақталған кэштердің желі арқылы деректерді алумен салыстырғанда қателік ықтималдығы 0% болғандықтан, олар біздің қолданбаның сенімділігін айтарлықтай арттырады. Сонымен қатар, кэштеу желілік трафикті азайтып, қателер ықтималдығын одан әрі азайтады. Демек, жадтағы кэшті пайдалану арқылы біз серверлік жүйелермен салыстырғанда қолданбамыздағы қателердің одан да төмен деңгейіне қол жеткізе аламыз. Бұған қоса, жадтағы кэштер желіге негізделген алудан гөрі деректерді жылдам алуды ұсынады, осылайша қолданбаның кідірісін азайтады, бұл маңызды артықшылық. Жадтағы кэш: жекелендірілген кэштер Пайдаланушы профильдері немесе ұсыныстар сияқты жеке деректер үшін жадтағы кэштерді пайдалану да жоғары тиімді болуы мүмкін. Бірақ пайдаланушының барлық сұраулары олар үшін кэштелген деректерді пайдалану үшін бір қолданба данасына тұрақты өтуін қамтамасыз етуіміз керек, бұл жабысқақ сеанстарды қажет етеді. Жабысқақ сеанстарды орындау қиын болуы мүмкін, бірақ бұл сценарий үшін бізге күрделі механизмдер қажет емес. Кішігірім трафикті қайта теңестіру қолайлы, сондықтан тұрақты хэштеу сияқты тұрақты жүктемені теңестіру алгоритмі жеткілікті. Сонымен қатар, түйін сәтсіз болған жағдайда, дәйекті хэштеу тек сәтсіз түйінмен байланысты пайдаланушылардың қайта теңестіруден өтуін қамтамасыз етеді, жүйенің бұзылуын азайтады. Бұл тәсіл жекелендірілген кэштерді басқаруды жеңілдетеді және қолданбамыздың жалпы тұрақтылығы мен өнімділігін арттырады. Жадтағы кэш: жергілікті деректерді репликациялау Егер біз кэштеуді жоспарлап отырған деректер маңызды болса және жүйеміз өңдейтін әрбір сұрауда, мысалы, кіру саясаттары, жазылым жоспарлары немесе домендегі басқа маңызды нысандарда пайдаланылса, бұл деректердің көзі жүйемізде маңызды сәтсіздікке әкелуі мүмкін. Бұл мәселені шешу үшін бір тәсіл - бұл деректерді тікелей қолданбамыздың жадына толығымен көшіру. Бұл сценарийде, егер дереккөздегі деректер көлемі басқарылатын болса, қолданбамыздың басында осы деректердің суретін жүктеп алу арқылы процесті бастауға болады. Кейіннен кэштелген деректердің дереккөзбен синхрондалғанын қамтамасыз ету үшін жаңарту оқиғаларын қабылдай аламыз. Бұл әдісті қолдану арқылы біз осы маңызды деректерге қол жеткізу сенімділігін арттырамыз, өйткені әрбір шығарып алу 0% қате ықтималдығы бар жадтан тікелей орындалады. Сонымен қатар, деректерді жадтан алу өте жылдам, осылайша біздің қолданба өнімділігін оңтайландырады. Бұл стратегия біздің қолданба жұмысы үшін маңызды ақпаратқа дәйекті және сенімді қол жеткізуді қамтамасыз ете отырып, сыртқы деректер көзіне сенумен байланысты тәуекелді тиімді түрде азайтады. Қайта жүктелетін конфигурация Дегенмен, қолданбаны іске қосу кезінде деректерді жүктеп алу қажеттілігі, осылайша іске қосу процесін кейінге қалдырады, қолданбаны жылдам іске қосуды жақтайтын «12 факторлы қолданба» принциптерінің бірін бұзады. Бірақ біз кэштеуді пайдаланудың артықшылықтарын жоғалтқымыз келмейді. Бұл дилемманы шешу үшін ықтимал шешімдерді қарастырайық. Жылдам іске қосу, әсіресе әртүрлі физикалық түйіндерге қолданбаларды жылдам тасымалдауға негізделген Kubernetes сияқты платформалар үшін өте маңызды. Бақытымызға орай, Kubernetes іске қосу зондтары сияқты мүмкіндіктерді пайдаланып баяу іске қосылатын қолданбаларды басқара алады. Қолданба жұмыс істеп тұрған кезде конфигурацияларды жаңарту бізге тап болуы мүмкін тағы бір қиындық. Көбінесе кэш уақытын немесе сұрау күту уақытын реттеу өндіріс мәселелерін шешу үшін қажет. Жаңартылған конфигурация файлдарын қолданбамызға жылдам орналастыра алатын болсақ та, бұл өзгерістерді қолдану әдетте қайта іске қосуды қажет етеді. Әрбір қолданбаның ұзартылған іске қосу уақытымен қайта іске қосу пайдаланушыларымызға түзетулерді енгізуді айтарлықтай кешіктіруі мүмкін. Мұны шешу үшін бір шешім - конфигурацияларды бір мезгілде айнымалы мәнде сақтау және оны мерзімді түрде жаңартып тұратын фондық ағынды алу. Дегенмен, HTTP сұрауының күту уақыттары сияқты кейбір параметрлер сәйкес конфигурация өзгерген кезде ықтимал қиындық тудыратын HTTP немесе дерекқор клиенттерін қайта іске қосуды талап етуі мүмкін. Дегенмен, Java үшін Cassandra драйвері сияқты кейбір клиенттер конфигурацияларды автоматты түрде қайта жүктеуді қолдайды, бұл процесті жеңілдетеді. Қайта жүктелетін конфигурацияларды іске асыру ұзақ қолданбаны іске қосу уақытының теріс әсерін азайтып, мүмкіндік жалауын іске асыруды жеңілдету сияқты қосымша артықшылықтарды ұсына алады. Бұл тәсіл конфигурация жаңартуларын тиімді басқара отырып, қолданбаның сенімділігі мен жауап беру қабілетін сақтауға мүмкіндік береді. Кері шегіну Енді тағы бір мәселені қарастырайық: біздің жүйеде пайдаланушы сұрауы серверге немесе дерекқорға сұрау жіберу арқылы алынған және өңделген кезде, күтілетін деректердің орнына кейде қате жауап алынады. Кейіннен біздің жүйе пайдаланушыға «қате» арқылы жауап береді. Дегенмен, көптеген сценарийлерде пайдаланушыны үлкен қызыл қате туралы хабармен қалдырмай, деректерді жаңартудың кешігуі бар екенін көрсететін хабармен бірге сәл ескірген деректерді көрсету жақсырақ болуы мүмкін. Бұл мәселені шешу және жүйенің әрекетін жақсарту үшін біз Fallback үлгісін енгізе аламыз. Бұл үлгінің артындағы тұжырымдама негізгі көзбен салыстырғанда сапасы төмен немесе жаңалығы бар деректерді қамтуы мүмкін қосымша деректер көзінің болуын қамтиды. Бастапқы деректер көзі қолжетімсіз болса немесе қатені қайтарса, жүйе қате туралы хабарды көрсетудің орнына пайдаланушыға ақпараттың қандай да бір пішінінің ұсынылуын қамтамасыз ете отырып, осы қосымша көзден деректерді алуға қайта оралуы мүмкін. Қайталап көріңіз Жоғарыдағы суретке қарасаңыз, қазіргі кездегі мәселе мен кэш үлгісінде кездесетін мәселе арасындағы ұқсастықты байқайсыз. Оны шешу үшін біз қайталау деп аталатын үлгіні енгізуді қарастыра аламыз. Кэштерге сенудің орнына, жүйе қате болған жағдайда сұрауды автоматты түрде қайта жіберу үшін жобалануы мүмкін. Бұл қайталау үлгісі қарапайымырақ балама ұсынады және қолданбамыздағы қателердің ықтималдығын тиімді түрде азайтады. Деректерді өзгерту үшін күрделі кэшті жарамсыздандыру механизмдерін жиі талап ететін кэштеуден айырмашылығы, сәтсіз сұрауларды қайталау салыстырмалы түрде оңай орындалады. Кэшті жарамсыздандыру бағдарламалық жасақтама жасаудағы ең күрделі тапсырмалардың бірі ретінде кеңінен қарастырылатындықтан, қайталау стратегиясын қабылдау қателерді өңдеуді жеңілдетеді және жүйенің тұрақтылығын жақсартады. Ажыратқыш Дегенмен, ықтимал салдарларды ескермей қайталау стратегиясын қабылдау одан әрі асқынуларға әкелуі мүмкін. Біздің серверлеріміздің бірі сәтсіздікке ұшырағанын елестетіп көрейік. Мұндай сценарийде сәтсіз серверге қайталауды бастау трафик көлемінің айтарлықтай өсуіне әкелуі мүмкін. Бұл трафиктің кенеттен өсуі серверді басып кетуі мүмкін, бұл сәтсіздікті күшейтеді және жүйеде каскадтық әсерді тудыруы мүмкін. Бұл қиындықты жеңу үшін қайталау үлгісін автоматты ажыратқыш үлгісімен толықтыру маңызды. Ажыратқыш төмен ағындық қызметтердің қателік жылдамдығын бақылайтын қорғау механизмі ретінде қызмет етеді. Қате деңгейі алдын ала анықталған шекті мәннен асқанда, автоматты ажыратқыш белгілі бір уақытқа әсер ететін қызметке сұрауларды үзеді. Бұл кезеңде жүйе істен шыққан қызмет уақытын қалпына келтіруге мүмкіндік беру үшін қосымша сұрауларды жіберуден бас тартады. Белгіленген аралықтан кейін автоматты ажыратқыш сақтықпен қызметтің тұрақтанғанын тексере отырып, сұраулардың шектеулі санына өтуге мүмкіндік береді. Егер қызмет қалпына келсе, қалыпты трафик біртіндеп қалпына келтіріледі; әйтпесе, қызмет қалыпты жұмысын қалпына келтірмейінше, схема сұрауларды блоктауды жалғастыра отырып, ашық қалады. Қайталау логикасымен қатар автоматты ажыратқыш үлгісін біріктіру арқылы біз қателік жағдайларын тиімді басқара аламыз және сервер ақаулары кезінде жүйенің шамадан тыс жүктелуін болдырмаймыз. Орау Қорытындылай келе, осы төзімділік үлгілерін енгізу арқылы біз төтенше жағдайларға қарсы қолданбаларымызды күшейте аламыз, жоғары қолжетімділікті сақтай аламыз және пайдаланушыларға үздіксіз тәжірибені ұсына аламыз. Бұған қоса, телеметрия жобаның тұрақтылығын қамтамасыз ету кезінде назардан тыс қалмауы керек тағы бір құрал екенін атап өткім келеді. Жақсы журналдар мен көрсеткіштер қызметтердің сапасын айтарлықтай арттырып, олардың өнімділігі туралы құнды түсініктер беріп, оларды одан әрі жақсарту үшін негізделген шешімдер қабылдауға көмектеседі.