एआई अनुप्रयोग: उन्नत वास्तुकला सलाह (AKA AAAA!)

आश्चर्य! यह वेब डेव्स श्रृंखला के लिए एआई के लिए एक बोनस ब्लॉग पोस्ट है जिसे मैंने हाल ही में समाप्त किया है। यदि आपने अभी तक वह श्रृंखला नहीं पढ़ी है, तो मैं आपको इसके लिए प्रोत्साहित करूंगा इसकी जांच - पड़ताल करें .

यह पोस्ट मौजूदा प्रोजेक्ट आर्किटेक्चर और उन तरीकों पर गौर करेगी जिनसे हम एप्लिकेशन डेवलपर्स और अंतिम उपयोगकर्ता दोनों के लिए इसे बेहतर बना सकते हैं।

मैं कुछ सामान्य अवधारणाओं पर चर्चा करूंगा, और अपने उदाहरणों में विशिष्ट अकामाई उत्पादों का उपयोग करूंगा।

बुनियादी अनुप्रयोग वास्तुकला

मौजूदा एप्लिकेशन काफी बुनियादी है. एक उपयोगकर्ता दो विरोधियों को प्रस्तुत करता है, फिर एप्लिकेशन एआई-जनित प्रतिक्रिया को स्ट्रीम करता है कि लड़ाई में कौन जीतेगा।

वास्तुकला भी सरल है:

1. क्लाइंट सर्वर को एक अनुरोध भेजता है।

   
   

2. सर्वर एक प्रॉम्प्ट बनाता है और उस प्रॉम्प्ट को OpenAI को अग्रेषित करता है।

   
   

3. OpenAI सर्वर पर स्ट्रीमिंग प्रतिक्रिया लौटाता है।

   
   

4. सर्वर कोई भी आवश्यक समायोजन करता है और क्लाइंट को स्ट्रीमिंग प्रतिक्रिया अग्रेषित करता है।

मैंने अकामाई की क्लाउड कंप्यूटिंग सेवाओं (पूर्व में) का उपयोग किया था लिनोड ), लेकिन वास्तव में यह किसी भी होस्टिंग सेवा के लिए समान होगा।

🤵 एक फैंसी रेस्तरां में एक सर्वर की तरह दिखता है, और 👁️‍🗨️ "एक आँख" या AI है। लोल्ज़

तकनीकी रूप से यह ठीक काम करता है, लेकिन कुछ समस्याएं हैं, खासकर जब उपयोगकर्ता डुप्लिकेट अनुरोध करते हैं। हमारे सर्वर पर प्रतिक्रियाओं को संग्रहीत करना और केवल अद्वितीय अनुरोधों के लिए OpenAI पर जाना तेज़ और अधिक लागत प्रभावी हो सकता है।

यह मानता है कि हमें हर एक अनुरोध को गैर-नियतात्मक होने की आवश्यकता नहीं है (एक ही इनपुट एक अलग आउटपुट उत्पन्न करता है)। आइए मान लें कि समान इनपुट के लिए समान आउटपुट उत्पन्न करना ठीक है। आख़िरकार, किसी लड़ाई में कौन जीतेगा इसकी भविष्यवाणी संभवतः नहीं बदलेगी।

डेटाबेस आर्किटेक्चर जोड़ें

यदि हम OpenAI से प्रतिक्रियाओं को संग्रहीत करना चाहते हैं, तो उन्हें रखने का एक व्यावहारिक स्थान किसी प्रकार के डेटाबेस में है जो दो विरोधियों का उपयोग करके त्वरित और आसान लुकअप की अनुमति देता है। इस तरह, जब कोई अनुरोध किया जाता है, तो हम पहले डेटाबेस की जाँच कर सकते हैं:

1. क्लाइंट सर्वर को एक अनुरोध भेजता है।

   
   

2. सर्वर डेटाबेस में मौजूदा प्रविष्टि की जाँच करता है जो उपयोगकर्ता के इनपुट से मेल खाती है।

   
   

