ონლაინ საცავის სწრაფი მასშტაბირება ChatGPT‑ის 1 მილიარდზე მეტი მომხმარებლისთვის

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

Habitat არის ონლაინ საცავის პლატფორმა, რომელიც OpenAI-ის პროდუქტებისთვის საჭირო ინფორმაციაზე სწრაფი და საიმედო წვდომის უზრუნველსაყოფად შევქმენით. Habitat ახლა ყოველ წამში 70 მილიონზე მეტ მოთხოვნას ამუშავებს და თითქმის 40 გეოგრაფიულ რეგიონში იმ პროდუქტებს ემსახურება, რომლებსაც ყოველკვირეულად 1 მილიარდზე მეტი ადამიანი იყენებს. Habitat პირველად DevDay 2023-ზე, GPT‑ების მხარდასაჭერად გაეშვა — როგორც მონაცემთა ერთ ბაზასთან დაკავშირებული, კლიენტის მხარეს მოქმედი მარტივი Python-ბიბლიოთეკა. დღეს ის რთული განაწილებული სისტემაა, რომელიც 500 პეტაბაიტზე მეტ მონაცემს ემსახურება.

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

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

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

Habitat მარტივი იდეით დაიწყო: პროდუქტის ინჟინრებს მონაცემთა ბაზის მართვაზე ფიქრი არ უნდა სჭირდებოდეთ. Habitat პირველად DevDay 2023-ზე, GPT‑ების მხარდასაჭერად გაეშვა, როგორც მცირე Python-ბიბლიოთეკა, რომელიც ChatGPT‑ის მთავარ სერვერთან ურთიერთქმედებდა. ის ოპერაციების მცირე ნაკრებს უჭერდა მხარს, რომლებიც შიდა დონეზე მონაცემთა ბაზის აპლიკაციას — Azure Cosmos DB-ს — შეესაბამებოდა.

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

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

ეს Python-ბიბლიოთეკა კარგად მუშაობდა და OpenAI-ის პროდუქტის ინჟინრებმა Habitat სწრაფად აითვისეს, მიუხედავად იმისა, რომ თვითმომსახურების Postgres-ისა და Azure Cosmos DB-ის გამოყენების შესაწყვეტად ცენტრალიზებული ძალისხმევა არ ყოფილა.

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

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

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

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

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

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

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

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

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

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

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

Asyncio Python-ს I/O-ზე დამოკიდებული დატვირთვების პარალელურად შესრულებაში ეხმარება, თუმცა Python-ის GIL-ის შეზღუდვას ვერ უვლის გვერდს და CPU-ზე პარალელურობას ვერ უზრუნველყოფს. I/O-ინტენსიური მოთხოვნების პროქსირების გარდა, Habitat CPU-ინტენსიურ მრავალ ფუნქციასა და ფონურ ამოცანას ასრულებს: მარშრუტიზაციას, შეკუმშვას, დაშიფვრას, საკონტროლო ჯამის გამოთვლას, ქვედა დონის სერვისების მდგომარეობის შემოწმებას, მოთხოვნების ჩრდილოვან გაშვებასა და ჰეჯირებას.

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

OpenAI-ში Python-ის სერვისებისთვის მეხსიერების, CPU-ს, ქსელისა და დისკის გამოყენების სტანდარტული უტილიზაციისა და გაჯერების მეტრიკებთან ერთად კრიტიკულად მნიშვნელოვანია asyncio-ს ციკლისა და მისი დატვირთულობის მონიტორინგი, შემდეგ კი შესაბამისი ოპტიმიზაცია.

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

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

სერვისის საწყისი გაშვებისას, პირდაპირ გარემოში CPU-ს პროფილირებით აღმოვაჩინეთ asyncio-ს მაღალი დაყოვნების — და აქედან გამომდინარე მაღალი ზღვრული დაყოვნებების — ერთ-ერთი ძირეული მიზეზი: Statsig-ის მეშვეობით ფუნქციური ალმების კონფიგურაციების პერიოდული JSON-ანალიზი (Statsig მართავს ფუნქციურ ალმებს და გამოიყენება A/B ტესტებისა და სხვა მიზნებისთვის).

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

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

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

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

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

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

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

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

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

