สร้างเวิร์กโฟลว์การเรียนรู้ของเครื่องแบบ end-to-end ที่ทำซ้ำได้ ปลอดภัย และขยายได้โดยใช้ Kubeflow บน AWS

นี่คือบล็อกโพสต์ของแขกที่เขียนร่วมกับ athenahealth

สุขภาพ ผู้ให้บริการซอฟต์แวร์และบริการเครือข่ายชั้นนำสำหรับกลุ่มแพทย์และระบบสุขภาพทั่วประเทศ บันทึกสุขภาพอิเล็กทรอนิกส์ การจัดการวงจรรายได้ และเครื่องมือการมีส่วนร่วมของผู้ป่วยช่วยให้เข้าถึงได้ทุกที่ทุกเวลา ขับเคลื่อนผลลัพธ์ทางการเงินที่ดีขึ้นสำหรับลูกค้า และทำให้ลูกค้าของผู้ให้บริการสามารถให้การดูแลที่มีคุณภาพดีขึ้น

ในพื้นที่ปัญญาประดิษฐ์ (AI) athenahealth ใช้วิทยาศาสตร์ข้อมูลและการเรียนรู้ของเครื่อง (ML) เพื่อเร่งกระบวนการทางธุรกิจและให้คำแนะนำ การคาดการณ์ และข้อมูลเชิงลึกในบริการต่างๆ ตั้งแต่การใช้งานครั้งแรกในบริการเอกสารอัตโนมัติ การประมวลผลเอกสารผู้ให้บริการและผู้ป่วยนับล้านแบบไม่สัมผัส ไปจนถึงงานล่าสุดในผู้ช่วยเสมือนและการปรับปรุงประสิทธิภาพของวงจรรายได้ athenahealth ยังคงใช้ AI เพื่อช่วยขับเคลื่อนประสิทธิภาพ ความสามารถในการให้บริการ และผลลัพธ์ที่ดีขึ้นสำหรับผู้ให้บริการ และผู้ป่วยของพวกเขา

โพสต์บล็อกนี้แสดงให้เห็นว่า athenahealth ใช้อย่างไร Kubeflow บน AWS (การกระจาย Kubeflow เฉพาะสำหรับ AWS) เพื่อสร้างและปรับปรุงเวิร์กโฟลว์วิทยาศาสตร์ข้อมูลแบบครบวงจรที่รักษาเครื่องมือที่จำเป็น เพิ่มประสิทธิภาพในการดำเนินงาน เพิ่มประสิทธิภาพการทำงานของนักวิทยาศาสตร์ข้อมูล และกำหนดขั้นตอนสำหรับการขยายขีดความสามารถ ML ได้ง่ายขึ้น

Kubeflow เป็นแพลตฟอร์ม ML แบบโอเพนซอร์สที่ทุ่มเทให้กับการทำให้เวิร์กโฟลว์ ML ใช้งานได้บน Kubernetes ที่เรียบง่าย พกพาสะดวก และปรับขนาดได้ Kubeflow บรรลุเป้าหมายนี้ด้วยการผสมผสานเครื่องมือโอเพนซอร์สที่เกี่ยวข้องซึ่งทำงานร่วมกับ Kubernetes ได้ดี โปรเจ็กต์เหล่านี้บางส่วน ได้แก่ Argo สำหรับการประสานไปป์ไลน์, Istio สำหรับบริการเมช, Jupyter สำหรับโน้ตบุ๊ก, Spark, TensorBoard และ Katib Kubeflow Pipelines ช่วยสร้างและปรับใช้เวิร์กโฟลว์ ML แบบพกพาที่ปรับขนาดได้ ซึ่งรวมถึงขั้นตอนต่างๆ เช่น การดึงข้อมูล การประมวลผลล่วงหน้า การฝึกโมเดล และการประเมินโมเดลในรูปแบบของไปป์ไลน์ที่ทำซ้ำได้

AWS ให้การสนับสนุนชุมชน Kubeflow แบบโอเพนซอร์สด้วยการจัดหา Kubeflow distribution ของตนเอง (เรียกว่า Kubeflow บน AWS) ซึ่งช่วยให้องค์กรต่างๆ เช่น athenahealth สร้างเวิร์กโฟลว์ ML ที่เชื่อถือได้สูง ปลอดภัย พกพาสะดวก และปรับขนาดได้ โดยมีค่าใช้จ่ายในการดำเนินงานลดลงผ่านการผสานรวมกับบริการที่มีการจัดการของ AWS AWS มีตัวเลือกการปรับใช้ Kubeflow ต่างๆ เช่น การปรับใช้ด้วย Amazon Cognito Co, ปรับใช้กับ บริการฐานข้อมูลเชิงสัมพันธ์ของ Amazon (Amazon RDS) และ บริการจัดเก็บข้อมูลอย่างง่ายของ Amazon (Amazon S3) และการปรับใช้วานิลลา สำหรับรายละเอียดเกี่ยวกับการรวมบริการและส่วนเสริมที่พร้อมใช้งานสำหรับแต่ละตัวเลือกเหล่านี้ โปรดดูที่ การใช้งาน.

วันนี้ Kubeflow บน AWS ให้เส้นทางที่ชัดเจนในการใช้ Kubeflow โดยเสริมด้วยบริการของ AWS ต่อไปนี้:

ลูกค้า AWS จำนวนมากใช้ประโยชน์จาก Kubeflow บนการกระจายของ AWS รวมถึง athenahealth

ที่นี่ ทีม athenahealth MLOps หารือเกี่ยวกับความท้าทายที่พวกเขาพบและวิธีแก้ปัญหาที่พวกเขาสร้างขึ้นในการเดินทางของ Kubeflow

ความท้าทายกับสภาพแวดล้อม ML ก่อนหน้า

ก่อนการนำ Kubeflow บน AWS มาใช้ นักวิทยาศาสตร์ข้อมูลของเราใช้ชุดเครื่องมือที่ได้มาตรฐานและกระบวนการที่อนุญาตให้มีความยืดหยุ่นในเทคโนโลยีและเวิร์กโฟลว์ที่ใช้ในการฝึกโมเดลที่กำหนด ตัวอย่างส่วนประกอบของเครื่องมือที่ได้มาตรฐาน ได้แก่ API การนำเข้าข้อมูล เครื่องมือสแกนความปลอดภัย ไปป์ไลน์ CI/CD ที่สร้างและดูแลโดยทีมอื่นภายใน athenahealth และแพลตฟอร์มการให้บริการทั่วไปที่สร้างและดูแลโดยทีม MLOps อย่างไรก็ตาม เมื่อการใช้ AI และ ML ของเราเติบโตเต็มที่ เครื่องมือและโครงสร้างพื้นฐานที่หลากหลายที่สร้างขึ้นสำหรับแต่ละรุ่นก็เพิ่มขึ้น แม้ว่าเราจะยังสามารถสนับสนุนกระบวนการที่มีอยู่ได้ แต่เราเห็นความท้าทายดังต่อไปนี้:

• การบำรุงรักษาและการเติบโต – การสร้างและบำรุงรักษาสภาพแวดล้อมการฝึกโมเดลต้องใช้ความพยายามมากขึ้นเมื่อจำนวนโมเดลที่ปรับใช้เพิ่มขึ้น แต่ละโปรเจ็กต์เก็บรักษาเอกสารรายละเอียดที่สรุปว่าแต่ละสคริปต์ถูกใช้เพื่อสร้างแบบจำลองขั้นสุดท้ายอย่างไร ในหลายกรณี นี่เป็นกระบวนการที่ซับซ้อนซึ่งเกี่ยวข้องกับสคริปต์ 5 ถึง 10 ตัว โดยแต่ละเอาต์พุตจะมีหลายเอาต์พุต สิ่งเหล่านี้ต้องถูกติดตามด้วยตนเองพร้อมคำแนะนำโดยละเอียดเกี่ยวกับวิธีการใช้แต่ละเอาต์พุตในกระบวนการที่ตามมา การรักษาสิ่งนี้เมื่อเวลาผ่านไปกลายเป็นเรื่องยุ่งยาก นอกจากนี้ เนื่องจากโครงการมีความซับซ้อนมากขึ้น จำนวนเครื่องมือก็เพิ่มขึ้นด้วย ตัวอย่างเช่น โมเดลส่วนใหญ่ใช้ Spark และ TensorFlow กับ GPU ซึ่งต้องการการกำหนดค่าสภาพแวดล้อมที่หลากหลายมากขึ้น เมื่อเวลาผ่านไป ผู้ใช้จะเปลี่ยนไปใช้เครื่องมือเวอร์ชันใหม่กว่าในสภาพแวดล้อมการพัฒนา แต่ก็ไม่สามารถเรียกใช้สคริปต์ที่เก่ากว่าได้เมื่อเวอร์ชันเหล่านั้นเข้ากันไม่ได้ ดังนั้น การบำรุงรักษาและเพิ่มโครงการเก่าต้องใช้เวลาและความพยายามด้านวิศวกรรมมากขึ้น นอกจากนี้ เมื่อนักวิทยาศาสตร์ข้อมูลใหม่เข้าร่วมทีม การถ่ายโอนความรู้และการเริ่มต้นใช้งานก็ใช้เวลามากขึ้น เนื่องจากการซิงโครไนซ์สภาพแวดล้อมในเครื่องนั้นรวมถึงการพึ่งพาที่ไม่มีเอกสารจำนวนมาก การสลับไปมาระหว่างโปรเจ็กต์ประสบปัญหาเดียวกัน เนื่องจากแต่ละโมเดลมีเวิร์กโฟลว์ของตัวเอง
• Security – เราให้ความสำคัญกับการรักษาความปลอดภัยอย่างจริงจัง และด้วยเหตุนี้จึงจัดลำดับความสำคัญของการปฏิบัติตามภาระหน้าที่ตามสัญญา กฎหมาย และข้อบังคับทั้งหมดที่เกี่ยวข้องกับ ML และวิทยาศาสตร์ข้อมูล ข้อมูลจะต้องถูกใช้ จัดเก็บ และเข้าถึงด้วยวิธีเฉพาะ และเราได้ฝังกระบวนการที่มีประสิทธิภาพเพื่อให้แน่ใจว่าแนวทางปฏิบัติของเราสอดคล้องกับภาระผูกพันทางกฎหมายของเรา รวมทั้งสอดคล้องกับแนวทางปฏิบัติที่ดีที่สุดในอุตสาหกรรม ก่อนการนำ Kubeflow มาใช้ ตรวจสอบให้แน่ใจว่าข้อมูลได้รับการจัดเก็บและเข้าถึงในลักษณะเฉพาะ ซึ่งเกี่ยวข้องกับการตรวจสอบเป็นประจำในเวิร์กโฟลว์ที่หลากหลายและหลากหลาย เรารู้ว่าเราสามารถปรับปรุงประสิทธิภาพได้โดยการรวมเวิร์กโฟลว์ที่หลากหลายเหล่านี้ไว้ในแพลตฟอร์มเดียว อย่างไรก็ตาม แพลตฟอร์มนั้นจะต้องมีความยืดหยุ่นเพียงพอที่จะรวมเข้ากับเครื่องมือที่ได้มาตรฐานของเราได้ดี
• การดำเนินการ – เรายังเห็นโอกาสในการเพิ่มประสิทธิภาพการดำเนินงานและการจัดการผ่านการรวมศูนย์การบันทึกและการตรวจสอบเวิร์กโฟลว์ เนื่องจากแต่ละทีมได้พัฒนาเครื่องมือของตนเอง เราจึงรวบรวมข้อมูลนี้จากแต่ละเวิร์กโฟลว์และรวมเข้าด้วยกัน

ทีมวิทยาศาสตร์ข้อมูลได้ประเมินโซลูชันต่างๆ สำหรับการรวมเวิร์กโฟลว์ นอกเหนือจากการจัดการกับข้อกำหนดเหล่านี้แล้ว เรามองหาโซลูชันที่จะผสานรวมกับโครงสร้างพื้นฐานและเครื่องมือที่ได้มาตรฐานอย่างราบรื่น เราเลือก Amazon EKS และ Kubeflow บน AWS เป็นโซลูชันเวิร์กโฟลว์ของเรา

วัฏจักรการพัฒนานักวิทยาศาสตร์ข้อมูลซึ่งรวม Kubeflow

โครงการวิทยาศาสตร์ข้อมูลเริ่มต้นด้วยกระดานชนวนที่สะอาด: ไม่มีข้อมูล ไม่มีรหัส มีเพียงปัญหาทางธุรกิจที่สามารถแก้ไขได้ด้วย ML งานแรกคือการพิสูจน์แนวคิด (POC) เพื่อค้นหาว่าข้อมูลมีสัญญาณเพียงพอที่จะทำให้แบบจำลอง ML มีประสิทธิภาพในการแก้ปัญหาทางธุรกิจหรือไม่ โดยเริ่มจากการสืบค้นชุดข้อมูลดิบจากคลังข้อมูล Snowflake ของเรา ขั้นตอนนี้เป็นแบบวนซ้ำ และนักวิทยาศาสตร์ด้านข้อมูลใช้พ็อด Kubernetes หรือโน้ตบุ๊ก Kubeflow Jupyter ในระหว่างกระบวนการนี้

คลัสเตอร์ Kubeflow ของเราใช้ตัวปรับขนาดคลัสเตอร์ Karpenter อัตโนมัติ ซึ่งทำให้การหมุนทรัพยากรเป็นเรื่องง่ายสำหรับนักวิทยาศาสตร์ข้อมูล เนื่องจากต้องมุ่งเน้นที่การกำหนดประเภทอินสแตนซ์ที่ต้องการเท่านั้น ในขณะที่การจัดเตรียมจะดำเนินการโดยชุดของตัวจัดเตรียม Karpenter ที่กำหนดไว้ล่วงหน้า เรามีตัวจัดเตรียมแยกกันสำหรับประเภทอินสแตนซ์ CPU และ GPU และอินสแตนซ์ทั้งหมดที่รองรับโดย Amazon EKS จะอยู่ในหนึ่งในสองหมวดหมู่นี้ตามการกำหนดค่าตัวจัดสรรของเรา นักวิทยาศาสตร์ข้อมูลเลือกประเภทอินสแตนซ์โดยใช้ตัวเลือกโหนด และ Karpenter จะดูแลการจัดการวงจรชีวิตของโหนด

หลังจากการสืบค้นได้รับการพัฒนา นักวิทยาศาสตร์ด้านข้อมูลจะดึงข้อมูลดิบไปยังตำแหน่งบน Amazon S3 จากนั้นเปิดใช้โน้ตบุ๊ก Jupyter จาก AWS Kubeflow UI เพื่อสำรวจข้อมูล เป้าหมายคือการสร้างชุดคุณลักษณะที่จะใช้ในการฝึกโมเดลแรก ซึ่งช่วยให้นักวิทยาศาสตร์ข้อมูลสามารถตรวจสอบว่ามีสัญญาณเพียงพอในข้อมูลเพื่อตอบสนองความต้องการทางธุรกิจของลูกค้าหรือไม่