3. यदि कोई पिछला रिकॉर्ड मौजूद है, तो सर्वर उस डेटा के साथ प्रतिक्रिया करता है, और अनुरोध पूरा हो जाता है। निम्नलिखित चरणों को छोड़ें.

   
   

4. यदि नहीं, तो सर्वर पिछले प्रवाह में चरण तीन का अनुसरण करता है।

   
   

5. प्रतिक्रिया बंद करने से पहले, सर्वर OpenAI परिणामों को डेटाबेस में संग्रहीत करता है।

बिंदीदार रेखाएं वैकल्पिक अनुरोधों का प्रतिनिधित्व करती हैं, और 💽 प्रकार एक हार्ड डिस्क की तरह दिखता है।

इस सेटअप के साथ, किसी भी डुप्लिकेट अनुरोध को डेटाबेस द्वारा नियंत्रित किया जाएगा। कुछ OpenAI अनुरोधों को वैकल्पिक बनाकर, हम संभावित रूप से विलंबित उपयोगकर्ताओं के अनुभव की मात्रा को कम कर सकते हैं, साथ ही एपीआई अनुरोधों की संख्या को कम करके पैसे भी बचा सकते हैं।

यह एक अच्छी शुरुआत है, खासकर यदि सर्वर और डेटाबेस एक ही क्षेत्र में मौजूद हों। यह OpenAI के सर्वर पर जाने की तुलना में बहुत तेज़ प्रतिक्रिया समय देगा।

हालाँकि, जैसे-जैसे हमारा एप्लिकेशन अधिक लोकप्रिय होता जाएगा, हमें दुनिया भर से उपयोगकर्ता मिलना शुरू हो सकते हैं। तेज़ डेटाबेस लुकअप बहुत अच्छा है, लेकिन क्या होगा यदि बाधा उड़ान में बिताए गए समय की विलंबता है?

हम चीजों को उपयोगकर्ता के करीब ले जाकर उस चिंता का समाधान कर सकते हैं।

एज कंप्यूट लाओ

यदि आप पहले से ही "एज" शब्द से परिचित नहीं हैं, तो यह भाग भ्रमित करने वाला हो सकता है, लेकिन मैं इसे सरलता से समझाने का प्रयास करूंगा। एज का तात्पर्य सामग्री को यथासंभव उपयोगकर्ता के करीब रखना है। कुछ लोगों के लिए, इसका मतलब IoT डिवाइस या सेलफोन टावर हो सकता है, लेकिन वेब के मामले में, कैनोनिकल उदाहरण एक है सामग्री वितरण नेटवर्क (सीडीएन) .

मैं आपको विवरण बताऊंगा, लेकिन सीडीएन विश्व स्तर पर वितरित कंप्यूटरों का एक नेटवर्क है जो नेटवर्क में निकटतम नोड से उपयोगकर्ता के अनुरोधों का जवाब दे सकता है ( कुछ ऐसा जिसके बारे में मैंने अतीत में लिखा है ). जबकि परंपरागत रूप से इन्हें स्थैतिक परिसंपत्तियों के लिए डिज़ाइन किया गया था, हाल के वर्षों में, उन्होंने एज कंप्यूट का समर्थन करना शुरू कर दिया है ( कुछ ऐसा भी जिसके बारे में मैंने अतीत में लिखा है ).

एज कंप्यूट के साथ, हम अपने बैकएंड लॉजिक के बहुत से हिस्से को उपयोगकर्ता के बहुत करीब ले जा सकते हैं, और यह कंप्यूट पर नहीं रुकता है। अधिकांश एज कंप्यूट प्रदाता समान एज नोड्स में कुछ प्रकार के अंततः सुसंगत कुंजी-मूल्य स्टोर की पेशकश भी करते हैं।

यह हमारे आवेदन को कैसे प्रभावित कर सकता है?

1. क्लाइंट हमारे बैकएंड को एक अनुरोध भेजता है।

   
   

