როგორ მოვაგვარეთ CIAN-ში ტერაბაიტები მორები

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

საიდან დავიწყეთ?

ბოლო რამდენიმე წლის განმავლობაში, cian.ru-ზე დატვირთვა ძალიან სწრაფად გაიზარდა და 2018 წლის მესამე კვარტალში რესურსების ტრაფიკმა მიაღწია 11.2 მილიონ უნიკალურ მომხმარებელს თვეში. იმ დროს, კრიტიკულ მომენტებში ჩვენ დავკარგეთ ჟურნალების 40%-მდე, რის გამოც სწრაფად ვერ გავუმკლავდით ინციდენტებს და დიდი დრო და ძალისხმევა დავხარჯეთ მათ მოგვარებაზე. ასევე ხშირად ვერ ვპოულობდით პრობლემის მიზეზს და გარკვეული დროის შემდეგ ის მეორდებოდა. ეს იყო ჯოჯოხეთი და რაღაც უნდა გაეკეთებინა.

იმ დროს ჩვენ ვიყენებდით 10 მონაცემთა კვანძის კლასტერს ElasticSearch ვერსიით 5.5.2 სტანდარტული ინდექსის პარამეტრებით ჟურნალების შესანახად. იგი დაინერგა ერთ წელზე მეტი ხნის წინ, როგორც პოპულარული და ხელმისაწვდომი გადაწყვეტა: მაშინ მორების ნაკადი არც თუ ისე დიდი იყო, აზრი არ ჰქონდა არასტანდარტული კონფიგურაციების შექმნას. 

შემომავალი ჟურნალების დამუშავება მოწოდებული იყო Logstash-ის მიერ სხვადასხვა პორტზე ElasticSearch-ის ხუთ კოორდინატორზე. ერთი ინდექსი, განურჩევლად ზომისა, შედგებოდა ხუთი ნატეხისაგან. მოეწყო საათობრივი და ყოველდღიური როტაცია, რის შედეგადაც ყოველ საათში 100-მდე ახალი ნატეხი ჩნდებოდა კლასტერში. მიუხედავად იმისა, რომ არ იყო ძალიან ბევრი ჟურნალი, კლასტერი კარგად უმკლავდებოდა და არავინ აქცევდა ყურადღებას მის პარამეტრებს. 

სწრაფი ზრდის გამოწვევები

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

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

ამან გამოიწვია პრობლემები ოპერატიული მეხსიერების გამოყოფასთან დაკავშირებით და როდესაც კვანძი დაიშალა, ყველა ფრაგმენტმა ერთდროულად დაიწყო მოძრაობა, გაამრავლა ტრაფიკი და იტვირთა სხვა კვანძები, რამაც თითქმის შეუძლებელი გახადა მონაცემების კლასტერში ჩაწერა. ამ პერიოდში კი მორების გარეშე დავრჩით. და თუ სერვერთან პრობლემა იყო, ჩვენ ძირითადად დავკარგეთ კლასტერის 1/10. მცირე ინდექსების დიდმა რაოდენობამ დაამატა სირთულე.

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

ჩვენ დასახული გვაქვს მიზანი მთლიანად აღმოვფხვრათ ჟურნალების დაკარგვა და შევამციროთ მათი მიწოდების დრო ELK კლასტერში მაქსიმუმ 15 წუთამდე ფორსმაჟორის დროს (ჩვენ მოგვიანებით ვეყრდნობოდით ამ მაჩვენებელს, როგორც შიდა KPI).

ბრუნვის ახალი მექანიზმი და ცხელ-თბილი კვანძები

ჩვენ დავიწყეთ კლასტერული კონვერტაცია ElasticSearch ვერსიის განახლებით 5.5.2-დან 6.4.3-მდე. კიდევ ერთხელ მოკვდა ჩვენი ვერსიის 5 კლასტერი და ჩვენ გადავწყვიტეთ მისი გამორთვა და მთლიანად განახლება - ჯერ კიდევ არ არის ჟურნალები. ასე რომ, ჩვენ ეს გადასვლა სულ რაღაც რამდენიმე საათში გავაკეთეთ.

ყველაზე მასშტაბური ტრანსფორმაცია ამ ეტაპზე იყო Apache Kafka-ს განხორციელება სამ კვანძზე კოორდინატორით, როგორც შუალედური ბუფერი. შეტყობინებების ბროკერმა გადაგვარჩინა ჟურნალების დაკარგვისგან ElasticSearch-თან დაკავშირებული პრობლემების დროს. ამავდროულად, კლასტერს დავამატეთ 2 კვანძი და გადავედით ცხელ-თბილ არქიტექტურაზე სამი „ცხელი“ კვანძით, რომლებიც განთავსებულია მონაცემთა ცენტრში სხვადასხვა თაროებში. ჩვენ გადავიყვანეთ ჟურნალები მათზე ნიღბის გამოყენებით, რომელიც არ უნდა დაიკარგოს არავითარ შემთხვევაში - nginx, ასევე აპლიკაციის შეცდომების ჟურნალები. მცირე ჟურნალები გაეგზავნა დარჩენილ კვანძებს - გამართვა, გაფრთხილება და ა.შ., ხოლო 24 საათის შემდეგ, "ცხელი" კვანძებიდან "მნიშვნელოვანი" ჟურნალები გადაეცა.

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

კლასტერის ოპტიმიზაცია

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

მაგალითად, როტაციის კონფიგურაციისთვის:

сurator-elk-rollover.yaml

---
actions:
  1:
    action: rollover
    options:
      name: "nginx_write"
      conditions:
        max_docs: 100000000
  2:
    action: rollover
    options:
      name: "python_error_write"
      conditions:
        max_docs: 10000000