หลังจากผลลัพธ์เป็นที่น่าพอใจ นักวิทยาศาสตร์ด้านข้อมูลจะเข้าสู่ขั้นตอนต่อไปของวัฏจักรการพัฒนาและเปลี่ยนการค้นพบของพวกเขาให้กลายเป็นไปป์ไลน์ที่แข็งแกร่ง พวกเขาแปลงรหัส POC เป็นรหัสคุณภาพการผลิตที่ทำงานตามขนาด เพื่อให้เป็นไปตามข้อกำหนดโดยใช้ไลบรารีที่ได้รับอนุมัติ คอนเทนเนอร์จะถูกสร้างขึ้นด้วยอิมเมจ Docker พื้นฐานที่เหมาะสม สำหรับนักวิทยาศาสตร์ด้านข้อมูลของเรา เราพบว่าการจัดเตรียมอิมเมจพื้นฐานของ Python, TensorFlow และ Spark ให้ความยืดหยุ่นเพียงพอสำหรับปริมาณงานส่วนใหญ่ หรือไม่ทั้งหมด จากนั้นจึงใช้ Dockerfile ของคอมโพเนนต์เพื่อปรับแต่งสภาพแวดล้อมการพัฒนาเพิ่มเติมได้ จากนั้น Dockerfile จะใช้กระบวนการ CI/CD เพื่อสร้างอิมเมจส่วนประกอบที่จะใช้ในการผลิต ดังนั้นจึงรักษาความสอดคล้องระหว่างสภาพแวดล้อมการพัฒนาและการผลิต

เรามีเครื่องมือที่ช่วยให้นักวิทยาศาสตร์ข้อมูลสามารถเปิดสภาพแวดล้อมการพัฒนาในพ็อดที่ทำงานบน Kubernetes ได้ เมื่อพ็อดนี้ทำงาน นักวิทยาศาสตร์ด้านข้อมูลสามารถแนบ Visual Studio Code IDE กับพ็อดได้โดยตรงและดีบักโค้ดโมเดล หลังจากที่โค้ดทำงานสำเร็จแล้ว พวกเขาสามารถพุชการเปลี่ยนแปลงไปยัง git และสร้างสภาพแวดล้อมการพัฒนาใหม่พร้อมกับการเปลี่ยนแปลงล่าสุด

ไปป์ไลน์วิทยาศาสตร์ข้อมูลมาตรฐานประกอบด้วยขั้นตอนต่างๆ ที่รวมถึงการดึงข้อมูล การประมวลผลล่วงหน้า การฝึกอบรม และการประเมิน แต่ละขั้นตอนในไปป์ไลน์จะปรากฏเป็นส่วนประกอบใน Kubeflow ซึ่งประกอบด้วยพ็อด Kubernetes ที่รันคำสั่งพร้อมข้อมูลบางส่วนที่ส่งผ่านเป็นพารามิเตอร์ พารามิเตอร์เหล่านี้อาจเป็นค่าคงที่หรือการอ้างอิงถึงเอาต์พุตจากส่วนประกอบก่อนหน้า อิมเมจ Docker ที่ใช้ในพ็อดสร้างจากกระบวนการ CI/CD รายละเอียดเกี่ยวกับกระบวนการนี้ปรากฏในเวิร์กโฟลว์ CI/CD ที่กล่าวถึงในหัวข้อถัดไป

วงจรการพัฒนาบน Kubeflow เวิร์กโฟลว์การพัฒนาเริ่มต้นทางด้านซ้ายด้วย POC โมเดลที่เสร็จสมบูรณ์ถูกปรับใช้กับแพลตฟอร์มที่ให้บริการโมเดล athenahealth ที่ทำงานบน Amazon ECS

กระบวนการ CI/CD รองรับเวิร์กโฟลว์อัตโนมัติ

ในกระบวนการ CI/CD ของเรา เราใช้ Jenkins เพื่อสร้างและทดสอบอิมเมจคอมโพเนนต์ Kubeflow ทั้งหมดพร้อมกัน เมื่อเสร็จสิ้นสำเร็จ เทมเพลตคอมโพเนนต์ไปป์ไลน์จะมีตัวชี้อ้างอิงไปยังรูปภาพ และไปป์ไลน์ที่เป็นผลลัพธ์จะถูกอัปโหลดไปยัง Kubeflow พารามิเตอร์ในไปป์ไลน์ Jenkins อนุญาตให้ผู้ใช้เปิดใช้ไปป์ไลน์และเรียกใช้การทดสอบการฝึกโมเดลหลังจากสร้างสำเร็จ

อีกทางหนึ่ง เพื่อรักษาวงจรการพัฒนาที่สั้น นักวิทยาศาสตร์ด้านข้อมูลยังสามารถเปิดไปป์ไลน์จากเครื่องในพื้นที่ของตน ปรับเปลี่ยนพารามิเตอร์ไปป์ไลน์ที่พวกเขาอาจทำการทดลองด้วย

มีเครื่องมือเพื่อให้แน่ใจว่าพอยน์เตอร์อ้างอิงจากบิลด์ CI/CD ถูกใช้โดยค่าเริ่มต้น หากมีอาร์ติแฟกต์ที่ปรับใช้ได้ใน repo ตรรกะ CI/CD จะยังคงปรับใช้อาร์ติแฟกต์กับแพลตฟอร์มที่ให้บริการโมเดล athenahealth (บริการคาดการณ์) ที่ทำงานบน Amazon ECS ด้วย AWS ฟาร์เกต. หลังจากผ่านขั้นตอนเหล่านี้ทั้งหมดแล้ว Data Scientist จะรวมรหัสเข้ากับสาขาหลัก ไปป์ไลน์และสิ่งประดิษฐ์ที่ปรับใช้ได้จะถูกผลักไปยังการผลิต

เวิร์กโฟลว์การปรับใช้ CI/CD ไดอะแกรมนี้อธิบายเวิร์กโฟลว์การสร้างและการปรับใช้ Data Science กระบวนการ CI/CD ขับเคลื่อนโดย เจนกิ้นส์.

Security

ในการรวมเวิร์กโฟลว์วิทยาศาสตร์ข้อมูล เราสามารถรวมศูนย์แนวทางของเราในการรักษาความปลอดภัยไปป์ไลน์การฝึกอบรม ในส่วนนี้ เราจะพูดถึงแนวทางของเราในการรักษาความปลอดภัยข้อมูลและคลัสเตอร์

ความปลอดภัยของข้อมูล

ความปลอดภัยของข้อมูลมีความสำคัญสูงสุดที่ athenahealth ด้วยเหตุนี้ เราจึงพัฒนาและบำรุงรักษาโครงสร้างพื้นฐานที่สอดคล้องกับกฎระเบียบและมาตรฐานที่ปกป้องความปลอดภัยและความสมบูรณ์ของข้อมูลเหล่านี้อย่างเต็มที่

