Agent Bucket: Agent-Native Storage Bucket for Trillions of Objects

In today's world where AI Agents are emerging like mushrooms after rain, developers are building imaginative intelligent applications at an unprecedented pace. From programming assistants that help you write code, to creative tools that generate a movie from a single sentence, to personal intelligent assistants that are always on standby, Agents are reshaping the way we interact with the digital world. Behind this wave, a consensus is becoming increasingly clear: with the help of Serverless architectures (such as Lambda), large language models (LLMs), and cloud storage (such as S3, TOS), combined with Vibe Coding, anyone can quickly build their own AI Agent in 30 minutes.

From "usable" to "easy to use", Agent developers still need to overcome challenges in transitioning from "toys" to "production-grade applications". As business scales to massive users, developers have to face an extremely complex challenge: how to build a complete storage solution for massive end-users on object storage? For most developers, this is not only a technical threshold, but also a gap that hinders the large-scale distribution of Agents. Agent Bucket aims to completely simplify the construction process of multi-tenant systems through AI-native storage design, providing more friendly Agent capabilities.

When Hundreds of Millions of Users Flood In, Traditional Object Storage is "Not Enough"

Imagine you've developed a wildly popular AIGC application. Each user will generate and store a large number of images, videos, and temporary files. As a developer, you will naturally choose mature and scalable object storage services like S3 and TOS. But here's the problem: how do you manage data for massive users?

The 2022 S3 blog post 《Partitioning and Isolating Multi-Tenant SaaS Data with Amazon S3》 describes two methods: "Using a separate S3 bucket for each tenant" and "Sharing an S3 bucket based on prefix isolation":

• Create a separate "bucket" for each user: This is feasible when the number of users is small, but when the number of users grows to tens of thousands or millions, the number of buckets will explode rapidly, and the management cost and resource limitations will be unbearable. S3 provides a total of 10,000 bucket quotas for the entire region, but for popular AI capabilities, 10,000 is far from enough.

• Use "prefixes" to distinguish users in the same bucket: This has become the mainstream solution. For example, user A's files all start with user-a/, and user B's files start with user-b/, just like managing files with folders on a computer. However, object storage does not have native folders. This solution distinguishes multi-tenants through "common prefixes" in the "K-V" storage system.

This "bucket" or "prefix" based solution has been widely adopted in the past decade. But there are the following problems:

• Multi-tenant isolation: All users' data is mixed in the same bucket. An abnormal high-frequency access by one user may affect all other users, resulting in a "neighbor effect". Performance isolation and fault isolation are out of the question.

• Permission control: Complex permission policies (IAM Policy) are difficult to maintain, and it is easy to make configuration errors, resulting in accidental access to user data, especially when interacting with other cloud services, the risk exposure is greater.

• Cost clarity: It is difficult for you to accurately know how much storage space each user has consumed and how much traffic costs have been generated. When you want to charge paying users based on usage, billing and metering become a mess.ทำไมความต้องการพื้นฐานเหล่านี้ นักพัฒนา Agent ถึงดูเหมือนจะ "หนัก" ในการใช้งาน Object Storage? การเจาะลึกถึงสาเหตุ เป็นเพราะในสถาปัตยกรรม Cloud Native ปัจจุบัน มีช่องว่างขนาดใหญ่อยู่ระหว่าง "Object Storage" อย่าง S3 กับ "File System" แบบดั้งเดิม Object Storage (S3/TOS) โดยพื้นฐานแล้วคือ "Flat" ซึ่งได้รับการออกแบบมาเพื่อการจัดเก็บข้อมูลจำนวนมหาศาลอย่างง่ายดาย เหมือนโกดังขนาดใหญ่ แม้ว่าความจุจะเกือบไม่จำกัด แต่โครงสร้างเชิงตรรกะนั้นเรียบง่ายมาก ขาดการจัดการไดเรกทอรีขั้นสูง การควบคุม Metadata แบบละเอียด และการรับรู้ถึงผู้เช่าที่แท้จริง เมื่อนักพัฒนาพยายามจำลองระบบไฟล์ Multi-Tenant แบบ "สามมิติ" บน S3 แบบ "Flat" โดยการ Hard Code Prefix เรากำลังใช้ "Static KV Storage" เพื่อรองรับวิธีการเข้าถึงไฟล์ของแอปพลิเคชัน Agent ที่มี "Semantic ของไดเรกทอรีและการแยกส่วนที่แข็งแกร่ง" กล่าวอีกนัยหนึ่ง Agent จำเป็นต้องใช้ Token เพิ่มเติมเพื่อจัดการไฟล์ และควบคุมการแก้ปัญหาการอนุญาตและการแยกส่วน Multi-Tenant Token ที่ใช้เพิ่มเติมเหล่านี้ทั้งหมดบ่งชี้ว่าบริการจัดเก็บข้อมูลอย่างง่ายที่ S3 กำหนดนั้นไม่เรียบง่ายเพียงพอสำหรับ Agent

