რეალურ სამყაროში გამძლე სტრატეგიები Fintech პროექტებისთვის

პროგრამული უზრუნველყოფის გამძლეობა გულისხმობს აპლიკაციის უნარს გააგრძელოს ფუნქციონირება შეუფერხებლად და საიმედოდ, თუნდაც მოულოდნელი პრობლემების ან წარუმატებლობის შემთხვევაში. Fintech პროექტებში გამძლეობას განსაკუთრებით დიდი მნიშვნელობა აქვს რამდენიმე მიზეზის გამო. პირველ რიგში, კომპანიები ვალდებულნი არიან დააკმაყოფილონ მარეგულირებელი მოთხოვნები და ფინანსური მარეგულირებლები ხაზს უსვამენ ოპერაციულ მდგრადობას სისტემის შიგნით სტაბილურობის შესანარჩუნებლად. უფრო მეტიც, ციფრული ხელსაწყოების გავრცელება და მესამე მხარის სერვისის პროვაიდერებზე დამოკიდებულება ავლენს Fintech-ის ბიზნესს უსაფრთხოების გაზრდილი საფრთხეების წინაშე. გამძლეობა ასევე ხელს უწყობს შერბილების რისკების შერბილებას სხვადასხვა ფაქტორებით, როგორიცაა კიბერ საფრთხეები, პანდემიები ან გეოპოლიტიკური მოვლენები, იცავს ძირითად ბიზნეს ოპერაციებს და კრიტიკულ აქტივებს. მდგრადობის ნიმუშების მიხედვით, ჩვენ გვესმის საუკეთესო პრაქტიკისა და სტრატეგიების ერთობლიობა, რომელიც შექმნილია იმის უზრუნველსაყოფად, რომ პროგრამული უზრუნველყოფა გაუძლოს შეფერხებებს და შეინარჩუნოს თავისი ოპერაციები. ეს შაბლონები მოქმედებს როგორც უსაფრთხოების ბადეები, რომლებიც უზრუნველყოფენ შეცდომების დამუშავების, დატვირთვის მართვისა და წარუმატებლობისგან აღდგენის მექანიზმებს, რაც უზრუნველყოფს აპლიკაციების გამძლეობას და საიმედოობას არახელსაყრელ პირობებში. მდგრადობის ყველაზე გავრცელებული სტრატეგიები მოიცავს ნაყარს, ქეშს, უკან დაბრუნებას, ხელახლა ცდას და ამომრთველს. ამ სტატიაში მე მათ უფრო დეტალურად განვიხილავ, იმ პრობლემების მაგალითებით, რომელთა გადაჭრაშიც დაგეხმარებათ. ნაყარი მოდით შევხედოთ ზემოთ მოცემულ პარამეტრს. ჩვენ გვაქვს ძალიან ჩვეულებრივი აპლიკაცია, რომელსაც აქვს რამდენიმე სარეზერვო სისტემა, რომ მიიღოთ გარკვეული მონაცემები. არსებობს რამდენიმე HTTP კლიენტი, რომლებიც დაკავშირებულია ამ ბექენდებთან. გამოდის, რომ ყველა მათგანი იზიარებს ერთსა და იმავე კავშირის აუზს! ასევე სხვა რესურსები, როგორიცაა CPU და RAM. რა მოხდება, თუ ერთ-ერთ სარეზერვო სისტემას შეექმნება გარკვეული პრობლემები, რაც გამოიწვევს მოთხოვნის შეყოვნებას? გამოხმაურების მაღალი დროის გამო, მთელი კავშირის აუზი სრულად დაიკავებს მოთხოვნებს, რომლებიც ელოდება პასუხებს backend1-ისგან. შედეგად, ჯანსაღი backend2 და backend3-ისთვის განკუთვნილი მოთხოვნები ვერ გაგრძელდება, რადგან აუზი ამოწურულია. ეს ნიშნავს, რომ ჩვენს ერთ-ერთ სარეზერვო სისტემაში წარუმატებლობამ შეიძლება გამოიწვიოს მარცხი მთელ აპლიკაციაში. იდეალურ შემთხვევაში, ჩვენ გვსურს, რომ მხოლოდ ფუნქციონალურობამ, რომელიც დაკავშირებულია წარუმატებელ backend-თან, განიცადოს დეგრადაცია, ხოლო დანარჩენი აპლიკაცია განაგრძობს ნორმალურად მუშაობას. რა არის Bulkhead Pattern? ტერმინი Bulkhead pattern მომდინარეობს გემთმშენებლობისგან, ის გულისხმობს გემის შიგნით რამდენიმე იზოლირებული კუპეს შექმნას. თუ გაჟონვა მოხდა ერთ განყოფილებაში, ის ივსება წყლით, მაგრამ დანარჩენი განყოფილებები უცვლელი რჩება. ეს იზოლაცია ხელს უშლის მთელი გემის ჩაძირვას ერთი დარღვევის გამო. როგორ გამოვიყენოთ ნაყარის ნიმუში ამ პრობლემის მოსაგვარებლად? Bulkhead-ის ნიმუში შეიძლება გამოყენებულ იქნას აპლიკაციის შიგნით სხვადასხვა ტიპის რესურსების იზოლირებისთვის, რათა თავიდან აიცილოს ერთი ნაწილის წარუმატებლობა მთელ სისტემაზე. აი, როგორ შეგვიძლია გამოვიყენოთ იგი ჩვენს პრობლემაზე: კავშირის აუზების იზოლირება ჩვენ შეგვიძლია შევქმნათ ცალ-ცალკე კავშირის აუზები თითოეული ბექენდისთვის (backend1, backend2, backend3). ეს უზრუნველყოფს იმას, რომ თუ backend1 განიცდის მაღალი რეაგირების დროს ან წარუმატებლობას, მისი კავშირის აუზი დამოუკიდებლად ამოიწურება, რაც გავლენას არ მოახდენს backend2 და backend3 კავშირის აუზებზე. ეს იზოლაცია საშუალებას აძლევს ჯანსაღ ბექენდებს განაგრძონ მოთხოვნების ნორმალურად დამუშავება. ფონური აქტივობების რესურსების შეზღუდვა Bulkheads-ის გამოყენებით, ჩვენ შეგვიძლია გამოვყოთ კონკრეტული რესურსები ფონური აქტივობებისთვის, როგორიცაა ჯგუფური დამუშავება ან დაგეგმილი ამოცანები. ეს ხელს უშლის ამ აქტივობებს რეალურ დროში ოპერაციებისთვის საჭირო რესურსების მოხმარებაში. მაგალითად, ჩვენ შეგვიძლია შევზღუდოთ ძაფების რაოდენობა ან CPU-ის გამოყენება, რომელიც მიძღვნილი იქნება ფონური ამოცანების შესასრულებლად, რაც უზრუნველყოფს საკმარისი რესურსების ხელმისაწვდომობას შემომავალი მოთხოვნების დასამუშავებლად. შემომავალ მოთხოვნებზე შეზღუდვების დაყენება ნაყარი ასევე შეიძლება გამოყენებულ იქნას აპლიკაციის სხვადასხვა ნაწილზე შემომავალი მოთხოვნების რაოდენობის შესაზღუდად. მაგალითად, ჩვენ შეგვიძლია დავაწესოთ მაქსიმალური ლიმიტი იმ მოთხოვნების რაოდენობაზე, რომლებიც შეიძლება ერთდროულად დამუშავდეს თითოეული ზემოთ ნაკადის სერვისისთვის. ეს ხელს უშლის რომელიმე ცალკეული სარეზერვო სისტემის გადატვირთვას და უზრუნველყოფს, რომ სხვა ბექენდებმა გააგრძელონ ფუნქციონირება მაშინაც კი, თუ რომელიმე მათგანი მძიმე დატვირთვის ქვეშ იმყოფება. ჩიჩი დავუშვათ, რომ ჩვენს backend სისტემებს აქვთ შეცდომის ცალკეული შეხვედრის დაბალი ალბათობა. თუმცა, როდესაც ოპერაცია მოიცავს პარალელურად ყველა ამ საყრდენის მოთხოვნას, თითოეულს შეუძლია დამოუკიდებლად დააბრუნოს შეცდომა. იმის გამო, რომ ეს შეცდომები დამოუკიდებლად წარმოიქმნება, ჩვენს აპლიკაციაში შეცდომის საერთო ალბათობა უფრო მაღალია, ვიდრე რომელიმე ცალკეული სარეზერვო სისტემის შეცდომის ალბათობა. კუმულაციური შეცდომის ალბათობა შეიძლება გამოითვალოს ფორმულის გამოყენებით P_total=1−(1−p)^n, სადაც n არის backend სისტემების რაოდენობა. მაგალითად, თუ გვაქვს ათი უკანა ნაწილი, რომელთაგან თითოეული შეცდომის ალბათობით არის p=0.001 (შეესაბამება SLA 99.9%), შეცდომის ალბათობა არის: P_სულ=1−(1−0.001)^10=0.009955 ეს ნიშნავს, რომ ჩვენი კომბინირებული SLA მცირდება დაახლოებით 99%-მდე, რაც ასახავს იმას, თუ როგორ მცირდება მთლიანი საიმედოობა, როდესაც პარალელურად კითხულობთ რამდენიმე საზურგეს. ამ პრობლემის შესამსუბუქებლად, ჩვენ შეგვიძლია დავაყენოთ მეხსიერების ქეში. როგორ მოვაგვაროთ ის მეხსიერების ქეშით მეხსიერების ქეში ემსახურება მონაცემთა მაღალსიჩქარიან ბუფერს, ინახავს ხშირად ხელმისაწვდომ მონაცემებს და გამორიცხავს მათი პოტენციურად ნელი წყაროებიდან ყოველ ჯერზე მიღების აუცილებლობას. იმის გამო, რომ მეხსიერებაში შენახულ ქეშებს აქვს 0% შეცდომის შანსი ქსელში მონაცემების მიღებასთან შედარებით, ისინი მნიშვნელოვნად ზრდის ჩვენი აპლიკაციის სანდოობას. გარდა ამისა, ქეშირება ამცირებს ქსელის ტრაფიკს, რაც კიდევ უფრო ამცირებს შეცდომების შანსს. შესაბამისად, მეხსიერების ქეშის გამოყენებით, ჩვენ შეგვიძლია მივაღწიოთ კიდევ უფრო დაბალი შეცდომის კოეფიციენტს ჩვენს აპლიკაციაში, ჩვენს backend სისტემებთან შედარებით. გარდა ამისა, მეხსიერების ქეშები გვთავაზობენ მონაცემთა უფრო სწრაფ მოძიებას, ვიდრე ქსელზე დაფუძნებული მიღება, რითაც ამცირებს აპლიკაციის შეყოვნებას - შესამჩნევი უპირატესობა. მეხსიერების ქეში: პერსონალიზებული ქეში პერსონალიზებული მონაცემებისთვის, როგორიცაა მომხმარებლის პროფილები ან რეკომენდაციები, მეხსიერების ქეშის გამოყენება ასევე შეიძლება იყოს ძალიან ეფექტური. მაგრამ ჩვენ უნდა დავრწმუნდეთ, რომ მომხმარებლის ყველა მოთხოვნა მუდმივად მიდის იმავე აპლიკაციის მაგალითზე, რათა გამოიყენოს მათთვის ქეშირებული მონაცემები, რაც მოითხოვს წებოვან სესიებს. წებოვანი სესიების განხორციელება შეიძლება იყოს რთული, მაგრამ ამ სცენარისთვის ჩვენ არ გვჭირდება რთული მექანიზმები. ტრაფიკის მცირე გადაბალანსება მისაღებია, ამიტომ საკმარისი იქნება დატვირთვის დაბალანსების სტაბილური ალგორითმი, როგორიცაა თანმიმდევრული ჰეშირება. უფრო მეტიც, კვანძის უკმარისობის შემთხვევაში, თანმიმდევრული ჰეშინგი უზრუნველყოფს, რომ მხოლოდ წარუმატებელ კვანძთან დაკავშირებულმა მომხმარებლებმა გაიარონ დაბალანსება, რაც ამცირებს სისტემის დარღვევას. ეს მიდგომა ამარტივებს პერსონალიზებული ქეშების მართვას და აძლიერებს ჩვენი აპლიკაციის საერთო სტაბილურობასა და შესრულებას. მეხსიერების ქეში: ადგილობრივი მონაცემთა რეპლიკაცია თუ მონაცემები, რომლებსაც ჩვენ ვაპირებთ ქეშირებას, კრიტიკულია და გამოიყენება ყველა მოთხოვნაში, რომელსაც ჩვენი სისტემა ამუშავებს, როგორიცაა წვდომის პოლიტიკა, გამოწერის გეგმები ან სხვა სასიცოცხლო მნიშვნელობის ერთეულები ჩვენს დომენში - ამ მონაცემების წყარომ შეიძლება გამოიწვიოს მნიშვნელოვანი მარცხი ჩვენს სისტემაში. ამ გამოწვევის გადასაჭრელად, ერთი მიდგომაა ამ მონაცემების სრულად გამეორება პირდაპირ ჩვენი აპლიკაციის მეხსიერებაში. ამ სცენარში, თუ წყაროში მონაცემთა მოცულობა მართვადია, ჩვენ შეგვიძლია დავიწყოთ პროცესი ამ მონაცემების სნეპშოტის ჩამოტვირთვის გზით ჩვენი აპლიკაციის დასაწყისში. შემდგომში, ჩვენ შეგვიძლია მივიღოთ განახლების მოვლენები, რათა დავრწმუნდეთ, რომ ქეშირებული მონაცემები დარჩება წყაროსთან სინქრონიზებული. ამ მეთოდის მიღებით, ჩვენ ვაძლიერებთ ამ მნიშვნელოვან მონაცემებზე წვდომის საიმედოობას, რადგან თითოეული მოძიება ხდება უშუალოდ მეხსიერებიდან 0% შეცდომის ალბათობით. გარდა ამისა, მეხსიერებიდან მონაცემების მოძიება ძალზე სწრაფია, რითაც ოპტიმიზაციას უკეთებს ჩვენი აპლიკაციის მუშაობას. ეს სტრატეგია ეფექტურად ამცირებს რისკს, რომელიც დაკავშირებულია მონაცემთა გარე წყაროზე დაყრდნობით, რაც უზრუნველყოფს ჩვენი აპლიკაციის მუშაობისთვის კრიტიკულ ინფორმაციაზე თანმიმდევრულ და საიმედო წვდომას. ხელახლა ჩატვირთვადი კონფიგურაცია თუმცა, აპლიკაციის გაშვების შესახებ მონაცემების ჩამოტვირთვის აუცილებლობა, რითაც აჭიანურებს გაშვების პროცესს, არღვევს "12-ფაქტორიანი აპლიკაციის" ერთ-ერთ პრინციპს, რომელიც მხარს უჭერს აპლიკაციის სწრაფი გაშვებას. მაგრამ, ჩვენ არ გვინდა დავკარგოთ ქეშირების გამოყენების უპირატესობები. ამ დილემის გადასაჭრელად, მოდით გამოვიკვლიოთ პოტენციური გადაწყვეტილებები. სწრაფი გაშვება გადამწყვეტია, განსაკუთრებით ისეთი პლატფორმებისთვის, როგორიცაა Kubernetes, რომლებიც ეყრდნობიან აპლიკაციის სწრაფ მიგრაციას სხვადასხვა ფიზიკურ კვანძებში. საბედნიეროდ, Kubernetes-ს შეუძლია ნელა დაწყებული აპლიკაციების მართვა ისეთი ფუნქციების გამოყენებით, როგორიცაა გაშვების ზონდები. კიდევ ერთი გამოწვევა, რომლის წინაშეც შეიძლება აღმოვჩნდეთ, არის კონფიგურაციის განახლება აპლიკაციის გაშვებისას. ხშირად, ქეშის დროის კორექტირება ან მოთხოვნის ვადის ამოწურვა აუცილებელია წარმოების პრობლემების მოსაგვარებლად. მაშინაც კი, თუ ჩვენ შეგვიძლია სწრაფად განვათავსოთ განახლებული კონფიგურაციის ფაილები ჩვენს აპლიკაციაში, ამ ცვლილებების გამოყენება ჩვეულებრივ მოითხოვს გადატვირთვას. თითოეული აპლიკაციის გაშვების გახანგრძლივებული დროით, მოძრავი გადატვირთვამ შეიძლება მნიშვნელოვნად შეაფერხოს ჩვენს მომხმარებლებზე შესწორებების გამოყენება. ამის გადასაჭრელად, ერთი გამოსავალი არის კონფიგურაციების შენახვა კონკურენტულ ცვლადში და პერიოდულად განაახლოს ფონის თემა. თუმცა, გარკვეულმა პარამეტრებმა, როგორიცაა HTTP მოთხოვნის ვადის ამოწურვა, შეიძლება მოითხოვოს HTTP ან მონაცემთა ბაზის კლიენტების ხელახალი ინიცირება, როდესაც შესაბამისი კონფიგურაცია იცვლება, რაც პოტენციურ გამოწვევას წარმოადგენს. მიუხედავად ამისა, ზოგიერთი კლიენტი, როგორიცაა Cassandra დრაივერი Java-სთვის, მხარს უჭერს კონფიგურაციების ავტომატურ გადატვირთვას, რაც ამარტივებს ამ პროცესს. ხელახლა ჩატვირთვადი კონფიგურაციების დანერგვამ შეიძლება შეამსუბუქოს აპლიკაციის გაშვების ხანგრძლივი დროის უარყოფითი გავლენა და შესთავაზოს დამატებითი უპირატესობები, როგორიცაა ფუნქციების დროშის დანერგვის ხელშეწყობა. ეს მიდგომა საშუალებას გვაძლევს შევინარჩუნოთ აპლიკაციის სანდოობა და რეაგირება კონფიგურაციის განახლებების ეფექტურად მართვის დროს. სარეზერვო ახლა მოდით გადავხედოთ კიდევ ერთ პრობლემას: ჩვენს სისტემაში, როდესაც მომხმარებლის მოთხოვნა მიიღება და მუშავდება მოთხოვნის გაგზავნით backend-ში ან მონაცემთა ბაზაში, ზოგჯერ, შეცდომის პასუხი მიიღება მოსალოდნელი მონაცემების ნაცვლად. შემდგომში, ჩვენი სისტემა პასუხობს მომხმარებელს „შეცდომით“. თუმცა, ბევრ სცენარში, შეიძლება უფრო სასურველი იყოს ოდნავ მოძველებული მონაცემების ჩვენება მესიჯთან ერთად, რომელიც მიუთითებს მონაცემთა განახლების შეფერხებაზე, ვიდრე მომხმარებლისთვის დიდი წითელი შეცდომის გაგზავნა. ამ პრობლემის მოსაგვარებლად და ჩვენი სისტემის ქცევის გასაუმჯობესებლად, ჩვენ შეგვიძლია განვახორციელოთ Fallback ნიმუში. ამ ნიმუშის კონცეფცია გულისხმობს მონაცემთა მეორადი წყაროს ქონას, რომელიც შეიძლება შეიცავდეს უფრო დაბალი ხარისხის ან სიახლის მონაცემებს პირველად წყაროსთან შედარებით. თუ მონაცემთა პირველადი წყარო მიუწვდომელია ან დააბრუნებს შეცდომას, სისტემას შეუძლია დაუბრუნდეს მონაცემების ამ მეორადი წყაროდან მოძიებას, რაც უზრუნველყოფს მომხმარებლისთვის ინფორმაციის გარკვეული ფორმის წარდგენას შეცდომის შეტყობინების ნაცვლად. ხელახლა სცადეთ თუ დააკვირდებით ზემოთ მოცემულ სურათს, შეამჩნევთ მსგავსებას იმ საკითხს შორის, რომელსაც ახლა ვაწყდებით და ქეშის მაგალითს შორის. მის გადასაჭრელად, ჩვენ შეგვიძლია განვიხილოთ ნიმუშის განხორციელება, რომელიც ცნობილია როგორც ხელახალი ცდა. იმის ნაცვლად, რომ დაეყრდნოს ქეშებს, სისტემა შეიძლება შეიქმნას შეცდომის შემთხვევაში მოთხოვნის ავტომატურად ხელახლა გაგზავნისთვის. ეს განმეორებითი ნიმუში გთავაზობთ უფრო მარტივ ალტერნატივას და შეუძლია ეფექტურად შეამციროს შეცდომების ალბათობა ჩვენს აპლიკაციაში. ქეშისგან განსხვავებით, რომელიც ხშირად საჭიროებს კომპლექსურ ქეშის გაუქმების მექანიზმებს მონაცემთა ცვლილებების დასამუშავებლად, წარუმატებელი მოთხოვნების ხელახალი ცდა შედარებით მარტივია. იმის გამო, რომ ქეშის გაუქმება ფართოდ განიხილება, როგორც ერთ-ერთი ყველაზე რთული ამოცანა პროგრამული უზრუნველყოფის ინჟინერიაში, ხელახლა ცდის სტრატეგიის მიღებამ შეიძლება გაამარტივოს შეცდომების დამუშავება და გააუმჯობესოს სისტემის მდგრადობა. ამომრთველი თუმცა, განმეორებითი სტრატეგიის მიღებამ პოტენციური შედეგების გათვალისწინების გარეშე შეიძლება გამოიწვიოს შემდგომი გართულებები. წარმოვიდგინოთ, რომ ერთ-ერთმა ჩვენმა ჯგუფმა მარცხი განიცადა. ასეთ სცენარში, ხელახალი ცდების წამოწყება წარუმატებელ უკანა ჯგუფში შეიძლება გამოიწვიოს ტრაფიკის მოცულობის მნიშვნელოვანი ზრდა. ტრაფიკის ამ უეცარმა ზრდამ შეიძლება გადალახოს უკანა ნაწილი, გაამწვავოს მარცხი და პოტენციურად გამოიწვიოს კასკადური ეფექტი მთელ სისტემაში. ამ გამოწვევის დასაძლევად მნიშვნელოვანია ხელახლა ცდის ნიმუში შეავსოთ ამომრთველის შაბლონით. ამომრთველი ემსახურება როგორც დამცავი მექანიზმი, რომელიც აკონტროლებს ქვედა დინების სერვისების შეცდომის სიხშირეს. როდესაც შეცდომის კოეფიციენტი აჭარბებს წინასწარ განსაზღვრულ ზღვარს, ამომრთველი წყვეტს მოთხოვნებს დაზარალებული სერვისისთვის განსაზღვრული ხანგრძლივობით. ამ პერიოდის განმავლობაში სისტემა თავს იკავებს დამატებითი მოთხოვნების გაგზავნისგან, რათა დაუშვას წარუმატებელი მომსახურების დრო აღდგენის. განსაზღვრული ინტერვალის შემდეგ, ამომრთველი ფრთხილად იძლევა შეზღუდული რაოდენობის მოთხოვნების გავლის საშუალებას, ამოწმებს, სტაბილიზირებულია თუ არა სერვისი. სერვისის აღდგენის შემთხვევაში, ჩვეული მოძრაობა თანდათან აღდგება; წინააღმდეგ შემთხვევაში, წრე ღია რჩება და განაგრძობს მოთხოვნების დაბლოკვას, სანამ სერვისი არ განაახლებს ნორმალურ მუშაობას. ამომრთველის ნიმუშის ხელახალი ცდის ლოგიკასთან ერთად ინტეგრირებით, ჩვენ შეგვიძლია ეფექტურად ვმართოთ შეცდომის სიტუაციები და თავიდან ავიცილოთ სისტემის გადატვირთვა უკანა ნაწილის წარუმატებლობის დროს. შეფუთვა დასასრულს, ამ გამძლეობის შაბლონების დანერგვით, ჩვენ შეგვიძლია გავაძლიეროთ ჩვენი აპლიკაციები საგანგებო სიტუაციების წინააღმდეგ, შევინარჩუნოთ მაღალი ხელმისაწვდომობა და მივაწოდოთ უპრობლემო გამოცდილება მომხმარებლებს. გარდა ამისა, მინდა ხაზგასმით აღვნიშნო, რომ ტელემეტრია არის კიდევ ერთი ინსტრუმენტი, რომელიც არ უნდა იყოს უგულებელყოფილი პროექტის მდგრადობის უზრუნველყოფისას. კარგი ჟურნალები და მეტრიკა მნიშვნელოვნად გაზრდის სერვისების ხარისხს და უზრუნველყოფს ღირებული ინფორმაციის მიწოდებას მათი მუშაობის შესახებ, რაც ხელს უწყობს ინფორმირებული გადაწყვეტილებების მიღებას მათი შემდგომი გაუმჯობესებაში.