KeyDB, როგორც Redis-ის [პოტენციური] შემცვლელი

არ იყო მიმოხილვები "რედისის უფრო სწრაფი ალტერნატივის" შესახებ Habré-ზე - KeyDB. მისი გამოყენების საკმაოდ უახლესი გამოცდილება რომ მივიღე, მსურს შევავსო ეს ხარვეზი.

ფონი საკმაოდ ბანალურია: ერთ დღეს, ტრაფიკის დიდი ნაკადით, დაფიქსირდა აპლიკაციის მუშაობის მნიშვნელოვანი დეგრადაცია (კერძოდ, რეაგირების დრო). იმ დროს, სამწუხაროდ, შეუძლებელი იყო ნორმალური დიაგნოზის ჩატარება იმის შესახებ, რაც ხდებოდა, ამიტომ შემდგომში დაიგეგმა დატვირთვის ტესტების სერია. მათი ჩატარების შემდეგ, ჩვენ შევძელით აღმოვაჩინეთ bottleneck, რომელიც იყო მონაცემთა ბაზის ქეში Redis-ში. როგორც ხშირად ხდება, პრობლემა ვერ მოგვარდა დაუყოვნებლივ და სწორი გზით - დეველოპერების მიერ (სამუშაო ლოგიკის შეცვლით). ამიტომ, ცნობისმოყვარეობა და სიტუაციის შემოვლითი გზით დაძლევის სურვილი გაჩნდა. ასე გამოჩნდა ეს სტატია.

საკითხები

ზოგადად რედისის შესახებ

როგორც ბევრმა იცის, Redis არის ერთნაკადიანი მონაცემთა ბაზა. უფრო ზუსტად, ასეა მომხმარებლის მონაცემებთან მუშაობის კონტექსტში. ყოველივე ამის შემდეგ, მეოთხე ვერსიიდან, სერვისი, Redis-ის შიდა ოპერაციები გადაცემულია პარალელური შესრულებისთვის. თუმცა, ეს ცვლილება შეეხო მხოლოდ დატვირთვის მცირე ნაწილს, რადგან სამუშაოს უმეტესი ნაწილი შესრულებულია მომხმარებლის მონაცემებზე.

უთვალავი ასლი გატეხილია ამ თემაზე, მაგრამ Redis-ის დეველოპერები ჯიუტად უარს ამბობენ სრული პარალელიზმის განხორციელებაზე და აღნიშნავენ, თუ რამდენად გაართულებს ეს აპლიკაციას და გაზრდის ზედნადურ ხარჯებს, ასევე დაამატებს მეტ შეცდომებს. მათი პოზიცია ასეთია: თუ ერთი ბირთვიანი პრობლემის წინაშე დგახართ, პრობლემები გაქვთ აპლიკაციის არქიტექტურასთან და მასში რაღაც უნდა შეიცვალოს. თუმცა, მომხმარებლებს შორის არის „სხვა ბანაკიც“ - ისინი, ვინც ერთ ბირთვზე არიან ჩარჩენილი და ამტკიცებენ, რომ Redis თავისთვის ქმნის ბოსტნეულს. მართლაც დიდი დატვირთვების შემთხვევაში - ადრე თუ გვიან - გარდაუვალია ამ პრობლემის წინაშე, რაც აწესებს მნიშვნელოვან შეზღუდვებს არქიტექტურას და/ან იძულებით გართულებებს მასში.

ამა თუ იმ მოსაზრებას არ შევაფასებ. ამის ნაცვლად, მე გაგიზიარებთ ჩვენს კონკრეტულ შემთხვევას და როგორ მოვაგვარეთ იგი.

ჩვენი საქმე

ერთ-ერთ პროექტში შევხვდით იმ ფაქტს, რომ დეველოპერების გუნდმა დააკონფიგურირა მონაცემთა ბაზიდან (PostgreSQL) უკიდურესად აგრესიული ქეშირება Redis-ის საშუალებით. ეს იყო ერთადერთი გზა, რომლითაც ტრაფიკის უეცარი შემოდინების დროს გადაარჩინა თავად PostgreSQL და, შედეგად, აპლიკაცია სიკვდილისგან.

დატვირთვის ტესტების სერიის შემდეგ, ჩვენ გავაანალიზეთ სიტუაცია და აღმოვაჩინეთ, რომ Redis შემოიფარგლებოდა ერთი ბირთვით (რასაც ეწოდება "თარო"), რასაც მოჰყვა აპლიკაციის საკმაოდ სწრაფი დეგრადაცია. "დახრჩობა" იყო ექსპონენციალური: როგორც კი Redis-ის შესრულების ლიმიტი მიაღწია, ყველაფერი შეჩერდა.