บทความในบล็อก S3 ปี 2025 เรื่อง 《Design patterns for multi-tenant access control on Amazon S3》 อธิบายเพิ่มเติมเกี่ยวกับ S3 Access Point ซึ่งหมายความว่าสามารถสร้างจุดเชื่อมต่อเครือข่ายเสมือนได้หลายจุด และกำหนดค่านโยบาย Access Point ที่กำหนดเองสำหรับแต่ละจุดเชื่อมต่อ ทำให้มีโซลูชันบางอย่างในระดับการจัดตารางเครือข่ายสำหรับสถานการณ์ Multi-Tenant

Agent Wonderland

นักพัฒนา Agent ในอุดมคติสามารถสร้าง Agent ที่เป็น Serverless อย่างสมบูรณ์โดยอิงจาก "Agent SDK + Storage + MaaS Service" เมื่อพัฒนา AI Agent:

• Agent สามารถทำงานแบบ Serverless ได้อย่างสมบูรณ์

• สามารถสร้าง Agent โดยการรวมความสามารถของผลิตภัณฑ์ที่มีอยู่ผ่าน Vibe Coding

• เพียงแค่ต้องดูแลสคริปต์ Python ของ "ADK"

• ที่เก็บข้อมูลใช้ Object Storage

• ความสามารถ AI ใช้ Doubao

• ในทางทฤษฎีไม่มี ECS หรือผลิตภัณฑ์ประเภท Instance อื่นๆ

ในขณะเดียวกัน ที่เก็บข้อมูลต้องมีความสามารถดังต่อไปนี้:

• Agent สามารถมีที่เก็บข้อมูลที่มี Semantic ของ Object (บันทึกไฟล์) ให้ความสามารถในการเข้าถึง Multi-Tenant เริ่มต้นที่ระดับล้าน และขยายได้ถึงระดับพันล้าน

• Agent สามารถจัดเตรียมพื้นที่อิสระสำหรับผู้ใช้แต่ละราย (ระหว่างหลายธุรกิจ ธุรกิจหรือ UID อาจมีชื่อซ้ำกัน)

• Agent สามารถกำหนดค่าแบนด์วิดท์สำหรับผู้ใช้แต่ละรายได้โดยตรง กำหนดขีดจำกัดขนาด Object ทั้งหมดของผู้ใช้

• Agent สามารถเรียกเก็บเงิน ตรวจสอบ และสังเกตตามผู้ใช้

• Agent สามารถกำหนดค่านโยบายการเข้าถึงสำหรับไฟล์ของผู้ใช้แต่ละรายได้

Agent Bucket: เติม "ยีน Multi-Tenant ดั้งเดิม" ให้กับ AI Agent

เพื่อแก้ปัญหาที่ยากลำบากนี้ตั้งแต่ต้นตอ เราได้นำเสนอ Paradigm ใหม่ของ Object Storage นั่นคือ Agent Bucket นวัตกรรมหลักคือการแนะนำระดับทรัพยากรดั้งเดิมใหม่ระหว่าง "Bucket" และ "Object" แบบดั้งเดิม: Object Set

แนวคิดหลักของการออกแบบนี้เรียบง่ายมาก: จับคู่ ObjectSet เฉพาะสำหรับผู้ใช้ปลายทางแต่ละรายของคุณ คุณสามารถจินตนาการถึง ObjectSet ว่าเป็น "ตู้เซฟข้อมูล" หรือ "พื้นที่ส่วนตัวบนคลาวด์" ที่สร้างขึ้นสำหรับผู้ใช้แต่ละรายโดยเฉพาะ ในเชิงตรรกะเป็นของ Bucket ของคุณ (นักพัฒนา) แต่ในทางกายภาพและการจัดการ มี "บุคลิก" และ "วงจรชีวิต" ที่เป็นอิสระของตัวเอง## การออกแบบ ObjectSet - ความสามารถที่เป็นมิตรกับ Agent

