AWS पर Kubeflow का उपयोग करके दोहराने योग्य, सुरक्षित और एक्स्टेंसिबल एंड-टू-एंड मशीन लर्निंग वर्कफ़्लो बनाएँ

यह एक अतिथि ब्लॉग पोस्ट है जिसे एथेनहेल्थ के साथ लिखा गया है।

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

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

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

Kubeflow एक ओपन-सोर्स ML प्लेटफ़ॉर्म है जो Kubernetes पर ML वर्कफ़्लोज़ को सरल, पोर्टेबल और स्केलेबल बनाने के लिए समर्पित है। Kubeflow प्रासंगिक ओपन-सोर्स टूल को शामिल करके इसे प्राप्त करता है जो Kubernetes के साथ अच्छी तरह से एकीकृत होता है। इनमें से कुछ परियोजनाओं में पाइपलाइन ऑर्केस्ट्रेशन के लिए अर्गो, सर्विस मेश के लिए इस्तियो, नोटबुक के लिए ज्यूपिटर, स्पार्क, टेंसरबोर्ड और कैटिब शामिल हैं। Kubeflow पाइपलाइन पोर्टेबल, स्केलेबल ML वर्कफ़्लोज़ को बनाने और तैनात करने में मदद करती है जिसमें डेटा निष्कर्षण, प्रीप्रोसेसिंग, मॉडल प्रशिक्षण और दोहराने योग्य पाइपलाइनों के रूप में मॉडल मूल्यांकन जैसे चरण शामिल हो सकते हैं।

AWS अपने स्वयं के Kubeflow वितरण (AWS पर Kubeflow कहा जाता है) प्रदान करके ओपन-सोर्स Kubeflow समुदाय में योगदान दे रहा है, जो athenahealth जैसे संगठनों को AWS प्रबंधित सेवाओं के साथ एकीकरण के माध्यम से कम परिचालन ओवरहेड के साथ अत्यधिक विश्वसनीय, सुरक्षित, पोर्टेबल और स्केलेबल ML वर्कफ़्लो बनाने में मदद करता है। AWS विभिन्न Kubeflow परिनियोजन विकल्प प्रदान करता है जैसे परिनियोजन के साथ अमेज़ॅन कॉग्निटो, तैनाती के साथ अमेज़न रिलेशनल डेटाबेस सर्विस (अमेज़ॅन आरडीएस) और अमेज़न सरल भंडारण सेवा (अमेज़ॅन एस 3), और वेनिला परिनियोजन। इनमें से प्रत्येक विकल्प के लिए सेवा एकीकरण और उपलब्ध ऐड-ऑन के विवरण के लिए, देखें तैनाती.

आज, AWS पर Kubeflow Kubeflow का उपयोग करने के लिए एक स्पष्ट मार्ग प्रदान करता है, जो निम्नलिखित AWS सेवाओं के साथ संवर्धित है:

कई AWS ग्राहक AWS वितरण पर Kubeflow का लाभ उठा रहे हैं, जिसमें एथेनहेल्थ भी शामिल है।

यहां, एथेनहेल्थ एमएलओप्स टीम उनके सामने आने वाली चुनौतियों और उनके क्यूबफ्लो यात्रा में उनके द्वारा बनाए गए समाधानों पर चर्चा करती है।

पिछले एमएल पर्यावरण के साथ चुनौतियां

AWS पर Kubeflow को अपनाने से पहले, हमारे डेटा वैज्ञानिकों ने उपकरणों के एक मानकीकृत सेट और एक प्रक्रिया का उपयोग किया, जो किसी दिए गए मॉडल को प्रशिक्षित करने के लिए उपयोग की जाने वाली तकनीक और वर्कफ़्लो में लचीलेपन की अनुमति देता है। मानकीकृत टूलिंग के उदाहरण घटकों में एक डेटा अंतर्ग्रहण एपीआई, सुरक्षा स्कैनिंग उपकरण, एथेनहेल्थ के भीतर किसी अन्य टीम द्वारा निर्मित और अनुरक्षित सीआई/सीडी पाइपलाइन और एमएलओपीएस टीम द्वारा निर्मित और अनुरक्षित एक सामान्य सर्विंग प्लेटफॉर्म शामिल हैं। हालाँकि, जैसे-जैसे AI और ML का हमारा उपयोग परिपक्व होता गया, प्रत्येक मॉडल के लिए विभिन्न प्रकार के उपकरण और बुनियादी ढाँचे बनाए गए। यद्यपि हम अभी भी मौजूदा प्रक्रिया का समर्थन करने में सक्षम थे, हमने क्षितिज पर निम्नलिखित चुनौतियों को देखा:

