AWS Bedrock കീകൾ ഇപ്പോൾ ഒരു ഇന്റേണൽ LLM ഗേറ്റ്വേ ഉപയോഗിച്ച് സംരക്ഷിക്കപ്പെട്ടിരിക്കുന്നു. ഇത് ഒരു ഫിൻടെക് സ്ഥാപനത്തിലെ ഓരോ ടീമിനും മോഡലുകൾ ഉപയോഗിക്കാൻ അനുവദിക്കുന്നു, എന്നാൽ ഓരോ അഭ്യർത്ഥനയും (request) ഓരോ ടീമിനും അനുവദിച്ച ടോക്കൺ ബജറ്റുമായി ബന്ധിപ്പിച്ചിരിക്കുന്നു. റെപ്പോസിറ്ററികളിലും (repos) നോട്ട്ബുക്കുകളിലും IAM ക്രെഡൻഷ്യലുകൾ ചിതറിക്കിടക്കുന്ന രീതി ഈ മാറ്റത്തിലൂടെ ഒഴിവാക്കാൻ സാധിച്ചു. ഇത് കമ്പനിയുടെ AI ചിലവ് ഒറ്റ ദിവസം കൊണ്ട് വർദ്ധിക്കാനുള്ള സാധ്യത ഇല്ലാതാക്കുന്നു.
എന്തുകൊണ്ടാണ് AWS കീകൾ വിതരണം ചെയ്യുന്നത് പെട്ടെന്ന് ഒരു കുഴപ്പമായി മാറുന്നത്
സ്ഥാപനത്തിലെ സാങ്കേതിക അറിവില്ലാത്ത വിഭാഗങ്ങൾ കമ്പനിയുടെ ലാംഗ്വേജ് മോഡലുകൾക്ക് നേരിട്ട് പ്രവേശനം ആവശ്യപ്പെട്ടു. സിദ്ധാന്തപരമായി പറഞ്ഞാൽ, AWS-ൽ മോഡലുകൾ പ്രവർത്തനസജ്ജമാക്കുകയും ഓരോ ഗ്രൂപ്പിനും ഒരു IAM പെർമിഷൻ നൽകുകയും ചെയ്യുന്നതായിരുന്നു ഏറ്റവും ലളിതമായ പരിഹാരം. പത്ത് മിനിറ്റ് ജോലി, കുറച്ച് പോളിസി എഡിറ്റുകൾ എന്നിവയിലൂടെ ഈ ജോലി പൂർത്തിയാക്കാം—ചിലപ്പോൾ സിദ്ധാന്തത്തിൽ മാത്രം.
പ്രായോഗികമായി നോക്കിയാൽ, IAM ക്രെഡൻഷ്യലുകൾ നൽകുന്നത് മൂന്ന് മറഞ്ഞിരിക്കുന്ന ചിലവുകൾ ഉണ്ടാക്കുന്നു:
- Credential sprawl – കീകൾ
.envഫയലുകൾ, CI പൈപ്പ്ലൈനുകൾ, Jupyter നോട്ട്ബുക്കുകൾ, ആഡ്-ഹോക്ക് സ്ക്രിപ്റ്റുകൾ എന്നിവയിൽ എത്തുമ്പോൾ അവ നിയന്ത്രണാതീതമാകുന്നു. കീകൾ മാറ്റേണ്ടി വരുമ്പോൾ (rotation), ഓരോ കോപ്പിയും ഒരു പരാജയ സാധ്യതയായി മാറുന്നു. - Zero visibility – ഒരു ഷെയർ ചെയ്ത കീ ഉപയോഗിക്കുമ്പോൾ ഏത് ടീമോ ഏത് കോഡോ ആണ് ഉപയോഗം ഉണ്ടാക്കുന്നത് എന്ന് മനസ്സിലാക്കാൻ കഴിയില്ല. ഒരു റണ്ണവേ ലൂപ്പ് (runaway loop) ആരംഭിച്ചാൽ, ആരും ശ്രദ്ധിക്കുന്നതിന് മുമ്പ് മുഴുവൻ ബജറ്റും തീർന്നുപോയേക്കാം.
- Operational overhead – ആർക്കൊക്കെ എന്ത് പെർമിഷൻ ഉണ്ടെന്ന് ട്രാക്ക് ചെയ്യുന്നതും, ആക്സസ് റദ്ദാക്കുന്നതും, ഉപയോഗം ഓഡിറ്റ് ചെയ്യുന്നതും പെട്ടെന്ന് തന്നെ മാനുവൽ ആയതും തെറ്റുകൾ സംഭവിക്കാനിടയുള്ളതുമായ ഒരു പ്രക്രിയയായി മാറുന്നു.
ഈ "പെട്ടെന്നുള്ള പരിഹാരം" ഉടൻ തന്നെ ഒരു സുരക്ഷാപരവും സാമ്പത്തികവുമായ ദുരന്തമായി മാറുമെന്ന് ഫിൻടെക് ടീം തിരിച്ചറിഞ്ഞു.
പകരം ഒരു റിവേഴ്സ്-പ്രോക്സി ഗേറ്റ്വേ നിർമ്മിക്കുന്നു
എല്ലാ ഇന്റേണൽ ആപ്ലിക്കേഷനുകൾക്കും AWS Bedrock-നും ഇടയിൽ ഒരു ചെറിയ റിവേഴ്സ് പ്രോക്സി സ്ഥാപിക്കുക എന്നതായിരുന്നു പരിഹാരം. ഈ പ്രോക്സി യഥാർത്ഥ AWS ക്രെഡൻഷ്യലുകൾ സുരക്ഷിതമായ ഒരു വോൾട്ടിൽ (vault) സൂക്ഷിക്കുകയും, വിളിക്കുന്നവർക്ക് (callers) കുറഞ്ഞ കാലയളവിലേക്ക് മാത്രം ഉപയോഗിക്കാവുന്ന, മനുഷ്യർക്ക് വായിക്കാൻ കഴിയുന്ന ടോക്കണുകൾ (ഉദാഹരണത്തിന്, lllkey_9f3c) നൽകുകയും ചെയ്യുന്നു.
പ്രധാന ഡിസൈൻ പോയിന്റുകൾ:
- No AWS credentials leave the gateway – ഡെവലപ്പർമാരും സേവനങ്ങളും യഥാർത്ഥ IAM കീകൾ ഒരിക്കലും കാണില്ല.
- Per-token policy enforcement – ഓരോ ടോക്കണിനും ഒരു പ്രത്യേക മോഡൽ ഫാമിലിക്കോ അല്ലെങ്കിൽ പരമാവധി ടോക്കൺ എണ്ണത്തിനോ പരിധി നിശ്ചയിക്കാം.
- Full audit trail – ഓരോ അഭ്യർത്ഥനയും പേരോടു കൂടി ലോഗ് ചെയ്യുന്നു.
ഗേറ്റ്വേ ഒരു അഭ്യർത്ഥന എങ്ങനെ പ്രോസസ്സ് ചെയ്യുന്നു
- Receive token – ക്ലയന്റ് അതിന്റെ
llmkey_…ടോക്കൺ HTTP ഹെഡറിൽ ഉൾപ്പെടുത്തുന്നു. - Validate token – ഗേറ്റ്വേ ടോക്കണിന്റെ നില (active, expired അല്ല എന്ന്) പരിശോധിക്കുകയും അഭ്യർത്ഥന അനുവദിച്ച ബജറ്റിനുള്ളിലാണോ എന്ന് ഉറപ്പുവരുത്തുകയും ചെയ്യുന്നു.
- Model whitelist – ആവശ്യപ്പെട്ട മോഡൽ ആ ടോക്കണിന് അനുവദനീയമാണോ എന്ന് ഇത് സ്ഥിരീകരിക്കുന്നു.
- Forward to Bedrock – സൂക്ഷിച്ചിട്ടുള്ള IAM ക്രെഡൻഷ്യലുകൾ ഉപയോഗിച്ച് അഭ്യർത്ഥന AWS-ലേക്ക് അയക്കുന്നു.
- Log and bill – റിപ്പോർട്ടിംഗിനായി ടോക്കൺ ഉപയോഗം, മോഡൽ പേര്, ചിലവ് എന്നിവ ഒരു സെൻട്രൽ ഡാറ്റാബേസിൽ രേഖപ്പെടുത്തുന്നു.
ഫിൻടെക് സ്ഥാപനത്തിന് എല്ലാ ഡാറ്റയും സ്വന്തം നെറ്റ്വർക്കിനുള്ളിൽ തന്നെ സൂക്ഷിക്കേണ്ടതുള്ളതിനാൽ, ഒരു തേർഡ് പാർട്ടി SaaS സേവനം ഉപയോഗിക്കാൻ കഴിയില്ലായിരുന്നു.
കമ്പനിക്ക് ലഭിച്ച നേട്ടങ്ങൾ
- Model control – കുറഞ്ഞ ചിലവുള്ള മോഡലുകൾ മാത്രം ആവശ്യമുള്ള ടീമുകളെ അതിലേക്ക് പരിമിതപ്പെടുത്താം, ഇത് അബദ്ധവശാൽ വിലകൂടിയതും ഉയർന്ന ശേഷിയുള്ളതുമായ മോഡലുകൾ ഉപയോഗിക്കുന്നത് തടയുന്നു.
- Budget protection – ടോക്കണുകൾക്ക് കൃത്യമായ പരിധിയുണ്ട്. പരിധി കഴിഞ്ഞാൽ, കൂടുതൽ ക്രെഡിറ്റുകൾ ഉപയോഗിക്കുന്നതിന് പകരം ഗേറ്റ്വേ ഒരു എറർ (error) കാണിക്കുന്നു.
- Attribution for finance – ഉപയോഗ വിവരങ്ങൾ (usage logs) അടിസ്ഥാനമാക്കി നിർമ്മിച്ച ഒരു ഡാഷ്ബോർഡ്, ഏത് ടീമോ സേവനമോ AI-ക്കായി എത്ര ചിലവാക്കി എന്ന് കൃത്യമായി കാണിക്കുന്നു. ഇത് അവ്യക്തമായ സ്പ്രെഡ്ഷീറ്റുകളെ സുതാര്യമായ റിപ്പോർട്ടുകളാക്കി മാറ്റുന്നു.
പ്രവർത്തന രീതിയിലും (operational workflow) മാറ്റം വന്നു. പുതിയ IAM പോളിസികളോ, സീക്രട്ട് റൊട്ടേഷനോ ആവശ്യമില്ലാതായി, കൂടാതെ കീകൾ വെർഷൻ കൺട്രോളിലേക്ക് ചോരാനുള്ള സാധ്യതയും ഇല്ലാതായി.
എതിർവാദം: എന്തുകൊണ്ട് ഒരു മാനേജ്ഡ് സർവീസ് ഉപയോഗിക്കരുത്
ഒരു കസ്റ്റം ഗേറ്റ്വേ നിർമ്മിക്കുന്നത് എഞ്ചിനീയറിംഗ് അധ്വാനവും പരിപാലനവും (maintenance) വർദ്ധിപ്പിക്കും എന്നതാണ് സാധാരണമായ ഒരു എതിർവാദം. എന്നാൽ ഈ ഫിൻടെക് സ്ഥാപനത്തിന്റെ കാര്യത്തിൽ, എല്ലാ AI ട്രാഫിക്കും ഉപയോഗ വിവരങ്ങളും കോർപ്പറേറ്റ് ഫയർവാളിന് പിന്നിൽ തന്നെ സൂക്ഷിക്കേണ്ടതിന്റെ ആവശ്യകത ഒരു തേർഡ് പാർട്ടി സൊല്യൂഷന്റെ സൗകര്യത്തേക്കാൾ വലുതായിരുന്നു. ഇന്റേണൽ പ്രോക്സി നിർമ്മിക്കാൻ ഒരു വാരാന്ത്യം എഞ്ചിനീയറിംഗ് ജോലി ആവശ്യമായി വന്നെങ്കിലും, കീകൾ വിതരണം ചെയ്യുന്ന രീതി പിന്തുടർന്നാൽ ഉണ്ടാകുമായിരുന്ന മാസങ്ങളോളം നീണ്ടുനിൽക്കുന്ന ക്രെഡൻഷ്യൽ ക്ലീനപ്പും ബജറ്റ് അധികച്ചെലവും ഇത് ഒഴിവാക്കി.
ചുരുക്കത്തിൽ
AWS Bedrock കീകൾ വിതരണം ചെയ്യുന്നത് സുരക്ഷാപരവും ബജറ്റ് സംബന്ധവുമായ വലിയ പ്രശ്നങ്ങളിലേക്ക് നയിക്കുന്ന ഒരു കുറുക്കവഴിയാണ്. ഒരു വാരാന്ത്യം കൊണ്ട് നിർമ്മിക്കാവുന്ന ലളിതമായ ഒരു റിവേഴ്സ്-പ്രോക്സി ഗേറ്റ്വേ, ക്രെഡൻഷ്യലുകളെ കേന്ദ്രീകരിക്കുന്നു, ഓരോ ടീമിനും പരിധികൾ നിശ്ചയിക്കുന്നു, കൂടാതെ സാമ്പത്തിക വിഭാഗത്തിന് ആവശ്യമായ ഓഡിറ്റ് ട്രായിലും നൽകുന്നു. നിയന്ത്രണം വിട്ടുകൊടുക്കാതെ തന്നെ ഒന്നിലധികം ഗ്രൂപ്പുകളെ LLM പരീക്ഷണങ്ങൾ നടത്താൻ അനുവദിക്കാൻ ആഗ്രഹിക്കുന്ന ഏതൊരു സ്ഥാപനത്തിനും, ഈ ഗേറ്റ്വേ രീതി ഭാവിയിലെ പ്രശ്നങ്ങളും അനാവശ്യ ചിലവുകളും ഒഴിവാക്കി ലാഭകരമാകും.