Agent Bucket: ტრილიონი დონის Agent-ის მშობლიური საცავი

დღეს, როდესაც AI Agent-ები სოკოებივით მრავლდებიან წვიმის შემდეგ, დეველოპერები წარმოუდგენელი სისწრაფით ქმნიან წარმოსახვით ინტელექტუალურ აპლიკაციებს. პროგრამირების ასისტენტიდან, რომელიც კოდის დაწერაში გეხმარებათ, ფილმის შემქმნელ ხელსაწყომდე, რომელიც ერთ წინადადებაში ქმნის ფილმს, დამთავრებული პერსონალური ინტელექტუალური ასისტენტით, რომელიც ყოველთვის მზად არის დასახმარებლად, Agent-ები ახლებურად აყალიბებენ ჩვენს ურთიერთობას ციფრულ სამყაროსთან. ამ ტალღის უკან, კონსენსუსი სულ უფრო ნათელი ხდება: Serverless არქიტექტურის (როგორიცაა Lambda), დიდი ენობრივი მოდელების (LLM) და ღრუბლოვანი საცავის (როგორიცაა S3, TOS) და Vibe Coding-ის დახმარებით, ნებისმიერს შეუძლია სწრაფად ააწყოს საკუთარი AI Agent 30 წუთში.

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

როდესაც მილიარდობით მომხმარებელი შემოვა, ტრადიციული ობიექტების საცავი "აღარ არის საკმარისი"

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

2022 წელს S3-ის ბლოგში სახელწოდებით "Partitioning and Isolating Multi-Tenant SaaS Data with Amazon S3" აღწერილია ორი გზა: "თითოეული მოიჯარისთვის გამოიყენეთ ცალკე S3 ბაკეტი" და "პრეფიქსზე დაფუძნებული იზოლირებული საერთო S3 ბაკეტი":

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

• გამოიყენეთ "პრეფიქსი" მომხმარებლების გასარჩევად იმავე ბაკეტში: ეს გახდა მთავარი გადაწყვეტა. მაგალითად, მომხმარებლის A ფაილები იწყება user-a/-ით, ხოლო მომხმარებლის B ფაილები იწყება user-b/-ით, ისევე როგორც ფაილების მართვა კომპიუტერზე საქაღალდეების გამოყენებით. თუმცა, ობიექტების საცავში არ არსებობს მშობლიური საქაღალდეები, ეს სქემა არის მრავალ მოიჯარის გარჩევა "K-V" საცავის სისტემაში "საერთო პრეფიქსის" (Prefix) საშუალებით.

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

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

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

• ხარჯების სიცხადე: თქვენთვის რთულია ზუსტად იცოდეთ, რამდენი საცავი მოიხმარა თითოეულმა მომხმარებელმა და რამდენი ტრაფიკის საფასური წარმოიქმნა. როდესაც გსურთ გადაიხადოთ ფასიან მომხმარებლებს გამოყენების მიხედვით, ბილინგი და გაზომვა ბუნდოვანი ხდება.რატომ არის, რომ ეს ერთი შეხედვით ძირითადი მოთხოვნები, Agent-ის დეველოპერებისთვის ობიექტების საცავში გარკვეულწილად „მძიმეა“? მიზეზის სიღრმისეული შესწავლა იმაში მდგომარეობს, რომ დღევანდელ ღრუბლოვან არქიტექტურაში, S3-ის მსგავს „ობიექტების საცავსა“ და ტრადიციულ „ფაილურ სისტემას“ შორის არსებობს უზარმაზარი ვაკუუმი. ობიექტების საცავის (S3/TOS) არსი არის „გაბრტყელება“, დიზაინის საწყისი მიზანია უზარმაზარი მონაცემების მარტივი შენახვა, ისევე როგორც უზარმაზარი საწყობი, თუმცა ტევადობა თითქმის უსაზღვროა, მაგრამ ლოგიკურ სტრუქტურაში უკიდურესად მარტივია. მას აკლია მშობლიური დირექტორიების მოწინავე მართვა, მარცვლოვანი მეტამონაცემების კონტროლი და ნამდვილი მოიჯარის აღქმა. როდესაც დეველოპერები ცდილობენ „ბრტყელ“ S3-ზე, მყარი კოდირების პრეფიქსის საშუალებით, მოახდინონ „სამგანზომილებიანი“ მრავალმოიჯარე ფაილური სისტემის სიმულაცია, ჩვენ რეალურად ვიყენებთ „სტატიკურ KV საცავს“, რათა განვახორციელოთ „დირექტორიის სემანტიკა, მკაცრად იზოლირებული“ Agent აპლიკაციის ფაილებზე წვდომის მეთოდი. სხვა სიტყვებით რომ ვთქვათ, Agent-ს სჭირდება დამატებითი ტოკენების მოხმარება ფაილების მართვისთვის და მრავალმოიჯარე უფლებებისა და იზოლაციის კონტროლისთვის. ეს დამატებითი ტოკენების მოხმარება მიუთითებს იმაზე, რომ S3-ის მიერ განსაზღვრული მარტივი შენახვის სერვისი საკმარისად მარტივი არ არის Agent-ისთვის.

