એન્જિનિયરોની એક ટીમે 'ફેલ-ક્લોઝ્ડ' (fail-closed) નેટવર્કિંગ લેયર રજૂ કર્યું છે જે સ્વાયત્ત AI એજન્ટોને સુસંગતતા ગુમાવ્યા વિના ક્લાઉડ સીમાઓ પર કામ કરવાની મંજૂરી આપે છે. આ પ્રોટોટાઇપે જાણીજોઈને ઉશ્કેરવામાં આવેલા 82 કેઓસ સાયકલ (chaos cycles) સામે ટકીને, સિંગલ-ઇફેક્ટ ઇવેન્ટ્સ માટે 100% સફળતાનો દર હાંસલ કર્યો અને પાવર કટ થાય ત્યારે પણ ડુપ્લીકેટ અપડેટ્સને દૂર કર્યા.
નવું કોઓર્ડિનેશન મોડલ શા માટે મહત્વનું છે
મલ્ટિપલ ક્લાઉડ પર લેંગ્વેજ-મોડલ-સંચાલિત એજન્ટોને તૈનાત કરવાથી એક નબળાઈ સામે આવી: જ્યારે નેટવર્ક પાર્ટિશન થાય અથવા સર્વિસ ક્વોટા સુધી પહોંચે ત્યારે સ્ટાન્ડર્ડ RPC કોલ્સ નિષ્ફળ જાય છે. તે ક્ષણોમાં, એજન્ટ કોઈ અપ્રમાણિત ધારણા પર કામ કરી શકે છે, જેનાથી શેર્ડ સ્ટેટ (shared state) બગડી શકે છે. નવું આર્કિટેક્ચર દરેક એક્શન માટે કોઈપણ ઘટક તેને સ્વીકારે તે પહેલાં ક્રિપ્ટોગ્રાફિક પુરાવો લાવવા માટે મજબૂર કરે છે, જે "ડિફોલ્ટ દ્વારા વિશ્વાસ" ને બદલે "માત્ર સાબિત થાય ત્યારે જ વિશ્વાસ" માં ફેરવે છે.
એજન્ટોને સિંકમાં રાખતા પાંચ ગવર્નન્સ નિયમો
- ટ્રાન્ઝેક્શનલ ઇન્જેસ્ટિયન (Transactional ingestion) – એટોમિસિટી (atomicity) ની ખાતરી કરવા માટે તમામ સ્ટેટ ફેરફારોને સિંગલ PostgreSQL ટ્રાન્ઝેક્શનમાં લપેટી દો.
- કેનોનિકલ એન્વલપ (Canonical envelope) – દરેક મેસેજ માટે ફિક્સ્ડ 10-ટપલ (10-tuple) ફોર્મેટનો ઉપયોગ કરો, જે પાર્સિંગ અને વેલિડેશનને ડિટરમિનિસ્ટિક બનાવે છે.
- ઓથોરિટી સેપરેશન (Authority separation) – એપ્લિકેશન કોડને Git માં રાખો જ્યારે ડેટાબેઝ માઇગ્રેશનનું વર્ઝનિંગ અલગ રીતે કરો, જેથી અકસ્માતે ક્રોસ-કન્ટેમિનેશન અટકાવી શકાય.
- ટાઇમ-બાઉન્ડ લોક્સ (Time-bound locks) – કોઈ કાર્ય પરના ક્લેમ્સને આપમેળે એક્સપાયર થવા દો, જેથી અટકેલો એજન્ટ પાઇપલાઇનને રોકી ન શકે.
- ફેલ-ક્લોઝ્ડ ડિફોલ્ટ (Fail-closed default) – વેરિફાઇ કરી શકાય તેવા પુરાવા વિનાના કોઈપણ ક્લેમને HOLD તરીકે માર્ક કરો, જેથી ડાઉનસ્ટ્રીમ એજન્ટો અંદાજ લગાવવાને બદલે રાહ જોવા માટે મજબૂર થાય.
આ નિયમો સાથે મળીને એક ઝીરો-ટ્રસ્ટ કોન્ટ્રાક્ટ બનાવે છે: જો તમે ક્રિપ્ટોગ્રાફિક રીતે સાબિત કરી શકતા નથી કે કોઈ એક્શન થઈ છે, તો સિસ્ટમ તેના પર કામ કરવાનો ઇનકાર કરે છે.
પુરાવો ધરાવતું 10-ટપલ એન્વલપ
ઇન્ટરનલ બસ પરના દરેક હેન્ડઓફમાં નીચેનાનો સમાવેશ થાય છે:
event_id– મૂળ ઇવેન્ટ માટે યુનિક આઇડેન્ટિફાયરeffect_id– વિનંતી કરવામાં આવેલા સ્ટેટ ફેરફારનો આઇડેન્ટિફાયરlog_id– ઓડિટ ટ્રેઇલ એન્ટ્રીનો સંદર્ભproducer_id– સોર્સ એજન્ટની ઓળખschema_version– વપરાતા મેસેજ સ્કીમાનું વર્ઝનsession_epoch– સત્રની અંદર ઓર્ડરિંગ માટે લોજિકલ ક્લોકdestination– ટાર્ગેટ એજન્ટ અથવા સર્વિસroute_status– વર્તમાન રાઉટિંગ સ્ટેટ (દા.ત., pending, held)issued_at– નિર્માણનો ટાઇમસ્ટેમ્પpayload_digest– પેલોડનો HMAC-સીલ કરેલ હેશ
આ ડાઇજેસ્ટ કોઈપણ ક્લાઉડ વર્કસ્પેસ ફોલ્ડરની બહાર સંગ્રહિત સિક્રેટ કીનો ઉપયોગ કરે છે, જે સુનિશ્ચિત કરે છે કે જો કોઈ કમ્પ્યુટ નોડ સાથે છેડછાડ કરવામાં આવી હોય, તો પણ તે માન્ય મેસેજ બનાવી શકશે નહીં.
તણાવ હેઠળ સિસ્ટમે કેવી રીતે કામ કર્યું
એન્જિનિયરોએ 82 કેઓસ સાયકલ ચલાવી હતી. તેના પરિણામો હતા:
- 100% સફળતા એ ઇવેન્ટ્સ માટે જેણે સિંગલ ઇફેક્ટ પેદા કરી; ટ્રાન્ઝેક્શન કાં તો સંપૂર્ણ રીતે કમિટ થયું અથવા ક્લીનલી રોલબેક થયું.
- પાવર કટ દરમિયાન ઝીરો ડુપ્લીકેટ ફેરફારો, જે પુષ્ટિ કરે છે કે ટ્રાન્ઝેક્શનલ બાઉન્ડરીએ આંશિક રાઇટ્સને અટકાવ્યા.
- ઝડપી લોક રિકવરી, ઓટોનોમસ ક્લીનઅપ એજન્ટોને કારણે જે એક્સપાયર થયેલા ક્લેમ્સ સ્કેન કરે છે અને માનવીય હસ્તક્ષેપ વિના તેમને રિલીઝ કરે છે.
આર્કિટેક્ટ્સ માટે વ્યવહારુ ટિપ્સ
- અન-ઓથેન્ટિકેટેડ વેબહુક્સને HMAC દ્વારા સીલ કરેલા લોગ્સ સાથે બદલો; આ સીલ 'ફેલ-ક્લોઝ્ડ' નિયમ દ્વારા જરૂરી ક્રિપ્ટોગ્રાફિક પુરાવા તરીકે કામ કરે છે.
- સિક્રેટ કીઝને એવા વોલ્ટમાં સ્ટોર કરો જે કોઈપણ કન્ટેનર અથવા VM ઇમેજની અંદર માઉન્ટ ન હોય.
- લાઇટવેઇટ એજન્ટો તૈનાત કરો જેનો એકમાત્ર હેતુ એક્સપાયર થયેલા લોક્સને પ્યોરજ (purge) કરવાનો છે; આ પ્રાથમિક એજન્ટ ક્રેશ થાય ત્યારે સિસ્ટમને અટકી જતી અટકાવે છે.
આગળ શું જોવું
આ અભિગમ HMAC કીઝની ગુપ્તતા પર આધારિત છે; તમારી સિક્રેટ કીઝને ક્લાઉડ વર્કસ્પેસ ફોલ્ડર્સની બહાર રાખો.
જો સમુદાય આ બે મોરચે કામ કરી શકે, તો 'ફેલ-ક્લોઝ્ડ' સ્વાયત્ત નેટવર્ક કોઈપણ મલ્ટી-એજન્ટ ડિપ્લોયમેન્ટ માટે ડિફોલ્ટ બની શકે છે જે સુસંગતતાના સિંગલ પોઈન્ટને સહન કરી શકતું નથી.