• रखरखाव और विकास - जैसे-जैसे तैनात मॉडलों की संख्या बढ़ती है, मॉडल प्रशिक्षण वातावरण को पुन: प्रस्तुत करने और बनाए रखने में अधिक प्रयास किए जाते हैं। प्रत्येक प्रोजेक्ट ने विस्तृत दस्तावेज़ीकरण बनाए रखा जो यह बताता है कि अंतिम मॉडल के निर्माण के लिए प्रत्येक स्क्रिप्ट का उपयोग कैसे किया गया था। कई मामलों में, यह एक विस्तृत प्रक्रिया थी जिसमें प्रत्येक में कई आउटपुट वाली 5 से 10 स्क्रिप्ट शामिल थीं। बाद की प्रक्रियाओं में प्रत्येक आउटपुट का उपयोग कैसे किया जाएगा, इस पर विस्तृत निर्देशों के साथ इन्हें मैन्युअल रूप से ट्रैक किया जाना था। समय के साथ इसे बनाए रखना बोझिल हो गया। इसके अलावा, जैसे-जैसे परियोजनाएं अधिक जटिल होती गईं, उपकरणों की संख्या भी बढ़ती गई। उदाहरण के लिए, अधिकांश मॉडलों ने GPU के साथ Spark और TensorFlow का उपयोग किया, जिसके लिए अधिक विविध प्रकार के पर्यावरण कॉन्फ़िगरेशन की आवश्यकता होती है। समय के साथ, उपयोगकर्ता अपने विकास परिवेश में टूल के नए संस्करणों पर स्विच करेंगे, लेकिन जब वे संस्करण असंगत हो गए तो पुरानी स्क्रिप्ट नहीं चला सकते थे। नतीजतन, पुरानी परियोजनाओं को बनाए रखने और बढ़ाने के लिए अधिक इंजीनियरिंग समय और प्रयास की आवश्यकता होती है। इसके अलावा, जैसे ही नए डेटा वैज्ञानिक टीम में शामिल हुए, ज्ञान हस्तांतरण और ऑनबोर्डिंग में अधिक समय लगा, क्योंकि स्थानीय वातावरण को सिंक्रनाइज़ करने में कई अनिर्दिष्ट निर्भरताएं शामिल थीं। परियोजनाओं के बीच स्विच करने में समान मुद्दों का सामना करना पड़ा क्योंकि प्रत्येक मॉडल का अपना वर्कफ़्लो था।
• सुरक्षा - हम सुरक्षा को गंभीरता से लेते हैं, और इसलिए एमएल और डेटा विज्ञान से जुड़े सभी संविदात्मक, कानूनी और नियामक दायित्वों के अनुपालन को प्राथमिकता देते हैं। डेटा को विशिष्ट तरीकों से उपयोग, संग्रहीत और एक्सेस किया जाना चाहिए, और हमने यह सुनिश्चित करने के लिए मजबूत प्रक्रियाओं को एम्बेड किया है कि हमारी प्रथाएं हमारे कानूनी दायित्वों का पालन करती हैं और साथ ही उद्योग की सर्वोत्तम प्रथाओं के साथ संरेखित होती हैं। Kubeflow अपनाने से पहले, यह सुनिश्चित करना कि डेटा को एक विशिष्ट तरीके से संग्रहीत और एक्सेस किया गया था, जिसमें कई, विविध वर्कफ़्लोज़ में नियमित सत्यापन शामिल था। हम जानते थे कि इन विविध कार्यप्रवाहों को एक मंच पर समेकित करके हम दक्षता में सुधार कर सकते हैं। हालाँकि, उस प्लेटफ़ॉर्म को हमारे मानकीकृत टूलिंग के साथ अच्छी तरह से एकीकृत करने के लिए पर्याप्त लचीला होना चाहिए।
• संचालन - हमने वर्कफ़्लोज़ की लॉगिंग और निगरानी को केंद्रीकृत करके परिचालन दक्षता और प्रबंधन को बढ़ाने का अवसर भी देखा। चूंकि प्रत्येक टीम ने अपने स्वयं के उपकरण विकसित किए थे, इसलिए हमने प्रत्येक कार्यप्रवाह से यह जानकारी व्यक्तिगत रूप से एकत्र की और उन्हें एकत्रित किया।

डेटा साइंस टीम ने वर्कफ़्लोज़ को समेकित करने के लिए विभिन्न समाधानों का मूल्यांकन किया। इन आवश्यकताओं को पूरा करने के अलावा, हमने एक ऐसे समाधान की तलाश की जो मौजूदा मानकीकृत बुनियादी ढांचे और उपकरणों के साथ मूल रूप से एकीकृत हो। हमने अपने वर्कफ़्लो समाधान के रूप में AWS पर Amazon EKS और Kubeflow को चुना।

Kubeflow शामिल डेटा वैज्ञानिक विकास चक्र

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

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

क्वेरी विकसित होने के बाद, डेटा वैज्ञानिक कच्चे डेटा को Amazon S3 पर एक स्थान पर निकालते हैं, फिर डेटा का पता लगाने के लिए AWS Kubeflow UI से एक ज्यूपिटर नोटबुक लॉन्च करते हैं। लक्ष्य फीचर सेट बनाना है जिसका उपयोग पहले मॉडल को प्रशिक्षित करने के लिए किया जाएगा। यह डेटा वैज्ञानिकों को यह निर्धारित करने की अनुमति देता है कि ग्राहक की व्यावसायिक आवश्यकता को पूरा करने के लिए डेटा में पर्याप्त संकेत है या नहीं।

परिणाम संतोषजनक होने के बाद, डेटा वैज्ञानिक विकास चक्र के अगले चरण में चले जाते हैं और अपनी खोजों को एक मजबूत पाइपलाइन में बदल देते हैं। वे POC कोड को प्रोडक्शन-क्वालिटी कोड में बदल देते हैं जो बड़े पैमाने पर चलता है। अनुमोदित पुस्तकालयों का उपयोग करके अनुपालन सुनिश्चित करने के लिए, उपयुक्त आधार डॉकर छवि के साथ एक कंटेनर बनाया जाता है। हमारे डेटा वैज्ञानिकों के लिए, हमने पाया है कि एक मानक पायथन, टेंसरफ्लो, और स्पार्क बेस इमेज प्रदान करने से अधिकांश, यदि सभी नहीं, तो वर्कलोड के लिए पर्याप्त लचीलापन मिलता है। फिर वे अपने विकास के माहौल को और अनुकूलित करने के लिए अपने घटक के डॉकरफाइल का उपयोग कर सकते हैं। इस डॉकरफाइल का उपयोग सीआई/सीडी प्रक्रिया द्वारा उन घटकों की छवि बनाने के लिए किया जाता है जिनका उपयोग उत्पादन में किया जाएगा, इसलिए विकास और उत्पादन वातावरण के बीच स्थिरता बनाए रखना।