2025 წლის S3 ბლოგი 《Design patterns for multi-tenant access control on Amazon S3》 შემდგომში განმარტავს S3 Access Point-ს. ეს ნიშნავს, რომ შესაძლებელია მრავალი ვირტუალური ქსელის წვდომის წერტილის შექმნა და თითოეული წვდომის წერტილისთვის მორგებული წვდომის წერტილის პოლიტიკის კონფიგურაცია, ქსელის განრიგის დონეზე მრავალმოიჯარე სცენარებისთვის გარკვეული გადაწყვეტილებების არსებობა.

Agent Wonderland

იდეალურ შემთხვევაში, Agent-ის დეველოპერს AI Agent-ის შემუშავებისას შეუძლია ააგოს სრულიად serverless Agent "Agent SDK + შენახვა + MaaS სერვისის" საფუძველზე:

• Agent-ს შეუძლია სრულიად serverless-ად იმუშაოს

• შესაძლებელია Vibe Coding-ის საშუალებით არსებული პროდუქტის შესაძლებლობების გაერთიანება Agent-ის ასაგებად

• საჭიროა მხოლოდ "ADK" python სკრიპტის შენარჩუნება

• შენახვისთვის გამოიყენება ობიექტების საცავი

• AI შესაძლებლობებისთვის გამოიყენება Doubao

• თეორიულად არ არის ECS ან სხვა ინსტანციის ტიპის პროდუქტები

ამავდროულად, შენახვამ უნდა უზრუნველყოს შემდეგი შესაძლებლობები:

• Agent-ს შეიძლება ჰქონდეს object სემანტიკის მქონე საცავი (ფაილების შესანახად), რომელიც უზრუნველყოფს მრავალმოიჯარე წვდომის შესაძლებლობას, დაწყებული მილიონიდან და გაფართოვდეს მილიარდამდე

• Agent-ს შეუძლია თითოეულ მომხმარებელს მიაწოდოს დამოუკიდებელი სივრცე (მრავალ ბიზნესს შორის, ბიზნესს ან uid-ს შეიძლება ჰქონდეს იგივე სახელი)

• Agent-ს შეუძლია პირდაპირ დააკონფიგურიროს თითოეული user-ის გამტარუნარიანობა, დააკონფიგურიროს user object-ის საერთო ზომის ლიმიტი

• Agent-ს შეუძლია user-ის მიხედვით ანგარიშის გამოწერა, მონიტორინგი, დაკვირვება

• Agent-ს შეუძლია თითოეული user-ის ფაილისთვის წვდომის პოლიტიკის კონფიგურაცია

Agent Bucket: AI Agent-ისთვის „მრავალმოიჯარე მშობლიური“ გენების შეყვანა

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

ამ დიზაინის ძირითადი იდეა უკიდურესად მარტივია: თქვენი თითოეული საბოლოო მომხმარებლისთვის შეუსაბამეთ ექსკლუზიური ObjectSet. შეგიძლიათ ObjectSet წარმოიდგინოთ, როგორც „მონაცემთა სეიფი“ ან „ღრუბლოვანი პირადი სივრცე“, რომელიც შექმნილია თითოეული მომხმარებლისთვის. ლოგიკურად ის თქვენს (დეველოპერის) Bucket-ს ეკუთვნის, მაგრამ ფიზიკურად და მართვის თვალსაზრისით, მას აქვს საკუთარი დამოუკიდებელი „ინდივიდუალურობა“ და „სიცოცხლის ციკლი“.Agent Bucket-ის თითოეული ბაკეტი მხარს უჭერს 100 მილიონ ObjectSet-ს, რაც იმას ნიშნავს, რომ თქვენ შეგიძლიათ მშვიდად მოემსახუროთ ასობით მილიონი საბოლოო მომხმარებელს, თითქოს თითოეული საბოლოო მომხმარებელი "ცხოვრობს" საკუთარ დამოუკიდებელ საცავში, და აღარ მოგიწევთ მრავალ მოიჯარეთა საცავის მართვის გამო თავის ტკივილი.

