Docker Compose თუ Kubernetes: ნაკლები CPU ყოველთვის ნაკლებ ხარჯს არ ნიშნავს

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

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

რას მართავს თითოეული პლატფორმა

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

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

ერთი ჰოსტი და განახლების რეალური ზღვარი

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

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

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

გადასვლის ზღვრები მოთხოვნების მიხედვით

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

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

CPU, მეხსიერება და სრული ხარჯი

ჰენრიკე ზანელა კოჩაკის SPIFFE-IdT-ის სადისერტაციო გაზომვაში DVID რეჟიმში subject workload-ის ვალიდაციისას Compose-ის განთავსებამ საშუალოდ 13.58% CPU და 33.30 MB მეხსიერება აჩვენა, ხოლო Kubernetes-ის განთავსებამ — 11.93% CPU და 36.10 MB მეხსიერება. ორივე გარემო ერთსა და იმავე ფიზიკურ სერვერზე შეამოწმეს; Kubernetes-ის მხარეს ერთკვანძიანი Minikube გამოიყენეს. ეს არის კონკრეტული კომპონენტისა და ოპერაციის შედარება, და არა პლატფორმების უნივერსალური წარმადობის მაჩვენებელი.

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

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

ასევე წაიკითხეთ:

• ChatGPT თუ Perplexity: კვლევაში მეტი წყარო ყოველთვის უკეთეს პასუხს არ ნიშნავს
• Shopify თუ WooCommerce: უფასო ბირთვი იაფ მაღაზიას არ ნიშნავს
• Stripe Atlas თუ Clerky: დაბალი საწყისი ფასი სრულ პაკეტს არ ნიშნავს