เพื่อให้แน่ใจว่าเราปฏิบัติตามมาตรฐานการปฏิบัติตามข้อกำหนดของข้อมูล เราจัดเตรียมโครงสร้างพื้นฐาน AWS ของเราตามหลักเกณฑ์สำหรับองค์กรด้านสุขภาพของ athenahealth ที่เก็บข้อมูลหลักสองแห่งคือ Amazon RDS สำหรับข้อมูลเมตาของไปป์ไลน์ที่ปรับขนาดได้สูงและ Amazon S3 สำหรับไปป์ไลน์และสิ่งประดิษฐ์ของโมเดล สำหรับ Amazon S3 เรารับรองว่าบัคเก็ตมีการเข้ารหัส ปลายทาง HTTPS ได้รับการบังคับใช้ และนโยบายของบัคเก็ตและ AWS Identity และการจัดการการเข้าถึง บทบาท (IAM) เป็นไปตามหลักการของสิทธิพิเศษน้อยที่สุดเมื่ออนุญาตให้เข้าถึงข้อมูล สิ่งนี้เป็นจริงสำหรับข้อมูล Amazon RDS เช่นกัน: การเข้ารหัสจะเปิดใช้งานเสมอ และกลุ่มความปลอดภัยและการเข้าถึงข้อมูลรับรองเป็นไปตามหลักการของสิทธิ์ขั้นต่ำ มาตรฐานนี้ทำให้แน่ใจว่ามีเพียงบุคคลที่ได้รับอนุญาตเท่านั้นที่สามารถเข้าถึงข้อมูลได้ และการเข้าถึงนี้จะถูกติดตาม

นอกเหนือจากมาตรการเหล่านี้ แพลตฟอร์มยังได้รับการประเมินภัยคุกคามด้านความปลอดภัยและการสแกนความปลอดภัยและการปฏิบัติตามข้อกำหนดอย่างต่อเนื่อง

เรายังแก้ไขข้อกำหนดการเก็บรักษาข้อมูลผ่านการจัดการวงจรอายุข้อมูลสำหรับบัคเก็ต S3 ทั้งหมดที่มีข้อมูลที่ละเอียดอ่อน นโยบายนี้จะย้ายข้อมูลไปที่ .โดยอัตโนมัติ ธารน้ำแข็ง Amazon S3 หลังจาก 30 วันของการสร้าง ข้อยกเว้นนี้ได้รับการจัดการผ่านคำขอดึงข้อมูลและได้รับการอนุมัติหรือปฏิเสธเป็นกรณีไป เพื่อให้แน่ใจว่าเวิร์กโฟลว์ทั้งหมดสอดคล้องกับนโยบายการเก็บรักษาข้อมูล สิ่งนี้ยังช่วยแก้ปัญหาด้วยการกู้คืนข้อมูลหากแบบจำลองมีประสิทธิภาพต่ำ และจำเป็นต้องมีการฝึกใหม่ หรือเมื่อต้องประเมินแบบจำลองใหม่เทียบกับการทำซ้ำในอดีตของชุดข้อมูลของแบบจำลองที่เก่ากว่า

สำหรับการจำกัดการเข้าถึง Amazon S3 และ Amazon RDS จากภายใน Kubeflow บน AWS และ Amazon EKS เราใช้ IRSA (บทบาท IAM สำหรับบัญชีบริการ) ซึ่งจัดเตรียมการอนุญาตตาม IAM สำหรับทรัพยากรภายใน Kubernetes ผู้เช่าแต่ละรายใน Kubeflow มีบัญชีบริการที่สร้างไว้ล่วงหน้าที่ไม่ซ้ำกัน ซึ่งเราผูกมัดกับบทบาท IAM ที่สร้างขึ้นโดยเฉพาะเพื่อให้เป็นไปตามข้อกำหนดการเข้าถึงของผู้เช่า การเข้าถึงของผู้ใช้ไปยังผู้เช่ายังถูกจำกัดโดยใช้การเป็นสมาชิกกลุ่มกลุ่มผู้ใช้ Amazon Cognito สำหรับผู้ใช้แต่ละราย เมื่อตรวจสอบสิทธิ์ผู้ใช้กับคลัสเตอร์แล้ว โทเค็นที่สร้างขึ้นจะมีการอ้างสิทธิ์กลุ่ม และ Kubernetes RBAC จะใช้ข้อมูลนี้เพื่ออนุญาตหรือปฏิเสธการเข้าถึงทรัพยากรเฉพาะในคลัสเตอร์ การตั้งค่านี้จะอธิบายรายละเอียดเพิ่มเติมในหัวข้อถัดไป

การรักษาความปลอดภัยคลัสเตอร์โดยใช้การแยกผู้ใช้หลายคน

ดังที่เราได้กล่าวไว้ในส่วนก่อนหน้านี้ นักวิทยาศาสตร์ด้านข้อมูลทำการวิเคราะห์ข้อมูลเชิงสำรวจ เรียกใช้การวิเคราะห์ข้อมูล และฝึกอบรมโมเดล ML ในการจัดสรรทรัพยากร จัดระเบียบข้อมูล และจัดการเวิร์กโฟลว์ตามโปรเจ็กต์ Kubeflow บน AWS ให้การแยกตามเนมสเปซ Kubernetes การแยกนี้ใช้สำหรับการโต้ตอบกับ Kubeflow UI; อย่างไรก็ตาม ไม่มีเครื่องมือใดๆ ในการควบคุมการเข้าถึง Kubernetes API โดยใช้ Kubectl ซึ่งหมายความว่าการเข้าถึงของผู้ใช้สามารถควบคุมได้บน Kubeflow UI แต่ไม่สามารถควบคุมผ่าน Kubernetes API ผ่าน Kubectl ได้

สถาปัตยกรรมที่อธิบายไว้ในไดอะแกรมต่อไปนี้แก้ไขปัญหานี้โดยรวมการเข้าถึงโปรเจ็กต์ใน Kubeflow ตามการเป็นสมาชิกกลุ่ม เพื่อให้บรรลุสิ่งนี้ เราใช้ประโยชน์จากรายการ Kubeflow บน AWS ซึ่งมีการผสานรวมกับกลุ่มผู้ใช้ Amazon Cognito นอกจากนี้ เราใช้ Kubernetes role-based access control (RBAC) เพื่อควบคุมการให้สิทธิ์ภายในคลัสเตอร์ สิทธิ์ของผู้ใช้ได้รับการจัดเตรียมตามการเป็นสมาชิกกลุ่ม Amazon Cognito ข้อมูลนี้ถูกส่งไปยังคลัสเตอร์ด้วยโทเค็นที่สร้างโดยไคลเอ็นต์ OIDC กระบวนการนี้ง่ายขึ้นด้วยฟังก์ชัน Amazon EKS ในตัวที่ช่วยให้เชื่อมโยงผู้ให้บริการข้อมูลประจำตัว OIDC เพื่อรับรองความถูกต้องกับคลัสเตอร์ได้

ตามค่าเริ่มต้น การตรวจสอบสิทธิ์ Amazon EKS จะดำเนินการโดยตัวตรวจสอบสิทธิ์ IAM ซึ่งเป็นเครื่องมือที่เปิดใช้งานการตรวจสอบสิทธิ์กับคลัสเตอร์ EKS โดยใช้ข้อมูลประจำตัว IAM วิธีการรับรองความถูกต้องนี้มีข้อดี อย่างไรก็ตาม ไม่เหมาะกับกรณีการใช้งานของเรา เนื่องจาก athenahealth ใช้ Microsoft Azure Active Directory สำหรับบริการระบุตัวตนทั่วทั้งองค์กร