ObjectSet-ის დიზაინი - Agent-ისთვის მოსახერხებელი შესაძლებლობები

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

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

• ორიგინალური ნებართვები: თითოეულ ObjectSet-ს შეიძლება ჰქონდეს დამოუკიდებელი დომენი. ეს ნიშნავს, რომ შეგიძლიათ მომხმარებელს A მისცეთ user-a.yourapp.com-ის ექსკლუზიური წვდომის მისამართი და აღარ გამოაქვეყნოთ მთელი საცავის დომენი. უფრო ჭკვიანურია "ორი საკეტის" დიზაინი: პირველი საკეტი არის ღრუბლოვანი სერვისის პროვაიდერის მიერ გაცემული დროებითი წვდომის სერთიფიკატი (STS), რომელიც აკონტროლებს წვდომის ნებართვებს აპლიკაციის დონეზე; მეორე საკეტი არის ObjectSet-ის დამოუკიდებელი დომენი, რომელიც ქსელის დონეზე კეტავს წვდომის მოთხოვნებს მომხმარებლის საკუთარ მონაცემთა სივრცეში. ეს მნიშვნელოვნად აუმჯობესებს მონაცემთა უსაფრთხოებას.

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

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

• ორიგინალური გაზომვა: გსურთ იცოდეთ, რამდენი საცავი გამოიყენა თითოეულმა მომხმარებელმა? გსურთ საცავის ხარჯები ზუსტად გაანაწილოთ თითოეულ მომხმარებელზე? ახლა ეს ძალიან მარტივია. Agent Bucket ავტომატურად გაგიანგარიშებთ თითოეული ObjectSet-ის მოცულობას და გამოყენებას, რაც თქვენს ბილინგსა და განაწილებას ნათელს გახდის.

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

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

• ორიგინალური ინტელექტი: Agent Bucket აძლევს Agent-ს საშუალებას, გამოვიდეს ტრადიციული ფაილების მარტივი "შენახვისა" და "წვდომის" შეზღუდვებიდან, ანიჭებს Object-ს ორიგინალურ ინტელექტს და უფრო ეფექტურად უჭერს მხარს Agent-ის ერთჯერად განვითარებას. ObjectSet-ს შეუძლია ერთი დაწკაპუნებით ჩართოს ინტელექტუალური ინდექსირება, რაც Agent-ს უზრუნველყოფს ორიგინალურად მოსახერხებელი მულტიმოდალური კითხვა-პასუხის შესაძლებლობებით, რაც ანაცვლებს ტრადიციულ Object CRUD-ის მექანიკურ ოპერაციებს; ის ასევე მხარს უჭერს ერთი დაწკაპუნებით Agentself რეჟიმის ჩართვას, აკავშირებს ვექტორებს, ცოდნას, მოდელებსა და prompt-ებს, პირდაპირ ავლენს სცენარზე ორიენტირებულ ქვედა Agent-ის ფუნქციებს, რაც ზედა დონის Agent-ის დეველოპერებს საშუალებას აძლევს, ფოკუსირდნენ ძირითადი ბიზნესის სამუშაო პროცესის შექმნაზე და სრულად გაათავისუფლონ ინტელექტუალური გარდაქმნის ეფექტურობა.

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

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

აპლიკაციის მასშტაბის სწრაფი გაფართოებით, Set-ების უზარმაზარი რაოდენობის მართვის სირთულე, იზოლაციის სირთულე და ფიზიკური შეზღუდვები ერთდროულად იჩენს თავს:

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

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

Set Tagging: მომხმარებლის დონის მართვა ტეგირებით

ObjectSet გთავაზობთ ტეგირების მართვის მშობლიურ მეთოდს, რაც Agent-ის დეველოპერებს საშუალებას აძლევს მარტივად გამოიყენონ set tagging-ის შესაძლებლობები მომხმარებლის დონის მართვისთვის. დეველოპერებს შეუძლიათ თითოეული განსაზღვრული მომხმარებლის დონე დაუკავშირონ ტეგს და ჩართონ სხვადასხვა კვოტები და მახასიათებლები თითოეული ტეგისთვის. ყველა ObjectSet, რომელსაც ეს ტეგი აქვს მინიჭებული, გამოიყენებს შესაბამის კვოტებსა და მახასიათებლებს. განვიხილოთ V1, V2 და V3 დონეების მაგალითი:

