𝗦𝗼𝗹𝘃𝗶𝗻𝗴 𝗠𝗖𝗣 𝗔𝘂𝘁𝗵𝗲𝗻𝘁𝗶𝗰𝗮𝘁𝗶𝗼𝗻 𝗮𝘁 𝗦𝗰𝗮𝗹𝗲
நீங்கள் ஒரு MCP சர்வரை உருவாக்கினீர்கள். அது உங்கள் லேப்டாப்பில் வேலை செய்கிறது. உங்கள் AI உதவியாளரால் Jira டிக்கெட்டுகளை உருவாக்கவும், தரவுத்தளங்களை (databases) வினவவும் (query) முடியும். ஒரு சக ஊழியர் அதை பயன்படுத்தக் கேட்கும் வரை அனைத்தும் சிறப்பாகவே இருந்தது.
உங்கள் MCP-ஐ ஒரு தயாரிப்பாக (product) விற்க விரும்பினால், நீங்கள் ஒரு புதிய சிக்கலை எதிர்கொள்வீர்கள். நீங்கள் பல பயனர்களை ஆதரிக்க வேண்டும். ஒவ்வொரு பயனருக்கும் அவர்களின் சொந்த API சாவிகள் (keys) மற்றும் பாதுகாப்பான அணுகல் (secure access) தேவைப்படும்.
பெரும்பாலான டெவலப்பர்கள் இங்கே தோல்வியடைகிறார்கள். அவர்கள் இரண்டு தவறான அணுகுமுறைகளை முயற்சிக்கிறார்கள்.
முதலாவது கைமுறை அமைப்பு (manual setup). பயனர்களை repo-வை குளோன் செய்யச் சொல்லுதல், dependencies-களை நிறுவுதல் மற்றும் உள்ளூர் சூழல் சாவிகளை (local environment keys) அமைத்தல் போன்றவற்றைச் செய்யச் சொல்வீர்கள். இதற்கு பல மணிநேரம் ஆகும். பெரும்பாலான பயனர்கள் இதை முடிப்பதற்கு முன்பே விட்டுவிடுவார்கள்.
இரண்டாவது சர்வர்லெஸ் (serverless) பயங்கரம். நீங்கள் Cloud Run அல்லது Vercel-இல் வரிசைப்படுத்துவீர்கள் (deploy). சர்வர்லெஸ் தளங்கள் செஷன்களை (sessions) சேமிக்காததால், ஒவ்வொரு கோரிக்கையும் (request) ஒரு புதிய இன்ஸ்டன்ஸைத் (instance) தொடும். உங்கள் பயனர்கள் ஒரு சுழற்சியில் (loop) சிக்கிக்கொள்வார்கள். அவர்கள் அங்கீகாரம் (authenticate) செய்வார்கள், ஆனால் அடுத்த கிளிக் மீண்டும் அங்கீகாரம் செய்யச் சொல்லும். இது ஒரு தயாரிப்பு அல்ல; இது ஒரு முற்றுப்பெறாத முன்மாதிரி (broken prototype).
இதை நாங்கள் BrainGrid-இல் தீர்த்தோம். நாங்கள் ஒரு உள்ளூர் கருவியிலிருந்து (local tool) பயன்பாட்டிற்குத் தயாரான உள்கட்டமைப்பிற்கு (production-ready infrastructure) மாறினோம். நாங்கள் அதை எப்படிச் செய்தோம் என்பது இதோ:
- Redis Session Store-ஐப் பயன்படுத்தவும்: சர்வர்லெஸ் இன்ஸ்டன்ஸ்கள் அழிந்து மீண்டும் தொடங்கும். உங்களால் நினைவகத்தில் (memory) செஷன்களைச் சேமிக்க முடியாது. அனைத்து இன்ஸ்டன்ஸ்களிலும் செஷன் தரவை உயிர்ப்புடன் வைத்திருக்க Redis-ஐப் பயன்படுத்தவும்.
- பல அடுக்கு கேச்சிங் (Multi-Tier Caching) முறையைச் செயல்படுத்தவும்: முதலில் உள்ளூர் நினைவகத்தைச் சரிபார்க்கவும். அங்கு இல்லையென்றால், Redis-ஐச் சரிபார்க்கவும். இது ஒவ்வொரு கோரிக்கைக்கும் அதிகச் செலவு பிடிக்கும் JWT சரிபார்ப்பைத் (validation) தவிர்க்கிறது.
- முக்கியமான தரவை குறியாக்கவும் (Encrypt): Redis-இல் வைப்பதற்கு முன் செஷன் தரவை குறியாக்கம் செய்ய AES-256-GCM-ஐப் பயன்படுத்தவும். இது பயனர் தகவல்களைப் பாதுகாப்பாக வைத்திருக்கும்.
- சரியான OAuth முறைகளைப் பயன்படுத்தவும்: MCP கிளையன்ட்கள் குறிப்பிட்ட discovery ஓட்டங்களை (flows) எதிர்பார்க்கின்றன. பிழைகளைத் தவிர்க்க உங்கள் WWW-Authenticate தலைப்புகளை (headers) சரியாக வடிவமைக்க வேண்டும்.
- வேகத்திற்காக மேம்படுத்தவும்: JWT சரிபார்ப்பு தாமதத்தை (latency) ஏற்படுத்துகிறது. சரிபார்க்கப்பட்ட செஷன்களை கேச் செய்வதன் மூலம், நாங்கள் பதிலளிக்கும் நேரத்தை (response times) கணிசமாகக் குறைத்தோம்.
இதன் விளைவாக, ஒரு பயனரிலிருந்து ஆயிரம் பயனர்கள் வரை விரிவடையக்கூடிய (scale) ஒரு அமைப்பு கிடைக்கிறது. இதை இயக்குவதற்கு மிகக் குறைந்த செலவே ஆகும் மற்றும் WorkOS அல்லது Auth0 போன்ற வழங்குநர்களுடன் எளிதாக ஒருங்கிணைக்க முடியும்.
உங்களுக்காக மட்டும் கருவிகளை உருவாக்குவதை நிறுத்துங்கள். உங்கள் வாடிக்கையாளர்களுக்காக உள்கட்டமைப்பை உருவாக்கத் தொடங்குங்கள்.