თუ არ იყო rollover მეტსახელი, მოხდა შეცდომა:

ERROR     alias "nginx_write" not found.
ERROR     Failed to complete action: rollover.  <type 'exceptions.ValueError'>: Unable to perform index rollover with alias "nginx_write".

ამ პრობლემის გადაწყვეტა შემდეგი გამეორებისთვის დავტოვეთ და სხვა საკითხს შევუდექით: გადავედით Logstash-ის pull ლოგიკაზე, რომელიც ამუშავებს შემომავალ ჟურნალებს (აცილებს არასაჭირო ინფორმაციას და გამდიდრებს). ჩვენ განვათავსეთ ის დოკერში, რომელსაც გავუშვით docker-compose-ის საშუალებით და ასევე მოვათავსეთ logstash-ექსპორტიორი, რომელიც აგზავნის მეტრიკას პრომეთეს ლოგის ნაკადის ოპერატიული მონიტორინგისთვის. ამ გზით ჩვენ მივეცით საკუთარ თავს შესაძლებლობა შეუფერხებლად შეგვეცვალა logstash ინსტანციების რაოდენობა, რომლებიც პასუხისმგებელნი არიან თითოეული ტიპის ჟურნალის დამუშავებაზე.

სანამ კლასტერს ვაუმჯობესებდით, cian.ru-ს ტრაფიკი თვეში 12,8 მილიონ უნიკალურ მომხმარებელამდე გაიზარდა. შედეგად, აღმოჩნდა, რომ ჩვენი გარდაქმნები ოდნავ ჩამორჩებოდა წარმოების ცვლილებებს და ჩვენ დავდექით იმ ფაქტის წინაშე, რომ "თბილი" კვანძები ვერ უმკლავდებოდნენ დატვირთვას და შეანელეს მორების მთელი მიწოდება. ჩვენ მივიღეთ "ცხელი" მონაცემები წარუმატებლობით, მაგრამ ჩვენ უნდა ჩავერევით დანარჩენების მიწოდებაში და გაგვეკეთებინა ხელით გადახვევა, რათა თანაბრად გადანაწილებულიყო ინდექსები. 

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

ჟურნალის გადანაწილება

მიმდინარე წლის სექტემბერში ჩვენ ჯერ კიდევ ვჭრით მონოლითს, კლასტერზე დატვირთვა იზრდებოდა და ლოგის ნაკადი წამში 30 ათას შეტყობინებას უახლოვდებოდა. 

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

• „ცხელი“ კვანძებისთვის: E3-1270 v6 / 960 გბ SSD / 32 გბ x 3 x 2 (3 Hot1-სთვის და 3 Hot2-ისთვის).
• "თბილი" კვანძებისთვის: E3-1230 v6 / 4Tb SSD / 32 Gb x 4.

ამ განმეორებით, ჩვენ გადავიტანეთ ინდექსი მიკროსერვისების წვდომის ჟურნალებით, რომელიც იკავებს იმავე ადგილს, როგორც წინა ხაზის nginx ჟურნალები, სამი "ცხელი" კვანძის მეორე ჯგუფში. ჩვენ ახლა ვინახავთ მონაცემებს „ცხელ“ კვანძებზე 20 საათის განმავლობაში და შემდეგ გადავცემთ მათ „თბილ“ კვანძებში დანარჩენ ჟურნალებში. 

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

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

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

სამომავლო გეგმები

განხორციელებული კონფიგურაცია მშვენივრად მასშტაბებს და ახლა ჩვენ ვინახავთ 13,3 ტბ მონაცემს - ყველა ჟურნალს 4 დღის განმავლობაში, რაც აუცილებელია სიგნალების გადაუდებელი ანალიზისთვის. ჩვენ ვცვლით ზოგიერთ ჟურნალს მეტრიკად, რომელსაც ვამატებთ Graphite-ს. ინჟინრების მუშაობის გასაადვილებლად, ჩვენ გვაქვს მეტრიკა ინფრასტრუქტურის კლასტერისთვის და სკრიპტები საერთო პრობლემების ნახევრად ავტომატური შეკეთებისთვის. მონაცემთა კვანძების რაოდენობის გაზრდის შემდეგ, რაც მომავალ წელს იგეგმება, გადავალთ მონაცემთა შენახვაზე 4-დან 7 დღემდე. ეს საკმარისი იქნება ოპერატიული მუშაობისთვის, რადგან ჩვენ ყოველთვის ვცდილობთ, რაც შეიძლება მალე გამოვიკვლიოთ ინციდენტები, ხოლო გრძელვადიანი გამოკვლევებისთვის არის ტელემეტრიული მონაცემები. 

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

ახლა ჩვენ ვემზადებით ElasticSearch-ის მე-7 ვერსიაზე განახლებისთვის. თუმცა, ამისათვის მოგვიწევს მრავალი ინდექსის განახლება ElasticSearch-ში, რადგან ისინი გადავიდნენ 5.5 ვერსიიდან და გამოცხადდა მოძველებულად მე-6 ვერსიაში (ისინი უბრალოდ არ არსებობენ ვერსიაში 7). ეს ნიშნავს, რომ განახლების პროცესში აუცილებლად იქნება რაიმე სახის ფორსმაჟორი, რომელიც დაგვტოვებს ლოგების გარეშე, სანამ საკითხი მოგვარდება. მე-7 ვერსიიდან, ჩვენ ყველაზე მეტად ველით Kibana-ს გაუმჯობესებული ინტერფეისით და ახალი ფილტრებით. 

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

წყარო: www.habr.com