არქიტექტურა Badoo-ში ფოტოების შენახვისა და გაზიარებისთვის

არტემ დენისოვი ( bo0rsh201, Badoo)

Badoo არის მსოფლიოში ყველაზე დიდი გაცნობის საიტი. ამჟამად ჩვენ გვყავს დაახლოებით 330 მილიონი რეგისტრირებული მომხმარებელი მთელ მსოფლიოში. მაგრამ რაც ბევრად უფრო მნიშვნელოვანია ჩვენი დღევანდელი საუბრის კონტექსტში არის ის, რომ ჩვენ ვინახავთ მომხმარებლის ფოტოს დაახლოებით 3 პეტაბაიტს. ყოველდღიურად ჩვენი მომხმარებლები ატვირთავენ დაახლოებით 3,5 მილიონ ახალ ფოტოს და კითხვის დატვირთვა დაახლოებით 80 ათასი მოთხოვნა წამში. ეს საკმაოდ ბევრია ჩვენი ბექენდისთვის და ზოგჯერ ამაში სირთულეებია.

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

ახლა დავიწყოთ.

როგორც ვთქვი, ეს იქნება რეტროსპექტივა და საიდანღაც რომ დავიწყოთ, ავიღოთ ყველაზე გავრცელებული მაგალითი.

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

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

Badoo ისტორიულად - ახლაც და მაშინაც (იმ დროს, როდესაც ის ჯერ კიდევ ადრეულ ასაკში იყო) - ცხოვრობს საკუთარ სერვერებზე, ჩვენს DC-ებში. ამიტომ ეს ვარიანტი ჩვენთვის ოპტიმალური იყო.

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

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

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

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

ასე იყო ჩვენთვის გარკვეული პერიოდი.

ეს იყო დაახლოებით 2009 წელს. მიიტანეს მანქანები, მიიტანეს...

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

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

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

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

და ბოლო წერტილი არის ფასი.

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

და ბოლოს, ჩვენ გადავწყვიტეთ ე.წ. Storage Area Network-ის გამოყენება.

ეს არის დიდი SHD, რომლებიც სპეციალურად შექმნილია დიდი რაოდენობით მონაცემების შესანახად. ეს არის თაროები დისკებით, რომლებიც დამონტაჟებულია საბოლოო ოპტიკურ გამომავალ მანქანებზე. რომ. ჩვენ გვაქვს მანქანების ერთგვარი აუზი, საკმაოდ მცირე, და ეს SHD-ები, რომლებიც გამჭვირვალეა ჩვენი გაგზავნის ლოგიკით, ე.ი. ჩვენი nginx-ისთვის ან სხვა ვინმესთვის ამ ფოტოების მოთხოვნით.

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

მეორე პლუსი.

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

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

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

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

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

და აქ ყველაფერი ჩვენს ხელშია.

მე უკვე ვთქვი პირველ სლაიდში: ჩვენ გვაქვს 80 ათასი კითხვის მოთხოვნა წამში მხოლოდ 3,5 მილიონი ატვირთვით დღეში. ანუ, ეს არის სიდიდის სამი რიგის სხვაობა. აშკარაა, რომ კითხვას ოპტიმიზაცია სჭირდება და პრაქტიკულად გასაგებია, როგორ.

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

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

ქეში LRU-ით გადაჭრის ჩვენს ყველა პრობლემას. Რას ვაკეთებთ?

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

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

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

Რას გავს? მომხმარებელი აგზავნის მოთხოვნას ფოტოზე. NGINX ეძებს მას ჯერ ადგილობრივ ქეშში. თუ არა, მაშინ უბრალოდ proxy_pass ჩვენს საცავში, ჩამოტვირთეთ ფოტო იქიდან და მიეცით მომხმარებელს.

მაგრამ ეს ძალიან ბანალურია და გაუგებარია რა ხდება შიგნით. მუშაობს რაღაც ამდაგვარი.

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

1. ეს არის ბუფერი, სადაც მიდის პროქსიდან ჩამოტვირთული ფოტოები.
2. ეს არის ცხელი ქეში, რომელიც ინახავს ამჟამად აქტიურად მოთხოვნილ ფოტოებს.
3. და ცივი ქეში, სადაც ფოტოები თანდათანობით იშლება ცხელი ქეშიდან, როდესაც მათზე ნაკლები მოთხოვნა მოდის.

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

Nginx უბრალოდ წერს RAMDisk access.log-ში თითოეული მოთხოვნისთვის, რომელშიც მიუთითებს იმ ფოტოსკენ მიმავალ გზაზე, რომელსაც ამჟამად ემსახურებოდა (რა თქმა უნდა, შედარებითი გზა) და რომელ განყოფილებას ემსახურებოდა. იმათ. შეიძლება თქვას „ფოტო 1“ და შემდეგ ან ბუფერი, ან ცხელი ქეში, ან ცივი ქეში, ან პროქსი.