हमारे पास एक उपकरण है जो डेटा वैज्ञानिकों को कुबेरनेट्स पर चलने वाले पॉड में अपने विकास के माहौल को लॉन्च करने की क्षमता देता है। जब यह पॉड चल रहा होता है, तब डेटा वैज्ञानिक विजुअल स्टूडियो कोड आईडीई को सीधे पॉड से जोड़ सकते हैं और अपने मॉडल कोड को डीबग कर सकते हैं। कोड के सफलतापूर्वक चलने के बाद, वे अपने परिवर्तनों को git में धकेल सकते हैं और सबसे हाल के परिवर्तनों के साथ एक नया विकास वातावरण बनाया जाता है।

मानक डेटा विज्ञान पाइपलाइन में ऐसे चरण होते हैं जिनमें निष्कर्षण, प्रीप्रोसेसिंग, प्रशिक्षण और मूल्यांकन शामिल होते हैं। पाइपलाइन में प्रत्येक चरण क्यूबफ्लो में एक घटक के रूप में प्रकट होता है, जिसमें कुबेरनेट्स पॉड होता है जो पैरामीटर के रूप में पारित कुछ जानकारी के साथ एक कमांड चलाता है। ये पैरामीटर या तो स्थिर मान हो सकते हैं या पिछले घटक से आउटपुट के संदर्भ हो सकते हैं। पॉड में प्रयुक्त डॉकर छवि CI/CD प्रक्रिया से बनाई गई है। इस प्रक्रिया का विवरण अगले भाग में चर्चा किए गए CI/CD वर्कफ़्लो में दिखाई देता है।

क्यूबफ्लो पर विकास चक्र। विकास कार्यप्रवाह पीओसी के साथ बाईं ओर शुरू होता है। पूर्ण मॉडल को Amazon ECS पर चलने वाले एथेनहेल्थ मॉडल सर्विंग प्लेटफॉर्म पर तैनात किया गया है।

स्वचालित वर्कफ़्लो का समर्थन करने वाली CI/CD प्रक्रिया

हमारी CI/CD प्रक्रिया के हिस्से के रूप में, हम समानांतर में सभी Kubeflow घटक छवियों के निर्माण और परीक्षण के लिए जेनकिंस का उपयोग करते हैं। सफलतापूर्वक पूरा होने पर, पाइपलाइन घटक टेम्पलेट में छवियों के संदर्भ सूचक होते हैं, और परिणामी पाइपलाइन Kubeflow पर अपलोड की जाती है। जेनकिंस पाइपलाइन में पैरामीटर उपयोगकर्ताओं को सफल निर्माण के बाद पाइपलाइन लॉन्च करने और अपने मॉडल प्रशिक्षण परीक्षण चलाने की अनुमति देते हैं।

वैकल्पिक रूप से, एक छोटा विकास चक्र बनाए रखने के लिए, डेटा वैज्ञानिक अपने स्थानीय मशीन से पाइपलाइन लॉन्च कर सकते हैं, किसी भी पाइपलाइन पैरामीटर को संशोधित कर सकते हैं जिसका वे प्रयोग कर रहे हैं।

यह सुनिश्चित करने के लिए टूलिंग मौजूद है कि सीआई/सीडी बिल्ड से संदर्भ पॉइंटर्स डिफ़ॉल्ट रूप से उपयोग किए जाते हैं। यदि रेपो में एक परिनियोजन योग्य आर्टिफैक्ट है, तो CI/CD लॉजिक आर्टिफ़ैक्ट को Amazon ECS पर चलने वाले एथेनहेल्थ मॉडल सर्विंग प्लेटफ़ॉर्म (पूर्वानुमान सेवा) पर तैनात करना जारी रखेगा। AWS फरगेट. इन सभी चरणों के बीत जाने के बाद, डेटा वैज्ञानिक कोड को प्राथमिक शाखा में मिला देता है। पाइपलाइनों और परिनियोजन योग्य कलाकृतियों को तब उत्पादन में धकेल दिया जाता है।

सीआई/सीडी परिनियोजन कार्यप्रवाह। यह आरेख डेटा साइंस बिल्ड और परिनियोजन वर्कफ़्लो का वर्णन करता है। CI/CD प्रक्रिया किसके द्वारा संचालित होती है? जेनकींस.

सुरक्षा

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

डाटा सुरक्षा

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

