ஏஜெண்டுகளுக்கான பாதுகாப்பான டெலிவரி பைப்லைனை உருவாக்குதல்
பெரும்பாலான ஏஜென்ட் டெமோக்கள் ஒரு முக்கியமான கேள்வியைத் தவிர்க்கின்றன. உங்கள் சார்பாக ஒரு தன்னாட்சி அமைப்பு (autonomous system) விஷயங்களை அனுப்பும்போது, இரட்டிப்பாக அனுப்பாமல் அல்லது அங்கீகரிக்கப்படாத பணிகளை அனுப்பாமல் இருப்பதை எப்படி உறுதி செய்வது?
இரட்டிப்பாக அனுப்புவது (double-send) என்பது அரிதான பிழை அல்ல. ஒரு பணி நடந்து கொண்டிருக்கும்போது ஒரு worker செயலிழந்துவிட்டால், ஒரு சாதாரணக் வரிசையில் (queue) இது இயல்பாகவே நடக்கும் ஒரு செயலாகும். ஒரு worker ஒரு செய்தியை அனுப்பிவிட்டு, அது வெற்றிகரமாக முடிந்துவிட்டதாகப் பதிவு செய்வதற்கு முன்பே செயலிழந்துவிடுகிறது. இதனால் அந்தப் பணி தோல்வியடைந்துவிட்டதாகத் தற்காலிக அமைப்பு கருதி, புதிய worker-ஐ மீண்டும் முயற்சி செய்யச் சொல்கிறது. வாடிக்கையாளருக்கு இரண்டு மின்னஞ்சல்கள் செல்கின்றன, உங்களுக்கு ஒரு சப்போர்ட் டிக்கெட் (support ticket) கிடைக்கிறது.
ஒவ்வொரு செயலிழப்பையும் உங்களால் தடுக்க முடியாது. ஒரு செயல் மற்றும் அதன் பதிவு ஆகியவற்றிற்கு இடைப்பட்ட இடைவெளியில் ஏற்படும் செயலிழப்பிற்கு ஏற்ப நீங்கள் வடிவமைக்க வேண்டும்.
நிஜமான விளைவுகளை ஏற்படுத்தும் எந்தவொரு ஏஜென்ட் வெளியீட்டிற்கும் இந்த ஆறு நிலைகளைக் கொண்ட பைப்லைனைப் பயன்படுத்தவும்:
• Produce: ஏஜென்ட் முழுமையான ஆவணத்தை (artifact) உருவாக்குகிறது. இது இன்னும் எதையும் அனுப்பாது. • Persist: நோக்கத்தையும் ஆவணத்தையும் முதலில் நிலையான சேமிப்பகத்தில் (durable storage) எழுதவும். • Score: வெளியீட்டிற்கு ஒரு நம்பிக்கைப் புள்ளியை (confidence score) இணைக்கவும். • Review: குறைந்த நம்பிக்கைப் புள்ளிகள் கொண்ட விஷயங்களை ஒரு மனிதரிடம் ஒப்படைக்கவும். • Approve: 'fail-closed gate' முறையைப் பயன்படுத்தவும். ஒரு மனிதர் வெளிப்படையான அங்கீகாரம் வழங்கும் வரை, அமைப்பு அனைத்துப் பதிவுகளையும் தடுக்கும். • Send and Attest: ஒரு லீஸ் (lease) அடிப்படையில் பொருளை அனுப்பிவிட்டு, பின்னர் ஒரு ஆதார ரசீதை (evidence receipt) எழுதவும்.
ஒவ்வொரு நிலையையும் ஒரு தனித்த நிலையான மாற்றமாக (durable transition) இருக்க வேண்டும். நிலை (state) உங்கள் தரவுத்தளத்தில் (database) இருக்க வேண்டும், ஒரு worker-ன் நினைவகத்தில் (memory) இருக்கக்கூடாது.
நகல்களைத் தடுக்க, row-level leasing முறையைப் பயன்படுத்தவும். Postgres-இல், SELECT ... FOR UPDATE SKIP LOCKED என்பதைப் பயன்படுத்தவும். இது ஒரு நேரத்தில் ஒரு worker மட்டுமே ஒரு பணியைக் கட்டுப்படுத்துவதை உறுதி செய்கிறது.
காலாவதியான லீஸ்களை (expired leases) நீங்கள் எவ்வாறு கையாளுகிறீர்கள் என்பதே மிக முக்கியமான விதியாகும். ஒரு வெளிப்புறச் செய்தியை அனுப்பும்போது ஒரு worker செயலிழந்தால், அதைத் தானாகவே மீண்டும் முயற்சிக்க வேண்டாம். அதற்குப் பதிலாக, மனித ஆய்விற்காக அந்தப் பணியை அப்படியே விட்டுவிடுங்கள். கண்ணுக்குத் தெரியாத இரட்டிப்புப் பதிவை விட, கண்ணுக்குத் தெரியும் ஒரு தேக்கமடைந்த பணி (stuck task) சிறந்தது.
நீங்கள் fail-closed கொள்கைகளையும் பின்பற்ற வேண்டும்:
- அனுப்புதல் என்பது இயல்பாகவே முடக்கப்பட்டிருக்க வேண்டும் (off by default). ஒரு ஒற்றைக் கொடி (flag) மட்டுமே அனைத்து வெளிப்பயணப் போக்குவரத்தையும் (outbound traffic) செயல்படுத்த வேண்டும்.
- அடையாளம் சரிபார்க்கப்பட வேண்டும். அனுப்பும் தருணத்தில், அமைப்பு அனுப்பும் முகவரி மற்றும் போக்குவரத்துப் பாதுகாப்பை (transport security) சரிபார்க்க வேண்டும்.
- ஒவ்வொன்றுக்கும் ஒரு ரசீது இருக்க வேண்டும். பதிவு செய்யப்படாத அனுப்புதல் என்பது ஒரு தோல்வியாகும்.
உள் பதிவுகள் (internal logs) போன்ற குறைந்த முக்கியத்துவம் வாய்ந்த பணிகளுக்காக இதை உருவாக்க வேண்டாம். ஒரு தவறு பண இழப்பை ஏற்படுத்தினால், சட்ட சிக்கலை உருவாக்கினால் அல்லது சப்போர்ட் டிக்கெட் தேவைப்பட்டால் இதைப் பயன்படுத்தவும்.
Optional learning community: https://t.me/GyaanSetuAi