აქედან გამომდინარე, ჩვენ როგორმე უნდა გადავწყვიტოთ რა ვუყოთ ფოტოს.

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

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

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

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

იმისათვის, რომ ფოტო დაუყოვნებლივ შეინახოს ბუფერში მისი პროქსის დროს, ვიყენებთ proxy_store დირექტივას და ბუფერიც არის RAMDisk, ე.ი. მომხმარებლისთვის ის ძალიან სწრაფად მუშაობს. ეს ეხება თავად ქეშირების სერვერის შიდა ნაწილებს.

დარჩენილი კითხვა არის როგორ გავანაწილოთ მოთხოვნები ამ სერვერებზე.

ვთქვათ, არის ოცი შესანახი მანქანის კლასტერი და სამი ქეშირების სერვერი (ასე მოხდა).

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

ყველაზე გავრცელებული ვარიანტია Round Robin. ან შემთხვევით გააკეთე?

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

ჩვენ უნდა როგორმე ცალსახად განვსაზღვროთ რომელ სერვერზე რომელ მოთხოვნას მივაწოდოთ.

არსებობს ბანალური გზა. ჩვენ ვიღებთ ჰეშს URL-დან ან ჰეშს ჩვენი გაზიარების გასაღებიდან, რომელიც არის URL-ში და ვყოფთ მას სერვერების რაოდენობაზე. Იმუშავებს? უილ.

იმათ. ჩვენ გვაქვს 2% მოთხოვნა, მაგალითად, ზოგიერთი "example_url"-ისთვის ის ყოველთვის მოხვდება სერვერზე ინდექსით "XNUMX" და ქეში მუდმივად განადგურდება რაც შეიძლება უკეთესად.

მაგრამ ასეთ სქემაში არის გადართვის პრობლემა. გადატვირთვა - ვგულისხმობ სერვერების რაოდენობის შეცვლას.

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

დავამატოთ.

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

ეს ვარიანტი არც ჩვენ ჯდება.

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

Რას გავს?

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

თითოეული სერვერი განისაზღვრება ერთი წერტილით და სექტორი, რომელიც საათის ისრის მიმართულებით მიდის მასზე, შესაბამისად, ემსახურება ამ ჰოსტს. როდესაც მოთხოვნა მოდის ჩვენთან, ჩვენ მაშინვე ვხედავთ, რომ, მაგალითად, მოთხოვნა A - მას აქვს ჰეში - და მას ემსახურება სერვერი 2. მოთხოვნა B - სერვერის მიერ 3. და ასე შემდეგ.

რა ხდება ამ სიტუაციაში გადართვის დროს?

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

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

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

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

ეს ეხება ქეშირების სისტემას. მოდით შევხედოთ შედეგებს.

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

ჩვენ განვათავსეთ ეს სერვერები ჩვენს სამ DC-ში და მივიღეთ ყოფნის სამი წერტილი - პრაღა, მაიამი და ჰონგ კონგი.

რომ. ისინი მეტ-ნაკლებად ადგილობრივად არიან განლაგებული ჩვენს თითოეულ სამიზნე ბაზარზე.

და როგორც კარგი ბონუსი, მივიღეთ ეს ქეშირების პროქსი, რომელზედაც CPU რეალურად უმოქმედოა, რადგან ის არც ისე საჭიროა კონტენტის მოსამსახურებლად. და იქ, NGINX+ Lua-ს გამოყენებით, ჩვენ განვახორციელეთ ბევრი უტილიტარული ლოგიკა.

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

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

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

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

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

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

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

პირველი არის ფოტოები.

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

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

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

და წერტილი, რომელიც გამომდინარეობს წინადან არის

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

რა დასკვნას გვთავაზობს ეს? ჩვენს შემთხვევაში, CDN არ არის ძალიან კარგი ალტერნატივა.

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

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

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

ეს ეხება ფოტოების გაცემას.

მოდით ახლა ცოტა წინ წავიდეთ ჩვენს რეტროსპექტივაში და ვისაუბროთ შენახვაზე.

2013 წელი გადიოდა.

დაემატა ქეშირების სერვერები, მუშაობის პრობლემები გაქრა. Ყველაფერი კარგადაა. მონაცემთა ნაკრები იზრდება. 2013 წლის მდგომარეობით, ჩვენ გვქონდა დაახლოებით 80 სერვერი დაკავშირებული საცავთან და დაახლოებით 40 ქეშირებადი თითოეულ DC-ში. ეს არის 560 ტერაბაიტი მონაცემები თითოეულ DC-ზე, ე.ი. სულ დაახლოებით პეტაბაიტი.