यह सुनिश्चित करने के लिए कि हम डेटा अनुपालन मानकों को पूरा करते हैं, हम अपने एथेनहेल्थ उद्यम दिशानिर्देशों के अनुसार अपने एडब्ल्यूएस बुनियादी ढांचे का प्रावधान करते हैं। डेटा के लिए दो मुख्य स्टोर अत्यधिक स्केलेबल पाइपलाइन मेटाडेटा के लिए अमेज़ॅन आरडीएस और पाइपलाइन और मॉडल कलाकृतियों के लिए अमेज़ॅन एस 3 हैं। Amazon S3 के लिए, हम सुनिश्चित करते हैं कि बकेट एन्क्रिप्टेड हैं, HTTPS एंडपॉइंट लागू हैं, और बकेट नीतियां और AWS पहचान और अभिगम प्रबंधन (IAM) भूमिकाएँ डेटा तक पहुँच की अनुमति देते समय कम से कम विशेषाधिकार के सिद्धांतों का पालन करती हैं। यह अमेज़ॅन आरडीएस डेटा के लिए भी सच है: एन्क्रिप्शन हमेशा सक्षम होता है, और सुरक्षा समूह और क्रेडेंशियल एक्सेस कम से कम विशेषाधिकार के सिद्धांत का पालन करते हैं। यह मानकीकरण सुनिश्चित करता है कि केवल अधिकृत पक्षों के पास डेटा तक पहुंच है, और इस पहुंच को ट्रैक किया जाता है।

इन उपायों के अलावा, मंच सुरक्षा खतरे के आकलन और निरंतर सुरक्षा और अनुपालन स्कैन से भी गुजरता है।

हम संवेदनशील डेटा वाले सभी S3 बकेट के लिए डेटा जीवनचक्र प्रबंधन के माध्यम से डेटा प्रतिधारण आवश्यकताओं को भी संबोधित करते हैं। यह नीति स्वचालित रूप से डेटा को यहां ले जाती है अमेज़न S3 ग्लेशियर निर्माण के 30 दिनों के बाद। इसके अपवादों को डेटा पुनर्प्राप्ति अनुरोधों के माध्यम से प्रबंधित किया जाता है और मामला-दर-मामला आधार पर स्वीकृत या अस्वीकार किया जाता है। यह सुनिश्चित करता है कि सभी कार्यप्रवाह डेटा प्रतिधारण नीति का अनुपालन करते हैं। यह डेटा को पुनर्प्राप्त करने की समस्या को भी हल करता है यदि कोई मॉडल खराब प्रदर्शन करता है, और फिर से प्रशिक्षण की आवश्यकता होती है, या जब एक पुराने मॉडल के डेटासेट के ऐतिहासिक पुनरावृत्ति के खिलाफ एक नए मॉडल का मूल्यांकन किया जाना चाहिए।

एडब्ल्यूएस और अमेज़ॅन ईकेएस पर क्यूबफ्लो के भीतर से अमेज़ॅन एस 3 और अमेज़ॅन आरडीएस तक पहुंच को प्रतिबंधित करने के लिए, हम आईआरएसए (सेवा खातों के लिए आईएएम भूमिकाएं) का उपयोग करते हैं, जो कुबेरनेट्स के भीतर संसाधनों के लिए आईएएम-आधारित अनुमति प्रावधान प्रदान करता है। Kubeflow में प्रत्येक टैनेंट के पास एक अद्वितीय पूर्व-निर्मित सेवा खाता होता है जिसे हम टैनेंट एक्सेस आवश्यकताओं को पूरा करने के लिए विशेष रूप से बनाई गई IAM भूमिका के लिए बाध्य करते हैं। प्रत्येक उपयोगकर्ता के लिए Amazon Cognito उपयोगकर्ता पूल समूह सदस्यता का उपयोग करके किरायेदारों तक उपयोगकर्ता की पहुंच भी प्रतिबंधित है। जब उपयोगकर्ता को क्लस्टर के लिए प्रमाणित किया जाता है, तो उत्पन्न टोकन में समूह के दावे होते हैं, और Kubernetes RBAC इस जानकारी का उपयोग क्लस्टर में किसी विशेष संसाधन तक पहुंच की अनुमति देने या अस्वीकार करने के लिए करता है। इस सेटअप को अगले भाग में और अधिक विस्तार से समझाया गया है।

बहु-उपयोगकर्ता अलगाव का उपयोग करके क्लस्टर सुरक्षा

जैसा कि हमने पिछले अनुभाग में उल्लेख किया है, डेटा वैज्ञानिक खोजपूर्ण डेटा विश्लेषण करते हैं, डेटा विश्लेषण चलाते हैं, और एमएल मॉडल को प्रशिक्षित करते हैं। संसाधनों को आवंटित करने, डेटा व्यवस्थित करने और परियोजनाओं के आधार पर वर्कफ़्लो प्रबंधित करने के लिए, AWS पर Kubeflow Kubernetes नामस्थान के आधार पर अलगाव प्रदान करता है। यह आइसोलेशन Kubeflow UI के साथ इंटरैक्ट करने के लिए काम करता है; हालांकि, यह Kubectl का उपयोग करके Kubernetes API तक पहुंच को नियंत्रित करने के लिए कोई टूलिंग प्रदान नहीं करता है। इसका मतलब है कि उपयोगकर्ता की पहुंच Kubeflow UI पर नियंत्रित की जा सकती है लेकिन Kubernetes API पर Kubectl के माध्यम से नहीं।

निम्नलिखित आरेख में वर्णित वास्तुकला समूह सदस्यता के आधार पर क्यूबफ्लो में परियोजनाओं तक पहुंच को एकीकृत करके इस मुद्दे को संबोधित करती है। इसे प्राप्त करने के लिए, हमने AWS मैनिफ़ेस्ट पर Kubeflow का लाभ उठाया, जिसका Amazon Cognito उपयोगकर्ता पूल के साथ एकीकरण है। इसके अलावा, हम क्लस्टर के भीतर प्राधिकरण को नियंत्रित करने के लिए Kubernetes भूमिका-आधारित अभिगम नियंत्रण (RBAC) का उपयोग करते हैं। उपयोगकर्ता अनुमतियों का प्रावधान Amazon Cognito समूह सदस्यता के आधार पर किया जाता है। यह जानकारी OIDC क्लाइंट द्वारा उत्पन्न टोकन के साथ क्लस्टर को दी जाती है। इस प्रक्रिया को सरल बनाया गया है, अंतर्निहित अमेज़ॅन ईकेएस कार्यक्षमता के लिए धन्यवाद जो ओआईडीसी पहचान प्रदाताओं को क्लस्टर के साथ प्रमाणित करने की अनुमति देता है।