• V1: ნაგულისხმევი დონე, უფასო მომხმარებლები, ყველა ObjectSet-ის ნაგულისხმევი ტეგი. შესაძლებელია კონფიგურაცია, რომ შეინახოს მაქსიმუმ 1GiB მონაცემები, საჯარო ქსელის განაწილება არ უნდა აღემატებოდეს 100mbps გამტარობას, ხოლო ერთჯერადი ნაკადის ჩამოტვირთვის სიჩქარე კონტროლდება 1mbps-მდე;

• V2: საწყისი დონის ფასიანი წევრობა, კონფიგურაცია, რომ შეინახოს მაქსიმუმ 10GiB მონაცემები, საჯარო ქსელის განაწილება არ უნდა აღემატებოდეს 10gbps გამტარობას, ხოლო ერთჯერადი ნაკადის ჩამოტვირთვის სიჩქარე კონტროლდება 10mbps-მდე;

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

Agent-ის დეველოპერებს შეუძლიათ მოქნილად გამოიყენონ V1/V2/V3 tagging სხვადასხვა მომხმარებლის განვითარების ციკლისთვის, რათა მართონ ამ მომხმარებლებისთვის ხელმისაწვდომი რესურსები და დამატებითი ღირებულების მახასიათებლები.

Set Slice: მომხმარებლის მონაცემების მშობლიური იზოლაცია დიდი მოცულობით

როდესაც Agent Bucket-ში Set-ების რაოდენობა მიაღწევს ასობით მილიონს, ხოლო ობიექტების რაოდენობა მიაღწევს ასობით მილიარდს ან ტრილიონს, ფაქტი, რომ "ყველა მეტამონაცემი ერთ Bucket-ში კონცენტრირებულია ერთ KV კლასტერში", თავისთავად წარმოქმნის სიმძლავრისა და მუშაობის რისკებს.

Set Slice გთავაზობთ "ლოგიკურად არ დაიშლება, ფიზიკურად დაიშლება" მიდგომას:

• ლოგიკურად, თქვენ კვლავ მართავთ მხოლოდ ერთ Agent Bucket-ს.

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

Set Slice არის ObjectSet-ის შესაძლებლობების შემდგომი გაფართოება და გარანტია. ის ძირეულად წყვეტს ფიზიკური სიმძლავრის უსასრულო გაფართოების პრობლემას და ამავე დროს უზრუნველყოფს ObjectSet-ის მართვის მოდელის სტაბილურობასა და თანმიმდევრულობას.

• მართვის საზღვრების სტაბილურობა: მაშინაც კი, თუ Agent Bucket-ის მონაცემები მოიცავს მრავალ ფიზიკურ კლასტერს, ObjectSet კვლავ რჩება ნებართვების, კვოტების, ბილინგისა და მონიტორინგის ერთადერთ ძირითად ერთეულად. დეველოპერების მიერ ObjectSet-ისთვის კონფიგურირებული პოლიტიკები (როგორიცაა წვდომის კონტროლი, სიმძლავრის ლიმიტი) ავტომატურად ამოქმედდება ყველა შესაბამის Slices-ზე, მონაცემების განაწილებაზე ფიქრის გარეშე.

• ერთი Set შეიძლება ხაზობრივად გაფართოვდეს: როდესაც კონკრეტული ObjectSet-ის მონაცემთა რაოდენობა სწრაფად იზრდება, მისი მონაცემები ბუნებრივად ნაწილდება მრავალ Slices-ში. მთლიანი კლასტერის გაფართოებასთან ერთად, ამ ObjectSet-ის სიმძლავრე ასევე შეუფერხებლად და ხაზობრივად იზრდება. დეველოპერებს არ სჭირდებათ ამ ObjectSet-ის რაიმე დაშლა ან მიგრაცია.