და მონაცემთა ნაკრების ზრდასთან ერთად, საოპერაციო ხარჯები მნიშვნელოვნად გაიზარდა. რას ნიშნავდა ეს?

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

პირველ რიგში, თავად Storage Area Network (SAN), რომელიც შეიძლება ჩავარდეს.

მეორეც, ის ოპტიკის საშუალებით უკავშირდება ბოლო მანქანებს. შეიძლება იყოს პრობლემები ოპტიკურ ბარათებთან და სანთლებთან დაკავშირებით.

რა თქმა უნდა, არ არის ისეთი ბევრი მათგანი, როგორც თავად SAN-ში, მაგრამ, მიუხედავად ამისა, ეს ასევე წარუმატებლობის წერტილებია.

შემდეგი არის თავად მანქანა, რომელიც დაკავშირებულია საცავთან. ასევე შეიძლება ჩავარდეს.

ჯამში სამი მარცხი გვაქვს.

გარდა ამისა, უკმარისობის წერტილების გარდა, არის თავად საწყობის მძიმე მოვლა.

ეს რთული მრავალკომპონენტიანი სისტემაა და სისტემურ ინჟინრებს შეიძლება გაუჭირდეთ მასთან მუშაობა.

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

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

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

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

ჩვენ უბრალოდ დავამატეთ მეორე ნაწილი.

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

აქ ჩვენ უბრალოდ ვქმნით ასინქრონულ რიგში სიახლოვეს.

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

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

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

ჩვენ დავამატეთ მესამე დისკი, რომელიც არის პატარა SSD, და ვუწოდეთ მას ბუფერი.

როგორ მუშაობს ახლა.

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

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

და რაც მთავარია: ჩვენ შევწყვიტეთ მონაცემების დაკარგვა.

ვთქვათ, გავჩერდით პოტენციურად დავკარგეთ მონაცემები, რადგან ჩვენ ის ნამდვილად არ დავკარგეთ. მაგრამ იყო საფრთხე. ჩვენ ვხედავთ, რომ ეს გამოსავალი, რა თქმა უნდა, კარგია, მაგრამ ის ცოტათი ჰგავს პრობლემის სიმპტომების აღმოფხვრას, ნაცვლად იმისა, რომ მთლიანად მოგვარდეს. და გარკვეული პრობლემები აქ რჩება.

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

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

და ჩვენ გავაკეთეთ მესამე ვერსია (ფაქტობრივად, მეორე ფაქტიურად) - დაჯავშნის ვერსია. როგორ გამოიყურებოდა?

აი ეს იყო -

ჩვენი მთავარი პრობლემა არის ის, რომ ეს არის ფიზიკური მასპინძელი.

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

ეს უკვე 2014-2015 წლებია და იმ დროს სიტუაცია დისკებთან და მათ ტევადობასთან ერთ ჰოსტში ბევრად უკეთესი გახდა. ჩვენ გადავწყვიტეთ, რატომ არ ვცადოთ.

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

ამრიგად, ჩვენ ვიღებთ ამ დიაგრამას. ჩვენ გვყავს ორი მანქანა, რომლებიც ინახავს იმავე მონაცემთა ნაკრებებს. ისინი სრულად ქმნიან ერთმანეთის სარეზერვო ასლს და სინქრონიზებენ მონაცემებს ქსელში ასინქრონული რიგის მეშვეობით იმავე MySQL-ში.

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

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

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

ამოცანა ცოტა უფრო რთულია.

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

თუ ის იქ არ არის, ჩვენ უბრალოდ ვთხოვთ მეზობელს და გარანტირებულად მივიღებთ იქიდან.

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

ჩვენს სიტუაციაში ეს ნელა არ მუშაობს.

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

მაშ, კიდევ რა გვაქვს, რომ მართლაც მაგარია?

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

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

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

ერთი მანქანა ფუჭდება.

Არაა პრობლემა! სისტემურმა ინჟინერმა შეიძლება ღამითაც არ გაიღვიძოს, დილამდე დაელოდება, ცუდი არაფერი მოხდება.

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

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

რა დასკვნების გამოტანა შეიძლება ამ ჭარბი სქემიდან?

ჩვენ მივიღეთ შეცდომის შემწყნარებლობა.

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

კითხვის ორმაგი შემწეობა მივიღეთ.

ეს არის ძალიან კარგი ბონუსი შეცდომის ტოლერანტობის გარდა.

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

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

და აქ კვლავ წარმოიქმნება გარკვეული კონფლიქტი.

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