डिफ़ॉल्ट रूप से, Amazon EKS प्रमाणीकरण IAM प्रमाणक द्वारा किया जाता है, जो एक ऐसा उपकरण है जो IAM क्रेडेंशियल्स का उपयोग करके EKS क्लस्टर के साथ प्रमाणीकरण को सक्षम बनाता है। इस प्रमाणीकरण पद्धति के अपने गुण हैं; हालांकि, यह हमारे उपयोग के मामले के लिए उपयुक्त नहीं है क्योंकि एथेनहेल्थ पूरे संगठन में पहचान सेवा के लिए Microsoft Azure Active Directory का उपयोग करता है।

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

Azure Active Directory, एक एंटरप्राइज़-व्यापी पहचान सेवा होने के नाते, Kubeflow क्लस्टर में उपयोगकर्ता की पहुँच को नियंत्रित करने के लिए सत्य का स्रोत है। इसके लिए सेटअप में एक Azure एंटरप्राइज़ एप्लिकेशन बनाना शामिल है जो सेवा प्रिंसिपल के रूप में कार्य करता है और विभिन्न किरायेदारों के लिए समूह जोड़ता है जिन्हें क्लस्टर तक पहुंच की आवश्यकता होती है। Azure पर यह सेटअप Amazon Cognito में एक फ़ेडरेटेड OIDC पहचान प्रदाता की स्थापना करके दिखाया गया है जो Azure को प्रमाणीकरण जिम्मेदारी आउटसोर्स करता है। Azure समूहों तक पहुंच को SailPoint IdentityIQ द्वारा नियंत्रित किया जाता है, जो परियोजना के स्वामी को अनुमति देने या उचित रूप से अस्वीकार करने के लिए एक्सेस अनुरोध भेजता है। Amazon Cognito उपयोगकर्ता पूल में, दो एप्लिकेशन क्लाइंट बनाए जाते हैं: एक का उपयोग OIDC पहचान प्रदाता का उपयोग करके Kubernetes क्लस्टर के लिए प्रमाणीकरण सेट करने के लिए किया जाता है, और दूसरा Kubeflow UI में Kubeflow प्रमाणीकरण को सुरक्षित करने के लिए किया जाता है। इन क्लाइंट को क्लस्टर के साथ प्रमाणीकरण पर समूह दावों को पारित करने के लिए कॉन्फ़िगर किया गया है, और इन समूह दावों का उपयोग क्लस्टर के भीतर प्राधिकरण स्थापित करने के लिए RBAC के साथ किया जाता है।

Kubernetes RBAC भूमिका बाइंडिंग समूहों और क्लस्टर भूमिका Kubeflow-edit के बीच स्थापित की जाती है, जो क्लस्टर में Kubeflow स्थापित करने पर बनाई जाती है। यह भूमिका बंधन सुनिश्चित करता है कि कोई भी उपयोगकर्ता ओआईडीसी के माध्यम से लॉग इन करने के बाद क्लस्टर के साथ इंटरैक्ट कर रहा है, वे उन नामस्थानों तक पहुंच सकते हैं जिनके लिए उनके समूह दावों में परिभाषित किया गया है। यद्यपि यह Kubectl का उपयोग करके क्लस्टर के साथ इंटरैक्ट करने वाले उपयोगकर्ताओं के लिए काम करता है, Kubeflow UI वर्तमान में समूह सदस्यता के आधार पर उपयोगकर्ताओं तक पहुंच का प्रावधान नहीं करता है क्योंकि यह RBAC का उपयोग नहीं करता है। इसके बजाय, यह उपयोगकर्ताओं के लिए पहुँच को नियंत्रित करने के लिए इस्तियो प्राधिकरण नीति संसाधन का उपयोग करता है। इस चुनौती को दूर करने के लिए, हमने एक कस्टम नियंत्रक विकसित किया है जो अमेज़ॅन कॉग्निटो समूहों को मतदान करके उपयोगकर्ताओं को सिंक्रनाइज़ करता है और समूह के बजाय प्रत्येक उपयोगकर्ता के लिए संबंधित भूमिका बाइंडिंग जोड़ता या हटाता है। Kubeflow UI और Kubectl दोनों के साथ इंटरैक्ट करते समय यह सेटअप उपयोगकर्ताओं को समान स्तर की अनुमतियाँ प्राप्त करने में सक्षम बनाता है।

कार्यकारी कुशलता

इस खंड में, हम चर्चा करते हैं कि हमने अपने वर्कफ़्लो को प्रबंधित करने और डीबग करने के साथ-साथ Kubeflow के उन्नयन के परिचालन प्रभाव को कम करने के लिए हमारे पास उपलब्ध ओपन सोर्स और AWS टूल का लाभ कैसे उठाया।

लॉगिंग और निगरानी