• რესურსების იზოლაცია Set-ებს შორის: სხვადასხვა დიაპაზონის ობიექტების განაწილებით სხვადასხვა ფიზიკურ კლასტერზე, SetSlice ახორციელებს რესურსების იზოლაციის უფრო მაღალ განზომილებას. ObjectSet-ის კვოტების მართვასთან ერთად, შესაძლებელია ეფექტურად თავიდან აიცილოთ კონკრეტული "სუპერ დიდი" ObjectSet-ის მონაცემების ზრდა, რომელიც იკავებს ერთი კლასტერის ყველა რესურსს, რითაც გავლენას ახდენს სხვა ObjectSet-ების სტაბილურობაზე და მთლიანი სიმძლავრის რისკი ხდება კონტროლირებადი.- ლოგიკური ერთიანობა და თავსებადობა: ბიზნესისა და დეველოპერებისთვის, რამდენი Slice-იც არ უნდა იყოს ქვედა დონეზე, ისინი ყოველთვის ერთიან ლოგიკურ Agent Bucket-ს აწყდებიან. ყველა ოპერაცია Bucket-ზე, ObjectSet-ზე და ობიექტებზე უცვლელი რჩება, რაც უზრუნველყოფს ფიზიკური გაფართოების სრულ გამჭვირვალობას ზედა დონის აპლიკაციებისთვის.

Set AccessPoint: თითოეული მომხმარებლის წვდომის იზოლირებული წერტილი

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

დამოუკიდებელი წვდომის დომენი {$apid}.tos-objectset-ap.volces.com: უსაფრთხოების ორდონიანი დაცვა

• პირველი დონე Obscurity (დამალულობა): By User/ObjectSet დამოუკიდებელი ქვედომენი, apid მაღალი ენტროპიის ჰეშირება, უკიდურესად დაბალი შეჯახების ალბათობა, შეუძლებელია კონკრეტული მომხმარებლის შესასვლელის გამოცნობა და ამოწურვა წვდომის დომენის კუთხით;

• მეორე დონე Containment (შეზღუდულობა): Agent-ის დეველოპერები იყენებენ sts-ს ObjectSet-ის დონის წვდომის უფლებების გასაცემად, sts-ის გაჟონვის შემთხვევაშიც კი, შესაძლებელია მისი წვდომის დიაპაზონის კონტროლი გარკვეული ObjectSet-ის შეზღუდული ვადით;

ევრისტიკული დაგეგმვის სისტემა: მილიარდობით დომენის დაგეგმვის სტრატეგიის გამოთვლა

• By user/ObjectSet:tag-ის დიფერენცირებული წვდომის სტრატეგია

• მრავალი user/ObjectSet ავტომატურად იფანტება სხვადასხვა საჯარო ქსელის შესასვლელში, ერთი შესასვლელის გაუმართაობა აკონტროლებს user-ების რაოდენობას, რომლებზეც გავლენა აქვს

• სრული რეგიონის ელასტიური დაგეგმვა, ნებისმიერი ერთი შესასვლელის გაუმართაობა/გადატვირთვა ავტომატურად ასრულებს ტრაფიკის შეფუთვას და გადაადგილებას

• საჯარო ქსელის აჩქარებული განაწილების ტიპის user-ები, აყენებენ საჯარო ქსელის გადაცემის აჩქარების tag-ს, ავტომატურად გეგმავენ აჩქარების შესასვლელს

• საჯარო ქსელის რისკის ტიპის user-ები, აყენებენ რისკის tag-ს, ავტომატურად გეგმავენ საჯარო ქსელის იზოლირებულ შესასვლელს და ამცირებენ საჯარო ქსელის გამტარუნარიანობის კვოტას

• შიდა ქსელის ჯვარედინი დომენის ტიპის user-ები, აყენებენ ჯვარედინი დომენის tag-ს, ავტომატურად გეგმავენ შიდა ქსელის გამოყოფილი ხაზის აჩქარების გზას

• ლოკალური რეგიონის ამაჩქარებლის user-ები, აყენებენ ამაჩქარებლის tag-ს, ავტომატურად ამაგრებენ ლოკალური რეგიონის ამაჩქარებელს

პროგრამირების ასისტენტიდან AI ღრუბლოვან დისკამდე, Agent Bucket-ის უსაზღვრო შესაძლებლობები

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

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