การแยกเนมสเปซ Kubernetes นักวิทยาศาสตร์ข้อมูลสามารถรับสมาชิกภาพกลุ่มเดียวหรือหลายกลุ่มได้ตามความจำเป็นสำหรับงานของตน การเข้าถึงจะได้รับการตรวจสอบเป็นประจำและลบออกตามความเหมาะสม

Azure Active Directory ซึ่งเป็นบริการระบุตัวตนทั่วทั้งองค์กร เป็นแหล่งที่มาของความจริงในการควบคุมการเข้าถึงของผู้ใช้ไปยังคลัสเตอร์ Kubeflow การตั้งค่าสำหรับสิ่งนี้รวมถึงการสร้าง Azure Enterprise Application ที่ทำหน้าที่เป็นบริการหลักและเพิ่มกลุ่มสำหรับผู้เช่าต่างๆ ที่ต้องการการเข้าถึงคลัสเตอร์ การตั้งค่าบน Azure นี้สะท้อนให้เห็นใน Amazon Cognito โดยการตั้งค่าผู้ให้บริการข้อมูลประจำตัว OIDC แบบรวมศูนย์ที่เอาต์ซอร์สความรับผิดชอบในการตรวจสอบสิทธิ์ไปยัง Azure การเข้าถึงกลุ่ม Azure ถูกควบคุมโดย SailPoint IdentityIQ ซึ่งส่งคำขอเข้าถึงไปยังเจ้าของโครงการเพื่ออนุญาตหรือปฏิเสธตามความเหมาะสม ในกลุ่มผู้ใช้ Amazon Cognito ไคลเอ็นต์แอปพลิเคชันสองรายการจะถูกสร้างขึ้น: ไคลเอ็นต์หนึ่งใช้เพื่อตั้งค่าการตรวจสอบสิทธิ์สำหรับคลัสเตอร์ Kubernetes โดยใช้ผู้ให้บริการข้อมูลประจำตัว OIDC และอีกรายการหนึ่งเพื่อรักษาความปลอดภัยการตรวจสอบสิทธิ์ Kubeflow ใน UI ของ Kubeflow ไคลเอ็นต์เหล่านี้ได้รับการกำหนดค่าให้ส่งผ่านการอ้างสิทธิ์แบบกลุ่มเมื่อตรวจสอบสิทธิ์กับคลัสเตอร์ และการอ้างสิทธิ์กลุ่มเหล่านี้จะใช้ควบคู่ไปกับ RBAC เพื่อตั้งค่าการอนุญาตภายในคลัสเตอร์

การเชื่อมโยงบทบาท Kubernetes RBAC ได้รับการตั้งค่าระหว่างกลุ่มและบทบาทของคลัสเตอร์ Kubeflow-edit ซึ่งสร้างขึ้นเมื่อติดตั้ง Kubeflow ในคลัสเตอร์ การเชื่อมโยงบทบาทนี้ช่วยให้มั่นใจว่าผู้ใช้ที่โต้ตอบกับคลัสเตอร์หลังจากเข้าสู่ระบบผ่าน OIDC สามารถเข้าถึงเนมสเปซที่พวกเขามีสิทธิ์ตามที่กำหนดไว้ในการอ้างสิทธิ์กลุ่ม แม้ว่าจะใช้ได้กับผู้ใช้ที่โต้ตอบกับคลัสเตอร์โดยใช้ Kubectl แต่ปัจจุบัน UI ของ Kubeflow ไม่ได้จัดเตรียมการเข้าถึงให้กับผู้ใช้ตามการเป็นสมาชิกกลุ่ม เนื่องจากไม่ได้ใช้ RBAC แต่จะใช้ทรัพยากรนโยบายการอนุญาตของ Istio เพื่อควบคุมการเข้าถึงสำหรับผู้ใช้แทน เพื่อเอาชนะความท้าทายนี้ เราได้พัฒนาตัวควบคุมแบบกำหนดเองที่ซิงโครไนซ์ผู้ใช้โดยการสำรวจกลุ่ม Amazon Cognito และเพิ่มหรือลบการผูกบทบาทที่สอดคล้องกันสำหรับผู้ใช้แต่ละรายแทนที่จะแยกตามกลุ่ม การตั้งค่านี้ช่วยให้ผู้ใช้มีสิทธิ์ในระดับเดียวกันเมื่อโต้ตอบกับทั้ง Kubeflow UI และ Kubectl

ประสิทธิภาพการดำเนินงาน

ในส่วนนี้ เราจะพูดถึงวิธีที่เราใช้ประโยชน์จากโอเพ่นซอร์สและเครื่องมือของ AWS ที่มีให้เราจัดการและแก้ไขจุดบกพร่องของเวิร์กโฟลว์ของเรา รวมถึงลดผลกระทบด้านการปฏิบัติงานจากการอัปเกรด Kubeflow

การบันทึกและการตรวจสอบ

สำหรับการบันทึก เราใช้ FluentD เพื่อส่งบันทึกคอนเทนเนอร์ทั้งหมดของเราไปที่ บริการ Amazon OpenSearch และระบบเมตริกของโพรมีธีอุส จากนั้นเราใช้ Kibana และ Grafana UI ในการค้นหาและกรองบันทึกและเมตริก ไดอะแกรมต่อไปนี้อธิบายวิธีที่เราตั้งค่านี้

การบันทึก Kubeflow เราใช้ทั้ง Grafana UI และ Kibana เพื่อดูและกรองผ่านบันทึก

ภาพหน้าจอต่อไปนี้เป็นมุมมอง Kibana UI จากไปป์ไลน์ของเรา

ตัวอย่างมุมมอง Kibana UI Kibana ช่วยให้สามารถกำหนดมุมมองได้เอง

อัปเกรดคลัสเตอร์ Kubeflow อย่างปลอดภัย

ขณะที่เราเริ่มต้นใช้งานผู้ใช้ Kubeflow บน AWS เรายังคงรักษาประสบการณ์ผู้ใช้ที่เชื่อถือได้และสม่ำเสมอ ในขณะที่ช่วยให้ทีม MLOps ทำงานได้อย่างคล่องตัวด้วยการเปิดตัวและผสานรวมคุณสมบัติใหม่ บนพื้นผิว Kustomize ดูเหมือนโมดูลาร์สำหรับเราเพื่อให้สามารถทำงานและอัปเกรดส่วนประกอบได้ครั้งละหนึ่งส่วนโดยไม่กระทบต่อส่วนประกอบอื่น ซึ่งช่วยให้เราเพิ่มความสามารถใหม่โดยรบกวนผู้ใช้น้อยที่สุด อย่างไรก็ตาม ในทางปฏิบัติ มีบางสถานการณ์ที่วิธีที่ดีที่สุดคือสร้างคลัสเตอร์ Kubernetes ใหม่ แทนที่จะใช้การอัปเกรดระดับคอมโพเนนต์สำหรับคลัสเตอร์ที่มีอยู่ เราพบกรณีการใช้งานสองกรณีที่เหมาะสมกว่าในการสร้างคลัสเตอร์ใหม่ทั้งหมด:

• การอัปเกรดเป็นเวอร์ชัน Kubernetes ที่ AWS ให้บริการอัปเกรดคลัสเตอร์แบบแทนที่ อย่างไรก็ตาม การทดสอบว่าทรัพยากร Kubeflow และ Kubernetes แต่ละรายการทำงานตามที่ตั้งใจทำได้ยากหรือไม่ และไฟล์ Manifest ยังคงความเข้ากันได้แบบย้อนหลัง
• การอัปเกรด Kubeflow เป็นรุ่นที่ใหม่กว่าซึ่งมีการเพิ่มหรือแก้ไขคุณลักษณะหลายอย่าง และเกือบจะไม่ใช่แนวคิดที่ดีที่จะทำการอัพเกรดแบบแทนที่บนคลัสเตอร์ Kubernetes ที่มีอยู่