2. एज कंप्यूट नेटवर्क अनुरोध को निकटतम एज नोड तक रूट करता है।

   
   

3. एज नोड कुंजी-मूल्य स्टोर में मौजूदा प्रविष्टि की जांच करता है जो उपयोगकर्ता के इनपुट से मेल खाता है।

   
   

4. यदि कोई पिछला रिकॉर्ड मौजूद है, तो एज नोड उस डेटा के साथ प्रतिक्रिया करता है, और अनुरोध पूरा हो जाता है। निम्नलिखित चरणों को छोड़ें.

   
   

5. यदि नहीं, तो एज नोड मूल सर्वर को अनुरोध अग्रेषित करता है, जो इसे OpenAI और yadda yadda yadda को भेजता है।

   
   

6. प्रतिक्रिया को बंद करने से पहले, सर्वर ओपनएआई परिणामों को एज की-वैल्यू स्टोर में संग्रहीत करता है।

एज नोड नीला बॉक्स है और इसे 🔪 द्वारा दर्शाया जाता है क्योंकि इसमें एक किनारा है, एजवर्कर अकामाई का एज कंप्यूट उत्पाद है जिसे 🧑‍🏭 द्वारा दर्शाया जाता है, और एजकेवी अकामाई का कुंजी-मूल्य स्टोर है जिसे 🔑🤑🏪 द्वारा दर्शाया जाता है। भौतिक दूरी को दर्शाने के लिए एज बॉक्स क्लाउड में मूल सर्वर की तुलना में क्लाइंट के अधिक करीब है।

मूल सर्वर यहां सख्ती से आवश्यक नहीं हो सकता है, लेकिन मुझे लगता है कि इसके वहां होने की अधिक संभावना है। डेटा, गणना और तर्क प्रवाह के लिए, यह अधिकतर पिछले आर्किटेक्चर के समान ही है। मुख्य अंतर यह है कि पहले संग्रहीत परिणाम अब उपयोगकर्ताओं के बहुत करीब मौजूद हैं और उन्हें लगभग तुरंत वापस किया जा सकता है।

(नोट: हालांकि डेटा को किनारे पर कैश किया जा रहा है, प्रतिक्रिया अभी भी गतिशील रूप से बनाई गई है। यदि आपको गतिशील प्रतिक्रियाओं की आवश्यकता नहीं है, तो मूल सर्वर के सामने सीडीएन का उपयोग करना और सही HTTP हेडर सेट करना आसान हो सकता है प्रतिक्रिया को कैश करें। यहां बहुत सारी बारीकियां हैं, और मैं और अधिक कह सकता हूं लेकिन...ठीक है, मैं थक गया हूं और वास्तव में ऐसा नहीं करना चाहता। यदि आपके कोई प्रश्न हों तो बेझिझक संपर्क करें।)

अब हम खाना बना रहे हैं! किसी भी डुप्लिकेट अनुरोध का लगभग तुरंत जवाब दिया जाएगा, साथ ही हमें अनावश्यक एपीआई अनुरोधों से भी बचाया जाएगा।

यह पाठ प्रतिक्रियाओं के लिए आर्किटेक्चर को सुलझाता है, लेकिन हमारे पास एआई-जनरेटेड छवियां भी हैं।

उन छवियों को कैश करें

आखिरी चीज़ जिस पर आज हम विचार करेंगे वह है छवियाँ। छवियों के साथ काम करते समय, हमें वितरण और भंडारण के बारे में सोचने की ज़रूरत है। मुझे यकीन है कि ओपनएआई के लोगों के पास अपने स्वयं के समाधान हैं, लेकिन कुछ संगठन सुरक्षा, अनुपालन या विश्वसनीयता कारणों से संपूर्ण बुनियादी ढांचे का मालिक बनना चाहते हैं। कुछ लोग OpenAI का उपयोग करने के बजाय अपनी स्वयं की छवि निर्माण सेवाएँ भी चला सकते हैं।