დიახ, მართლაც, დროთა განმავლობაში სიტუაცია ძალიან შეიცვალა და ახლა ამ მიდგომას ბევრი უპირატესობა აქვს. პირველ რიგში, ჩვენ ვიღებთ ბევრად უფრო მარტივ ოპერაციას.

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

იქ არის უზარმაზარი მანქანები და ეს არის მხოლოდ რამდენიმე დისკი, რომლებიც აწყობილია აქ მანქანაზე რეიდის სახით.

მაგრამ არსებობს უარყოფითი მხარეებიც.

ეს დაახლოებით 1,5-ჯერ უფრო ძვირია, ვიდრე SAN-ების გამოყენება დღევანდელ ფასებშიც კი. ამიტომ, ჩვენ გადავწყვიტეთ თამამად არ გადაგვექცია ჩვენი მთელი დიდი კლასტერი ადგილობრივ მყარი დისკებით მანქანებად და გადავწყვიტეთ დაგვეტოვებინა ჰიბრიდული გადაწყვეტა.

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

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

მოდით მოკლედ შევაჯამოთ რას მივაღწიეთ, რისთვის ვიბრძოდით და მივაღწიეთ თუ არა წარმატებას.

შედეგები

ჩვენ გვყავს მომხმარებელი - 33 მილიონი.

ჩვენ გვაქვს სამი ადგილი - პრაღა, მაიამი, ჰონგ კონგი.

ისინი შეიცავს ქეშირების ფენას, რომელიც შედგება მანქანებისგან სწრაფი ლოკალური დისკებით (SSD), რომელზედაც მუშაობს NGINX-ის მარტივი აპარატურა, მისი access.log და Python დემონები, რომლებიც ამუშავებენ ამ ყველაფერს და მართავენ ქეშს.

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

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

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

ამ მანქანებიდან ზოგიერთი დაკავშირებულია SAN-თან.

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

ეს არის მოკლე მიმოხილვა არქიტექტურაზე, თუ რა მივიღეთ და როგორ განვითარდა ეს ყველაფერი.

კიდევ რამდენიმე რჩევა კაპიტნისგან, ძალიან მარტივი.

პირველ რიგში, თუ მოულოდნელად გადაწყვეტთ, რომ სასწრაფოდ გჭირდებათ ყველაფერი გააუმჯობესოთ თქვენს ფოტო ინფრასტრუქტურაში, ჯერ გაზომეთ, რადგან შესაძლოა არაფრის გაუმჯობესება არ არის საჭირო.

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

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

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

ჯერ გავზომეთ, მერე გავაუმჯობესეთ.

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

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

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

შემდეგი წერტილი. ზომის შეცვლის შესახებ.

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

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

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

და დამატებითი ასინქრონული სარეზერვო საშუალება კარგია.

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

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

კონტაქტი

» bo0rsh201
» Badoo ბლოგი

ეს მოხსენება არის ერთ-ერთი საუკეთესო გამოსვლის ჩანაწერი მაღალი დატვირთვის სისტემების შემქმნელთა კონფერენციაზე მაღალი დატვირთვა ++. 2017 წლის HighLoad++ კონფერენციამდე თვეზე ნაკლები რჩება.

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

წელს ჩვენ ვაგრძელებთ არქიტექტურისა და სკალირების თემის შესწავლას:

• როგორ მოემსახუროს მილიარდ მომხმარებელს და უზრუნველყოს ტერაბიტიანი ტრაფიკი / იგორ ვასილიევი
• როგორ გადავწეროთ VKontakte პერსონალური შეტყობინებების მონაცემთა ბაზა ნულიდან და გადავიდეთ მასში შეფერხების გარეშე / დიმიტრი ეგოროვი
• სიკვდილი გაყიდვით: როგორ ცდილობდა Yandex.Money დაეჩქარებინა შავი პარასკევი და გადარჩენილიყო / ანატოლი პლასკოვსკი
• ბანკის ფრონტ-ენდის სისტემის შეცდომის ტოლერანტული არქიტექტურა / რომან შეხოვცოვი, ალექსეი გრომაჩიკოვი
• გადახდის სისტემის არქიტექტურა: თითქმის საწარმო / ფილიპ დელგადო

ჩვენ ასევე ვიყენებთ ზოგიერთ ამ მასალას ჩვენს ონლაინ ტრენინგ კურსში მაღალი დატვირთვის სისტემების შემუშავებაზე HighLoad.Guide არის სპეციალურად შერჩეული ასოების, სტატიების, მასალების, ვიდეოების ჯაჭვი. ჩვენი სახელმძღვანელო უკვე შეიცავს 30-ზე მეტ უნიკალურ მასალას. დაკავშირება!

წყარო: www.habr.com