ในการแก้ไขปัญหานี้ เราได้พัฒนากลยุทธ์ที่ช่วยให้เราสามารถเปลี่ยนคลัสเตอร์ได้อย่างปลอดภัยโดยไม่ส่งผลกระทบต่อปริมาณงานที่มีอยู่ เพื่อให้บรรลุสิ่งนี้ เราต้องมีคุณสมบัติตามเกณฑ์ต่อไปนี้:

• แยกพื้นที่จัดเก็บ Kubeflow และประมวลผลทรัพยากรเพื่อให้ข้อมูลเมตาของไปป์ไลน์ สิ่งประดิษฐ์ไปป์ไลน์ และข้อมูลผู้ใช้ถูกเก็บรักษาไว้เมื่อยกเลิกการจัดสรรคลัสเตอร์ที่เก่ากว่า
• ผสานรวมกับ Kubeflow บน AWS จะปรากฏเมื่อเกิดการอัปเกรดเวอร์ชัน Kubeflow จำเป็นต้องมีการเปลี่ยนแปลงเล็กน้อย
• มีวิธีย้อนกลับได้อย่างง่ายดายหากมีสิ่งผิดปกติหลังจากการอัปเกรดคลัสเตอร์
• มีอินเทอร์เฟซที่เรียบง่ายเพื่อส่งเสริมคลัสเตอร์ผู้สมัครเป็นการผลิต

ไดอะแกรมต่อไปนี้แสดงสถาปัตยกรรมนี้

อัปเกรดคลัสเตอร์ Kubeflow อย่างปลอดภัย เมื่อการทดสอบ Kubeflow Candidate สำเร็จ จะได้รับการเลื่อนขั้นเป็น Kubeflow Prod ผ่านการอัพเดทเป็น Route 53

รายการ Kubeflow บน AWS มาพร้อมกับการผสานรวม Amazon RDS และ Amazon S3 ล่วงหน้า ด้วยบริการที่มีการจัดการเหล่านี้ซึ่งทำหน้าที่เป็นที่เก็บข้อมูลทั่วไป เราจึงสามารถกำหนดกลยุทธ์การปรับใช้สีน้ำเงิน-เขียวได้ เพื่อให้บรรลุสิ่งนี้ เรารับรองว่าข้อมูลเมตาของไปป์ไลน์ยังคงอยู่ใน Amazon RDS ซึ่งทำงานเป็นอิสระจากคลัสเตอร์ EKS และบันทึกไปป์ไลน์และอาร์ติแฟกต์ยังคงอยู่ใน Amazon S3 นอกจากข้อมูลเมตาของไปป์ไลน์และอาร์ติแฟกต์แล้ว เรายังตั้งค่า FluentD เพื่อกำหนดเส้นทางบันทึกพ็อดไปยัง Amazon OpenSearch Service

สิ่งนี้ทำให้มั่นใจได้ว่าชั้นการจัดเก็บข้อมูลถูกแยกออกจากเลเยอร์การคำนวณอย่างสมบูรณ์ และด้วยเหตุนี้จึงเปิดใช้งานการเปลี่ยนแปลงการทดสอบระหว่างการอัปเดตเวอร์ชัน Kubeflow บนคลัสเตอร์ EKS ใหม่ทั้งหมด หลังจากที่การทดสอบทั้งหมดประสบความสำเร็จ เราก็สามารถเปลี่ยน Amazon เส้นทาง 53 บันทึก DNS ไปยังคลัสเตอร์ผู้สมัครที่โฮสต์ Kubeflow นอกจากนี้เรายังให้คลัสเตอร์เก่าทำงานเป็นข้อมูลสำรองเป็นเวลาสองสามวันในกรณีที่เราจำเป็นต้องย้อนกลับ

ประโยชน์ของ Amazon EKS และ Kubeflow บน AWS สำหรับไปป์ไลน์ ML ของเรา

Amazon EKS และแพ็คเกจ Kubeflow บน AWS ย้ายเวิร์กโฟลว์การพัฒนาของเราไปเป็นรูปแบบที่สนับสนุนการฝึกโมเดลที่ทำซ้ำได้อย่างมาก เครื่องมือเหล่านี้ช่วยให้เรามีคลัสเตอร์ที่กำหนดโดยสมบูรณ์พร้อมผู้เช่าที่กำหนดไว้อย่างสมบูรณ์และเรียกใช้โค้ดที่กำหนดโดยสมบูรณ์

ชัยชนะมากมายจากการสร้างแพลตฟอร์มนี้มีเชิงปริมาณน้อยกว่าและเกี่ยวข้องกับการปรับปรุงเวิร์กโฟลว์สำหรับทั้งนักพัฒนาแพลตฟอร์มและผู้ใช้มากขึ้น ตัวอย่างเช่น MinIO ถูกแทนที่ด้วยการเข้าถึงโดยตรงไปยัง Amazon S3 ซึ่งทำให้เราเข้าใกล้เวิร์กโฟลว์เดิมมากขึ้น และลดจำนวนบริการที่เราต้องดูแล เรายังสามารถใช้ Amazon RDS เป็นแบ็กเอนด์สำหรับ Kubeflow ได้ ซึ่งช่วยให้ย้ายข้อมูลระหว่างคลัสเตอร์ได้ง่ายขึ้น และทำให้เราสามารถสำรองข้อมูลไปป์ไลน์ของเราทุกคืน

นอกจากนี้เรายังพบว่าการปรับปรุงในการผสานรวม Kubeflow กับบริการที่มีการจัดการของ AWS นั้นมีประโยชน์ ตัวอย่างเช่น ด้วย Amazon RDS, Amazon S3 และ Amazon Cognito ที่กำหนดค่าไว้ล่วงหน้าในรายการ Kubeflow บน AWS เราประหยัดเวลาและความพยายามในการอัปเดตเป็นการกระจาย Kubeflow ที่ใหม่กว่า เมื่อเราเคยแก้ไขไฟล์ Manifest อย่างเป็นทางการของ Kubeflow ด้วยตนเอง การอัปเดตเป็นเวอร์ชันใหม่จะใช้เวลาหลายสัปดาห์ ตั้งแต่การออกแบบไปจนถึงการทดสอบ

การเปลี่ยนไปใช้ Amazon EKS ทำให้เรามีโอกาสกำหนดคลัสเตอร์ใน Kustomize (ปัจจุบันเป็นส่วนหนึ่งของ Kubectl) และ Terraform ปรากฎว่าสำหรับงานแพลตฟอร์ม Kubernetes และ Terraform นั้นใช้งานได้ง่ายมากหลังจากใช้เวลาพอสมควรในการเรียนรู้ หลังจากการทำซ้ำหลายครั้ง เครื่องมือที่เราสามารถใช้ได้ทำให้การดำเนินการแพลตฟอร์มมาตรฐานเป็นเรื่องง่าย เช่น การอัปเกรดส่วนประกอบหรือการเปลี่ยนคลัสเตอร์การพัฒนาทั้งหมด เทียบกับงานวิ่งดิบ อเมซอน อีลาสติก คอมพิวท์ คลาวด์ อินสแตนซ์ (Amazon EC2) เป็นเรื่องยากที่จะเปรียบเทียบความแตกต่างมหาศาลที่ทำให้มีพ็อดที่กำหนดไว้อย่างดีพร้อมการรับประกันการล้างทรัพยากรและกลไกการลองใหม่ในตัว

