თუ ამ გვერდზე შეხვედით და ფიქრობთ, რომ გამდიდრდებით სწრაფი გამდიდრების სქემით, ვწუხვარ, რომ იმედი გაგიცრუებთ. ამ სტატიაში ვისაუბრებთ იმაზე, თუ როგორ შეამციროთ თქვენი ღრუბლოვანი ხარჯების გადასახადები 1 მილიონი დოლარით. ამით თქვენ არსებითად გამოიმუშავებთ დამატებით მილიონ დოლარს - რომელიც შეგიძლიათ დახარჯოთ ჩემი ონლაინ კურსის შესაძენად, თუ როგორ უნდა გამდიდრდეთ AWS-ით ( ). კურსის ბმული აქ Cloud ღირებულება ხშირად შეუმჩნეველი და გაუთვალისწინებელია კომპანიების პროექტების დასაწყისში. 2021 HashiCorp-ის გამოკითხვამ დაადგინა, რომ კომპანიების თითქმის 40%-მა ზედმეტად დახარჯა ღრუბლოვანი ხარჯები 2021 წელს [ ]. 2023 წელს თითქმის ყველა კომპანიამ (94%) აღიარა, რომ ფლანგავდა ფულს ღრუბელზე [ ] და ღრუბლის ხარჯების მინიმუმ 30% იხარჯებოდა [ ]. Cloud-ის დახარჯვა 2022 წელს თითქმის 500 მილიარდი დოლარი იყო - შესაბამისად, ჩვენ ვსაუბრობთ წელიწადში 150 მილიარდ დოლარზე გაფლანგვაზე!! 1 1 2 ეს არ არის მხოლოდ გამოტოვებული შემოსავლების შეშფოთება, არამედ მდგრადობის ცუდი პრაქტიკაც. 150 მილიარდი დოლარის გადაყრილი ენერგია! ეს დასკვნები მოიცავს როგორც მსხვილ, ისე მცირე საწარმოებს, მაღალი ღრუბლის სიმწიფიდან დაწყებული ღრუბლის სიმწიფემდე. ეს ეხება AWS-ს, მაგრამ იგივე პრინციპები შეიძლება გამოყენებულ იქნას ნებისმიერი სხვა ღრუბლოვანი პროვაიდერისთვის. ასე რომ, თუ თქვენი სამუშაოს რომელიმე ნაწილი ღრუბელშია, მაშინ ეს სტატია თქვენთვისაა. მე ვსაუბრობ მონაცემთა ინჟინრის პერსპექტივიდან, მაგრამ იგივე ცოდნა შეიძლება გამოყენებულ იქნას სხვა პროგრამული ინჟინერიის პრაქტიკაში. მოდი ჩავყვინთოთ. რა არის საჭირო წელიწადში 1 მილიონი დოლარის დახარჯვა ღრუბელში? ამ სახის ღრუბლოვანი გადასახადი, როგორც წესი, შემოიფარგლება ძალიან მსხვილი საწარმოებით, რომლებიც მუშაობენ გლობალურად მილიონობით კლიენტით. წარმოდგენა რომ მოგაწოდოთ, 1 მილიონი აშშ დოლარის ღრუბლოვანი გადასახადი შეიძლება მოჰყვეს Spark ETL სამუშაოს დამუშავებას ~ 1,5 ტბ საათში 24x7 წელიწადში 365 დღის განმავლობაში. კიდევ ერთი მაგალითი შეიძლება იყოს აპლიკაცია, რომელიც დღეში მილიარდობით მოთხოვნას იღებს მსოფლიოს მრავალი ადგილიდან. მსხვილ საწარმოში, ამ ზომის ასობით აპლიკაციაა - რის შედეგადაც ხდება მილიარდი დოლარის კონტრაქტები ღრუბელ-პროვაიდერებთან. მაგალითად, Airbnb-ს ჰქონდა ვალდებულება 2019 წლის ბოლოს ხუთი წლის განმავლობაში 1,2 მილიარდი დოლარი დახარჯოს ღრუბლოვანი რესურსებისთვის [ ]. 3 Expedia-ში ჩვენ შევამცირეთ მონაცემთა დამუშავების ETL-ის ხარჯები, რომელიც წელიწადში 1,1 მილიონი დოლარი ჯდება, სულ რაღაც 100,000 დოლარამდე წელიწადში ოპტიმიზაციის პრაქტიკის დანერგვით. ეს არის ხარჯების 91%-იანი შემცირება!! ყველა კომპანიას არ აქვს ასეთი უზარმაზარი ზომის აპლიკაციები, მაგრამ წარმოიდგინეთ, რომ თქვენი ღრუბლის ღირებულება 90%-ით შემცირდება მხოლოდ ერთი აპლიკაციისთვის ან მთელი კომპანიისთვის. როგორ დავიწყოთ დაზოგვა? ნაბიჯი 1: გამოწვევა თქვენი დიზაინის ვარაუდები წადით და მიიღეთ თქვენი ყველაზე ძვირადღირებული აპლიკაციების სია და . გააპროტესტეთ თქვენი დიზაინის ვარაუდები თქვენ აშენებთ აპლიკაციას, რომელსაც აქვს 99,999% ხელმისაწვდომობა და ქვემილიწამიანი შეყოვნება, მაგრამ რეალურად მომხმარებლები საკმარისად კარგი იქნებიან 99% ხელმისაწვდომობით და ასობით მილიწამის შეყოვნებით? ქმნით მონაცემთა ნაკრებებს მილიარდობით მწკრივით, მაგრამ მომხმარებლები გამოიყენებენ მხოლოდ ზოგიერთი ღონისძიების აგრეგაციას? აგზავნით მონაცემებს რეალურ დროში, მაგრამ მონაცემები ანალიზდება მხოლოდ დღეში ერთხელ? განაახლებთ ქეშს ყოველ 10 წამში, მაგრამ ის ნამდვილად იცვლება დღის განმავლობაში? ყველა ეს კითხვა უბრუნდება ყველაზე მნიშვნელოვან კითხვას: როგორ იქნება აპლიკაციის გამოყენება? რა არის ბიზნესის ღირებულება მის არსებობისთვის? როგორ გვეხმარება აპლიკაცია მოცემული მიზნის მიღწევაში? რა თქმა უნდა, ყველა ეს პასუხი მაგრამ სწორედ ამიტომ, დიზაინი ყოველთვის უნდა იყოს განმეორებადი პროცესი - რაც საშუალებას მისცემს ცვლილებები მოხდეს რაც შეიძლება შეუფერხებლად. ინჟინრებმა უნდა გაითავისონ ევოლუცია და ცვლილებები, აპლიკაციის შემუშავების გათანაბრება გავლენასთან. ძალიან ხშირად გაურკვეველია პროექტის დასაწყისში; ნაბიჯი 2: დაარეგულირეთ თქვენი ინფრასტრუქტურის რესურსები თქვენს საჭიროებებზე მეორე ნაბიჯი მოიცავს აპლიკაციის სწორი რესურსებით უზრუნველყოფას და სწორ ინფრასტრუქტურაზე მორგებას. როგორც ინჟინერმა, იცოდეთ როგორ გამოითვლება ღრუბლის ხარჯები. მაგალითად, AWS გთავაზობთ წერტილოვან შემთხვევებს, სადაც შეგიძლიათ განაცხადოთ კლასტერული ფასი – ეს განსაკუთრებით სასარგებლოა, თუ თქვენ გაქვთ შეცდომისადმი ტოლერანტული და მოქნილი აპლიკაციები. გამოიყენეთ ისინი, თუ შეგიძლიათ — AWS აცხადებს ხარჯების 90%-მდე შემცირებას [ ]. 4 ზოგიერთი სხვა მოსაზრება, რომლის განხილვაც გსურთ, არის: ემსახურებით მომხმარებლებს გლობალურად თუ მხოლოდ ერთ გეოგრაფიულ არეალში? ნამდვილად გჭირდებათ თქვენი ინფრასტრუქტურა, რომ იცხოვროთ მთელ მსოფლიოში, თუ შეგიძლიათ დააყენოთ ის უფრო ახლოს თქვენს მომხმარებელთა ბაზასთან? ზედმეტად ახორციელებთ თქვენს კლასტერულ ინსტანციებს? შეეცადეთ უზრუნველყოთ საკმარისი სიმძლავრე, რათა გაუმკლავდეთ პიკს ზედმეტი ხარჯების გარეშე. გამოიყენეთ ავტომატური სკალირება რესურსების დინამიურად კორექტირებისთვის ფაქტობრივი მოთხოვნილების საფუძველზე, რაც თავიდან აიცილებთ უმოქმედო რესურსების ზედმეტ გადახდას. თუ თქვენ მუშაობთ მონაცემებთან და Spark-თან, თუ არა, გადახედეთ შემდეგ რესურსებს [ ] [ ] [ ] [ ] [ ]. დარწმუნდით, რომ გესმით Spark-ის კონცეფციები და tuning! 5 6 7 8 9 ნაბიჯი 3: გამოიყენეთ AWS Graviton ინსტანციები AWS Graviton-ის ინსტანციების გამოყენებაში მცირე ხარვეზებია. AWS-მა დიდი ინვესტიცია მოახდინა ყველაზე ეკონომიური პროცესორების შესაქმნელად. თქვენ შეგიძლიათ მიიღოთ ღრუბლოვანი ხარჯების 40%-მდე შემცირება მხოლოდ Intel-ზე დაფუძნებული პროცესორიდან ARM-ზე დაფუძნებულ პროცესორზე გადასვლით [ ]. 10 ამის ერთადერთი გაფრთხილება არის ის, რომ თქვენი აპლიკაცია უნდა იყოს თავსებადი ARM-ზე დაფუძნებულ პროცესორებთან, რომლებზეც მუშაობს Graviton. თუ საქმე გაქვთ ისეთ მართულ სერვისებთან, როგორიცაა RDS ან OpenSearch, მაშინ გადართვაში არანაირი გართულება არ არის – AWS ეხება ძირითად OS და აპლიკაციების თავსებადობას. თუ თქვენ ქმნით საკუთარ აპლიკაციას, მაშინ შეიძლება დაგჭირდეთ პაკეტის ხელახლა შედგენა იმისდა მიხედვით, თუ რომელ ენას იყენებთ - Java და სხვა ენები არ საჭიროებენ ცვლილებას, ხოლო Python მოითხოვს გარკვეულ ყურადღებას. ნაბიჯი 4: თვალყური ადევნეთ თქვენს ხარჯებს და გაეცანით ხარჯების ინფორმირებულობას და ბოლოს, არ დაგავიწყდეთ გააგრძელოთ თქვენი ხარჯების მონიტორინგი მოულოდნელი მწვერვალებისა და სიურპრიზებისთვის. თქვენი განაცხადის 0 დღის ღირებულება განსხვავდება 170 დღის ღირებულებისგან. დარწმუნდით, რომ თვალყურს ადევნებთ ცვლილებებს და გესმით, რატომ ხდება ცვლილება: აგროვებს s3 შენახვის ხარჯებს თუ ეს მხოლოდ ერთჯერადია სპიკი? ! დააყენეთ საჭირო გაფრთხილებები და ოპერაციული სახელმძღვანელოები მნიშვნელოვანია, დანერგეთ ხარჯების განაწილების ტეგები, რათა თვალყური ადევნოთ ხარჯებს დეპარტამენტის, პროექტის ან გარემოს მიხედვით. მოერიდეთ მონაცემთა ჭაობის შექმნის რისკს, სადაც ღირებულება მიუკვლეველია ან მოითხოვს გრძელ მოგზაურობას სხვადასხვა ჟურნალის სისტემაში. სწრაფი და მარტივი უნდა იყოს ნებისმიერი მოცემული განაცხადის ღირებულებაზე დაბრუნება. საბოლოო აზრები სადაც არ უნდა მუშაობდეთ, რთულია ახალი ფუნქციების მიწოდების დაბალანსება მიმდინარე ფუნქციების ოპტიმიზაციასთან. ვისზეც არ ყოფილა ზეწოლა, რომ მიეწოდებინა ახალი უცნაური თვისებები სინათლის სიჩქარით. თუმცა, ინჟინრებისთვისაც და მენეჯერებისთვისაც აუცილებელია მიზანმიმართული და აქტიური გადაწყვეტილებების მიღება მიმდინარე პროექტების შესახებ, რისკებისა და შესაძლებლობების ეფექტურად მართვაში.