კავშირების მაქსიმალურად კონსოლიდირებისთვის Envoy-საც ვიყენებთ. მისი მეშვეობით Python-ის HTTP/1 კავშირები HTTP/2-ზე გადაგვყავს, რათა მულტიპლექსირებით ვისარგებლოთ, შემდეგ კი ამ კავშირებს ვაერთიანებთ და მათი სიცოცხლის ხანგრძლივობას ვზრდით. Envoy ასევე გვაძლევს ცენტრალურ ადგილს სიხშირის შეზღუდვებისა და ავტომატური ამომრთველების დასანერგად, რომლებიც Python-ის თითოეულ დამოუკიდებელ პროცესში ნაკლებად ეფექტიანი იქნებოდა.

Python-ის ამ მასშტაბამდე გაზრდა ნაწილობრივ Habitat-ის შეზღუდულმა API-მ შეგვაძლებინა, რომელიც მოთხოვნის ხარჯს პროგნოზირებადს ხდის. იმის ნაცვლად, რომ კლიენტებს თვითნებური SQL-მოთხოვნების შექმნის საშუალება მივცეთ, რასაც დიდი ცხრილების სკანირება ან მრავალი ცხრილის გაერთიანება შეიძლება მოჰყვეს, Habitat მარტივ NoSQL API-ს სთავაზობს. მძლავრი API-ის არქონა Habitat-ის დიზაინში გააზრებული კომპრომისია.

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

Habitat-სა და Azure Cosmos DB-ზე გადასვლამდე OpenAI-ის ონლაინ მონაცემების უმეტესობა Postgres-ში ინახებოდა. იმ დროს მარტივი იყო ყველა მოთხოვნისა და სქემის ცვლილების შემოწმება, რათა საწარმოო გარემოში გაშვებამდე დავრწმუნებულიყავით, რომ ისინი გამართულად მუშაობდა და ინდექსირებულ მონაცემებს იყენებდა. გუნდისა და პროდუქტების ზრდასთან ერთად ეს სწრაფად გახდა უმართავი და შეფერხებების ხშირ მიზეზად იქცა: დატვირთულ გზაზე დამატებული ერთი ახალი, ძვირადღირებული მოთხოვნაც კი მონაცემთა ბაზას თიშავდა.

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

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

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

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

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

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

2026 წლის მეორე კვარტალში, მხოლოდ 2 ინჟინრის, Codex-ისა და GPT‑5.5‑ის დახმარებით, მთელი სერვისი Rust-ზე თავიდან დავწერეთ. ახალი Rust-სერვისი ახლა ჩვენი საწარმოო მოთხოვნების 95%-ს ამუშავებს; უახლოეს კვირებში Python-ს სრულად ამოვიღებთ გამოყენებიდან. ჩვენი მონაცემებით, Rust-სერვისი Python-ის ვერსიაზე CPU-ს მხრივ 6-ჯერ, მეხსიერების მხრივ კი 15-ჯერ ეფექტიანია და მისი საშუალო და ზღვრული დაყოვნებებიც მნიშვნელოვნად ნაკლებია. სამომავლო ბლოგპოსტში დამატებითი გამოცდილების გაზიარებას ვგეგმავთ.

Python-ის, ახლა კი Rust-ის სერვისი Habitat-ის მხოლოდ ერთი მხარეა. ამ სერიის მეორე ნაწილში, რომელიც აღწერს, როგორ გავზარდეთ სწრაფად ონლაინ საცავი ChatGPT‑ის 1 მილიარდზე მეტი მომხმარებლის მოსამსახურებლად, ვისაუბრებთ საცავის ფენაზე და იმაზე, როგორ ემსახურება Habitat 500 პეტაბაიტზე მეტ მონაცემსა და წამში 70 მილიონზე მეტ მოთხოვნას.

თუ გსურთ მოწინავე მასშტაბის OLTP სისტემებზე მუშაობა და მსგავსი ინჟინერია გაინტერესებთ, იხილეთ ჩვენს გუნდში არსებული ვაკანსია⁠.