लॉगिंग के लिए, हम अपने सभी कंटेनर लॉग को आगे बढ़ाने के लिए FluentD का उपयोग करते हैं अमेज़न ओपन सर्च सर्विस और सिस्टम मेट्रिक्स प्रोमेथियस के लिए। फिर हम लॉग और मेट्रिक्स को खोजने और फ़िल्टर करने के लिए किबाना और ग्राफाना यूआई का उपयोग करते हैं। निम्नलिखित आरेख वर्णन करता है कि हम इसे कैसे सेट करते हैं।

क्यूबफ्लो लॉगिंग। लॉग्स को देखने और छानने के लिए हम Grafana UI और Kibana दोनों का उपयोग करते हैं

निम्नलिखित स्क्रीनशॉट हमारी पाइपलाइन से एक किबाना यूआई दृश्य है।

नमूना किबाना यूआई व्यू। किबाना अनुकूलित दृश्यों की अनुमति देता है।

सुरक्षित Kubeflow क्लस्टर उन्नयन

जब हम AWS पर Kubeflow के उपयोगकर्ताओं को ऑनबोर्ड करते हैं, तो हम MLOps टीम को नई सुविधाओं को जारी करने और एकीकृत करने के साथ चुस्त रहने की अनुमति देते हुए एक विश्वसनीय और सुसंगत उपयोगकर्ता अनुभव बनाए रखते हैं। सतह पर, Kustomize दूसरों को प्रभावित किए बिना एक समय में एक घटक को काम करने और अपग्रेड करने में सक्षम करने के लिए मॉड्यूलर लगता है, जिससे हमें उपयोगकर्ताओं को न्यूनतम व्यवधान के साथ नई क्षमताओं को जोड़ने की अनुमति मिलती है। हालांकि, व्यवहार में ऐसे परिदृश्य हैं जहां मौजूदा क्लस्टर के लिए घटक-स्तर के उन्नयन को लागू करने के बजाय नए कुबेरनेट्स क्लस्टर को बस स्पिन करने का सबसे अच्छा तरीका है। हमें दो उपयोग के मामले मिले जहां पूरी तरह से नए क्लस्टर बनाने के लिए यह अधिक समझ में आया:

• Kubernetes संस्करण में अपग्रेड करना जहां AWS इन-प्लेस क्लस्टर अपग्रेड प्रदान करता है। हालाँकि, यह परीक्षण करना मुश्किल हो जाता है कि क्या प्रत्येक Kubeflow और Kubernetes संसाधन इरादे के अनुसार काम कर रहे हैं और मैनिफ़ेस्ट पिछड़ी संगतता बनाए रखते हैं।
• Kubeflow को एक नई रिलीज़ में अपग्रेड करना जहाँ कई सुविधाएँ जोड़ी या संशोधित की गई हैं और मौजूदा Kubernetes क्लस्टर पर इन-प्लेस अपग्रेड करना लगभग हमेशा एक आशाजनक विचार नहीं है।

इस मुद्दे को हल करने में, हमने एक रणनीति विकसित की है जो हमें किसी भी मौजूदा कार्यभार को प्रभावित किए बिना सुरक्षित क्लस्टर प्रतिस्थापन करने में सक्षम बनाती है। इसे प्राप्त करने के लिए, हमें निम्नलिखित मानदंडों को पूरा करना होगा:

• Kubeflow संग्रहण को अलग करें और संसाधनों की गणना करें ताकि पुराने क्लस्टर को हटाते समय पाइपलाइन मेटाडेटा, पाइपलाइन कलाकृतियों और उपयोगकर्ता डेटा को बनाए रखा जाए
• एडब्ल्यूएस मेनिफेस्ट पर क्यूबफ्लो के साथ एकीकृत करें ताकि जब क्यूबफ्लो संस्करण अपग्रेड हो, तो न्यूनतम बदलाव की आवश्यकता हो
• क्लस्टर अपग्रेड के बाद चीजें गलत होने पर वापस रोल करने का एक आसान तरीका है
• एक उम्मीदवार क्लस्टर को उत्पादन के लिए बढ़ावा देने के लिए एक सरल इंटरफ़ेस रखें

निम्नलिखित चित्र इस वास्तुकला को दर्शाता है।

सुरक्षित Kubeflow क्लस्टर अपग्रेड। Kubeflow कैंडिडेट का परीक्षण सफल होने के बाद, इसे रूट 53 के अपडेट के माध्यम से Kubeflow Prod में पदोन्नत किया जाता है।

AWS मेनिफेस्ट पर Kubeflow Amazon RDS और Amazon S3 इंटीग्रेशन के साथ प्री-पैकेज्ड आता है। इन प्रबंधित सेवाओं के साथ सामान्य डेटा स्टोर के रूप में कार्य करने के साथ, हम एक नीली-हरी परिनियोजन रणनीति स्थापित कर सकते हैं। इसे प्राप्त करने के लिए, हमने सुनिश्चित किया कि अमेज़ॅन आरडीएस में पाइपलाइन मेटाडेटा कायम है, जो ईकेएस क्लस्टर से स्वतंत्र रूप से काम करता है, और पाइपलाइन लॉग और कलाकृतियां अमेज़ॅन एस 3 में बनी रहती हैं। पाइपलाइन मेटाडेटा और कलाकृतियों के अलावा, हमने पॉड लॉग को Amazon OpenSearch सेवा में रूट करने के लिए FluentD भी सेट किया है।

