వ్యాసం వివరించే ఆర్కిటెక్చర్ ఇలస్ట్రేషన్: ఒక ఏజెంట్, దాని isolated microVM, యాక్సెస్‌ను మధ్యవర్తిత్వం చేసే గేట్‌వే, checkpoint, షేర్డ్ ఇమేజ్, వర్క్‌స్పేస్ నిల్వ. ఇది భావనాత్మకమైనది, అధికారిక Google Cloud డయాగ్రామ్ కాదు, కొలిచిన పనితీరును చూపదు.
Google Agent Compute Engine హార్డ్‌వేర్-ఐసోలేటెడ్ microVM లను, checkpoint ఆధారిత ఎగ్జిక్యూషన్‌ను, షేర్డ్ మెమరీని, బయటి నుంచి అమలు చేసే అనుమతులను కలుపుతుంది. స్వయంప్రతిపత్తి గల ఏజెంట్ల పెద్ద సముదాయాలను నడపడంలోని ఒక కష్టమైన సమస్యను ఈ ఆర్కిటెక్చర్ పరిష్కరిస్తుంది: ఏజెంట్ పనిచేసే కంప్యూటర్‌ను భద్రపరుస్తూనే, దానికి ఇక అవసరం లేని వనరులను ఎలా విడుదల చేయాలి.
ఖాళీగా ఉన్నప్పుడు కంప్యూట్‌ను పట్టుకోని పనిచేసే కంప్యూటర్ ఏజెంట్లకు కావాలి
ఒక కోడింగ్ ఏజెంట్ కొన్ని నిమిషాల పాటు ప్రాజెక్ట్‌ను కంపైల్ చేయవచ్చు, టెస్ట్‌లు నడపవచ్చు, ఫలితాలను పరిశీలించవచ్చు, ఆ తర్వాత డెవలపర్ స్పందన కోసం ఆగవచ్చు. డెవలపర్ తిరిగి వచ్చినప్పుడు, ఏజెంట్‌కు దాని ఫైళ్లు, ఇన్‌స్టాల్ చేసిన dependencies, ఎగ్జిక్యూషన్ వాతావరణం చెక్కుచెదరకుండా ఉండాలి. ఆ వాతావరణాన్ని ఒక ప్రత్యేక virtual machine లో నడపడం సులభం, కానీ ఇలాంటి వందల వేల వాతావరణాలను నిర్వహించడం వేరే సమస్య.
ప్రతి ఏజెంట్ రూపొందించిన లేదా తెలియని కోడ్‌ను నడపవచ్చు కాబట్టి దానికి ఐసోలేషన్ అవసరం. పనుల మధ్య నిలిచి ఉండే వర్క్‌స్పేస్ కూడా కావాలి. కానీ వేచి ఉన్న ప్రతి ఏజెంట్‌కు CPU, మెమరీని కేటాయించి ఉంచితే, పని ఏమీ జరగకపోయినా మౌలిక సదుపాయాల ఖర్చు పెరుగుతూ పోతుంది.
October 22, 2026 నాడు, ఇలాంటి లక్షణాలున్న వర్క్‌లోడ్‌ల కోసం అభివృద్ధి చేసిన నిర్వహించే కంప్యూటింగ్ ఆర్కిటెక్చర్ అయిన Agent Compute Engine ను Google పరిచయం చేసింది. ఈ ప్లాట్‌ఫాం ఇప్పటికే Google అంతర్గత Gemini, Antigravity, ఏజెంట్-ఎవాల్యుయేషన్ వ్యవస్థలకు మద్దతిస్తోంది, బయటి కస్టమర్ ప్రివ్యూ రాబోయే నెలల్లో ప్రణాళికలో ఉంది.
ఏజెంట్ ఎగ్జిక్యూషన్ వాతావరణాన్ని, దాన్ని నడిపే భౌతిక మెషీన్ నుంచి వేరు చేయగల శాశ్వత వనరుగా Google చూడటం ఈ విధానాన్ని గమనించదగినదిగా చేస్తుంది. ప్రతి సెషన్‌కు కంప్యూట్‌ను నిరంతరం రిజర్వ్ చేయడానికి బదులు, ప్లాట్‌ఫాం ఒక వాతావరణపు స్థితిని భద్రపరచి, దాని క్రియాశీల వనరులను విడుదల చేసి, ఏజెంట్ కొనసాగాల్సినప్పుడు దాన్ని పునరుద్ధరించగలదు. దీని వెనుక ఉన్న ఇంజనీరింగ్, ఒక AI ఏజెంట్‌ను కేవలం container లో పెట్టడం కంటే చాలా సంక్లిష్టమైనది.
harness తన కమాండ్‌లను నడిపే sandbox బయటే ఉంటుంది
Google ఆర్కిటెక్చర్ మొదట ఏజెంట్‌ను రెండు భాగాలుగా విడదీస్తుంది. harness AI మోడల్‌తో పరస్పర చర్యను నిర్వహిస్తుంది, ఏ టూల్స్‌ను పిలవాలో, ఏ చర్యలను ప్రయత్నించాలో నిర్ణయిస్తుంది. sandbox ఆ చర్యలను అమలు చేస్తుంది, కమాండ్‌లు నడపడానికి, ఫైళ్లను మార్చడానికి, సాఫ్ట్‌వేర్ ఇన్‌స్టాల్ చేయడానికి, బ్రౌజర్ టూల్స్ వాడటానికి కావాల్సిన ఆపరేటింగ్-సిస్టమ్ వాతావరణాన్ని ఇస్తుంది.
ఒక సాఫ్ట్‌వేర్ రిపాజిటరీపై పనిచేస్తున్న ఏజెంట్‌ను ఊహించండి. టెస్ట్ సూట్ నడపాలని harness నిర్ణయించవచ్చు, కానీ కంపైలేషన్, టెస్టింగ్ sandbox లోపల జరుగుతాయి.
Agent Compute Engine ఆ ఎగ్జిక్యూషన్ వాతావరణం కోసం ఒక ప్రత్యేక microVM ను వాడుతుంది. సాధారణంగా host ఆపరేటింగ్-సిస్టమ్ kernel ను పంచుకునే మామూలు container లా కాకుండా, microVM కి హార్డ్‌వేర్ వర్చువలైజేషన్ సరిహద్దు వెనుక దాని సొంత guest kernel ఉంటుంది. కోడింగ్ ఏజెంట్లకు root అనుమతులు, ప్రత్యేక డెవలప్‌మెంట్ టూల్స్ లేదా నమ్మదగినదని భావించలేని కోడ్‌ను నడిపే సామర్థ్యం అవసరమైనప్పుడు ఇది ముఖ్యం.
Google తన microVM లను Titanium మౌలిక సదుపాయాల మద్దతుతో కూడిన భద్రతా రక్షణలతో సింగిల్-టెనెంట్ ఎగ్జిక్యూషన్ వాతావరణాలుగా వర్ణిస్తుంది. harness sandbox బయట పనిచేస్తుంది, కాబట్టి ప్రమాదకరమైన కమాండ్‌లను నడిపే వాతావరణం, నమ్మకమైన ఆర్కెస్ట్రేషన్ ప్రక్రియను నియంత్రించదు. ఈ విభజన ఉపయోగకరమైన కార్యాచరణ సరిహద్దును సృష్టిస్తుంది, ఎందుకంటే ఏజెంట్ పనిని నిర్దేశించే harness తో సంబంధం లేకుండా సిస్టమ్ ఒక sandbox ను నిర్వహించవచ్చు, నిలిపివేయవచ్చు లేదా మార్చవచ్చు.
పని ఏదీ మిగల్లేదని runtime చెప్పినప్పుడు ఏజెంట్ ఖాళీ అవుతుంది
ఏజెంట్ కార్యకలాపం, అభ్యర్థనను స్వీకరించి, ప్రతిస్పందనను ఇచ్చి, తన ఎగ్జిక్యూషన్ వాతావరణాన్ని మర్చిపోయే సాధారణ వెబ్ సర్వీస్‌లా ఉండదు. ఏజెంట్ టూల్ ఎగ్జిక్యూషన్‌కు, మోడల్ ఇన్ఫరెన్స్, బయటి సర్వీస్‌లు లేదా మానవ ఇన్‌పుట్ కోసం వేచి ఉండటానికి మధ్య పదే పదే మారవచ్చు. సాధారణ ప్రయోజన virtual-machine hypervisor వనరుల వినియోగాన్ని గమనించగలదు, కానీ guest తదుపరి ఏజెంట్ సూచన కోసం వేచి ఉందో లేక చట్టబద్ధమైన బ్యాక్‌గ్రౌండ్ జాబ్ నడుపుతోందో దానికి అర్థం కావాలని లేదు.
sandbox కమాండ్ runtime ను host executor కు అనుసంధానించడం ద్వారా Google దీన్ని పరిష్కరిస్తుంది. ఒక టూల్ కాల్ ముగిసిన తర్వాత, ఇంకా క్రియాశీల కమాండ్‌లు లేదా బ్యాక్‌గ్రౌండ్ టాస్క్‌లు మిగిలి ఉన్నాయా అని runtime నిర్ణయించగలదు. వాతావరణం సురక్షితమైన ఖాళీ స్థితికి చేరినప్పుడు, sandbox ఆ స్థితిని host కు సంకేతంగా తెలియజేస్తుంది.
అప్పుడు host, ఎగ్జిక్యూషన్ వనరులను రిజర్వ్‌లో ఉంచడానికి బదులు microVM ను checkpoint చేయగలదు. harness మరో టూల్ కాల్ చేసినప్పుడు, వాతావరణం పునరుద్ధరించబడి ఎగ్జిక్యూషన్ కొనసాగుతుంది.
ముఖ్యమైన యంత్రాంగం application-aware idle detection. తక్కువ CPU వినియోగం చూసి వాతావరణాన్ని నిలిపివేయవచ్చని మౌలిక సదుపాయాలు కేవలం ఊహించవు, ఎందుకంటే అవి ఏజెంట్-ఎగ్జిక్యూషన్ runtime నుంచి లైఫ్‌సైకిల్ సమాచారాన్ని అందుకుంటాయి. ఒక ప్రక్రియ నెట్‌వర్క్ కార్యకలాపం లేదా బయటి ఈవెంట్ కోసం వేచి ఉంటూ దాదాపు CPU వాడకపోయినా అవసరమైన పని చేస్తూనే ఉండవచ్చు కాబట్టి ఇది ముఖ్యం.
తక్కువ CPU అంటే ఖాళీ అని ఎందుకు కాదు
సందర్భం: ఒక ప్రక్రియ నెట్‌వర్క్ కార్యకలాపం లేదా బయటి ఈవెంట్ కోసం వేచి ఉంది. మౌలిక సదుపాయాలు ఎలా నిర్ణయిస్తాయో ఎంచుకుని, ప్రతి విధానం ఏమి చెప్పగలదో చూడండి.
CPU మాత్రమే ఆధారంగా ఊహ
ఇది ఏమి చూస్తుంది
- వేచి ఉన్న ప్రక్రియ దాదాపు CPU వాడదు, కాబట్టి వాతావరణం ఖాళీగా కనిపిస్తుంది.
- సాధారణ ప్రయోజన hypervisor వనరుల వినియోగాన్ని గమనించగలదు.
ఇది చెప్పలేనిది
- ప్రక్రియ ఇంకా అవసరమైన పని చేస్తోందా అన్నది, ఎందుకంటే ప్రక్రియ నెట్‌వర్క్ కార్యకలాపం లేదా బయటి ఈవెంట్ కోసం వేచి ఉంటూ కూడా అవసరమే కావచ్చు.
- guest తదుపరి ఏజెంట్ సూచన కోసం వేచి ఉందా లేక చట్టబద్ధమైన బ్యాక్‌గ్రౌండ్ జాబ్ నడుపుతోందా అన్నది.
runtime చెప్పే ఖాళీ స్థితి
ఇది ఏమి చూస్తుంది
- టూల్ కాల్ ముగిసిన తర్వాత, ఇంకా క్రియాశీల కమాండ్‌లు లేదా బ్యాక్‌గ్రౌండ్ టాస్క్‌లు ఉన్నాయా అని runtime తనిఖీ చేస్తుంది.
- ఏవీ లేనప్పుడు, sandbox సురక్షితమైన ఖాళీ స్థితిని host కు తెలియజేస్తుంది, host microVM ను checkpoint చేయగలదు.
ఇది చెప్పలేనిది
- CPU వినియోగం నుంచి ఊహ, ఎందుకంటే మౌలిక సదుపాయాలు ఏజెంట్-ఎగ్జిక్యూషన్ runtime నుంచి లైఫ్‌సైకిల్ సమాచారాన్ని అందుకుంటాయి.
- నిలిపివేసినప్పుడు లైవ్ కనెక్షన్‌లు మార్పు లేకుండా కొనసాగుతాయనే హామీ.
క్రియాశీల కమాండ్‌లు లేదా బ్యాక్‌గ్రౌండ్ టాస్క్‌లు ఏవీ నడవనప్పుడు నిలిపివేత జరుగుతుందని Google వివరిస్తుంది. వాతావరణం నిలిపివేయబడినప్పుడు ఏకపక్ష బ్యాక్‌గ్రౌండ్ ప్రక్రియలు, లైవ్ కనెక్షన్‌లు మార్పు లేకుండా పనిచేస్తూనే ఉంటాయని అది నిర్ధారించదు, కాబట్టి కస్టమర్లు బ్యాక్‌గ్రౌండ్-టాస్క్ ప్రవర్తనను, కనెక్షన్ పునరుద్ధరణను, పునరుద్ధరణ హామీలను పరీక్షించాలి.
క్రియాశీల కమాండ్‌లు లేదా బ్యాక్‌గ్రౌండ్ టాస్క్‌లు ఏవీ నడవనప్పుడు నిలిపివేత జరుగుతుందని Google వివరిస్తుంది. వాతావరణం నిలిపివేయబడినప్పుడు ఏకపక్ష బ్యాక్‌గ్రౌండ్ ప్రక్రియలు, లైవ్ కనెక్షన్‌లు మార్పు లేకుండా పనిచేస్తూనే ఉంటాయని అది నిర్ధారించదు. భవిష్యత్ సర్వీస్‌ను మూల్యాంకనం చేసే కస్టమర్లు బ్యాక్‌గ్రౌండ్-టాస్క్ ప్రవర్తనను, కనెక్షన్ పునరుద్ధరణను, పునరుద్ధరణ హామీలను స్పష్టంగా పరీక్షించాల్సి ఉంటుంది.
Google వివరించే యంత్రాంగం గురించి TechiesJournal భావనాత్మక డయాగ్రామ్, అధికారిక Google Cloud డయాగ్రామ్ కాదు.
చిత్రం 1 టెక్స్ట్ రూపం
- harness టూల్ ఎగ్జిక్యూషన్‌ను అభ్యర్థిస్తుంది.
- Isolated microVM కమాండ్‌ను నడుపుతుంది.
- కమాండ్‌లు లేదా బ్యాక్‌గ్రౌండ్ టాస్క్‌లు ఇంకా క్రియాశీలంగా ఉంటే, microVM పనిని కొనసాగిస్తుంది.
- ఏవీ క్రియాశీలంగా లేకపోతే, runtime సురక్షితమైన ఖాళీ స్థితిని తెలియజేస్తుంది.
- host ఎగ్జిక్యూషన్ స్థితిని checkpoint చేస్తుంది.
- క్రియాశీల కంప్యూట్ వనరులు విడుదలవుతాయి.
- తదుపరి టూల్ అభ్యర్థన వస్తుంది.
- microVM స్థితి పునరుద్ధరించబడి కమాండ్ నడుస్తుంది, ఇది రెండో దశకు తిరిగి వెళ్తుంది.
షేర్డ్ బేస్ మెమరీ చాలా వాతావరణాల పునరుద్ధరణను ఆచరణీయం చేస్తుంది
చాలా వాతావరణాలను అధిక మెమరీ వాడకుండా వేగంగా పునరుద్ధరించగలిగితేనే checkpointing పెద్ద స్థాయిలో ఉపయోగపడుతుంది. సంప్రదాయ పద్ధతి ప్రతి sandbox కోసం ప్రత్యేక guest ఆపరేటింగ్ సిస్టమ్‌ను ప్రారంభించి, Python ను లోడ్ చేసి, బ్రౌజర్ ప్రక్రియలను మొదలుపెట్టి, సాధారణ టూల్స్‌ను ఇన్‌స్టాల్ చేయవచ్చు, ఆ ప్రారంభ పనిలో చాలా భాగం ఒకే పనిని మళ్లీ మళ్లీ చేయడమే.
బదులుగా Google, ఇప్పటికే ప్రారంభించిన ఆపరేటింగ్-సిస్టమ్ భాగాలను, లైబ్రరీలను, టూల్ runtime లను కలిగిన pre-warmed snapshot లను వాడుతుంది. host ఆ snapshot లలోని షేర్డ్, ఎక్కువగా మార్పులేని భాగాలను Direct Access (DAX) ద్వారా మెమరీలోకి మ్యాప్ చేస్తుంది, కాబట్టి అనేక microVM లు ఒక్కొక్కటీ పూర్తి ప్రత్యేక కాపీని ఉంచుకోకుండా ఆ భౌతిక పేజీలను ఉపయోగించగలవు. ఏజెంట్ మెమరీని మార్చినప్పుడు, copy-on-write (CoW) దాని మార్పుల కోసం ప్రైవేట్ పేజీలను ఇస్తుంది, ఇతర ఏజెంట్లు సాధారణ బేస్ పేజీలనే వాడుతూ ఉంటాయి.
ఒకే ఆపరేటింగ్-సిస్టమ్ ఇమేజ్, Python runtime, బ్రౌజర్ బైనరీలను వాడే 500 ఏజెంట్ వాతావరణాలను ఊహించండి. షేర్డ్ భాగాలు ఒక్కొక్కటీ స్వతంత్ర భౌతిక-మెమరీ కేటాయింపును ఆక్రమించాల్సిన అవసరం లేదు, మెమరీ వాడకం ప్రధానంగా ప్రతి వాతావరణానికి ప్రత్యేకమైన ప్రైవేట్ డేటా, మార్పులతో పెరుగుతుంది. వర్క్‌లోడ్‌లు మారుతున్నప్పుడు వనరులను తిరిగి పొందడానికి memory reclaim, compression ను కూడా Google వివరిస్తుంది.
షేర్డ్ బేస్ మెమరీ లెక్క
ఇది మీరు సెట్ చేసే ఇన్‌పుట్‌లతో కూడిన లెక్కల ఉదాహరణ, Google కొలత కాదు. షేర్డ్ బేస్ మెమరీని 100 యూనిట్లుగా తీసుకోండి. ప్రతి వాతావరణం అదే నైరూప్య యూనిట్లలో లెక్కించే తన ప్రైవేట్ పేజీలను జోడిస్తుంది. ఒక షేర్డ్ బేస్‌ను, ప్రతి వాతావరణానికి పూర్తి కాపీతో పోల్చడానికి వాతావరణాల సంఖ్యను, ప్రైవేట్ మొత్తాన్ని ఎంచుకోండి.
1 వాతావరణం
ఒక్కసారి ఉంచిన షేర్డ్ బేస్ పేజీలు: 100 యూనిట్లు, ప్లస్ 1 × 10 ప్రైవేట్ యూనిట్లు, మొత్తం 110 యూనిట్లు.
ప్రతి వాతావరణానికి పూర్తి కాపీ: 1 × (100 + 10) యూనిట్లు, మొత్తం 110 యూనిట్లు.
షేర్డ్ బేస్: 110 యూనిట్లు. ఒక్కొక్కదానికి పూర్తి కాపీ: 110 యూనిట్లు.
ఒకే వాతావరణం ఉంటే పంచుకోవడానికి ఏమీ లేదు, కాబట్టి రెండు మొత్తాలు ఒకటే.
ఒక్కసారి ఉంచిన షేర్డ్ బేస్ పేజీలు: 100 యూనిట్లు, ప్లస్ 1 × 30 ప్రైవేట్ యూనిట్లు, మొత్తం 130 యూనిట్లు.
ప్రతి వాతావరణానికి పూర్తి కాపీ: 1 × (100 + 30) యూనిట్లు, మొత్తం 130 యూనిట్లు.
షేర్డ్ బేస్: 130 యూనిట్లు. ఒక్కొక్కదానికి పూర్తి కాపీ: 130 యూనిట్లు.
ఒకే వాతావరణం ఉంటే పంచుకోవడానికి ఏమీ లేదు, కాబట్టి రెండు మొత్తాలు ఒకటే.
ఒక్కసారి ఉంచిన షేర్డ్ బేస్ పేజీలు: 100 యూనిట్లు, ప్లస్ 1 × 60 ప్రైవేట్ యూనిట్లు, మొత్తం 160 యూనిట్లు.
ప్రతి వాతావరణానికి పూర్తి కాపీ: 1 × (100 + 60) యూనిట్లు, మొత్తం 160 యూనిట్లు.
షేర్డ్ బేస్: 160 యూనిట్లు. ఒక్కొక్కదానికి పూర్తి కాపీ: 160 యూనిట్లు.
ఒకే వాతావరణం ఉంటే పంచుకోవడానికి ఏమీ లేదు, కాబట్టి రెండు మొత్తాలు ఒకటే.
10 వాతావరణాలు
ఒక్కసారి ఉంచిన షేర్డ్ బేస్ పేజీలు: 100 యూనిట్లు, ప్లస్ 10 × 10 ప్రైవేట్ యూనిట్లు, మొత్తం 200 యూనిట్లు.
ప్రతి వాతావరణానికి పూర్తి కాపీ: 10 × (100 + 10) యూనిట్లు, మొత్తం 1100 యూనిట్లు.
షేర్డ్ బేస్: 200 యూనిట్లు. ఒక్కొక్కదానికి పూర్తి కాపీ: 1100 యూనిట్లు.
9 వాతావరణాలకు బేస్ పునరావృతం కాదు, కాబట్టి తేడా 900 యూనిట్లు.
ఒక్కసారి ఉంచిన షేర్డ్ బేస్ పేజీలు: 100 యూనిట్లు, ప్లస్ 10 × 30 ప్రైవేట్ యూనిట్లు, మొత్తం 400 యూనిట్లు.
ప్రతి వాతావరణానికి పూర్తి కాపీ: 10 × (100 + 30) యూనిట్లు, మొత్తం 1300 యూనిట్లు.
షేర్డ్ బేస్: 400 యూనిట్లు. ఒక్కొక్కదానికి పూర్తి కాపీ: 1300 యూనిట్లు.
9 వాతావరణాలకు బేస్ పునరావృతం కాదు, కాబట్టి తేడా 900 యూనిట్లు.
ఒక్కసారి ఉంచిన షేర్డ్ బేస్ పేజీలు: 100 యూనిట్లు, ప్లస్ 10 × 60 ప్రైవేట్ యూనిట్లు, మొత్తం 700 యూనిట్లు.
ప్రతి వాతావరణానికి పూర్తి కాపీ: 10 × (100 + 60) యూనిట్లు, మొత్తం 1600 యూనిట్లు.
షేర్డ్ బేస్: 700 యూనిట్లు. ఒక్కొక్కదానికి పూర్తి కాపీ: 1600 యూనిట్లు.
9 వాతావరణాలకు బేస్ పునరావృతం కాదు, కాబట్టి తేడా 900 యూనిట్లు.
100 వాతావరణాలు
ఒక్కసారి ఉంచిన షేర్డ్ బేస్ పేజీలు: 100 యూనిట్లు, ప్లస్ 100 × 10 ప్రైవేట్ యూనిట్లు, మొత్తం 1100 యూనిట్లు.
ప్రతి వాతావరణానికి పూర్తి కాపీ: 100 × (100 + 10) యూనిట్లు, మొత్తం 11000 యూనిట్లు.
షేర్డ్ బేస్: 1100 యూనిట్లు. ఒక్కొక్కదానికి పూర్తి కాపీ: 11000 యూనిట్లు.
99 వాతావరణాలకు బేస్ పునరావృతం కాదు, కాబట్టి తేడా 9900 యూనిట్లు.
ఒక్కసారి ఉంచిన షేర్డ్ బేస్ పేజీలు: 100 యూనిట్లు, ప్లస్ 100 × 30 ప్రైవేట్ యూనిట్లు, మొత్తం 3100 యూనిట్లు.
ప్రతి వాతావరణానికి పూర్తి కాపీ: 100 × (100 + 30) యూనిట్లు, మొత్తం 13000 యూనిట్లు.
షేర్డ్ బేస్: 3100 యూనిట్లు. ఒక్కొక్కదానికి పూర్తి కాపీ: 13000 యూనిట్లు.
99 వాతావరణాలకు బేస్ పునరావృతం కాదు, కాబట్టి తేడా 9900 యూనిట్లు.
ఒక్కసారి ఉంచిన షేర్డ్ బేస్ పేజీలు: 100 యూనిట్లు, ప్లస్ 100 × 60 ప్రైవేట్ యూనిట్లు, మొత్తం 6100 యూనిట్లు.
ప్రతి వాతావరణానికి పూర్తి కాపీ: 100 × (100 + 60) యూనిట్లు, మొత్తం 16000 యూనిట్లు.
షేర్డ్ బేస్: 6100 యూనిట్లు. ఒక్కొక్కదానికి పూర్తి కాపీ: 16000 యూనిట్లు.
99 వాతావరణాలకు బేస్ పునరావృతం కాదు, కాబట్టి తేడా 9900 యూనిట్లు.
500 వాతావరణాలు
ఒక్కసారి ఉంచిన షేర్డ్ బేస్ పేజీలు: 100 యూనిట్లు, ప్లస్ 500 × 10 ప్రైవేట్ యూనిట్లు, మొత్తం 5100 యూనిట్లు.
ప్రతి వాతావరణానికి పూర్తి కాపీ: 500 × (100 + 10) యూనిట్లు, మొత్తం 55000 యూనిట్లు.
షేర్డ్ బేస్: 5100 యూనిట్లు. ఒక్కొక్కదానికి పూర్తి కాపీ: 55000 యూనిట్లు.
499 వాతావరణాలకు బేస్ పునరావృతం కాదు, కాబట్టి తేడా 49900 యూనిట్లు.
ఒక్కసారి ఉంచిన షేర్డ్ బేస్ పేజీలు: 100 యూనిట్లు, ప్లస్ 500 × 30 ప్రైవేట్ యూనిట్లు, మొత్తం 15100 యూనిట్లు.
ప్రతి వాతావరణానికి పూర్తి కాపీ: 500 × (100 + 30) యూనిట్లు, మొత్తం 65000 యూనిట్లు.
షేర్డ్ బేస్: 15100 యూనిట్లు. ఒక్కొక్కదానికి పూర్తి కాపీ: 65000 యూనిట్లు.
499 వాతావరణాలకు బేస్ పునరావృతం కాదు, కాబట్టి తేడా 49900 యూనిట్లు.
ఒక్కసారి ఉంచిన షేర్డ్ బేస్ పేజీలు: 100 యూనిట్లు, ప్లస్ 500 × 60 ప్రైవేట్ యూనిట్లు, మొత్తం 30100 యూనిట్లు.
ప్రతి వాతావరణానికి పూర్తి కాపీ: 500 × (100 + 60) యూనిట్లు, మొత్తం 80000 యూనిట్లు.
షేర్డ్ బేస్: 30100 యూనిట్లు. ఒక్కొక్కదానికి పూర్తి కాపీ: 80000 యూనిట్లు.
499 వాతావరణాలకు బేస్ పునరావృతం కాదు, కాబట్టి తేడా 49900 యూనిట్లు.
వాస్తవంగా ఎంత స్థితిని పంచుకోగలమనే దానిపై ప్రయోజనం ఆధారపడి ఉంటుంది, ప్రతి వాతావరణానికి ప్రైవేట్ మొత్తం ఎక్కువైతే అది తగ్గుతుంది. Google ఇంజనీరింగ్ వెల్లడింపు యంత్రాంగాన్ని నిర్ధారిస్తుంది, కానీ స్వతంత్రంగా కొలిచిన కస్టమర్ పనితీరును అందించదు.
అందుకే ఈ ఆర్కిటెక్చర్ రెండు రకాల వృథాను ఒకేసారి లక్ష్యంగా చేసుకుంటుంది: ఖాళీ ఏజెంట్ల కోసం రిజర్వ్ చేసిన కంప్యూట్, దాదాపు ఒకేలాంటి సాఫ్ట్‌వేర్ వాతావరణాలున్న ఏజెంట్లలో నకిలీ అయిన మెమరీ.
సమర్థత ప్రయోజనం, వాస్తవంగా ఎంత స్థితిని పంచుకోగలమనే దానిపై ఆధారపడుతుంది. అధికంగా అనుకూలీకరించిన సాఫ్ట్‌వేర్ స్టాక్‌లు నడిపే, పెద్ద ప్రైవేట్ మెమరీ ప్రాంతాలను నిర్వహించే లేదా తమ వాతావరణాల్లో గణనీయమైన భాగాలను మార్చే ఏజెంట్లు, సాధారణ pre-warmed ఇమేజ్‌లను వాడే ఏజెంట్ల కంటే తక్కువ మెమరీ షేరింగ్‌ను సాధించవచ్చు. Google ఇంజనీరింగ్ వెల్లడింపు యంత్రాంగాన్ని నిర్ధారిస్తుంది, కానీ ఈ వివిధ వర్క్‌లోడ్ ప్రొఫైల్‌లలో స్వతంత్రంగా కొలిచిన కస్టమర్ పనితీరును అందించదు.
శాశ్వత వర్క్‌స్పేస్ ఫైళ్లు తాత్కాలిక స్థితి నుంచి వేరుగా నిల్వ అవుతాయి
ఎగ్జిక్యూషన్ స్థితిని భద్రపరచడం, ఏ ఫైళ్లు రోజులు లేదా వారాల పాటు నిలవాలో నిర్ణయించడం ఒకటి కాదు. ఒక కోడింగ్ ఏజెంట్ తాత్కాలిక compiler అవుట్‌పుట్‌లను సృష్టించవచ్చు, సాధారణ toolchain లను వాడవచ్చు, ఒక ప్రైవేట్ రిపాజిటరీని మార్చవచ్చు, ఆ డేటా వర్గాలకు వేర్వేరు నిలకడ అవసరాలుంటాయి. Google ఆర్కిటెక్చర్ మూడు నిల్వ రకాలను వేరు చేస్తుంది.
తాత్కాలిక లాగ్‌లు, బిల్డ్ ఆర్టిఫాక్ట్‌లు, ఆపరేటింగ్-సిస్టమ్ మార్పులు వాడి పారేసే overlay లలో ఉండవచ్చు. ఇవి ఎగ్జిక్యూషన్ సమయంలో ఉపయోగపడతాయి కానీ దీర్ఘకాలిక నిలుపుదల అవసరం లేదు.
షేర్డ్ టూల్స్, బేస్ ఇమేజ్‌లు, ప్యాకేజీ కాష్‌లను సాధారణ read-only నిల్వ ద్వారా అందించవచ్చు. ఇది పదే పదే డౌన్‌లోడ్‌లను, sandbox ల మధ్య అనవసర నకిలీని తగ్గిస్తుంది.
ఏజెంట్ సొంత ఫైళ్లు, సేవ్ చేసిన పని ఒక శాశ్వత వర్క్‌స్పేస్‌గా ఏర్పడతాయి. ఏజెంట్ రేపు లేదా అంతర్లీన కంప్యూట్ వాతావరణం మారిన తర్వాత కొనసాగినప్పుడు అందుబాటులో ఉండాల్సిన సమాచారం అదే. ఈ అవసరాల కోసం ఎన్‌క్రిప్ట్ చేసిన Hyperdisk నిల్వను వాడతామని, తగిన చోట షేర్డ్ వాల్యూమ్‌లు, Cloud Storage ఆధారిత యాక్సెస్ అందుబాటులో ఉంటాయని Google వివరిస్తుంది.
ఏ నిల్వ శ్రేణిలో ఏది ఉంటుంది
ఒక రకం డేటాను ఎంచుకుంటే Google ఆర్కిటెక్చర్ దాన్ని ఎక్కడ ఉంచుతుంది, ఎంతకాలం నిలవాలి, ఎందుకు అన్నది కనిపిస్తుంది.
Compiler అవుట్‌పుట్
ఇది ఎక్కడ ఉంటుంది
- శ్రేణి: వాడి పారేసే overlay.
- జీవితకాలం: ఎగ్జిక్యూషన్ సమయంలో ఉపయోగపడుతుంది.
- ఎందుకు: తాత్కాలిక లాగ్‌లు, బిల్డ్ ఆర్టిఫాక్ట్‌లు, ఆపరేటింగ్-సిస్టమ్ మార్పులకు దీర్ఘకాలిక నిలుపుదల అవసరం లేకపోవచ్చు.
దీనికి అవసరం లేనివి
- దీర్ఘకాలిక నిలుపుదల.
Python runtime, toolchains
ఇది ఎక్కడ ఉంటుంది
- శ్రేణి: షేర్డ్ read-only నిల్వ.
- పరిధి: అనేక sandbox లకు ఉమ్మడి.
- ఎందుకు: షేర్డ్ టూల్స్, బేస్ ఇమేజ్‌లు పదే పదే డౌన్‌లోడ్‌లను, అనవసర నకిలీని తగ్గిస్తాయి.
దీనికి అవసరం లేనివి
- ప్రతి sandbox కు ప్రత్యేక కాపీ.
ప్యాకేజీ కాష్
ఇది ఎక్కడ ఉంటుంది
- శ్రేణి: షేర్డ్ read-only నిల్వ.
- పరిధి: అనేక sandbox లకు ఉమ్మడి.
- ఎందుకు: సాధారణ నిల్వ ద్వారా అందించే ప్యాకేజీ కాష్‌లు పదే పదే డౌన్‌లోడ్‌లను తగ్గిస్తాయి.
దీనికి అవసరం లేనివి
- ప్రతి ఖాళీ ఏజెంట్‌కు సాంప్రదాయ, స్వతంత్రంగా కేటాయించిన డిస్క్.
రిపాజిటరీ మార్పులు
ఇది ఎక్కడ ఉంటుంది
- శ్రేణి: శాశ్వత వర్క్‌స్పేస్.
- జీవితకాలం: ఏజెంట్ రేపు లేదా అంతర్లీన కంప్యూట్ వాతావరణం మారిన తర్వాత కొనసాగినప్పుడు అందుబాటులో ఉండాలి.
- ఎందుకు: ఇవి ఏజెంట్ సొంత ఫైళ్లు, సేవ్ చేసిన పని. ఈ అవసరం కోసం ఎన్‌క్రిప్ట్ చేసిన Hyperdisk నిల్వను, తగిన చోట షేర్డ్ వాల్యూమ్‌లను, Cloud Storage ఆధారిత యాక్సెస్‌ను Google వివరిస్తుంది.
దీనికి అవసరం లేనివి
- తాత్కాలిక స్థితితో పాటు పారవేయడం.
Google మూడు నిల్వ రకాలను వేరు చేస్తుంది. ప్రొడక్షన్ వర్క్‌లోడ్‌ల కోసం నిర్వహించే సర్వీస్‌పై ఆధారపడే ముందు కస్టమర్లకు డాక్యుమెంట్ చేసిన రికవరీ, స్థిరత్వ హామీలు ఇంకా అవసరం.
ఆ విభజన ఒక సాధారణ ఆర్కిటెక్చర్ తప్పును నివారిస్తుంది, అంటే డెవలప్‌మెంట్ వాతావరణం సృష్టించిన ప్రతి బైట్‌ను సమానంగా ముఖ్యమైనదిగా పరిగణించడం. అంతర్లీన సాఫ్ట్‌వేర్‌లో చాలా భాగం ఒకేలా లేదా తాత్కాలికంగా ఉన్నప్పుడు, ప్రతి ఖాళీ ఏజెంట్‌కు స్వతంత్రంగా కేటాయించిన సాంప్రదాయ డిస్క్‌ను జతచేయడాన్ని కూడా ఇది తప్పిస్తుంది. host లు శాశ్వత స్థానిక స్థితిని ఉంచుకోవు కాబట్టి, ఏజెంట్ వర్క్‌స్పేస్ దాని కమాండ్‌లు చివరిగా నడిచిన నిర్దిష్ట host కు ముడిపడి ఉండదు.
ఈ ఆర్కిటెక్చర్ శాశ్వత వర్క్‌స్పేస్ డేటాను checkpoint చేసిన runtime స్థితితో కలుపుతుంది, అయితే ప్రొడక్షన్ వర్క్‌లోడ్‌ల కోసం నిర్వహించే సర్వీస్‌పై ఆధారపడే ముందు కస్టమర్లకు డాక్యుమెంట్ చేసిన రికవరీ, స్థిరత్వ హామీలు ఇంకా అవసరం.
credentials నమ్మలేని sandbox బయటే ఉంటాయి
శాశ్వత sandbox మరో సవాలును సృష్టిస్తుంది. ఒక వాతావరణం ఎంత ఎక్కువ కాలం ఉంటే, శత్రు సూచనలు, బలహీనమైన dependencies లేదా రాజీపడిన టూల్స్‌ను ఎదుర్కొనే అవకాశాలు అంత ఎక్కువ. guest లోపల ఉన్న సాఫ్ట్‌వేర్ root స్థాయి యాక్సెస్‌తో కూడా రాజీపడవచ్చనే ఊహతో Google డిజైన్ రూపొందింది.
కాబట్టి ఈ ఆర్కిటెక్చర్ దీర్ఘకాలిక యూజర్ credentials ను, OAuth refresh tokens ను, క్లౌడ్ service-account కీలను sandbox లోపల ఉంచకుండా ఉంటుంది. ప్రతి microVM కి SPIFFE ఆధారంగా తాత్కాలిక workload identity ఇవ్వబడుతుంది. ఆ ఐడెంటిటీ ఏ sandbox నుంచి అభ్యర్థన వచ్చిందో నిర్ధారిస్తుంది, కానీ అది స్వయంగా ఏ backend సర్వీస్‌కూ అపరిమిత యాక్సెస్ ఇవ్వదు.
నెట్‌వర్క్ మార్గం ఆ తేడా చుట్టూ రూపొందించబడింది. sandbox కి సాధారణ బాహ్య నెట్‌వర్క్ ఇంటర్‌ఫేస్ లేదా నేరుగా VPC యాక్సెస్ ఉండదు. అభ్యర్థనలు పాయింట్-టు-పాయింట్ virtio-vsock ఛానెల్ ద్వారా బయటకు వెళ్లి, స్థానిక mediation proxy గుండా వెళ్లి, బాహ్య Agent Gateway కు చేరతాయి.
గేట్‌వే, బయటికి వెళ్లే యాక్సెస్ విధానాలను వర్తింపజేసే ముందు sandbox ఐడెంటిటీని, node ఐడెంటిటీని (host attestation మద్దతుతో), సంబంధిత యూజర్ delegation ను ధృవీకరిస్తుంది. ఆమోదించిన గమ్యస్థానానికి, గేట్‌వే అవసరమైన backend credential ను ఆ credential ను sandbox కు తిరిగి ఇవ్వకుండానే బయటికి వెళ్లే అభ్యర్థనకు జతచేయగలదు.
ఆమోదించిన ఒక డాక్యుమెంట్‌ను చదవమని అడిగిన ఎంటర్‌ప్రైజ్ ఏజెంట్‌ను ఊహించండి. sandbox ఆ డాక్యుమెంట్‌ను అభ్యర్థించవచ్చు, కానీ అధికార నిర్ణయం ఏజెంట్ టూల్స్‌ను నడిపే వాతావరణం బయట జరుగుతుంది, అభ్యర్థన యూజర్ delegated అనుమతులను, ఆ వనరును నియంత్రించే విధానాన్ని తృప్తి పరచాలి. భద్రతా సరిహద్దు అంటే ఏజెంట్‌కు చెల్లుబాటయ్యే ఐడెంటిటీ ఉండటం మాత్రమే కాదు. ఐడెంటిటీ, delegation, అధికారం వేర్వేరుగా మూల్యాంకనం కావడమే.
Google విస్తృత డిజైన్‌లో యూజర్ ఐడెంటిటీ, delegated-agent ఐడెంటిటీ, స్వల్పకాలిక workload ఐడెంటిటీ, ఏజెంట్ సొంత workforce ఐడెంటిటీ ఉన్నాయి. ఇవి పరస్పరం మార్చుకోగల నాలుగు credentials కావు, ఎందుకంటే అవి వేర్వేరు సంబంధాలను సూచిస్తాయి: పనిని ఎవరు ప్రారంభించారు, ఏ అధికారం delegate చేయబడింది, ఏ ఎగ్జిక్యూషన్ వాతావరణం అభ్యర్థనను పంపింది, ఏజెంట్‌కు స్వతంత్రంగా నిర్వహించే సంస్థాగత ఐడెంటిటీ ఉందా.
| ఐడెంటిటీ | ఇది సూచించే సంబంధం |
|---|---|
| యూజర్ ఐడెంటిటీ | పనిని ఎవరు ప్రారంభించారు |
| Delegated-agent ఐడెంటిటీ | ఏ అధికారం delegate చేయబడింది |
| స్వల్పకాలిక workload ఐడెంటిటీ | అభ్యర్థనను ఏ ఎగ్జిక్యూషన్ వాతావరణం పంపింది, అయితే అది స్వయంగా ఏ backend సర్వీస్‌కూ అపరిమిత యాక్సెస్ ఇవ్వదు |
| ఏజెంట్ workforce ఐడెంటిటీ | ఏజెంట్‌కు స్వతంత్రంగా నిర్వహించే సంస్థాగత ఐడెంటిటీ ఉందా |
రాజీపడిన sandbox నుంచి పునర్వినియోగించగల credentials ను నేరుగా దొంగిలించే ప్రమాదాన్ని ఈ డిజైన్ తగ్గిస్తుంది. అధికారం ఉన్న ఇంటర్‌ఫేస్ ద్వారా దుర్వినియోగమయ్యే అవకాశాన్ని అది తొలగించదు, ఎందుకంటే దారి తప్పిన ఏజెంట్ ఇంకా అనుచితమైన చర్యను అభ్యర్థించవచ్చు, కాబట్టి గేట్‌వే అనుమతుల తనిఖీలు, కస్టమర్ delegation పరిధి కీలకంగానే ఉంటాయి.
Google వివరించే సరిహద్దుల గురించి TechiesJournal భావనాత్మక డయాగ్రామ్, అధికారిక Google Cloud డయాగ్రామ్ కాదు.
చిత్రం 2 టెక్స్ట్ రూపం
- యూజర్, వారి delegated అధికారం నమ్మకమైన ఏజెంట్ harness ద్వారా పనిని ప్రారంభిస్తాయి.
- harness isolated microVM sandbox కు టూల్ అభ్యర్థనలను పంపి ఎగ్జిక్యూషన్ ఫలితాలను అందుకుంటుంది.
- sandbox శాశ్వత ఫైళ్లను శాశ్వత వర్క్‌స్పేస్‌తో మార్చుకుంటుంది.
- sandbox checkpoint, షేర్డ్ బేస్ స్థితికి నిలిపివేయబడి, అక్కడి నుంచి పునరుద్ధరించబడుతుంది.
- బయటికి వెళ్లే అభ్యర్థనలు sandbox నుంచి virtio-vsock ద్వారా mediation proxy కి వెళ్తాయి, అది వాటిని Agent Gateway కు పంపుతుంది.
- Agent Gateway ఐడెంటిటీ, పాలసీని వర్తింపజేసి, యూజర్ delegated అధికారాన్ని అధికార సందర్భంగా వాడి, ఆమోదించిన అభ్యర్థనలను ఎంటర్‌ప్రైజ్, క్లౌడ్ సర్వీస్‌లకు పంపుతుంది.
ఆమోదించిన డాక్యుమెంట్‌ను చదవడం, దశలవారీగా
ఆమోదించిన ఒక డాక్యుమెంట్‌ను చదవమని అడిగిన ఎంటర్‌ప్రైజ్ ఏజెంట్‌ను అనుసరించండి. ఒక దశను ఎంచుకుంటే ఏమి తనిఖీ చేయబడుతుంది లేదా ఏమి జరుగుతుంది, sandbox కు ఏమి లేదు అన్నది కనిపిస్తుంది.
1. అభ్యర్థన
- 1Sandbox అభ్యర్థన (ప్రస్తుత దశ)
- 2virtio-vsock
- 3Mediation proxy
- 4Agent Gateway
- 5Credential జత చేయడం
- 6సర్వీస్
ఏమి తనిఖీ అవుతుంది లేదా ఏమి జరుగుతుంది
- sandbox ఆమోదించిన డాక్యుమెంట్‌ను అభ్యర్థిస్తుంది.
- దాని తాత్కాలిక SPIFFE workload ఐడెంటిటీ, అభ్యర్థన ఏ sandbox నుంచి వచ్చిందో నిర్ధారిస్తుంది.
sandbox కు లేనివి లేదా చేయనివి
- దీర్ఘకాలిక యూజర్ credentials, OAuth refresh tokens లేదా క్లౌడ్ service-account కీలు.
- ఏ backend సర్వీస్‌కైనా అపరిమిత యాక్సెస్, ఎందుకంటే workload ఐడెంటిటీ స్వయంగా దాన్ని ఇవ్వదు.
2. virtio-vsock
- 1Sandbox అభ్యర్థన
- 2virtio-vsock (ప్రస్తుత దశ)
- 3Mediation proxy
- 4Agent Gateway
- 5Credential జత చేయడం
- 6సర్వీస్
ఏమి తనిఖీ అవుతుంది లేదా ఏమి జరుగుతుంది
- అభ్యర్థన పాయింట్-టు-పాయింట్ virtio-vsock ఛానెల్ ద్వారా బయటకు వెళ్తుంది.
sandbox కు లేనివి లేదా చేయనివి
- సాధారణ బాహ్య నెట్‌వర్క్ ఇంటర్‌ఫేస్.
- నేరుగా VPC యాక్సెస్.
3. Mediation proxy
- 1Sandbox అభ్యర్థన
- 2virtio-vsock
- 3Mediation proxy (ప్రస్తుత దశ)
- 4Agent Gateway
- 5Credential జత చేయడం
- 6సర్వీస్
ఏమి తనిఖీ అవుతుంది లేదా ఏమి జరుగుతుంది
- అభ్యర్థన స్థానిక mediation proxy గుండా వెళ్తుంది.
- ప్రాక్సీ దాన్ని బాహ్య Agent Gateway కు అందిస్తుంది.
sandbox కు లేనివి లేదా చేయనివి
- sandbox నుంచి సర్వీస్‌కు నేరుగా మార్గం.
4. Agent Gateway
- 1Sandbox అభ్యర్థన
- 2virtio-vsock
- 3Mediation proxy
- 4Agent Gateway (ప్రస్తుత దశ)
- 5Credential జత చేయడం
- 6సర్వీస్
ఏమి తనిఖీ అవుతుంది లేదా ఏమి జరుగుతుంది
- గేట్‌వే sandbox ఐడెంటిటీని, node ఐడెంటిటీని (host attestation మద్దతుతో), సంబంధిత యూజర్ delegation ను ధృవీకరిస్తుంది.
- తర్వాత బయటికి వెళ్లే యాక్సెస్ విధానాలను వర్తింపజేస్తుంది, కాబట్టి అధికార నిర్ణయం ఏజెంట్ టూల్స్‌ను నడిపే వాతావరణం బయట జరుగుతుంది.
sandbox కు లేనివి లేదా చేయనివి
- ఐడెంటిటీ మాత్రమే ఆధారంగా తీసుకునే నిర్ణయం, ఎందుకంటే ఐడెంటిటీ, delegation, అధికారం వేర్వేరుగా మూల్యాంకనం అవుతాయి.
5. Credential జత చేయడం
- 1Sandbox అభ్యర్థన
- 2virtio-vsock
- 3Mediation proxy
- 4Agent Gateway
- 5Credential జత చేయడం (ప్రస్తుత దశ)
- 6సర్వీస్
ఏమి తనిఖీ అవుతుంది లేదా ఏమి జరుగుతుంది
- ఆమోదించిన గమ్యస్థానానికి, గేట్‌వే అవసరమైన backend credential ను బయటికి వెళ్లే అభ్యర్థనకు జతచేయగలదు.
sandbox కు లేనివి లేదా చేయనివి
- credential sandbox కు తిరిగి ఇవ్వబడదు.
6. సర్వీస్
- 1Sandbox అభ్యర్థన
- 2virtio-vsock
- 3Mediation proxy
- 4Agent Gateway
- 5Credential జత చేయడం
- 6సర్వీస్ (ప్రస్తుత దశ)
ఏమి తనిఖీ అవుతుంది లేదా ఏమి జరుగుతుంది
- ఆమోదించిన అభ్యర్థన ఎంటర్‌ప్రైజ్ లేదా క్లౌడ్ సర్వీస్‌కు చేరుతుంది.
sandbox కు లేనివి లేదా చేయనివి
- అధికారం ఉన్నా దారి తప్పిన అభ్యర్థనకు రక్షణ, ఎందుకంటే అది గేట్‌వే అనుమతుల తనిఖీలు, delegation పరిధిపై ఆధారపడి ఉంటుంది.
ప్రతి దశలోనూ sandbox ఎప్పుడూ backend credential ను కలిగి ఉండదు. అధికారం ఉన్న అభ్యర్థన దారి తప్పినా హానికరం కావచ్చు, కాబట్టి గేట్‌వే అనుమతుల తనిఖీలు, కస్టమర్ delegation పరిధి కీలకంగానే ఉంటాయి.
గ్లోబల్ షెడ్యూలింగ్ వేర్వేరు రకాల ఏజెంట్ల మధ్య సామర్థ్యాన్ని పంచుతుంది
ఖాళీ sandbox లను నిలిపివేయడం ఒక ఏజెంట్ సెషన్‌లోని వనరుల వినియోగాన్ని పరిష్కరిస్తుంది. వేర్వేరు రకాల ఏజెంట్లు వేర్వేరు సమయాల్లో కంప్యూట్ సామర్థ్యాన్ని కోరడం వల్ల ఒక పెద్ద షెడ్యూలింగ్ సవాలు కూడా ఉందని Google వివరిస్తుంది. కన్స్యూమర్ అసిస్టెంట్లు, బిజినెస్ ఏజెంట్లు, ఎవాల్యుయేషన్ వర్క్‌లోడ్‌లు ఒకేసారి గరిష్ట డిమాండ్‌కు చేరాలని లేదు.
ఇంటరాక్టివ్ యూజర్లు వేగవంతమైన ప్రతిస్పందనలను ఆశిస్తారు, కొన్ని షెడ్యూల్ చేసిన జాబ్‌లు, ఎవాల్యుయేషన్‌లు, reinforcement-learning వర్క్‌లోడ్‌లు ఆలస్యమైన ఎగ్జిక్యూషన్‌ను తట్టుకోగలవు. అందుబాటులో ఉన్న సామర్థ్యం, భౌగోళిక పరిమితులు, కంప్లయన్స్ అవసరాలు, వర్క్‌లోడ్ ప్రాధాన్యతను పరిగణనలోకి తీసుకునే గ్లోబల్ షెడ్యూలింగ్‌తో కూడిన షేర్డ్ ఇన్‌ఫ్రాస్ట్రక్చర్ పూల్‌ను Google డిజైన్ వాడుతుంది. ఇంటరాక్టివ్ డిమాండ్ పెరిగినప్పుడు తక్కువ ప్రాధాన్యత గల ఎవాల్యుయేషన్ పని సామర్థ్యాన్ని వదులుకోవచ్చు, డిమాండ్ తగ్గినప్పుడు వాయిదా పడిన జాబ్‌లు లేకపోతే ఖాళీగా ఉండే వనరులను వాడుకోవచ్చు.
ఇది checkpointing నుంచి వేరైన సమర్థత యంత్రాంగం. checkpointing కాలక్రమంలో ఎన్ని శాశ్వత సెషన్‌లు క్రియాశీల కంప్యూట్ సామర్థ్యాన్ని పంచుకోగలవో పెంచుతుంది, ఏ వర్క్‌లోడ్‌లకు ఆ సామర్థ్యం ఎప్పుడు దక్కాలో షెడ్యూలింగ్ నిర్ణయిస్తుంది.
పెద్ద అంతర్గత సముదాయానికి రెండూ ప్రయోజనం ఇస్తాయి కాబట్టి ఈ తేడా ముఖ్యం. చిన్న డిప్లాయ్‌మెంట్‌లకు అదే షెడ్యూలింగ్ సంక్లిష్టత తక్కువ అదనపు విలువను ఇవ్వవచ్చు, కానీ వేలాది ఇంటరాక్టివ్ సెషన్‌లు, సమాంతర ఎవాల్యుయేషన్ టాస్క్‌లున్న వర్క్‌లోడ్‌లకు అది సామర్థ్య ప్రణాళికను, సర్వీస్ ప్రతిస్పందనను ప్రభావితం చేయగలదు. నిర్వహించే సర్వీస్ ద్వారా ఈ ప్రయోజనంలో ఎంత భాగం అందుబాటులోకి వస్తుందో లెక్కించడానికి సరిపడా బాహ్య కస్టమర్ ఆపరేటింగ్ డేటాను Google ఇంకా ప్రచురించలేదు.
Agent Substrate Kubernetes పై సంబంధిత సమస్యను పరిష్కరిస్తుంది
Agent Compute Engine ను Google ముందటి Agent Substrate కార్యక్రమం నుంచి కూడా వేరు చేసి చూడాలి. September 15 నాడు, Kubernetes ఆధారిత వాతావరణాల కోసం Google Agent Substrate ను ప్రకటించింది. ఇది ఐసోలేటెడ్ sandbox లు, వేగవంతమైన నిలిపివేత, పునరుద్ధరణ, సాధారణ Kubernetes Pod షెడ్యూలింగ్ మార్గం వెలుపల లైఫ్‌సైకిల్ నిర్వహణ వంటి యంత్రాంగాలను వాడుతూ ఏజెంట్-ఆధారిత ఎగ్జిక్యూషన్ లేయర్‌ను అందిస్తుంది.
ఈ ఆర్కిటెక్చర్ ఎంపిక ఒక నిర్దిష్ట సమస్యను పరిష్కరిస్తుంది. Kubernetes మెషీన్లను, అప్లికేషన్ వర్క్‌లోడ్‌లను నిర్వహించడంలో సమర్థమైనది, కానీ ప్రతి చిన్న ఏజెంట్ టూల్ కాల్ కోసం దాని సాధారణ-ప్రయోజన control plane ద్వారా Pod ను సృష్టించడం లేదా పునఃప్రారంభించడం అనవసర ఆలస్యాన్ని తెచ్చిపెట్టవచ్చు. Agent Substrate నోడ్ నిర్వహణ, ఆటోస్కేలింగ్, సముదాయ విశ్వసనీయతను Kubernetes వద్దే ఉంచి, తరచుగా జరిగే sandbox యాక్టివేషన్‌ను ప్రత్యేక ఎగ్జిక్యూషన్ లేయర్ ద్వారా నిర్వహిస్తుంది.
పునఃప్రారంభ ఆపరేషన్‌లకు 500 మిల్లీసెకన్ల కంటే తక్కువ సమయాన్ని, సంప్రదాయ container runtime ల కంటే పది రెట్లు వరకు ఎక్కువ కంప్యూట్ సాంద్రతను Google నివేదిస్తుంది, ఇవి Google సొంత నివేదిత పరీక్షల ప్రకారం. అవి Agent Substrate ఫలితాలు, Agent Compute Engine కు స్వతంత్రంగా ధృవీకరించిన బెంచ్‌మార్క్‌లు కావు. Google September రిలీజ్ నోట్స్ ప్రకారం, Agent Substrate మూల్యాంకనం, ప్రొడక్షన్ కాని వర్క్‌లోడ్‌ల కోసం అందుబాటులో ఉంది, ప్రొడక్షన్ మద్దతు పరిమిత allowlist కార్యక్రమం ద్వారా లభిస్తుంది.
Agent Compute Engine ఒక భిన్నమైన కార్యాచరణ నమూనాను లక్ష్యంగా చేసుకుంటుంది, అందులో అంతర్లీన sandbox సముదాయాన్ని Google సర్వీస్‌గా నిర్వహిస్తుంది, కస్టమర్లు తమ ఎగ్జిక్యూషన్ ఇమేజ్‌లను, ఐడెంటిటీలను, నెట్‌వర్కింగ్‌ను, లైఫ్‌సైకిల్ అవసరాలను కాన్ఫిగర్ చేస్తారు. కాబట్టి ఆ తేడా కొంతవరకు బాధ్యతకు సంబంధించినది. సొంత Kubernetes వాతావరణాన్ని నడిపే ప్లాట్‌ఫాం టీమ్ ఎగ్జిక్యూషన్ లేయర్‌పై నియంత్రణ కోరుకోవచ్చు, sandbox మౌలిక సదుపాయాలను నిర్వహించడానికి ఇష్టపడని సంస్థ, నిర్వహించే సర్వీస్ సామర్థ్యాలు, ఆపరేటింగ్ పరిస్థితులు మూల్యాంకనానికి అందుబాటులోకి వచ్చాక దాన్ని ఆకర్షణీయంగా భావించవచ్చు.
| అంశం | Agent Compute Engine | Agent Substrate |
|---|---|---|
| సముదాయాన్ని ఎవరు నడుపుతారు | అంతర్లీన sandbox సముదాయాన్ని Google సర్వీస్‌గా నిర్వహిస్తుంది, కస్టమర్లు ఎగ్జిక్యూషన్ ఇమేజ్‌లను, ఐడెంటిటీలను, నెట్‌వర్కింగ్‌ను, లైఫ్‌సైకిల్ అవసరాలను కాన్ఫిగర్ చేస్తారు | Kubernetes ఆధారిత వాతావరణాలు, ఇందులో నోడ్ నిర్వహణ, ఆటోస్కేలింగ్, సముదాయ విశ్వసనీయత Kubernetes వద్దే ఉంటాయి |
| ఎగ్జిక్యూషన్ లేయర్ | checkpoint ఆధారిత నిలిపివేత, పునరుద్ధరణతో కూడిన ప్రత్యేక microVM sandbox లు | సాధారణ Kubernetes Pod షెడ్యూలింగ్ మార్గం వెలుపల ఏజెంట్-ఆధారిత ఎగ్జిక్యూషన్ లేయర్, ఐసోలేటెడ్ sandbox లు, వేగవంతమైన నిలిపివేత, పునరుద్ధరణతో |
| లభ్యత | Gemini, Antigravity, ఏజెంట్ ఎవాల్యుయేషన్ కోసం Google అంతర్గతంగా వాడుతోంది, బయటి కస్టమర్ ప్రివ్యూ రాబోయే నెలల్లో ప్రణాళికలో ఉంది | Google September రిలీజ్ నోట్స్ ప్రకారం, మూల్యాంకనం, ప్రొడక్షన్ కాని వర్క్‌లోడ్‌ల కోసం అందుబాటులో ఉంది, ప్రొడక్షన్ మద్దతు పరిమిత allowlist కార్యక్రమం ద్వారా |
| Google నివేదించిన గణాంకాలు | Agent Compute Engine కోసం ఈ వ్యాసంలో ఏవీ ఉదహరించలేదు | 500 మిల్లీసెకన్ల కంటే తక్కువ సమయంలో resume, సంప్రదాయ container runtime ల కంటే పది రెట్లు వరకు ఎక్కువ కంప్యూట్ సాంద్రత, Google సొంత నివేదిత పరీక్షల ప్రకారం. Agent Substrate కోసం Google నివేదించినవి, ధృవీకరించలేదు, Agent Compute Engine బెంచ్‌మార్క్ కావు |
ఈ ప్రకటన ఇప్పటికే ఉన్న కంప్యూట్‌ను వాడుకలో లేనిదిగా చేయదు
ఈ ప్రకటన virtual machine లను, container లను లేదా serverless కంప్యూటింగ్‌ను వాడుకలో లేనివిగా చేయదు. API కాల్స్ చేసి, టాస్క్ స్థితిని డేటాబేస్‌లో నిల్వ చేసి, చిన్న జాబ్‌లు నడిపే సరళమైన ఏజెంట్ ఇప్పటికే ఉన్న మౌలిక సదుపాయాలకు బాగా సరిపోవచ్చు.
వాతావరణమే పరస్పర చర్యల మధ్య నిలవాల్సినప్పుడు, బలమైన ఐసోలేషన్ అవసరమైన నమ్మలేని కోడ్‌ను ఏజెంట్లు నడిపినప్పుడు, లేదా పెద్ద సంఖ్యలో స్వతంత్ర సెషన్‌లు పదే పదే నిలిచి కొనసాగినప్పుడు ప్రత్యేక ఎగ్జిక్యూషన్ ప్లాట్‌ఫాంలు ఎక్కువ సందర్భోచితమవుతాయి. కాబట్టి ఆర్కిటెక్చర్ పోలిక, స్థితిని, ఐసోలేషన్‌ను నిర్వహించే ఖర్చుకు వస్తుంది.
సంప్రదాయ container ప్లాట్‌ఫాం, రీస్టార్ట్ తర్వాత అప్లికేషన్లు runtime స్థితిని పునర్నిర్మించుకోవాలని కోరవచ్చు. శాశ్వత VM ఆ పునర్నిర్మాణాన్ని తప్పించగలదు కానీ మధ్యమధ్య పనిచేసే వర్క్‌లోడ్‌కు అవసరమైన దానికంటే ఎక్కువ వనరులను రిజర్వ్ చేయవచ్చు. ప్రత్యేకంగా రూపొందించిన sandbox runtime, క్రియాశీల కాలాల మధ్య వనరులను విడుదల చేస్తూనే ఎగ్జిక్యూషన్ స్థితిని భద్రపరచడానికి ప్రయత్నిస్తుంది.
| ఎంపిక | స్థితి నిర్వహణ, పునఃప్రారంభ ఖర్చు | ఖాళీగా ఉన్నప్పుడు వనరులు | వివరించిన ఐసోలేషన్ |
|---|---|---|---|
| Container ప్లాట్‌ఫాం | రీస్టార్ట్ తర్వాత అప్లికేషన్లు runtime స్థితిని పునర్నిర్మించుకోవాల్సి రావచ్చు | వ్యాసంలో పోల్చలేదు | సాధారణ container లు సాధారణంగా host ఆపరేటింగ్-సిస్టమ్ kernel ను పంచుకుంటాయి |
| శాశ్వత virtual machine | runtime స్థితిని పునర్నిర్మించడాన్ని తప్పించగలదు | మధ్యమధ్య పనిచేసే వర్క్‌లోడ్‌కు అవసరమైన దానికంటే ఎక్కువ వనరులను రిజర్వ్ చేయవచ్చు | వ్యాసంలో పోల్చలేదు |
| ప్రత్యేకంగా రూపొందించిన sandbox runtime | ఎగ్జిక్యూషన్ స్థితిని భద్రపరచడానికి ప్రయత్నిస్తుంది | క్రియాశీల కాలాల మధ్య వనరులను విడుదల చేయడానికి ప్రయత్నిస్తుంది | Agent Compute Engine microVM కి హార్డ్‌వేర్ వర్చువలైజేషన్ సరిహద్దు వెనుక దాని సొంత guest kernel ఉంటుంది |
ఆ ట్రేడ్-ఆఫ్‌లను పరిష్కరించడానికి ఉద్దేశించిన ఒక అంతర్గత ఆర్కిటెక్చర్‌ను Google ప్రదర్శించింది. కస్టమర్ వైపు పూర్తి కార్యాచరణ చిత్రాన్ని అది ఇంకా బహిరంగంగా నిర్ధారించలేదు. నిర్వహించే Agent Compute Engine సర్వీస్ ప్రివ్యూ కోసం లక్ష్యంగా ఉంది, ధర, ప్రాంతీయ కవరేజ్, కోటాలు, కస్టమర్-ముఖ హామీలతో కూడిన రికవరీ, పోల్చదగిన వర్క్‌లోడ్ బెంచ్‌మార్క్‌లు ఇంకా ముఖ్యమైన తెలియని అంశాలు.
ఈ ఆర్కిటెక్చర్‌ను ఎంచుకునే ముందు, ఇంజనీర్లు తమ ఏజెంట్లు వాస్తవంగా ఎంత తరచుగా పని చేస్తాయో, వాటి ప్రైవేట్ మెమరీ స్థితి ఎంత పెద్దదవుతుందో, ఏ ఫైళ్లకు నిలకడ అవసరమో, నిలిపిన టాస్క్‌లు ఎంత వేగంగా కొనసాగాలో, వారి ఎగ్జిక్యూషన్ నమూనాకు ఎంత స్థాయి ఐసోలేషన్ అవసరమో కొలవాలి. checkpoint చేసిన microVM వాతావరణాలు సరళమైన డిజైన్ కంటే అర్థవంతమైన ప్రయోజనాన్ని ఇస్తాయో లేదో ఆ కొలతలే నిర్ణయిస్తాయి.
ఏజెంట్లు వాస్తవంగా ఎలా నడుస్తాయనే దాని చుట్టూ Google ఇప్పటికే ఉన్న యంత్రాంగాలను సమన్వయం చేసింది
Agent Compute Engine లో ముఖ్యమైన పురోగతి, ఏదైనా ఒక కొత్త కంప్యూటింగ్ ప్రిమిటివ్‌ను ప్రవేశపెట్టడం కాదు. హార్డ్‌వేర్ వర్చువలైజేషన్, snapshot లు, copy-on-write మెమరీ, శాశ్వత డిస్క్‌లు, workload ఐడెంటిటీలు, సముదాయ షెడ్యూలింగ్ ఈ ప్రకటనకు ముందే ఉన్నాయి. స్వయంప్రతిపత్తి గల ఏజెంట్ల ఎగ్జిక్యూషన్ నమూనా చుట్టూ ఆ యంత్రాంగాలను సమన్వయంతో వాడటమే Google చేసిన కృషి.
ఈ ప్లాట్‌ఫాం ఏజెంట్ వర్క్‌స్పేస్‌ను శాశ్వతంగా, దాని క్రియాశీల కంప్యూటింగ్ వనరులను తాత్కాలికంగా, బయటి సిస్టమ్‌లను యాక్సెస్ చేసే అనుమతిని దాని ఎగ్జిక్యూషన్ వాతావరణం బయట అమలయ్యే అంశంగా పరిగణిస్తుంది. ఏజెంట్ సముదాయాలు పెరిగే కొద్దీ తలెత్తే నిజమైన కార్యాచరణ సమస్యలను ఈ కలయిక పరిష్కరిస్తుంది కాబట్టి దీన్ని పరిశీలించడం విలువైనది. నిర్వహించే సర్వీస్ ఇతర సంస్థలకు సరైన ఎంపిక అవుతుందో లేదో దాని చివరి లభ్యత, పనితీరు, ఖర్చు, కార్యాచరణ హామీలపై ఆధారపడి ఉంటుంది.
| అంశం | స్థితి | మూలం |
|---|---|---|
| Gemini, Antigravity, ఏజెంట్-ఎవాల్యుయేషన్ వ్యవస్థల అంతర్గత వాడకం | Google పేర్కొంది | Google ఇంజనీరింగ్ వ్యాసం |
| బయటి కస్టమర్ల కోసం నిర్వహించే సర్వీస్ | ప్రివ్యూ రాబోయే నెలల్లో ప్రణాళికలో ఉంది, ఇంకా అందుబాటులో లేదు | Google ఇంజనీరింగ్ వ్యాసం, ప్రకటన |
| యంత్రాంగాలు: microVM ఐసోలేషన్, checkpointing, షేర్డ్ బేస్ మెమరీ, నిల్వ శ్రేణులు, గేట్‌వే ద్వారా credentials, గ్లోబల్ షెడ్యూలింగ్ | Google తన డిజైన్‌గా పేర్కొంది | Google ఇంజనీరింగ్ వ్యాసం |
| ధర | పేర్కొనలేదు | సమీక్షించిన Google మూలాల్లో ఇవ్వలేదు |
| ప్రాంతాలు, కోటాలు | పేర్కొనలేదు | సమీక్షించిన Google మూలాల్లో ఇవ్వలేదు |
| కస్టమర్-ముఖ రికవరీ, స్థిరత్వ హామీలు | ఇంకా బహిరంగంగా నిర్ధారించలేదు | మూలాల సమీక్ష, October 26, 2026 |
| పోల్చదగిన వర్క్‌లోడ్ బెంచ్‌మార్క్‌లు | ఇంకా బహిరంగంగా నిర్ధారించలేదు | మూలాల సమీక్ష, October 26, 2026 |
| నిలిపివేసినప్పుడు బ్యాక్‌గ్రౌండ్ టాస్క్‌లు, లైవ్ కనెక్షన్‌లు | నిర్ధారించలేదు, ఎందుకంటే క్రియాశీల కమాండ్‌లు లేదా బ్యాక్‌గ్రౌండ్ టాస్క్‌లు ఏవీ నడవనప్పుడు నిలిపివేత జరుగుతుందని Google వివరిస్తుంది | Google ఇంజనీరింగ్ వ్యాసం, మూలాల సమీక్ష, October 26, 2026 |
ఇంజనీరింగ్ మార్పు అంటే ఏజెంట్లకు పూర్తిగా కొత్త రకం కంప్యూటర్ అవసరమని కాదు. ఏజెంట్ కంప్యూటర్ జీవితకాలాన్ని, దాన్ని నడిపే కంప్యూట్ వనరుల జీవితకాలం కంటే భిన్నంగా క్లౌడ్ మౌలిక సదుపాయాలు నిర్వహించాల్సి రావచ్చు అన్నదే.
మరింత లోతుగా
మూలాల సమీక్ష: October 26, 2026. Google అంతర్గత ఆర్కిటెక్చర్, పనితీరు వివరణలు Google కు ఆపాదించబడ్డాయి. కస్టమర్-ప్రివ్యూ పనితీరు, కార్యాచరణ హామీలు స్వతంత్రంగా ధృవీకరించబడలేదు.
Google ప్రకటనలు, డాక్యుమెంటేషన్
- Inside Agent Compute Engine: Building the Compute Foundation for the Agentic Era, Ramanathan Venkatapathy and Rohit Jnagal, Google Cloud, October 22, 2026, sandbox ఐసోలేషన్, workload ఐడెంటిటీలు, snapshotting, మెమరీ షేరింగ్, నిలకడ, షెడ్యూలింగ్‌కు ప్రాథమిక ఇంజనీరింగ్ మూలం.
- Introducing Agent Compute Engine and Expanded Agent Governance, Google Cloud, October 22, 2026, ఉత్పత్తి ప్రకటన, బయటి ప్రివ్యూ లభ్యత ప్రణాళిక.
- Agent Substrate brings high-density, scalable, trusted infrastructure to GKE, Alex Zakonov and Tim Hockin, Google Cloud, September 15, 2026, Kubernetes ఆధారిత ఏజెంట్ runtime ఆర్కిటెక్చర్, విక్రేత నివేదించిన పనితీరు ఫలితాలు.
- New feature release notes, Google Kubernetes Engine, September 11, 2026 ఎంట్రీ, Agent Substrate మూల్యాంకన లభ్యత, పరిమిత ప్రొడక్షన్ మద్దతు.
ఇప్పటికే ఉన్న ఐసోలేటెడ్ ఎగ్జిక్యూషన్ ఎంపికలు
- Azure Container Apps dynamic sessions, Microsoft Learn, AI రూపొందించిన, నమ్మలేని కోడ్ కోసం ఇప్పటికే ఉన్న ఐసోలేటెడ్ ఎగ్జిక్యూషన్ ఎంపికకు డాక్యుమెంటేషన్.
- Lambda execution environment lifecycle, AWS, serverless నమూనాలో ఎగ్జిక్యూషన్-వాతావరణ పునర్వినియోగాన్ని, నిలకడ పరిమితులను వివరించే డాక్యుమెంటేషన్.
ఈ వ్యాసం Google సొంత వివరణను, విక్రేత నివేదించిన ఫలితాలను, రచయిత విశ్లేషణను వేరు చేస్తుంది. చర్య తీసుకునే ముందు తదుపరి వెల్లడింపులను మళ్లీ తనిఖీ చేయాలి.
TechiesJournalలో సంబంధిత రచనలు
- AI ఏజెంట్లకు API కీలు కాదు, ప్రత్యేక గుర్తింపులు కావాలి, TechiesJournal, September 12, 2026, ఏజెంట్ ఐడెంటిటీ, delegated అనుమతులు చెల్లుబాటయ్యే credentials కలిగి ఉండటం కంటే ఎలా భిన్నమో వివరించే సంబంధిత నేపథ్యం.
- AI కోడింగ్ ఏజెంట్లు తమ సొంత మానిటరింగ్‌ను బలహీనపరిచినప్పుడు: నమోదైన రెండు సంఘటనలు, TechiesJournal, October 26, 2026, రక్షణలకు అవి పర్యవేక్షించే సాఫ్ట్‌వేర్ వెలుపల నియంత్రణలు ఎందుకు అవసరమో వివరించే తోడు వ్యాసం.
- AI ఏజెంట్లు తమ దారి తామే వెతుక్కున్నప్పుడు: హద్దులను నిర్ణయించేది ఎవరు?, TechiesJournal, October 15, 2026, AI ఏజెంట్‌లతో ప్రధాన సమస్య సామర్థ్యం కాదు అధికారమని, పరిమితులు ప్రాంప్ట్‌లలో కాకుండా వాతావరణంలో ఉండాలని వాదించే ఒక Perspective.