ObjectSet ใน Agent Bucket ไม่ได้เป็นเพียงการเพิ่มระดับ แต่ยังเปลี่ยนความต้องการที่ยากที่สุดในสถานการณ์ Multi-tenant ให้กลายเป็นความสามารถดั้งเดิมที่พร้อมใช้งาน เมื่อความเป็นเจ้าของข้อมูลถูกกำหนดไว้อย่างชัดเจนในระดับ ObjectSet ความสามารถต่างๆ ที่เคยยากที่จะทำให้เป็นจริงก็จะเกิดขึ้นตามมาอย่างเป็นธรรมชาติ

• การแยกส่วนดั้งเดิม: ในระดับ ObjectSet คุณสามารถตั้งค่า QPS, แบนด์วิดท์ และโควต้าความจุที่เป็นอิสระสำหรับผู้ใช้แต่ละคน ประสบการณ์ของผู้ใช้ที่ชำระเงินจะได้รับการรับประกัน และพฤติกรรมที่ผิดปกติของผู้ใช้ฟรีจะไม่ส่งผลกระทบต่อผู้อื่น นี่คือการแยกโดเมนความผิดพลาดที่แท้จริง ทำให้ "เพื่อนบ้าน" ไม่รบกวนซึ่งกันและกัน

• สิทธิ์ดั้งเดิม: ObjectSet แต่ละชุดสามารถมีโดเมนที่เป็นอิสระ ซึ่งหมายความว่าคุณสามารถให้ที่อยู่สำหรับเข้าถึงเฉพาะสำหรับผู้ใช้ A เช่น user-a.yourapp.com แทนที่จะเปิดเผยโดเมนของ Bucket ทั้งหมด สิ่งที่ฉลาดกว่าคือการออกแบบ "สองล็อค": ล็อคแรกคือข้อมูลประจำตัวการเข้าถึงชั่วคราว (STS) ที่ออกโดยผู้ให้บริการคลาวด์ ซึ่งควบคุมสิทธิ์การเข้าถึงในระดับแอปพลิเคชัน ล็อคที่สองคือโดเมนที่เป็นอิสระของ ObjectSet ซึ่งล็อคคำขอเข้าถึงในพื้นที่ข้อมูลของผู้ใช้เองจากระดับเครือข่าย สิ่งนี้ช่วยเพิ่มความปลอดภัยของข้อมูลอย่างมาก

• การตรวจสอบดั้งเดิม: บนแดชบอร์ดการตรวจสอบ คุณจะไม่สามารถเห็นข้อมูลสรุปของ Bucket ทั้งหมดได้อีกต่อไป คุณสามารถแยกย่อยแผนภูมิการตรวจสอบตาม ObjectSet เพื่อให้เข้าใจได้อย่างชัดเจนว่าผู้ใช้ปลายทางรายใดกำลังเข้าชมจำนวนมาก เพื่อทำการตัดสินใจด้านการดำเนินงานและการเพิ่มประสิทธิภาพที่แม่นยำ

• การลดระดับความสามารถดั้งเดิม: นโยบายที่เคยตั้งค่าได้เฉพาะในระดับ Bucket ตอนนี้สามารถลดระดับลงไปถึงผู้ใช้แต่ละคนได้แล้ว คุณสามารถตั้งค่าวงจรชีวิตข้อมูลที่แตกต่างกันสำหรับผู้ใช้ในระดับต่างๆ หรือใช้คีย์การเข้ารหัสที่แตกต่างกันสำหรับ ObjectSet แต่ละชุด เพื่อให้การจัดการข้อมูลมีความละเอียดและปลอดภัยยิ่งขึ้น

• การวัดผลดั้งเดิม: ต้องการทราบว่าผู้ใช้แต่ละคนใช้พื้นที่จัดเก็บข้อมูลเท่าใด ต้องการแบ่งค่าใช้จ่ายในการจัดเก็บข้อมูลให้กับผู้ใช้แต่ละคนอย่างแม่นยำหรือไม่ ตอนนี้มันง่ายมาก Agent Bucket จะรวบรวมความจุและการใช้งานของ ObjectSet แต่ละชุดโดยอัตโนมัติ ทำให้การเรียกเก็บเงินและการแบ่งปันรายได้ของคุณชัดเจน