यह सुनिश्चित करता है कि स्टोरेज लेयर पूरी तरह से कंप्यूट लेयर से अलग है और इस तरह पूरी तरह से नए ईकेएस क्लस्टर पर क्यूबफ्लो संस्करण अपडेट के दौरान परीक्षण परिवर्तनों को सक्षम बनाता है। सभी परीक्षण सफल होने के बाद, हम बस इसे बदलने में सक्षम हैं अमेज़ॅन रूट 53 Kubeflow की मेजबानी करने वाले उम्मीदवार क्लस्टर के लिए DNS रिकॉर्ड। इसके अलावा, हम पुराने क्लस्टर को कुछ दिनों के लिए बैकअप के रूप में चालू रखते हैं, जब हमें वापस रोल करने की आवश्यकता होती है।

हमारी ML पाइपलाइन के लिए AWS पर Amazon EKS और Kubeflow के लाभ

Amazon EKS और Kubeflow on AWS पैकेज ने हमारे विकास वर्कफ़्लो को एक ऐसे पैटर्न में बदल दिया है जो दोहराने योग्य मॉडल प्रशिक्षण को दृढ़ता से प्रोत्साहित करता है। ये उपकरण हमें पूरी तरह से परिभाषित किरायेदारों के साथ पूरी तरह से परिभाषित क्लस्टर रखने और पूरी तरह से परिभाषित कोड चलाने की अनुमति देते हैं।

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

हमने AWS प्रबंधित सेवाओं के साथ Kubeflow एकीकरण में सुधार को भी लाभकारी पाया। उदाहरण के लिए, Amazon RDS, Amazon S3 और Amazon Cognito को AWS मैनिफ़ेस्ट पर Kubeflow में पूर्व-कॉन्फ़िगर किए जाने के साथ, हम Kubeflow के नए वितरणों को अपडेट करने में लगने वाले समय और प्रयास की बचत करते हैं। जब हम आधिकारिक Kubeflow मैनिफ़ेस्ट को मैन्युअल रूप से संशोधित करते थे, तो नए संस्करण में अपडेट करने में डिज़ाइन से लेकर परीक्षण तक कई सप्ताह लगेंगे।

Amazon EKS पर स्विच करने से हमें अपने क्लस्टर को Kustomize (अब Kubectl का हिस्सा) और टेराफॉर्म में परिभाषित करने का अवसर मिलता है। यह पता चला है कि मंच के काम के लिए, कुबेरनेट्स और टेराफॉर्म सीखने के लिए पर्याप्त समय लगाने के बाद काम करना बहुत आसान है। कई पुनरावृत्तियों के बाद, हमारे लिए उपलब्ध उपकरण मानक प्लेटफ़ॉर्म संचालन करना बहुत आसान बनाते हैं जैसे किसी घटक को अपग्रेड करना या संपूर्ण विकास क्लस्टर को स्वैप करना। कच्चे से नौकरी चलाने की तुलना में अमेज़ॅन इलास्टिक कम्प्यूट क्लाउड (अमेज़ॅन ईसी 2) उदाहरणों में, यह तुलना करना कठिन है कि गारंटीकृत संसाधन सफाई और अंतर्निहित पुनः प्रयास तंत्र के साथ अच्छी तरह से परिभाषित पॉड्स के लिए यह कितना बड़ा अंतर बनाता है।

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

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

Kubeflow का उपयोग करने से एकल EC2 इंस्टेंस पर चलने की तुलना में बहुत अधिक प्रदर्शन में सुधार होता है। अक्सर मॉडल प्रशिक्षण में, डेटा वैज्ञानिकों को प्रीप्रोसेसिंग और प्रशिक्षण के लिए विभिन्न उपकरणों और अनुकूलन की आवश्यकता होती है। उदाहरण के लिए, प्रीप्रोसेसिंग अक्सर स्पार्क जैसे वितरित डेटा प्रोसेसिंग टूल का उपयोग करके चलाया जाता है, जबकि प्रशिक्षण अक्सर GPU इंस्टेंस का उपयोग करके चलाया जाता है। Kubeflow पाइपलाइन के साथ, वे पाइपलाइन में विभिन्न चरणों के लिए अलग-अलग उदाहरण प्रकार निर्दिष्ट कर सकते हैं। यह उन्हें एक चरण में शक्तिशाली GPU इंस्टेंस और दूसरे चरण में वितरित प्रसंस्करण के लिए छोटी मशीनों के बेड़े का उपयोग करने की अनुमति देता है। इसके अलावा, क्योंकि Kubeflow पाइपलाइन चरणों के बीच निर्भरता का वर्णन करती है, पाइपलाइन समानांतर में चरणों को चला सकती है।

अंत में, क्योंकि हमने टेनेंट को क्लस्टर में जोड़ने के लिए एक प्रक्रिया बनाई है, अब क्लस्टर पर टैनेंट के लिए टीमों को पंजीकृत करने का एक अधिक औपचारिक तरीका है। चूंकि हम अपने ईकेएस क्लस्टर में लागतों को ट्रैक करने के लिए कुबेकॉस्ट का उपयोग करते हैं, यह हमें खाता स्तर पर लागत को जिम्मेदार ठहराने के बजाय एक एकल परियोजना के लिए लागत को विशेषता देने की अनुमति देता है, जिसमें सभी डेटा विज्ञान परियोजनाएं शामिल हैं। Kubecost प्रति नाम स्थान पर खर्च किए गए धन की एक रिपोर्ट प्रस्तुत करता है, जो कि पाइपलाइन चलाने के लिए जिम्मेदार किरायेदार या टीम के साथ कसकर जुड़ा होता है।