დაახლოებით ასე გამოიყურებოდა:

New Relic-მა ნათლად გამოავლინა პრობლემა:

აქ მოცემულია ოპერაციის სტატისტიკა: get რედისში:

მას შემდეგ, რაც პრობლემა დეტალურად ეცნობა დეველოპერულ გუნდს, აღმოჩნდა, რომ „პრობლემა ახლა ვერ მოგვარდება“. ასე დაიწყო ოპერაციების მხარეს გამოსავლის ძიება და უკვე ნახსენები KeyDB იყო პასუხი.

თუმცა, სანამ ჩვენს მიმოხილვას დავიწყებთ, აღსანიშნავია, რომ პროექტი იყენებს დამოუკიდებელ Redis-ს, რადგან Sentinel-ზე დაფუძნებული კლასტერული გადაწყვეტა გაცილებით დაბალია ლატენტურობის თვალსაზრისით. ერთი აშკარა გამოსავალი იყო ქეშის რამდენიმე ასლის შექმნა: და აპლიკაციის გაშვება ყველგან დაბალანსებით! თუმცა, დეველოპერებთან კონსულტაციის შემდეგ, ჩვენ იძულებული გავხდით ეს ვარიანტი გაგვეგდო აპლიკაციის აქტიური და რთული ქეშის გაუქმების მექანიზმის გამო. იგივე პრობლემა გავრცელდა ქეშის განაწილებაზეც.

სწრაფი დათვალიერება KeyDB-ზე

პრობლემის შესაძლო გადაწყვეტის ძიებისას ჩვენ აღმოვაჩინეთ აპლიკაცია სახელწოდებით KeyDB. ეს არის Redis-ის ჩანგალი შემუშავებული კანადური კომპანია და განაწილებულია უფასო BSD ლიცენზიით. პროექტი ძალიან ახალგაზრდაა: ის 2019 წლის დასაწყისიდან არსებობს. მისი ისტორია იმაში მდგომარეობს, რომ ავტორებმაც ერთხელ წააწყდნენ Redis-ის შეზღუდვებს... და გადაწყვიტეს საკუთარი ჩანგალი გაეკეთებინათ. უფრო მეტიც, მან არა მხოლოდ გადაჭრა ცნობილი პრობლემები, არამედ მიიღო დამატებითი ფუნქციები, რომლებიც ხელმისაწვდომია მხოლოდ Redis-ის საწარმოო ვერსიაში.

ვისაც სურს უფრო დეტალურად გაეცნოს KeyDB-ს, არის კარგი შესავალი სტატია მედიუმზე, რომელიც წარმოგიდგენთ DBMS-ს და მოკლე კრიტერიუმებს, რომლებიც ადარებენ მის „მშობელს“ - Redis.

უპირველეს ყოვლისა, KeyDB-მა მიგვიზიდა ჩვენი პრობლემების პოტენციური გადაწყვეტით და ამავდროულად გვაინტერესებდა რამდენიმე დამატებითი ფუნქცია. KeyDB-ის გამოყენებამ დაჰპირდა შემდეგ უპირატესობებს:

• სრული მრავალძაფის მიღება;
• სრული და აბსოლუტური თავსებადობა Redis-თან (ეს განსაკუთრებით მნიშვნელოვანი იყო ჩვენთვის, რადგან შეუძლებელი იყო რაიმე ცვლილებების შეტანა განაცხადის მხარეს), რაც ასევე გვპირდებოდა უპრობლემო მიგრაციას;
• ჩაშენებული სარეზერვო მექანიზმი S3 საცავში;
• მარტივი განხორციელების აქტიური რეპლიკაცია;
• მარტივი კლასტერირება და დაშლა Sentinel-ისა და სხვა დამხმარე პროგრამული უზრუნველყოფის გარეშე.

3 ათასზე მეტი ვარსკვლავი და ბევრი კონტრიბუტორი GitHub-ზეც გამამხნევებლად გამოიყურებოდა. აპლიკაცია საკმაოდ აქტიურად არის შემუშავებული და მხარდაჭერილი, რაც ნათლად ჩანს კომისიებში, საკითხებში კომუნიკაციაში, ასევე დახურულ (მიღებულ) პიარებში. ყველა ფრონტზე მთავარი დამრიგებლის პასუხი ყოველთვის მეგობრული და სწრაფია. ზოგადად, ბევრი არგუმენტი იყო.

მიგრაცია და შედეგები

