ამ ბლოგპოსტში დეტალურად განვიხილავთ სამ მძლავრ გაფრთხილებას, რომლებიც უნიკალურ როლს ასრულებენ ჩვენი საწარმოო ინფრასტრუქტურის მხარდაჭერაში და შევისწავლით, თუ როგორ გვეხმარებიან ისინი შევინარჩუნოთ მაღალი წარმადობა და უწყვეტი მუშაობა, რაზეც ჩვენი საზოგადოებაა დამოკიდებული. ხშირად, ღრუბლოვანი გამოთვლის არქიტექტურებში, სადაც მონაცემები კერძო და საჯარო ქსელებს შორის მიედინება, NAT (ქსელის მისამართის ტრანსლაცია) კარიბჭის დანერგვა საუკეთესო პრაქტიკად ითვლება. ეს კარიბჭე მოქმედებს როგორც სტრატეგიული კარიბჭის მცველი, აკონტროლებს და აადვილებს საჯარო ინტერნეტისკენ მიმართულ მთელ გამავალ ტრაფიკს. გამავალი ტრაფიკის ცენტრალიზებით, NAT კარიბჭე უზრუნველყოფს სტრატეგიულ უპირატესობას ყოვლისმომცველი ხილვადობისთვის. ჩვენს გუნდს შეუძლია მარტივად მოიძიოს და გაანალიზოს ეს ტრაფიკი, რაც მას ფასდაუდებელ აქტივად აქცევს უსაფრთხოების, ხარჯების ოპტიმიზაციის ან სხვადასხვა საგამოძიებო სცენარების დროს. ხარჯების ოპტიმიზაცია ღრუბლოვანი ინფრასტრუქტურის მართვის კრიტიკული ასპექტია და ფასების დინამიკის გაგება გადამწყვეტია. მონაცემთა ცენტრებში ფასების სტრუქტურები ხშირად განასხვავებენ „აღმოსავლეთ-დასავლეთის“ ტრაფიკს (რომელიც, როგორც წესი, ხდება ერთსა და იმავე სერვერის საკრავში ან შენობაში) და „ჩრდილოეთ-სამხრეთის“ ტრაფიკს (კომუნიკაცია შორეულ კერძო ქსელებს ან ინტერნეტს შორის). ქსელის ტრაფიკის მოცულობის მონიტორინგით, Hugging Face იღებს ღირებულ ინფორმაციას ამ ტრაფიკის შაბლონების შესახებ. ეს ინფორმაცია საშუალებას გვაძლევს მივიღოთ ინფორმირებული გადაწყვეტილებები ინფრასტრუქტურის კონფიგურაციისა და არქიტექტურის შესახებ, რაც უზრუნველყოფს ზედმეტი ხარჯების თავიდან აცილებას. ჩვენი ერთ-ერთი ძირითადი გაფრთხილება შექმნილია იმისთვის, რომ შეგვატყობინოს, როდესაც ჩვენი ქსელის ტრაფიკის მოცულობა წინასწარ განსაზღვრულ ზღვარს გადააჭარბებს. ამ გაფრთხილებას მრავალი დანიშნულება აქვს. პირველ რიგში, ის მოქმედებს როგორც ადრეული გაფრთხილების სისტემა, რომელიც გვაცნობებს ტრაფიკის ნებისმიერი უჩვეულო ნახტომის შესახებ, რამაც შესაძლოა მიუთითოს პოტენციურ პრობლემებზე ან მოულოდნელ ქცევაზე. მეორეც, ის გვიბიძგებს რეგულარულად გადავხედოთ ჩვენი ტრაფიკის ტენდენციებს, რათა უზრუნველვყოთ ინფრასტრუქტურის ზრდისა და განვითარებადი საჭიროებების კონტროლი. ეს გაფრთხილება დაყენებულია სტატიკურ ზღვარზე, რომელიც დროთა განმავლობაში დავხვეწეთ, რაც უზრუნველყოფს მის აქტუალურობასა და ეფექტურობას. გააქტიურებისას, ის ხშირად ემთხვევა ჩვენი ინფრასტრუქტურის რეფაქტორიზაციის პერიოდებს. მაგალითად, მესამე მხარის უსაფრთხოების და ავტომატური სკალირების ხელსაწყოების ინტეგრირებისას, ჩვენ დავაფიქსირეთ ტელემეტრიული მონაცემების გაზრდილი გამავალი ნაკადი ჩვენი კვანძებიდან, რამაც გამოიწვია გაფრთხილება და გვიბიძგა კონფიგურაციების ოპტიმიზაციისკენ. კიდევ ერთი შემთხვევა, როდესაც ჩვენი ინფრასტრუქტურის ცვლილებებმა შეცდომით გამოიწვია კერძო, დაბალფასიანი გზის თავიდან არიდება პროდუქტის სპეციფიკურ ინფრასტრუქტურას შორის (მაგ., ტრაფიკი, რომელიც მიმართულია Hub-ისკენ Space-დან რეპოზიტორიის მონაცემებთან ურთიერთობისთვის). უფრო დეტალურად რომ განვიხილოთ, ყველაზე ეფექტური დატვირთვები ხარჯების დაზოგვის თვალსაზრისით, რომლებიც აღმოვაჩინეთ, არის ისეთები, რომლებიც წვდებიან ობიექტების საცავს. ობიექტების პირდაპირი მოძიება უფრო იაფია, ვიდრე CDN-ზე განთავსებული აქტივების გამოყენება ჩვენი LFS რეპოზიტორიის შესანახად და დამატებით არ საჭიროებს იმავე უსაფრთხოების ზომებს, რომლებსაც ჩვენი WAF უზრუნველყოფს საჯარო მოთხოვნებთან შედარებით. DNS გადაფარვების გამოყენება ტრაფიკის კერძო და საჯარო ქსელის გზებზე გადასართავად ჩვენთვის ღირებული ტექნიკა გახდა, რაც განპირობებულია CDKTF AWS პროვაიდერის მიერ. საბოლოოდ, მიუხედავად იმისა, რომ ჩვენ გვაქვს „კონფიგურაცია, როგორც კოდი“ (configuration-as-code), რაც უზრუნველყოფს სასურველი მდგომარეობის მუდმივ მოქმედებას, გაფრთხილებების დამატებითი ფენა გვეხმარება იმ შემთხვევაში, თუ სასურველი მდგომარეობის კოდით გამოხატვისას შეცდომები დაშვებული იქნება. Hugging Face-ის ლოგირების ინფრასტრუქტურა არის დახვეწილი სისტემა, რომელიც შექმნილია ჩვენი აპლიკაციებისა და სერვისების მიერ გენერირებული ლოგების დიდი მოცულობის მონაცემების შესაგროვებლად, დასამუშავებლად და შესანახად. ამ სისტემის გულში დგას Hub აპლიკაციის ლოგირების კონვეიერი (pipeline), კარგად შემუშავებული გადაწყვეტილება, რომელიც უზრუნველყოფს Hub მოდელის გამოყენების მონაცემების ეფექტურ აღებას, გამდიდრებას და შენახვას ანგარიშგებისა და არქივირების მიზნებისთვის. კონვეიერი იწყება Filebeat-ით, მსუბუქი ლოგების გამგზავნით, რომელიც მუშაობს როგორც daemonset ჩვენს აპლიკაციის პოდებთან ერთად თითოეულ Kubernetes კლასტერში. Filebeat-ის როლია ლოგების შეგროვება სხვადასხვა წყაროდან, მათ შორის აპლიკაციის კონტეინერებიდან, და მათი გადაგზავნა კონვეიერის შემდეგ ეტაპზე. მას შემდეგ, რაც ლოგები შეგროვდება Filebeat-ის მიერ, ისინი იგზავნება Logstash-ში, მძლავრ ლოგების დამმუშავებელ ხელსაწყოში. Logstash მოქმედებს როგორც მონაცემთა დამუშავების ძირითადი მექანიზმი, რომელიც შემომავალ ლოგებზე ახორციელებს მუტაციებისა და ტრანსფორმაციების სერიას. ეს მოიცავს ლოგების გამდიდრებას GeoIP მონაცემებით გეოლოკაციის შესახებ ინფორმაციისთვის, ლოგების კონკრეტულ Elasticsearch ინდექსებში მარშრუტიზაციას წინასწარ განსაზღვრული კრიტერიუმების საფუძველზე და ლოგების ველების მანიპულირებას მათი დამატებით, წაშლით ან გადაფორმატირებით თანმიმდევრულობისა და ანალიზის სიმარტივის უზრუნველსაყოფად. მას შემდეგ, რაც Logstash დაამუშავებს ლოგებს, ისინი გადაეგზავნება Elasticsearch კლასტერს. Elasticsearch, განაწილებული ძიების და ანალიზის ძრავა, ქმნის ჩვენი ლოგების შენახვისა და ანალიზის პლატფორმის საფუძველს. ის იღებს ლოგებს Logstash-დან და იყენებს საკუთარ დამუშავების წესებს Elasticsearch კონვეიერების მეშვეობით. ეს კონვეიერები ასრულებენ მინიმალურ დამუშავების ამოცანებს, როგორიცაა დროის ნიშნულის ველების დამატება დამუშავების დროის აღსანიშნავად, რაც გადამწყვეტია ლოგების ანალიზისა და კორელაციისთვის. Elasticsearch უზრუნველყოფს მასშტაბურობას