Kubernetes มอบมาตรฐานความปลอดภัยที่ยอดเยี่ยม และเราเพิ่งจะขีดข่วนสิ่งที่การแยกผู้ใช้หลายคนช่วยให้เราทำได้เท่านั้น เรามองว่าการแยกผู้ใช้หลายรายเป็นรูปแบบที่ให้ผลตอบแทนมากขึ้นในอนาคตเมื่อแพลตฟอร์มการฝึกอบรมสร้างข้อมูลระดับการผลิต และเรานำนักพัฒนาจากภายนอกทีมของเรามาใช้

ในขณะเดียวกัน Kubeflow ช่วยให้เรามีการฝึกอบรมแบบจำลองที่ทำซ้ำได้ แม้จะมีข้อมูลเดียวกัน ไม่มีการฝึกอบรมใดที่สร้างแบบจำลองที่เหมือนกัน แต่เรามีสิ่งที่ดีที่สุดรองลงมา ด้วย Kubeflow เรารู้แน่ชัดว่ามีการใช้โค้ดและข้อมูลใดในการฝึกโมเดล การเริ่มต้นใช้งานได้รับการปรับปรุงอย่างมาก เนื่องจากแต่ละขั้นตอนในไปป์ไลน์ของเราได้รับการกำหนดไว้อย่างชัดเจนและเป็นโปรแกรม เมื่อนักวิทยาศาสตร์ข้อมูลใหม่มีหน้าที่แก้ไขจุดบกพร่อง พวกเขาต้องการการจัดการน้อยลงมาก เนื่องจากมีโครงสร้างที่ชัดเจนเกี่ยวกับวิธีการใช้ผลลัพธ์ของโค้ดระหว่างขั้นตอนต่างๆ

การใช้ Kubeflow ยังให้ผลการปรับปรุงประสิทธิภาพมากมายเมื่อเทียบกับการทำงานบนอินสแตนซ์ EC2 เดียว บ่อยครั้งในการฝึกอบรมแบบจำลอง นักวิทยาศาสตร์ด้านข้อมูลต้องการเครื่องมือและการเพิ่มประสิทธิภาพที่แตกต่างกันสำหรับการประมวลผลล่วงหน้าและการฝึกอบรม ตัวอย่างเช่น การประมวลผลล่วงหน้ามักจะเรียกใช้โดยใช้เครื่องมือประมวลผลข้อมูลแบบกระจาย เช่น Spark ในขณะที่การฝึกอบรมมักจะเรียกใช้โดยใช้อินสแตนซ์ GPU ด้วยไปป์ไลน์ Kubeflow พวกเขาสามารถระบุประเภทอินสแตนซ์ที่แตกต่างกันสำหรับขั้นตอนต่างๆ ในไปป์ไลน์ ซึ่งช่วยให้พวกเขาใช้อินสแตนซ์ GPU อันทรงพลังในขั้นตอนเดียวและกลุ่มเครื่องขนาดเล็กกว่าสำหรับการประมวลผลแบบกระจายในอีกขั้นตอนหนึ่ง นอกจากนี้ เนื่องจากไปป์ไลน์ Kubeflow อธิบายการขึ้นต่อกันระหว่างสเตจ ไปป์ไลน์จึงสามารถรันสเตจพร้อมกันได้

สุดท้าย เนื่องจากเราสร้างกระบวนการสำหรับการเพิ่มผู้เช่าไปยังคลัสเตอร์ ขณะนี้จึงมีวิธีที่เป็นทางการมากขึ้นในการลงทะเบียนทีมกับผู้เช่าในคลัสเตอร์ เนื่องจากเราใช้ Kubecost เพื่อติดตามค่าใช้จ่ายในคลัสเตอร์ EKS ของเรา ซึ่งช่วยให้เราสามารถระบุต้นทุนให้กับโครงการเดียว แทนที่จะมีค่าใช้จ่ายที่ระดับบัญชี ซึ่งรวมถึงโครงการวิทยาศาสตร์ข้อมูลทั้งหมด Kubecost นำเสนอรายงานเกี่ยวกับเงินที่ใช้ไปต่อเนมสเปซ ซึ่งเชื่อมโยงกับผู้เช่าหรือทีมที่รับผิดชอบในการดำเนินการไปป์ไลน์อย่างแน่นหนา

แม้จะมีประโยชน์ทั้งหมด แต่เราขอเตือนให้ดำเนินการย้ายประเภทนี้เฉพาะในกรณีที่มีการซื้อจากผู้ใช้ทั้งหมด ผู้ใช้ที่ทุ่มเทเวลาจะได้รับประโยชน์มากมายจากการใช้ Amazon EKS และ Kubernetes แต่มีช่วงการเรียนรู้ที่สำคัญ

สรุป

ด้วยการใช้งาน Kubeflow บนไปป์ไลน์ AWS ในโครงสร้างพื้นฐาน ML แบบ end-to-end เราสามารถรวมและสร้างมาตรฐานเวิร์กโฟลว์วิทยาศาสตร์ข้อมูลของเราในขณะที่ยังคงเครื่องมือที่จำเป็นของเรา (เช่น CI/CD และการให้บริการโมเดล) ขณะนี้นักวิทยาศาสตร์ข้อมูลของเราสามารถย้ายไปมาระหว่างโครงการต่างๆ ตามเวิร์กโฟลว์นี้ โดยไม่ต้องเสียค่าใช้จ่ายในการเรียนรู้วิธีบำรุงรักษาชุดเครื่องมือที่ต่างไปจากเดิมอย่างสิ้นเชิง สำหรับโมเดลบางรุ่นของเรา เรายังรู้สึกประหลาดใจกับความเร็วของเวิร์กโฟลว์ใหม่ (เร็วกว่าห้าเท่า) ซึ่งทำให้สามารถฝึกซ้ำได้มากขึ้น และทำให้สร้างโมเดลที่มีการคาดการณ์ได้ดีขึ้น

นอกจากนี้เรายังได้สร้างรากฐานที่แข็งแกร่งเพื่อเพิ่มขีดความสามารถ MLOps และปรับขนาดจำนวนและขนาดของโครงการของเรา ตัวอย่างเช่น เมื่อเราปรับท่าทางการกำกับดูแลของเราให้เข้มงวดขึ้นในสายงานโมเดลและการติดตาม เราได้ลดโฟกัสของเราจากกว่า 15 เวิร์กโฟลว์ให้เหลือเพียงขั้นตอนเดียว และเมื่อช่องโหว่ของ Log4shell ปรากฏขึ้นในช่วงปลายปี 2021 เราก็สามารถมุ่งเน้นไปที่เวิร์กโฟลว์เดียวและแก้ไขได้อย่างรวดเร็วตามความจำเป็น (ดำเนินการ การลงทะเบียน Amazon Elastic Container (Amazon ECR) สแกน อัปเกรด Amazon OpenSearch Service อัปเดตเครื่องมือของเรา และอื่นๆ) โดยมีผลกระทบน้อยที่สุดต่องานต่อเนื่องโดยนักวิทยาศาสตร์ข้อมูล เมื่อการเพิ่มประสิทธิภาพ AWS และ Kubeflow พร้อมใช้งาน เราสามารถรวมเข้าด้วยกันตามที่เห็นสมควร