सभी लाभों के बावजूद, हम केवल इस प्रकार के माइग्रेशन को करने के लिए सावधान रहेंगे यदि उपयोगकर्ताओं से कुल खरीद-फरोख्त हो। जो उपयोगकर्ता समय लगाते हैं उन्हें Amazon EKS और Kubernetes का उपयोग करने से बहुत लाभ मिलता है, लेकिन सीखने की एक महत्वपूर्ण अवस्था है।

निष्कर्ष

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

हमने अपनी एमएलओपीएस क्षमताओं को बढ़ाने और अपनी परियोजनाओं की संख्या और आकार को बढ़ाने के लिए एक ठोस आधार भी स्थापित किया है। उदाहरण के लिए, जैसा कि हम मॉडल वंश और ट्रैकिंग में अपने शासन की मुद्रा को सख्त करते हैं, हमने अपना ध्यान 15 से अधिक वर्कफ़्लोज़ से घटाकर केवल एक कर दिया है। और जब 4 के अंत में Log2021shell भेद्यता प्रकाश में आई, तो हम एकल वर्कफ़्लो पर ध्यान केंद्रित करने में सक्षम थे और आवश्यकता के अनुसार जल्दी से उपचार कर सकते थे (प्रदर्शन कर रहे थे) अमेज़ॅन इलास्टिक कंटेनर रजिस्ट्री (अमेज़ॅन ईसीआर) डेटा वैज्ञानिकों द्वारा चल रहे काम पर न्यूनतम प्रभाव के साथ स्कैन, अमेज़ॅन ओपनसर्च सर्विस को अपग्रेड करना, हमारे टूलिंग को अपडेट करना, और बहुत कुछ)। जैसे-जैसे AWS और Kubeflow एन्हांसमेंट उपलब्ध होते जाते हैं, वैसे-वैसे हम उन्हें शामिल कर सकते हैं।

यह हमें AWS अपनाने पर हमारे Kubeflow के एक महत्वपूर्ण और कम किए गए पहलू पर लाता है। इस यात्रा के महत्वपूर्ण परिणामों में से एक हमारे डेटा वैज्ञानिकों के लिए Kubeflow में अपग्रेड और एन्हांसमेंट को मूल रूप से रोल आउट करने की क्षमता है। हालाँकि हमने पहले इस पर अपने दृष्टिकोण पर चर्चा की थी, हम AWS द्वारा प्रदान किए गए Kubeflow मैनिफ़ेस्ट पर भी भरोसा करते हैं। हमने संस्करण 2019 के जारी होने से पहले 1.0.0 में अवधारणा के प्रमाण के रूप में अपनी Kubeflow यात्रा शुरू की थी। (हम वर्तमान में 1.4.1 पर हैं, 1.5 का मूल्यांकन कर रहे हैं। एडब्ल्यूएस पहले से ही 1.6 संस्करण पर काम कर रहा है।) बीच के 3 वर्षों में, पर्याप्त सामग्री के साथ कम से कम छह रिलीज हुई हैं। इन उन्नयनों को एकीकृत और मान्य करने के लिए अपने अनुशासित दृष्टिकोण के माध्यम से और अनुमानित, विश्वसनीय समय पर घोषणापत्र जारी करने के लिए, एडब्ल्यूएस में क्यूबफ्लो टीम एथेनहेल्थ एमएलओप्स टीम को हमारे विकास रोडमैप की योजना बनाने में सक्षम बनाने में महत्वपूर्ण रही है, और इसके परिणामस्वरूप हमारे संसाधन आवंटन और फोकस के क्षेत्र , भविष्य में और अधिक आत्मविश्वास के साथ।

आप इस का पालन कर सकते हैं एडब्ल्यूएस लैब्स गिटहब रिपोजिटरी Kubeflow में सभी AWS योगदानों को ट्रैक करने के लिए। आप एडब्ल्यूएस टीमों को भी ढूंढ सकते हैं Kubeflow #AWS स्लैक चैनल; आपकी प्रतिक्रिया AWS को Kubeflow प्रोजेक्ट में योगदान करने के लिए अगली सुविधाओं को प्राथमिकता देने में मदद करती है।

---

लेखक के बारे में

कंवलजीत खुर्मी Amazon वेब सर्विसेज में सीनियर सॉल्यूशन आर्किटेक्ट हैं। वह AWS ग्राहकों के साथ मार्गदर्शन और तकनीकी सहायता प्रदान करने के लिए काम करता है जिससे उन्हें AWS का उपयोग करते समय उनके समाधानों के मूल्य में सुधार करने में मदद मिलती है। कंवलजीत कंटेनरीकृत और मशीन लर्निंग एप्लिकेशन के साथ ग्राहकों की मदद करने में माहिर हैं।

टायलर कलबाच एथेनहेल्थ में तकनीकी स्टाफ के प्रधान सदस्य हैं। टायलर के पास हेल्थकेयर स्पेस में एनालिटिक्स, डेटा साइंस, न्यूरल नेटवर्क्स और मशीन लर्निंग एप्लिकेशन के विकास में लगभग 7 साल का अनुभव है। उन्होंने कई मशीन लर्निंग समाधानों में योगदान दिया है जो वर्तमान में उत्पादन यातायात की सेवा कर रहे हैं। वर्तमान में एथेनहेल्थ के इंजीनियरिंग संगठन में एक प्रधान डेटा वैज्ञानिक के रूप में कार्यरत, टायलर उस टीम का हिस्सा रहा है जिसने उस प्रयास की शुरुआत से एथेनहेल्थ के लिए नया मशीन लर्निंग ट्रेनिंग प्लेटफॉर्म बनाया है।

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

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

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

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