• การเรียกเก็บเงินดั้งเดิม: นักพัฒนาสามารถแบ่งค่าใช้จ่ายได้อย่างง่ายดาย โดยส่งต่อค่าใช้จ่ายที่เกิดจากการจัดเก็บข้อมูลไปยังผู้ใช้ปลายทางแต่ละรายได้อย่างแม่นยำ ตัวอย่างเช่น เรียกเก็บเงินที่แตกต่างกันตามสัดส่วนต้นทุนที่เกิดขึ้นจริงของผู้ใช้ A, B และ C เพื่อให้การสนับสนุนข้อมูลสำหรับการสร้างรายได้ของ Agent

• ขีดจำกัดความจุเดิม: เพื่อควบคุมต้นทุนการดำเนินงานของ Agent คุณสามารถตั้งค่า Quota (ขีดจำกัดความจุ) สำหรับ ObjectSet แต่ละชุด เมื่อถึงค่าที่ตั้งไว้ล่วงหน้า ระบบจะจำกัดผู้ใช้ไม่ให้สร้างไฟล์ใหม่ต่อไป เพื่อหลีกเลี่ยงการใช้ทรัพยากรในทางที่ผิดในสถานการณ์ Multi-tenant ตั้งแต่ต้นทาง

• ความฉลาดดั้งเดิม: Agent Bucket ช่วยให้ Agent หลุดพ้นจากข้อจำกัดของการ "จัดเก็บ" และ "เข้าถึง" ไฟล์แบบง่ายๆ แบบดั้งเดิม โดยให้ Object มีความฉลาดดั้งเดิม และสนับสนุนการพัฒนาแบบครบวงจรของ Agent ได้อย่างมีประสิทธิภาพมากขึ้น ObjectSet สามารถเปิดใช้งานดัชนีอัจฉริยะได้ด้วยคลิกเดียว เพื่อให้ Agent มีความสามารถในการตอบคำถามแบบ Multi-modal ที่เป็นมิตรกับ Agent แทนที่การดำเนินการเชิงกลของ Object CRUD แบบดั้งเดิม หรือแม้แต่รองรับการเปิดใช้งานโหมด Agentself ได้ด้วยคลิกเดียว เชื่อมต่อเวกเตอร์ ความรู้ โมเดล และ Prompt โดยตรงเพื่อแสดงฟังก์ชัน Agent ย่อยตามสถานการณ์ ทำให้ผู้พัฒนา Agent ระดับบนมุ่งเน้นไปที่การสร้าง Workflow ธุรกิจหลัก และปลดปล่อยประสิทธิภาพการสร้างรายได้อัจฉริยะอย่างเต็มที่

ความท้าทายทางเทคนิคที่เกิดจากการเติบโตอย่างรวดเร็วของแอปพลิเคชัน

Agent Bucket นำเสนอแนวคิดดั้งเดิมของ ObjectSet เพื่อให้นักพัฒนาแอปพลิเคชันมีวิธีที่สง่างามและมีประสิทธิภาพในการจัดการข้อมูลผู้ใช้ปลายทางนับล้านชุด สินทรัพย์ดิจิทัลของผู้ใช้แต่ละรายจะถูกจัดเก็บอย่างปลอดภัยใน ObjectSet เฉพาะของตน ซึ่งมีการแยกส่วน การเรียกเก็บเงิน และการจัดการโควต้าโดยธรรมชาติ

เมื่อขนาดของแอปพลิเคชันขยายตัวอย่างรวดเร็ว ความซับซ้อนในการจัดการ Set จำนวนมาก ความยากลำบากในการแยกส่วน และข้อจำกัดทางกายภาพก็ปรากฏขึ้นพร้อมกัน:

• ปัญหาการจัดการตามระดับของผู้ใช้จำนวนมาก: เมื่อแอปพลิเคชันจัดการทรัพยากรและคุณสมบัติของผู้ใช้ในระดับต่างๆ จำนวนมาก จะต้องออกแบบและใช้งาน Metadata การจัดระดับของผู้ใช้เอง และเชื่อมโยงสวิตช์คุณสมบัติของ Object Storage การช่วยเหลือนักพัฒนาในการจัดการการจัดระดับผู้ใช้อย่างสง่างามบนแนวคิดดั้งเดิมของ Set เป็นสิ่งสำคัญในการเร่งการใช้งานแอปพลิเคชัน- ข้อจำกัดด้านความจุของคลัสเตอร์เดียว: แม้ว่า Agent Bucket จะสามารถขยายได้ไม่จำกัดในเชิงตรรกะ แต่ข้อมูลเมตาจะถูกจัดเก็บไว้ในคลัสเตอร์ทางกายภาพเดียวโดยค่าเริ่มต้น เมื่อจำนวนวัตถุทั้งหมดใน Bucket ถึงระดับแสนล้านหรือล้านล้าน ความจุทางกายภาพของคลัสเตอร์เดียวจะกลายเป็นขีดจำกัดที่ไม่สามารถเอาชนะได้

• ปัญหาการแชร์จุดเชื่อมต่อ: ความหลากหลายของธุรกิจของ Agent และผู้ใช้จำนวนมากนำมาซึ่งความเสี่ยงด้านความปลอดภัยและรัศมีการระเบิดที่มากขึ้นสำหรับจุดเชื่อมต่อเอง วิธีการทำการจัดตารางเวลาแบบไดนามิกตามความแตกต่างของธุรกิจและผู้ใช้จำนวนมาก เพื่อให้เกิดความปลอดภัย การแยก และความสามารถในการเร่งความเร็วที่แตกต่างกันจึงกลายเป็นเรื่องยาก

Set Tagging: การจัดการผู้ใช้แบบแบ่งชั้นด้วย Tagging

ObjectSet มีวิธีการจัดการแบบ Tagging ดั้งเดิม ช่วยให้นักพัฒนา Agent สามารถใช้ความสามารถ Set Tagging ได้อย่างง่ายดาย เพื่อให้การจัดการผู้ใช้แบบแบ่งชั้นเสร็จสมบูรณ์ นักพัฒนาสามารถกำหนดระดับผู้ใช้แต่ละระดับให้สอดคล้องกับ Tag และเปิดใช้งานโควต้าและคุณสมบัติที่แตกต่างกันสำหรับแต่ละ Tag ObjectSet ทั้งหมดที่ถูก Tag จะใช้โควต้าและคุณสมบัติที่สอดคล้องกัน ตัวอย่างเช่น ระดับ V1, V2 และ V3:

• V1: ระดับเริ่มต้น ผู้ใช้ฟรี Tag เริ่มต้นสำหรับ ObjectSet ทั้งหมด สามารถกำหนดค่าให้จัดเก็บข้อมูลได้สูงสุด 1GiB การกระจายแบบสาธารณะต้องไม่เกินแบนด์วิดท์ 100mbps และควบคุมความเร็วในการดาวน์โหลดสตรีมเดียวเป็น 1mbps

• V2: สมาชิกแบบชำระเงินระดับเริ่มต้น กำหนดค่าให้จัดเก็บข้อมูลได้สูงสุด 10GiB การกระจายแบบสาธารณะต้องไม่เกินแบนด์วิดท์ 10gbps และควบคุมความเร็วในการดาวน์โหลดสตรีมเดียวเป็น 10mbps

• V3: สมาชิกแบบชำระเงินระดับสูง นอกเหนือจากการให้โควต้าการจัดเก็บและการกระจายแบบสาธารณะที่มากขึ้นแล้ว ยังรองรับการกำหนดค่าเพื่อเปิดใช้งานการเร่งความเร็วเครือข่ายที่ไม่ดีแบบสาธารณะและความสามารถในการเร่งความเร็วสื่อประสิทธิภาพสูงเพิ่มเติม

นักพัฒนา Agent สามารถใช้ Tagging V1/V2/V3 ได้อย่างยืดหยุ่นเพื่อจัดการทรัพยากรและคุณสมบัติเพิ่มเติมที่ผู้ใช้เหล่านี้สามารถใช้ได้สำหรับวงจรการพัฒนาที่แตกต่างกันของผู้ใช้ที่แตกต่างกัน

Set Slice: การแยกข้อมูลผู้ใช้จำนวนมากแบบดั้งเดิม

เมื่อจำนวน Set ภายใน Agent Bucket หนึ่งถึงระดับร้อยล้าน และจำนวนวัตถุถึงระดับแสนล้านหรือล้านล้าน ข้อเท็จจริงที่ว่า "ข้อมูลเมตาทั้งหมดของ Bucket เดียวรวมอยู่ในคลัสเตอร์ KV เดียว" จะนำมาซึ่งความเสี่ยงด้านความจุและประสิทธิภาพ