สิ่งนี้นำเราไปสู่แง่มุมที่สำคัญและเข้าใจง่ายของการปรับใช้ Kubeflow บน AWS ผลลัพธ์ที่สำคัญอย่างหนึ่งของเส้นทางนี้คือความสามารถในการเปิดตัวการอัปเกรดและการปรับปรุง Kubeflow สำหรับนักวิทยาศาสตร์ด้านข้อมูลของเราอย่างราบรื่น แม้ว่าเราจะพูดถึงแนวทางของเราในเรื่องนี้ก่อนหน้านี้ แต่เราก็ยังอาศัยรายการ Kubeflow ที่ AWS จัดหาให้ เราเริ่มต้นเส้นทาง Kubeflow เพื่อเป็นการพิสูจน์แนวคิดในปี 2019 ก่อนการเปิดตัวเวอร์ชัน 1.0.0 (ขณะนี้เรากำลังใช้ 1.4.1 ประเมิน 1.5 AWS กำลังทำงานในเวอร์ชัน 1.6 อยู่แล้ว) ในช่วง 3 ปีที่ผ่านมา มีอย่างน้อยหกรุ่นที่มีเนื้อหาจำนวนมาก ด้วยแนวทางที่มีระเบียบวินัยในการผสานรวมและตรวจสอบการอัปเกรดเหล่านี้และเผยแพร่รายการตามกำหนดการที่คาดการณ์ได้และเชื่อถือได้ ทีม Kubeflow ที่ AWS มีความสำคัญอย่างยิ่งในการช่วยให้ทีม Athenahealth MLOps สามารถวางแผนแผนงานการพัฒนาของเรา ส่งผลให้การจัดสรรทรัพยากรและพื้นที่โฟกัสของเรา ต่อไปในอนาคตด้วยความมั่นใจที่มากขึ้น

คุณสามารถทำตาม ที่เก็บ GitHub ของ AWS Labs เพื่อติดตามการมีส่วนร่วมของ AWS ทั้งหมดกับ Kubeflow คุณยังสามารถค้นหาทีม AWS ได้ที่ Kubeflow #AWS ช่องหย่อน; คำติชมของคุณช่วยให้ AWS จัดลำดับความสำคัญของคุณสมบัติถัดไปเพื่อสนับสนุนโครงการ Kubeflow

---

เกี่ยวกับผู้แต่ง

กันวัลจิต คุรมี เป็นสถาปนิกโซลูชันอาวุโสที่ Amazon Web Services เขาทำงานร่วมกับลูกค้าของ AWS เพื่อให้คำแนะนำและความช่วยเหลือด้านเทคนิคเพื่อช่วยปรับปรุงมูลค่าของโซลูชันเมื่อใช้ AWS Kanwaljit เชี่ยวชาญในการช่วยเหลือลูกค้าด้วยแอพพลิเคชั่นการเรียนรู้แบบตู้คอนเทนเนอร์และแมชชีนเลิร์นนิง

ไทเลอร์ คัลบัค เป็นอาจารย์ใหญ่ของเจ้าหน้าที่ด้านเทคนิคที่ athenahealth Tyler มีประสบการณ์ประมาณ 7 ปีในด้าน Analytics, Data Science, Neural Networks และการพัฒนาแอปพลิเคชัน Machine Learning ในด้าน Healthcare เขาได้มีส่วนร่วมในโซลูชันการเรียนรู้ของเครื่องหลายตัวที่กำลังให้บริการปริมาณการใช้งานจริง ปัจจุบันทำงานเป็นหัวหน้านักวิทยาศาสตร์ข้อมูลในองค์กรด้านวิศวกรรมของ athenahealth ไทเลอร์เป็นส่วนหนึ่งของทีมที่สร้างแพลตฟอร์มการฝึกอบรมการเรียนรู้ด้วยเครื่องใหม่สำหรับ athenahealth ตั้งแต่เริ่มดำเนินการ

วิกเตอร์ ครีลอฟ เป็นอาจารย์ใหญ่ของเจ้าหน้าที่ด้านเทคนิคที่ athenahealth Victor เป็นวิศวกรและผู้เชี่ยวชาญด้านการต่อสู้ ซึ่งช่วยให้นักวิทยาศาสตร์ด้านข้อมูลสร้างไปป์ไลน์แมชชีนเลิร์นนิงที่รวดเร็วและปลอดภัย ใน athenahealth เขาได้ทำงานเกี่ยวกับส่วนต่อประสาน การสั่งซื้อทางคลินิก ใบสั่งยา การตั้งเวลา การวิเคราะห์ และตอนนี้แมชชีนเลิร์นนิง เขาให้คุณค่ากับโค้ดที่เขียนได้สะอาดตาและผ่านการทดสอบหน่วยได้ดี แต่กลับหลงใหลในโค้ดแบบตัวเดียวอย่างไม่ดีต่อสุขภาพ ในเวลาว่าง เขาชอบฟังพอดแคสต์ขณะพาสุนัขไปเดินเล่น

ศาสงค์ เวมูริ เป็นหัวหน้าเจ้าหน้าที่ด้านเทคนิคของ athenahealth เขามีประสบการณ์ในการทำงานกับการพัฒนาโซลูชันที่ขับเคลื่อนด้วยข้อมูลในโดเมนต่างๆ เช่น การดูแลสุขภาพ การประกันภัย และชีวสารสนเทศ ปัจจุบัน Sasank ทำงานร่วมกับการออกแบบและพัฒนาแพลตฟอร์มการฝึกอบรมการเรียนรู้ของเครื่องและการอนุมานบน AWS และ Kubernetes ที่ช่วยในการฝึกอบรมและปรับใช้โซลูชัน ML ในระดับต่างๆ

อนุ ธรรมกูร เป็นสถาปนิกที่ athenahealth Anu มีประสบการณ์มากกว่าสองทศวรรษในด้านสถาปัตยกรรม การออกแบบ ประสบการณ์การพัฒนาในการสร้างผลิตภัณฑ์ซอฟต์แวร์ต่างๆ ในการเรียนรู้ของเครื่อง การดำเนินการบนคลาวด์ บิ๊กดาต้า ไปป์ไลน์ข้อมูลแบบกระจายตามเวลาจริง เทคโนโลยีโฆษณา การวิเคราะห์ข้อมูล การวิเคราะห์โซเชียลมีเดีย ปัจจุบัน Anu ทำงานเป็นสถาปนิกในองค์กร Product Engineering ของ athenahealth ในทีม Machine Learning Platform และ Data Pipeline

วิลเลียม เซ็น เป็นผู้จัดการอาวุโสฝ่ายวิศวกรรมที่ athenahealth เขามีประสบการณ์ความเป็นผู้นำด้านวิศวกรรมมากกว่า 20 ปีในการสร้างโซลูชันด้านไอทีด้านการดูแลสุขภาพ การประมวลผลแบบกระจายข้อมูลขนาดใหญ่ เครือข่ายออปติคัลอัจฉริยะ ระบบตัดต่อวิดีโอแบบเรียลไทม์ ซอฟต์แวร์ระดับองค์กร และการรับประกันภัยด้านการดูแลสุขภาพแบบกลุ่ม ปัจจุบัน William เป็นผู้นำทีมที่ยอดเยี่ยมสองทีมที่ athenahealth, Machine Learning Operations และทีมวิศวกรรม DevOps ในองค์กร Product Engineering