वर्तमान वर्कफ़्लो में, उपयोगकर्ता एक अनुरोध करता है जो अंततः OpenAI तक पहुंचता है। OpenAI छवि बनाता है लेकिन उसे वापस नहीं करता है। इसके बजाय, वे ओपनएआई के बुनियादी ढांचे पर होस्ट की गई छवि के यूआरएल के साथ एक JSON प्रतिक्रिया लौटाते हैं।

इस प्रतिक्रिया के साथ, URL का उपयोग करके पृष्ठ पर एक <img> टैग जोड़ा जा सकता है, जो वास्तविक छवि के लिए एक और अनुरोध शुरू करता है।

यदि हम छवि को अपने बुनियादी ढांचे पर होस्ट करना चाहते हैं, तो हमें इसे संग्रहीत करने के लिए एक जगह की आवश्यकता है। हम छवियों को मूल सर्वर की डिस्क पर लिख सकते हैं, लेकिन इससे डिस्क स्थान जल्दी खर्च हो सकता है, और हमें अपने सर्वर को अपग्रेड करना होगा, जो महंगा हो सकता है।

वस्तु भंडारण बहुत सस्ता उपाय है ( मैंने इस बारे में लिखा भी है ). छवि के लिए OpenAI URL का उपयोग करने के बजाय, हम इसे अपने स्वयं के ऑब्जेक्ट स्टोरेज इंस्टेंस पर अपलोड कर सकते हैं और इसके बजाय उस URL का उपयोग कर सकते हैं।

यह भंडारण प्रश्न को हल करता है, लेकिन ऑब्जेक्ट स्टोरेज बकेट आम तौर पर एक ही क्षेत्र में तैनात किए जाते हैं। यह उस समस्या को प्रतिध्वनित करता है जो हमें डेटाबेस में पाठ संग्रहीत करने में हुई थी। एक एकल क्षेत्र उपयोगकर्ताओं से बहुत दूर हो सकता है, जिससे बहुत विलंब हो सकता है।

पहले से ही बढ़त पेश करने के बाद, केवल स्थैतिक संपत्तियों के लिए सीडीएन सुविधाओं को जोड़ना बहुत मामूली होगा (स्पष्ट रूप से, प्रत्येक साइट में सीडीएन होना चाहिए)। एक बार कॉन्फ़िगर होने के बाद, सीडीएन प्रारंभिक अनुरोध पर ऑब्जेक्ट स्टोरेज से छवियों को खींच लेगा और उन्हें उसी क्षेत्र में आगंतुकों से भविष्य के किसी भी अनुरोध के लिए कैश कर देगा।

यहां बताया गया है कि छवियों के लिए हमारा प्रवाह कैसा दिखेगा:

1. एक ग्राहक अपने विरोधियों के आधार पर एक छवि बनाने के लिए अनुरोध भेजता है।

   
   

2. एज कंप्यूट जाँचता है कि उस अनुरोध के लिए छवि डेटा पहले से मौजूद है या नहीं। यदि हां, तो यह यूआरएल लौटाता है।

   
   

3. छवि को URL के साथ पृष्ठ पर जोड़ा जाता है, और ब्राउज़र छवि का अनुरोध करता है।

   
   

4. यदि छवि को पहले सीडीएन में कैश किया गया है, तो ब्राउज़र इसे लगभग तुरंत लोड कर देता है। यह प्रवाह का अंत है.

   
   

5. यदि छवि को पहले कैश नहीं किया गया है, तो सीडीएन छवि को ऑब्जेक्ट स्टोरेज स्थान से खींच लेगा, भविष्य के अनुरोधों के लिए इसकी एक प्रति कैश कर देगा, और छवि को क्लाइंट को वापस कर देगा। यह प्रवाह का दूसरा छोर है.

   
   