Set Slice นำเสนอแนวคิดของ "ไม่แยกเชิงตรรกะ แยกทางกายภาพ":

• ในเชิงตรรกะ คุณยังคงจัดการ Agent Bucket เดียว

• ในทางกายภาพ ข้อมูลเมตาจะถูกแบ่งออกเป็นหลาย Slice (ส่วน) ตาม Set และช่วงชื่อวัตถุภายใน Set แต่ละ 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

• ผู้ใช้/ObjectSet จำนวนมากจะกระจายไปยังทางเข้าสาธารณะที่แตกต่างกันโดยอัตโนมัติ จำนวนผู้ใช้ที่ได้รับผลกระทบจากความล้มเหลวของทางเข้าเดียวจะถูกควบคุม

• การจัดตารางเวลาที่ยืดหยุ่นในทุกภูมิภาค ความล้มเหลว/การโอเวอร์โหลดของทางเข้าเดียวจะทำการบรรจุและการถ่ายโอนปริมาณการใช้งานโดยอัตโนมัติ

• ผู้ใช้ประเภทการกระจายการเร่งความเร็วสาธารณะ ติดแท็กการเร่งความเร็วในการส่งข้อมูลสาธารณะ และจัดตารางเวลาทางเข้าการเร่งความเร็วโดยอัตโนมัติ

• ผู้ใช้ประเภทความเสี่ยงสาธารณะ ติดแท็กความเสี่ยง และจัดตารางเวลาทางเข้าการแยกสาธารณะโดยอัตโนมัติ และลดโควต้าแบนด์วิดท์สาธารณะ

• ผู้ใช้ประเภทข้ามโดเมนเครือข่ายภายใน ติดแท็กข้ามโดเมน และจัดตารางเวลาเส้นทางการเร่งความเร็วสายเฉพาะเครือข่ายภายในโดยอัตโนมัติ

• ผู้ใช้ตัวเร่งความเร็วในภูมิภาค ติดแท็กตัวเร่งความเร็ว และติดตั้งตัวเร่งความเร็วในภูมิภาคโดยอัตโนมัติ

จากผู้ช่วยเขียนโปรแกรมไปจนถึง AI Cloud Disk ความเป็นไปได้ที่ไร้ขีดจำกัดของ Agent Bucket

Agent Bucket มอบโซลูชันที่สมบูรณ์แบบสำหรับ Agent และสถานการณ์การใช้งานการออกแบบ ObjectSet นั้นมีมากกว่านั้น สามารถขยายไปยังแอปพลิเคชันทั้งหมดที่ต้องการให้บริการแก่ผู้ใช้ปลายทางจำนวนมากได้อย่างง่ายดาย:

• ที่เก็บโค้ด: ในอดีต เมื่อบริษัทหรือบุคคลโฮสต์โค้ดบนคลาวด์ พวกเขามักจะต้องสร้าง - แพลตฟอร์มการโฮสต์โมเดล: ในสถานการณ์การโฮสต์โมเดลขนาดใหญ่ แต่ละโมเดลไม่เพียงแต่มีขนาดใหญ่เท่านั้น แต่ยังอาจมีเวอร์ชัน น้ำหนัก และการกำหนดค่าการอนุมานที่แตกต่างกัน การสร้าง ObjectSet สำหรับแต่ละโมเดลสามารถแพ็คน้ำหนักของโมเดล, Tokenizer, ไฟล์การกำหนดค่า และข้อมูลการประเมินที่เกี่ยวข้องและโฮสต์ไว้ในพื้นที่เดียวกัน ฝ่ายปฏิบัติการสามารถกำหนดนโยบายการเข้ารหัส นโยบายการสำรองข้อมูล และการควบคุมแบนด์วิดท์ที่แตกต่างกันสำหรับโมเดลต่างๆ ในขณะเดียวกันก็สามารถใช้ความสามารถในการวัดผลแบบเนทีฟเพื่อสถิติค่าใช้จ่ายในการใช้งานจริงของแต่ละโมเดล ซึ่งเป็นพื้นฐานสำหรับการเรียกเก็บเงินและการจัดสรรทรัพยากรตามมิติของโมเดล

• บริการ Data 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/