𝗪𝗵𝘆 𝗜 𝗦𝘁𝗼𝗽𝗽𝗲𝗱 𝗥𝗲𝗹𝘆𝗶𝗻𝗴 𝗼𝗻 𝗮 𝗦𝗶𝗻𝗴𝗹𝗲 𝗔𝗜 𝗣𝗿𝗼𝘃𝗶𝗱𝗲𝗿
நான் ஒரு சமூக மன்றத்திற்காக (community forum) ஒரு நிகழ்நேர (real-time) சாட்போட்டை உருவாக்கினேன். ஒரே ஒரு API போதுமானதாக இருக்கும் என்று நான் நினைத்தேன். ஆனால் நான் தவறு செய்துவிட்டேன்.
மூன்று வாரங்களுக்குப் பிறகு, அதிகப்படியான பயன்பாடு இருக்கும் நேரங்களில் (peak hours) எனக்கு 5xx பிழை (error) ஏற்பட்டது. எனது சாட்போட் செயலிழந்தது. பயனர்கள் விரக்தியடைந்தனர். தயாரிப்பு பயன்பாடுகளுக்கு (production apps) ஒரே ஒரு வழங்குநரை மட்டும் நம்பி இருக்க முடியாது என்பதை நான் உணர்ந்தேன்.
நான் GPT-4 ஐப் பயன்படுத்தினேன். அது நன்றாகச் செயல்பட்டது, ஆனால் திடீரெனத் தடுமாறியது. நான் rate limits, timeouts மற்றும் முழுமையான சேவைத் தடங்கல்களை (outages) எதிர்கொண்டேன். அதிகப்படியான கட்டணத் திட்டங்களுக்கு (higher tiers) மாறுவது, பிரச்சனையைத் தீர்ப்பதற்குப் பதிலாக அதன் அறிகுறியை மட்டும் சரிசெய்வது போலத் தோன்றியது.
நான் மற்ற வழங்குநர்களையும் முயற்சி செய்தேன், ஆனால் அவை அனைத்தும் வெவ்வேறு வடிவங்களையும் (formats) அங்கீகார முறைகளையும் (auth methods) கொண்டிருந்தன. எனது குறியீடு (code) switch-case கூற்றுகளின் (statements) குழப்பமாக மாறியது. எனக்குப் பின்வரும் வசதிகளைக் கொண்ட ஒரு அமைப்பு தேவைப்பட்டது:
- வழங்குநர்களுக்கு இடையிலான வேறுபாடுகளை மறைக்க.
- தோல்வியடையும் போது ஒரு மாற்று (backup) வழங்குநருக்கு மாற.
- பதில்களைச் சேமித்து வைக்க (Cache).
- ஒரு குறிப்பிட்ட நிறுவனத்தையே சார்ந்திருக்கும் நிலையைத் (vendor lock-in) தவிர்க்க.
மூன்றாம் தரப்பு நூலகங்கள் (third-party libraries) மிகவும் சிக்கலானவை மற்றும் எளிதில் செயலிழந்துவிடும் என்பதால் அவற்றை நான் தவிர்த்தேன். அதற்குப் பதிலாக, ஒரு எளிய ரூட்டரை (router) உருவாக்கினேன்.
முதலில், அனைத்து வழங்குநர்களுக்கும் பொதுவான ஒரு இடைமுகத்தை (interface) வரையறுத்தேன். ஒவ்வொரு வழங்குநரும் ஒரு generate முறை (method) மற்றும் ஒரு health check முறையைச் செயல்படுத்த வேண்டும்.
அடுத்து, ஒரு router class ஐ உருவாக்கினேன். இது ஒரு குறிப்பிட்ட வரிசையில் வழங்குநர்களை முயற்சிக்கும். இது exponential backoff மற்றும் ஒரு எளிய cache முறையைப் பயன்படுத்துகிறது. முதல் வழங்குநர் தோல்வியடைந்தால், அமைப்பு காத்திருந்து அடுத்தவரை முயற்சிக்கும்.
மூன்று வெவ்வேறு சேவைத் தடங்கல்களின் போது இந்த அமைப்பு எனது வார இறுதி நாட்களைக் காப்பாற்றியது. ஒரு முக்கிய வழங்குநர் செயலிழந்தாலும் கூட, இது எனது செயலியைத் தொடர்ந்து இயங்க வைக்கிறது.
நீங்கள் இதைக் கட்டியெழுப்பினால், இந்த விஷயங்களைக் கவனத்தில் கொள்ளுங்கள்:
- தயாரிப்புச் சூழலில் (production) உள்ளூர் அகராதிக்கு (local dictionary) பதிலாக caching செய்ய Redis ஐப் பயன்படுத்துங்கள்.
- Health checks வெற்றியை உறுதி செய்யாது. ஒரு வழங்குநர் சோதனையில் தேர்ச்சி பெறலாம், ஆனால் உண்மையான கோரிக்கையில் (request) தோல்வியடையலாம்.
- rate limits ஐச் சரியாகக் கையாள Retry-After headers ஐப் பகுப்பாய்வு (parse) செய்யுங்கள்.
- செலவுகளைக் கண்காணிக்க token பயன்பாட்டிற்கான logging ஐச் சேர்க்கவும்.
- சிறந்த செயல்திறனுக்காக asyncio ஐப் பயன்படுத்துங்கள்.
உங்கள் திட்டம் சிறியதாக இருந்தால், தேவையில்லாமல் சிக்கலாக்க வேண்டாம் (over-engineer). உங்களுக்கு streaming தேவைப்பட்டால், இந்த முறை தாமதத்தை (latency) ஏற்படுத்தும். உங்கள் தேவையின் அளவிற்கு ஏற்ப சரியான கருவியைத் தேர்ந்தெடுங்கள்.
நீங்கள் வழங்குநரின் நம்பகத்தன்மையைக் கையாளுகிறீர்களா? நீங்கள் ஒரே ஒரு வழங்குநரை மட்டும் நம்பியிருக்கிறீர்களா அல்லது ஒரு fallback அடுக்கை (layer) உருவாக்குகிறீர்களா?
Optional learning community: https://t.me/GyaanSetuAi