6. यदि छवि डेटा एज की-वैल्यू स्टोर में नहीं है, तो छवि उत्पन्न करने का अनुरोध सर्वर और ओपनएआई पर जाता है, जो छवि उत्पन्न करता है और यूआरएल जानकारी लौटाता है। सर्वर ऑब्जेक्ट स्टोरेज बकेट में छवि को सहेजने के लिए एक कार्य शुरू करता है, छवि डेटा को एज की-वैल्यू स्टोर में संग्रहीत करता है, और छवि डेटा को एज कंप्यूट पर लौटाता है।

   
   

7. नए छवि डेटा के साथ, क्लाइंट छवि बनाता है जो एक नया अनुरोध बनाता है और ऊपर चरण पांच से जारी रहता है।

सामग्री वितरण नेटवर्क को एक डिलीवरी ट्रक (🚚) और एक नेटवर्क सिग्नल (📶) द्वारा दर्शाया जाता है, और वस्तु भंडारण को एक बॉक्स में मोजे (🧦📦), या भंडारण में वस्तुओं द्वारा दर्शाया जाता है। यह कैप्शन संभवतः आवश्यक नहीं है, क्योंकि मुझे लगता है कि ये स्पष्ट हैं, लेकिन मुझे अपने इमोजी गेम पर बहुत गर्व है और मुझे सत्यापन की आवश्यकता है। मुझे शामिल करने के लिए धन्यवाद. जारी रखो।

बेशक, यह अंतिम आर्किटेक्चर थोड़ा अधिक जटिल है, लेकिन यदि आपका एप्लिकेशन गंभीर ट्रैफ़िक को संभालने जा रहा है, तो यह विचार करने योग्य है।

देखा

सही पर! उन सभी परिवर्तनों के साथ, हमने अद्वितीय अनुरोधों के लिए एआई-जनरेटेड टेक्स्ट और छवियां बनाई हैं और डुप्लिकेट अनुरोधों के लिए किनारे से कैश्ड सामग्री प्रदान की है। परिणाम तेज़ प्रतिक्रिया समय और बहुत बेहतर उपयोगकर्ता अनुभव (कम एपीआई कॉल के अलावा) है।

मैंने इन आर्किटेक्चर आरेखों को उद्देश्य से विभिन्न डेटाबेस, एज कंप्यूट, ऑब्जेक्ट स्टोरेज और सीडीएन प्रदाताओं पर लागू रखा है। मैं चाहता हूं कि मेरी सामग्री व्यापक रूप से लागू हो। लेकिन यह उल्लेखनीय है कि किनारे को एकीकृत करना केवल प्रदर्शन से कहीं अधिक है। ऐसी बहुत सी बेहतरीन सुरक्षा सुविधाएँ हैं जिन्हें आप सक्षम भी कर सकते हैं।

उदाहरण के लिए, अकामाई के नेटवर्क पर, आप जैसी चीजों तक पहुंच प्राप्त कर सकते हैं वेब एप्लिकेशन फ़ायरवॉल (WAF) , वितरित इनकार सेवा (डीडीओएस) सुरक्षा , बुद्धिमान बॉट का पता लगाना , और अधिक। हालाँकि, यह सब आज की पोस्ट के दायरे से परे है।

तो, अभी के लिए, मैं आपको पढ़ने के लिए एक बड़े "धन्यवाद" के साथ छोड़ता हूँ। मुझे आशा है कि आपने कुछ सीखा होगा। और हमेशा की तरह, टिप्पणियों, प्रश्नों या चिंताओं के साथ किसी भी समय बेझिझक संपर्क करें।

पढ़ने के लिए आपको बहुत बहुत शुक्रिया। यदि आपको यह लेख पसंद आया है, और आप मेरा समर्थन करना चाहते हैं, तो ऐसा करने का सबसे अच्छा तरीका है इसे शेयर करें , मेरे न्यूज़लैटर के लिए साइन अप करें , और ट्विटर पर मुझे फॉलो करें .

मूलतः पर प्रकाशित austingil.com .