• საწარმოს ფოტო ალბომი/ღრუბლოვანი დისკი: ტრადიციული ფოტო ალბომის ან ღრუბლოვანი დისკის სერვისები ხშირად აერთიანებს ყველა მომხმარებლის ფოტოს ერთ Bucket-ში, მომხმარებლების გარჩევა ხდება პრეფიქსების საშუალებით, რაც არა მხოლოდ ართულებს მართვას, არამედ იწვევს „მეზობლის ეფექტს“. ObjectSet-ზე დაფუძნებული, თითოეული მომხმარებლის ფოტო და ვიდეო განთავსებულია საკუთარ Set-ში, წვდომის პიკები ერთმანეთს ხელს არ უშლის და ასევე შესაძლებელია მომხმარებლის მიერ მოცულობის ლიმიტის, სარეზერვო ასლის შექმნის სტრატეგიისა და დაშიფვრის მეთოდის დაყენება, რაც ნამდვილად უზრუნველყოფს, რომ „თითოეულს აქვს უსაფრთხო და კონტროლირებადი ღრუბლოვანი ფოტო ალბომი“.

• Hadoop მონაცემთა საცავი: საწარმოს მონაცემთა საცავში, სხვადასხვა ბიზნეს ხაზები და სხვადასხვა მონაცემთა ბაზები ხშირად იზიარებენ რესურსებს იმავე ქვედა დონის საცავზე. თითოეული მონაცემთა ბაზის ObjectSet-ზე გადატანით, საწარმოებს შეუძლიათ განახორციელონ იზოლაცია და კვოტის კონტროლი ერთიან საცავზე. განსაკუთრებით ObjectSet უზრუნველყოფს დამატებით დონის ნებართვებს TOS-ზე, TOS-ზე შენახული მონაცემთა ბაზებისა და ცხრილების იზოლაციისა და ნებართვების კონტროლის უზრუნველსაყოფად, არსებული Proton on TOS-ის შეცვლის გარეშე.- მოდელის ჰოსტინგის პლატფორმა: დიდი მოდელების ჰოსტინგის სცენარებში, თითოეული მოდელი არა მხოლოდ მოცულობით დიდია, არამედ შესაძლოა შეესაბამებოდეს სხვადასხვა ვერსიას, წონას და დასკვნის კონფიგურაციას. თითოეული მოდელისთვის ObjectSet-ის შექმნით, შესაძლებელია მოდელის წონების, Tokenizer-ის, კონფიგურაციის ფაილების და მასთან დაკავშირებული შეფასების მონაცემების ერთ სივრცეში შეფუთვა და ჰოსტინგი. ოპერირების მხარეს შეუძლია სხვადასხვა მოდელისთვის განსხვავებული დაშიფვრის პოლიტიკის, სარეზერვო პოლიტიკის და გამტარუნარიანობის კონტროლის დაყენება. ამავდროულად, ორიგინალური საზომი შესაძლებლობების საშუალებით, შესაძლებელია თითოეული მოდელის რეალური გამოყენების ღირებულების სტატისტიკური მონაცემების შეგროვება, რაც საფუძველს უყრის მოდელის განზომილების მიხედვით ბილინგსა და რესურსების განაწილებას.

• მონაცემთა SaaS სერვისი: ტერმინალური მომხმარებლებისთვის მონაცემთა მასობრივი გავრცელების პლატფორმებს ხშირად სჭირდებათ მრავალი მონაცემთა მიმწოდებლის ერთდროულად დაკავშირება. აუცილებელია თითოეული მხარის მონაცემთა საზღვრების სიცხადის უზრუნველყოფა და ასევე „ერთი დიდი კასრი ყველას აფერხებს“ შესრულების რისკის თავიდან აცილება. Agent Bucket-ის დახმარებით, თითოეულ მონაცემთა მიმწოდებელს შეუძლია ჰქონდეს საკუთარი ObjectSet, რომელიც მართავს ორიგინალურ მონაცემებს და დამუშავების შედეგებს ერთიანად. დამოუკიდებელი დომენისა და გამტარუნარიანობის, QPS კვოტების საშუალებით, შესაძლებელია სხვადასხვა მიმწოდებლისთვის სერვისის დიფერენცირებული გარანტიისა და შეზღუდვის განხორციელება, რაც უზრუნველყოფს „ერთ პლატფორმას, მრავალ მიმწოდებელს, იზოლირებულ და კონტროლირებად თანამშრომლობას“ მონაცემთა გავრცელების ინფრასტრუქტურას.

მითითება:

• https://aws.amazon.com/cn/blogs/apn/partitioning-and-isolating-multi-tenant-saas-data-with-amazon-s3/

• https://aws.amazon.com/cn/blogs/storage/design-patterns-for-multi-tenant-access-control-on-amazon-s3/