მიუხედავად იმისა, რომ მიგრაციის პროექტი ცოტა აზარტული იყო (KeyDB-ის სიახლის გამო), დასაკარგი ბევრი არაფერი იყო. ყოველივე ამის შემდეგ, ცვლილებების უკან დაბრუნება საკმაოდ სწრაფი და მარტივია - საბედნიეროდ, მთელი ინფრასტრუქტურა განლაგებულია Kubernetes-ში და ჩაშენებული მექანიზმები მოძრავი განახლება ასეთ პრობლემებს ძალიან კარგად აგვარებენ.

ზოგადად, ჩვენ მოვამზადეთ Helm-ის შაბლონები, სატესტო გარემოში აპლიკაცია გადავრთეთ ახალ მონაცემთა ბაზაზე და გავაფართოვეთ ეს ყველაფერი, გადავეცი კლიენტის ხარისხის უზრუნველყოფის განყოფილებას.

დაიწყო ტესტირება, რომელიც დაახლოებით ერთი კვირა გაგრძელდა და რომლის დეტალებზეც არ ჩავუღრმავდით. ჩვენ მხოლოდ ვიცით, რომ მომხმარებელმა შეამოწმა Redis-თან მუშაობის სტანდარტული ფუნქციები PHP დრაივერის გამოყენებით phpredisდა ასევე ჩაატარა მომხმარებლის ინტერფეისის QA ტესტირება. ამის შემდეგ ჩვენ აჩვენეს მწვანე შუქი: ახალი პროგრამული უზრუნველყოფის გამოყენებისას გვერდითი მოვლენები არ გამოვლენილა. ანუ განაცხადის თვალსაზრისით, არაფერი შეცვლილა.

აღსანიშნავია, რომ ჩვენ არაფერი შეგვიცვლია კონფიგურაციაში: ფაქტიურად, ჩვენ უბრალოდ შევცვალეთ გამოყენებული სურათი. იგივე ეხება პრომეთეს მეტრიკის მონიტორინგს და ექსპორტს: მათგან ყველაზე გავრცელებული მუშაობს იდეალურად KeyDB-თან და ყოველგვარი ცვლილებების გარეშე. ამრიგად, თამამად შეგვიძლია ვთქვათ, რომ ოპერატიული თვალსაზრისით, ეს უბრალოდ იდეალური ნაბიჯია.

ამ ყველაფრის წყალობით, აპლიკაციის ახალ DBMS-ზე გადართვის შემდეგ, თქვენ ვერაფერს შეცვლით, მაგრამ როგორც „სტაბილიზაციის ღონისძიება“ შეგიძლიათ დატოვოთ იგი ამ ფორმით, რათა გარკვეული დროით იმუშაოთ ბრძოლაში. თუმცა, თუ გსურთ იხილოთ შესრულების ზრდა (ან რაიმე ცვლილება), არ უნდა დაივიწყოთ ეს ნაგულისხმევი KeyDB პარამეტრი, რომელიც პასუხისმგებელია მრავალნაკადზე (server-threads), უდრის ერთს, ანუ DBMS მუშაობს ზუსტად ისევე, როგორც Redis.

ახალ აპლიკაციაზე გადართვის, ტესტირებისა და გარკვეული დროის გატარების შემდეგ (KeyDB-ით), გადავწყვიტეთ განმეორდეს დატვირთვის ტესტირება იმავე პარამეტრებით, რაც გამოიყენებოდა Redis-ისთვის. რა შედეგები მოჰყვა მას?..

პროცესორის მოხმარების გრაფიკის მიხედვით, მაშინვე შესამჩნევი გახდა ერთი ბირთვის „ჭერის“ პრობლემების აღმოფხვრა: პროცესმა დაიწყო ხელმისაწვდომი რესურსების გამოყენება:

მოგვიანებით კი ვცადე აპლიკაციის „წამება“ საკმაოდ ძლიერად და დავინახე სამ ბირთვამდე მოხმარება...

New Relic-ის თანახმად, მთლიანობაში ვებ აპლიკაციამ, რომელსაც იგივე დატვირთვა აქვს, შესამჩნევად უფრო ადეკვატურად დაიწყო ქცევა. შესრულების გარკვეული დეგრადაცია მაინც შეინიშნებოდა, თუმცა, ზემოთ მოცემულ მსგავს გრაფიკთან შედარებით, თქვენ შეგიძლიათ შეაფასოთ მნიშვნელოვანი პროგრესი:

ახალი მონაცემთა ბაზის (KeyDB) შეყოვნება ასევე გაუარესდა, მაგრამ დარჩა მისაღები მნიშვნელობების ფარგლებში:

შემდეგი გრაფიკი ნათლად გვიჩვენებს, რომ თავად KeyDB-ზე მოთხოვნის რაოდენობა მსგავსია:

ამ სინთეზური ტესტების შესაჯამებლად, შეგვიძლია ვთქვათ, რომ Redis და KeyDB აჩვენებს შესრულების მნიშვნელოვან დეგრადაციას ლატენტურობაში (40 ms+) პარალელური კავშირების რაოდენობის მნიშვნელოვანი ზრდით (1000+). ჩვენს შემთხვევაში, ვებ-აპლიკაციამ შეძლო Redis-ის შეყოვნების „გაფლანგვა“ კავშირების უფრო დაბალი რაოდენობის შემთხვევაშიც კი (400+), თუმცა KeyDB-სთვის ასეთი დატვირთვა მისაღები დარჩა.

დასკვნები

ეს მაგალითი ნათლად აჩვენებს ღია კოდის საზოგადოების სიძლიერეს პროექტების შემუშავებაში, რომლითაც ის დაინტერესებულია. ინტერნეტში წავაწყდი შესანიშნავ განცხადებას, რომლის ზოგადი მნიშვნელობა შემდეგნაირად ჩამოყალიბდა: „ზოგიერთი მსხვილი კომპანია ქმნის საინტერესო პროდუქტს, თავის ზოგიერთ ფუნქციას ღიად აქცევს, მაგრამ ყველაზე მნიშვნელოვან ნაწილს ანაზღაურებად ტოვებს. საზოგადოება იყენებს მას და იყენებს მას, შემდეგ კი ვიღაც უარს ამბობს და აკეთებს ჩანგალს, ახორციელებს მასში იგივე ფასიან ფუნქციებს და ხსნის მათ ყველასთვის.” აქ KeyDB არის იგივე შემთხვევა.

თავად მიგრაციაზე საუბრისას, რომელიც საოცრად მარტივი იყო, არ მიგვიღია იმდენი შესრულების მნიშვნელოვანი ზრდა, რაც შეიძლება მოსალოდნელია KeyDB-ის ავტორების გრაფიკების დათვალიერებით... თუმცა, ეს მხოლოდ ჩვენი განსაკუთრებული შემთხვევაა, რომელშიც შეიძლება იყოს ბევრი გადახრები, მათ შორის აპლიკაციის ყბადაღებული არქიტექტურა (მაგ. , ბრძანებების დიდი რაოდენობა get Redis-ში, მთლიანი მოთხოვნების უფრო ეფექტური ვარიანტის ნაცვლად mget...). მიუხედავად ამისა, ჩვენ მოვახერხეთ დადებითი შედეგების მიღწევა და მათთან ერთად ბევრი სასარგებლო ფუნქცია, რომელსაც უახლოეს მომავალში განვახორციელებთ.

ზოგადად, KeyDB პერსპექტიულად გამოიყურება: რადგან ამ DBMS-ით პრაქტიკულ გამოცდილებას მივიღებთ (და ჯერ კიდევ უნდა მოვიპოვოთ!) და თავად განვავითაროთ პროექტი, განვიხილავთ მისი გამოყენების შესაძლებლობას სხვა სიტუაციებში.

თუმცა, ეს სტატია არ უნდა ჩაითვალოს სახელმძღვანელოდ (რომ აღარაფერი ვთქვათ მოწოდებად) მოქმედებისთვის Redis-ის ფართოდ მიტოვების მიზნით KeyDB-ის სასარგებლოდ. მიუხედავად ჩვენი დადებითი გამოცდილებისა, ცხადია, რომ ეს არ არის ვერცხლის ტყვია. საქმე ძალიან სპეციფიკური იყო: კონკრეტულად მომენტალური პრობლემის გადასაჭრელად ისეთ სიტუაციაში, როდესაც საჭირო იყო ამის სწრაფად და მინიმალური დანახარჯებით გაკეთება, ეს გადაწყვეტა გამართლებული იყო. იქნება თუ არა KeyDB სასარგებლო თქვენს შემთხვევაში? ყოველ შემთხვევაში ახლა თქვენ იცით, რომ ეს პოტენციური შესაძლებლობა არსებობს.

PS

ასევე წაიკითხეთ ჩვენს ბლოგზე:

• «მონაცემთა ბაზები და Kubernetes (მიმოხილვა და ვიდეო ანგარიში)";
• «კასანდრას მიგრაცია კუბერნეტებში: მახასიათებლები და გადაწყვეტილებები";
• «MongoDB-ის უწყვეტი მიგრაცია Kubernetes-ში";
• «RabbitMQ-ის უწყვეტი მიგრაცია Kubernetes-ში".

წყარო: www.habr.com