AWS'de Kubeflow'u kullanarak tekrarlanabilir, güvenli ve genişletilebilir uçtan uca makine öğrenimi iş akışları oluşturun

Bu, athenahealth ile birlikte yazılmış bir misafir blog yazısıdır.

athenahealth ülke çapında tıbbi gruplar ve sağlık sistemleri için ağ özellikli yazılım ve hizmetlerin lider sağlayıcısı. Elektronik sağlık kayıtları, gelir döngüsü yönetimi ve hasta katılım araçları, müşterileri için daha iyi finansal sonuçlar sağlayarak ve sağlayıcı müşterilerinin daha kaliteli bakım sunmasını sağlayarak her zaman, her yerden erişime izin verir.

Yapay zeka (AI) alanında athenahealth, iş süreçlerini hızlandırmak ve birden çok hizmette öneriler, tahminler ve öngörüler sağlamak için veri bilimi ve makine öğrenimini (ML) kullanır. Otomatik belge hizmetlerindeki ilk uygulamasından, milyonlarca sağlayıcı-hasta belgesini temassız olarak işlemesinden, sanal asistanlardaki daha yakın tarihli çalışmasına ve gelir döngüsü performansını iyileştirmesine kadar, athenahealth, sağlayıcılar için verimliliği, hizmet yeteneklerini ve daha iyi sonuçları sağlamaya yardımcı olmak için yapay zekayı uygulamaya devam ediyor. ve onların hastaları.

Bu blog yazısı, athenahealth'in nasıl kullanıldığını gösterir AWS'de Kubeflow (AWS'ye özgü bir Kubeflow dağıtımı) temel araçları koruyan, operasyonel verimliliği optimize eden, veri bilimci üretkenliğini artıran ve ML yeteneklerini daha kolay genişletmek için zemin hazırlayan uçtan uca bir veri bilimi iş akışı oluşturmak ve kolaylaştırmak için.

Kubeflow, Kubernetes'te ML iş akışlarının dağıtımını basit, taşınabilir ve ölçeklenebilir hale getirmeye adanmış açık kaynaklı ML platformudur. Kubeflow bunu, Kubernetes ile iyi bir şekilde entegre olan ilgili açık kaynaklı araçları birleştirerek başarır. Bu projelerden bazıları, ardışık düzen düzenlemesi için Argo, hizmet ağı için Istio, dizüstü bilgisayarlar için Jupyter, Spark, TensorBoard ve Katib'dir. Kubeflow Pipelines, veri çıkarma, ön işleme, model eğitimi ve tekrarlanabilir işlem hatları biçiminde model değerlendirme gibi adımları içerebilen taşınabilir, ölçeklenebilir ML iş akışlarının oluşturulmasına ve dağıtılmasına yardımcı olur.

AWS, athenahealth gibi kuruluşların AWS tarafından yönetilen hizmetler ile entegrasyon yoluyla düşük operasyonel ek yük ile son derece güvenilir, güvenli, taşınabilir ve ölçeklenebilir ML iş akışları oluşturmasına yardımcı olan kendi Kubeflow dağıtımını (AWS'de Kubeflow olarak adlandırılır) sağlayarak açık kaynaklı Kubeflow topluluğuna katkıda bulunuyor. AWS, aşağıdakilerle dağıtım gibi çeşitli Kubeflow dağıtım seçenekleri sunar: Amazon Cognito'suile dağıtım Amazon İlişkisel Veritabanı Hizmeti (Amazon RDS) ve Amazon Basit Depolama Hizmeti (Amazon S3) ve vanilya dağıtımı. Hizmet entegrasyonu ve bu seçeneklerin her biri için mevcut eklentiler hakkında ayrıntılar için bkz. açılma.

Bugün, AWS'de Kubeflow, aşağıdaki AWS hizmetleriyle güçlendirilmiş Kubeflow'u kullanmak için net bir yol sunuyor:

Birçok AWS müşterisi, athenahealth dahil olmak üzere AWS dağıtımında Kubeflow'tan yararlanıyor.

Burada, athenahealth MLOps ekibi, Kubeflow yolculuklarında karşılaştıkları zorlukları ve yarattıkları çözümleri tartışıyor.

Önceki ML ortamıyla ilgili zorluklar

AWS'de Kubeflow'u benimsemeden önce, veri bilimcilerimiz belirli bir modeli eğitmek için kullanılan teknoloji ve iş akışında esnekliğe izin veren standartlaştırılmış bir araç seti ve bir süreç kullandı. Standartlaştırılmış araçların örnek bileşenleri arasında bir veri alımı API'si, güvenlik tarama araçları, athenahealth içinde başka bir ekip tarafından oluşturulan ve sürdürülen CI/CD ardışık düzeni ve MLOps ekibi tarafından oluşturulan ve sürdürülen ortak bir hizmet platformu bulunur. Ancak yapay zeka ve makine öğrenimi kullanımımız olgunlaştıkça, her model için oluşturulan araç ve altyapı çeşitliliği arttı. Halen mevcut süreci destekleyebilmemize rağmen, ufukta aşağıdaki zorlukları gördük:

• Bakım ve büyüme – Dağıtılan modellerin sayısı arttıkça model eğitim ortamlarının yeniden üretilmesi ve bakımı daha fazla çaba gerektirdi. Her proje, son modeli oluşturmak için her bir betiğin nasıl kullanıldığını özetleyen ayrıntılı belgelere sahipti. Çoğu durumda, bu, her biri birkaç çıktıya sahip 5 ila 10 komut dosyası içeren ayrıntılı bir süreçti. Bunların, her bir çıktının sonraki süreçlerde nasıl kullanılacağına ilişkin ayrıntılı talimatlarla manuel olarak izlenmesi gerekiyordu. Bunu sürdürmek zamanla hantal hale geldi. Ayrıca projeler karmaşıklaştıkça araç sayısı da arttı. Örneğin, çoğu model, daha fazla ortam yapılandırması gerektiren GPU'larla Spark ve TensorFlow'u kullandı. Zamanla, kullanıcılar geliştirme ortamlarında araçların daha yeni sürümlerine geçerler, ancak bu sürümler uyumsuz hale geldiğinde eski komut dosyalarını çalıştıramazlardı. Sonuç olarak, eski projeleri sürdürmek ve geliştirmek, daha fazla mühendislik zamanı ve çabası gerektiriyordu. Ek olarak, ekibe yeni veri bilimcileri katıldıkça, yerel ortamların senkronize edilmesi birçok belgelenmemiş bağımlılık içerdiğinden, bilgi aktarımları ve ilk katılım daha fazla zaman aldı. Her modelin kendi iş akışları olduğundan, projeler arasında geçiş yapmak aynı sorunlarla karşı karşıya kaldı.
• Güvenlik – Güvenliği ciddiye alıyoruz ve bu nedenle makine öğrenimi ve veri bilimi ile ilgili tüm sözleşmeye dayalı, yasal ve düzenleyici yükümlülüklere uymaya öncelik veriyoruz. Veriler belirli şekillerde kullanılmalı, saklanmalı ve erişilmelidir ve uygulamalarımızın yasal yükümlülüklerimize uymasının yanı sıra sektördeki en iyi uygulamalarla uyumlu olmasını sağlamak için sağlam süreçlere sahibiz. Kubeflow'un benimsenmesinden önce, verilerin belirli bir şekilde depolanmasını ve bunlara erişilmesini sağlamak, birden çok farklı iş akışında düzenli doğrulamayı içeriyordu. Bu çeşitli iş akışlarını tek bir platformda birleştirerek verimliliği artırabileceğimizi biliyorduk. Ancak, bu platformun standartlaştırılmış araçlarımızla iyi bir şekilde entegre olacak kadar esnek olması gerekir.
• Operasyon – İş akışlarının günlüğe kaydedilmesini ve izlenmesini merkezileştirerek operasyonel verimliliği ve yönetimi artırma fırsatı da gördük. Her ekip kendi araçlarını geliştirdiğinden, bu bilgileri her iş akışından ayrı ayrı topladık ve bir araya getirdik.

Veri bilimi ekibi, iş akışlarını birleştirmek için çeşitli çözümleri değerlendirdi. Bu gereksinimleri karşılamanın yanı sıra, mevcut standartlaştırılmış altyapı ve araçlarla sorunsuz bir şekilde entegre olacak bir çözüm aradık. İş akışı çözümümüz olarak AWS'de Amazon EKS ve Kubeflow'u seçtik.

Kubeflow'u içeren veri bilimcisi geliştirme döngüsü

Bir veri bilimi projesi temiz bir sayfa ile başlar: veri yok, kod yok, yalnızca makine öğrenimi ile çözülebilecek iş sorunu. İlk görev, Snowflake veri ambarımızdan ham veri kümesini sorgulamakla başlayarak, verilerin bir makine öğrenimi modelini iş sorununu çözmede etkili kılmak için yeterli sinyali tutup tutmadığını keşfetmek için bir kavram kanıtıdır (POC). Bu aşama yinelemelidir ve veri bilimcileri bu işlem sırasında Kubernetes bölmelerini veya Kubeflow Jupyter not defterlerini kullanır.

Kubeflow kümemiz, kaynak sağlama işi bir dizi önceden tanımlanmış Karpenter sağlayıcısı tarafından yapılırken, yalnızca istenen örnek türlerini tanımlamaya odaklanmaları gerektiğinden, veri bilimcileri için kaynakları döndürmeyi kolaylaştıran Karpenter kümesi otomatik ölçekleyicisini kullanır. CPU ve GPU bulut sunucusu türleri için ayrı sağlayıcılarımız vardır ve Amazon EKS tarafından desteklenen tüm bulut sunucuları, sağlayıcı yapılandırmamıza göre bu iki kategoriden birine girer. Veri bilimcileri, düğüm seçicileri kullanarak örnek türlerini seçer ve Karpenter düğüm yaşam döngüsü yönetimiyle ilgilenir.

Sorgu geliştirildikten sonra, veri bilimcileri ham verileri Amazon S3'teki bir konuma çıkarır ve ardından verileri keşfetmek için AWS Kubeflow UI'den bir Jupyter not defteri başlatır. Amaç, ilk modeli eğitmek için kullanılacak özellik setini oluşturmaktır. Bu, veri bilimcilerinin, müşterinin iş ihtiyacını karşılamak için verilerde yeterli sinyal olup olmadığını belirlemesine olanak tanır.

Sonuçlar tatmin edici olduktan sonra, veri bilimcileri geliştirme döngüsünün bir sonraki aşamasına geçer ve keşiflerini sağlam bir boru hattına dönüştürür. POC kodunu, ölçekte çalışan üretim kalitesi koduna dönüştürürler. Onaylı kitaplıkları kullanarak uyumluluğu sağlamak için uygun temel Docker görüntüsüyle bir kapsayıcı oluşturulur. Veri bilimcilerimiz için standart bir Python, TensorFlow ve Spark temel görüntüsü sağlamanın, tümü olmasa da çoğu iş yükleri için yeterli esneklik sağladığını bulduk. Ardından, geliştirme ortamlarını daha da özelleştirmek için bileşenlerinin Dockerfile'ını kullanabilirler. Bu Docker dosyası daha sonra üretimde kullanılacak bileşen görüntüsünü oluşturmak için CI/CD işlemi tarafından kullanılır, bu nedenle geliştirme ve üretim ortamları arasındaki tutarlılığı korur.

Veri bilimcilerine, geliştirme ortamlarını Kubernetes üzerinde çalışan bir kapsülde başlatma yeteneği veren bir aracımız var. Bu bölme çalışırken, veri bilimcileri daha sonra Visual Studio Code IDE'yi doğrudan bölmeye ekleyebilir ve model kodlarında hata ayıklayabilir. Kodu başarıyla çalıştırdıktan sonra, değişikliklerini git'e aktarabilirler ve en son değişikliklerle yeni bir geliştirme ortamı oluşturulur.

Standart veri bilimi boru hattı, çıkarma, ön işleme, eğitim ve değerlendirmeyi içeren aşamalardan oluşur. İşlem hattındaki her aşama, bazı bilgilerin parametre olarak iletildiği bir komutu çalıştıran bir Kubernetes bölmesinden oluşan Kubeflow'ta bir bileşen olarak görünür. Bu parametreler, statik değerler veya önceki bir bileşenin çıktısına yönelik referanslar olabilir. Bölmede kullanılan Docker görüntüsü, CI/CD sürecinden oluşturulmuştur. Bu işlemle ilgili ayrıntılar, sonraki bölümde ele alınan CI/CD iş akışında görünür.

Kubeflow'ta Geliştirme Döngüsü. Geliştirme iş akışı, POC ile soldan başlar. Tamamlanan model, Amazon ECS üzerinde çalışan athenahealth model hizmet platformuna dağıtılır.

Otomatikleştirilmiş iş akışlarını destekleyen CI/CD süreci

CI/CD sürecimizin bir parçası olarak, tüm Kubeflow bileşen görüntülerini paralel olarak oluşturmak ve test etmek için Jenkins kullanıyoruz. Başarılı bir şekilde tamamlandığında, ardışık düzen bileşen şablonu, görüntülere referans işaretçileri içerir ve ortaya çıkan ardışık düzen Kubeflow'a yüklenir. Jenkins işlem hattındaki parametreler, kullanıcıların işlem hatlarını başlatmasına ve başarılı derlemelerden sonra model eğitim testlerini yürütmesine olanak tanır.

Alternatif olarak, kısa bir geliştirme döngüsünü sürdürmek için veri bilimcileri, deney yapabilecekleri herhangi bir işlem hattı parametresini değiştirerek işlem hattını yerel makinelerinden başlatabilir.

CI/CD yapısındaki referans işaretçilerinin varsayılan olarak kullanılmasını sağlamak için araçlar mevcuttur. Depoda dağıtılabilir bir yapı varsa CI/CD mantığı, yapıtı Amazon ECS üzerinde çalışan athenahealth model hizmet platformuna (Tahmin Hizmeti) dağıtmaya devam eder. AWS Fargate. Tüm bu aşamalar geçtikten sonra veri bilimcisi, kodu birincil dalla birleştirir. İşlem hatları ve konuşlandırılabilir yapıtlar daha sonra üretime gönderilir.

CI/CD Dağıtım iş akışı. Bu diyagram, Veri Bilimi oluşturma ve devreye alma iş akışını açıklar. CI/CD süreci, Jenkins.

Güvenlik

Veri bilimi iş akışlarımızı konsolide ederken, eğitim hattının güvenliğini sağlamaya yönelik yaklaşımımızı merkezileştirebildik. Bu bölümde, veri ve küme güvenliğine yaklaşımımızı tartışıyoruz.

Veri güvenliği

Athenahealth'de veri güvenliği son derece önemlidir. Bu nedenle, bu verilerin güvenliğini ve bütünlüğünü koruyan mevzuat ve standartlarla tam uyumlu altyapılar geliştiriyor ve sürdürüyoruz.

Veri uyumluluğu standartlarını karşıladığımızdan emin olmak için AWS altyapımızı athenahealth kurumsal yönergelerimize uygun olarak sağlıyoruz. Veriler için iki ana depo, yüksek düzeyde ölçeklenebilir işlem hattı meta verileri için Amazon RDS ve işlem hattı ve model yapıları için Amazon S3'tür. Amazon S3 için paketlerin şifrelenmesini, HTTPS uç noktalarının uygulanmasını ve paket politikalarının ve AWS Kimlik ve Erişim Yönetimi (IAM) rolleri, verilere erişime izin verirken en az ayrıcalık ilkelerini takip eder. Bu, Amazon RDS verileri için de geçerlidir: şifreleme her zaman etkindir ve güvenlik grupları ile kimlik bilgilerine erişim, en az ayrıcalık ilkesini takip eder. Bu standardizasyon, verilere yalnızca yetkili tarafların erişmesini sağlar ve bu erişim izlenir.

Bu önlemlere ek olarak platform, güvenlik tehdidi değerlendirmelerinden ve sürekli güvenlik ve uyumluluk taramalarından da geçer.

Ayrıca, hassas veriler içeren tüm S3 klasörleri için veri yaşam döngüsü yönetimi aracılığıyla veri saklama gereksinimlerini ele alıyoruz. Bu politika, verileri otomatik olarak Amazon S3 Buzulu 30 günlük oluşturulduktan sonra. Bunun istisnaları, veri alma talepleri aracılığıyla yönetilir ve duruma göre onaylanır veya reddedilir. Bu, tüm iş akışlarının veri saklama ilkesine uymasını sağlar. Bu aynı zamanda, bir model kötü performans gösteriyorsa ve yeniden eğitim gerekliyse veya yeni bir modelin daha eski bir modelin veri kümesinin geçmiş yinelemesine karşı değerlendirilmesi gerektiğinde verileri kurtarma sorununu da çözer.

AWS ve Amazon EKS'de Kubeflow içinden Amazon S3 ve Amazon RDS'ye erişimi kısıtlamak için Kubernetes içindeki kaynaklar için IAM tabanlı izin sağlama sağlayan IRSA'yı (Hizmet Hesapları için IAM Rolleri) kullanıyoruz. Kubeflow'daki her kiracının, kiracı erişim gereksinimlerini karşılamak için özel olarak oluşturulmuş bir IAM rolüne bağladığımız, önceden oluşturulmuş benzersiz bir hizmet hesabı vardır. Kiracılara kullanıcı erişimi, her kullanıcı için Amazon Cognito kullanıcı havuzları grup üyeliği kullanılarak da kısıtlanır. Bir kullanıcının kümede kimliği doğrulandığında, oluşturulan belirteç grup taleplerini içerir ve Kubernetes RBAC bu bilgiyi kümedeki belirli bir kaynağa erişime izin vermek veya erişimi reddetmek için kullanır. Bu kurulum bir sonraki bölümde daha ayrıntılı olarak açıklanmaktadır.

Çok kullanıcılı izolasyon kullanarak küme güvenliği

Önceki bölümde belirttiğimiz gibi, veri bilimcileri keşif amaçlı veri analizleri gerçekleştirir, veri analitiğini çalıştırır ve ML modellerini eğitir. AWS'de Kubeflow, kaynakları tahsis etmek, verileri düzenlemek ve projelere dayalı iş akışlarını yönetmek için Kubernetes ad alanlarını temel alan yalıtım sağlar. Bu izolasyon, Kubeflow UI ile etkileşim için çalışır; ancak Kubectl kullanarak Kubernetes API'sine erişimi denetlemek için herhangi bir araç sağlamaz. Bu, kullanıcı erişiminin Kubeflow UI üzerinden kontrol edilebileceği, ancak Kubectl aracılığıyla Kubernetes API üzerinden kontrol edilemediği anlamına gelir.

Aşağıdaki şemada açıklanan mimari, Kubeflow'daki projelere erişimi grup üyeliklerine göre birleştirerek bu sorunu giderir. Bunu başarmak için Amazon Cognito kullanıcı havuzlarıyla entegrasyonu olan Kubeflow on AWS bildirimlerinden yararlandık. Ayrıca, küme içindeki yetkilendirmeyi kontrol etmek için Kubernetes rol tabanlı erişim denetimi (RBAC) kullanıyoruz. Kullanıcı izinleri, Amazon Cognito grup üyeliğine göre sağlanır. Bu bilgi, OIDC istemcisi tarafından oluşturulan belirteçle kümeye iletilir. Bu işlem, ilişkilendirilen OIDC kimlik sağlayıcılarının kümeyle kimlik doğrulaması yapmasına olanak tanıyan yerleşik Amazon EKS işlevi sayesinde basitleştirilmiştir.

Varsayılan olarak Amazon EKS kimlik doğrulaması, IAM kimlik bilgilerini kullanarak bir EKS kümesiyle kimlik doğrulamayı sağlayan bir araç olan IAM kimlik doğrulayıcısı tarafından gerçekleştirilir. Bu kimlik doğrulama yönteminin avantajları vardır; ancak, athenahealth kuruluş genelinde kimlik hizmeti için Microsoft Azure Active Directory kullandığından kullanım durumumuz için uygun değildir.

Kubernetes ad alanı yalıtımı. Veri Bilimcileri, çalışmaları için gerektiğinde tek veya birden fazla gruba üyelik elde edebilir. Erişim düzenli olarak gözden geçirilir ve uygun şekilde kaldırılır.

Kurumsal çapta bir kimlik hizmeti olan Azure Active Directory, Kubeflow kümesine kullanıcı erişimini denetlemek için gerçeğin kaynağıdır. Bunun kurulumu, hizmet sorumlusu görevi gören bir Azure Kurumsal Uygulaması oluşturmayı ve kümeye erişim gerektiren çeşitli kiracılar için gruplar eklemeyi içerir. Azure'daki bu kurulum, kimlik doğrulama sorumluluğunu Azure'a dış kaynak sağlayan bir birleşik OIDC kimlik sağlayıcısı kurarak Amazon Cognito'da yansıtılır. Azure gruplarına erişim, proje sahibine uygun şekilde izin vermesi veya reddetmesi için erişim istekleri gönderen SailPoint IdentityIQ tarafından kontrol edilir. Amazon Cognito kullanıcı havuzunda iki uygulama istemcisi oluşturulur: biri OIDC kimlik sağlayıcısını kullanarak Kubernetes kümesi için kimlik doğrulamasını ayarlamak için, diğeri ise Kubeflow kullanıcı arabiriminde Kubeflow kimlik doğrulamasını güvenceye almak için kullanılır. Bu istemciler, küme ile kimlik doğrulaması üzerine grup taleplerini iletmek üzere yapılandırılır ve bu grup talepleri, küme içinde yetkilendirmeyi ayarlamak için RBAC ile birlikte kullanılır.

Kubernetes RBAC rol bağlamaları, gruplar ve kümeye Kubeflow yüklendikten sonra oluşturulan küme rolü Kubeflow-edit arasında ayarlanır. Bu rol bağlama, OIDC aracılığıyla oturum açtıktan sonra kümeyle etkileşime giren herhangi bir kullanıcının, grup taleplerinde tanımlandığı şekilde izinlerine sahip oldukları ad alanlarına erişebilmesini sağlar. Bu, Kubectl kullanarak kümeyle etkileşime giren kullanıcılar için işe yarasa da, Kubeflow UI, RBAC kullanmadığı için şu anda kullanıcılara grup üyeliğine dayalı erişim sağlamaz. Bunun yerine, kullanıcıların erişimini denetlemek için Istio Yetkilendirme Politikası kaynağını kullanır. Bu zorluğun üstesinden gelmek için, Amazon Cognito gruplarını yoklayarak kullanıcıları senkronize eden ve grup yerine her kullanıcı için karşılık gelen rol bağlamalarını ekleyen veya kaldıran özel bir denetleyici geliştirdik. Bu kurulum, kullanıcıların hem Kubeflow UI hem de Kubectl ile etkileşim kurarken aynı düzeyde izinlere sahip olmasını sağlar.

Operasyonel verimlilik

Bu bölümde, Kubeflow'u yükseltmenin operasyonel etkisini en aza indirmenin yanı sıra iş akışlarımızı yönetmek ve hatalarını ayıklamak için bize sunulan açık kaynak ve AWS araçlarından nasıl yararlandığımızı tartışıyoruz.

Günlük kaydı ve izleme

Günlük kaydı için, tüm kapsayıcı günlüklerimizi aşağıdakilere göndermek için FluentD'yi kullanırız. Amazon Açık Arama Hizmeti ve Prometheus'a sistem metrikleri. Daha sonra günlükleri ve ölçümleri aramak ve filtrelemek için Kibana ve Grafana UI'sini kullanırız. Aşağıdaki şema, bunu nasıl ayarladığımızı açıklamaktadır.

Kubeflow Günlüğü. Günlükleri görüntülemek ve gözden geçirmek için hem Grafana UI hem de Kibana kullanıyoruz

Aşağıdaki ekran görüntüsü, boru hattımızdan bir Kibana UI görünümüdür.

Örnek Kibana UI Görünümü. Kibana, özelleştirilmiş görünümlere izin verir.

Güvenli Kubeflow küme yükseltmeleri

Kullanıcıları AWS'de Kubeflow'a dahil ederken, güvenilir ve tutarlı bir kullanıcı deneyimi sağlarken MLOps ekibinin yeni özellikleri yayınlayıp entegre ederek çevik kalmasına olanak tanıyoruz. Yüzeyde, Kustomize, diğerlerini etkilemeden bir seferde bir bileşenin çalışıp yükseltilmesine olanak sağlamak için modüler görünüyor ve böylece kullanıcılara minimum kesinti ile yeni yetenekler eklememize izin veriyor. Ancak pratikte, en iyi yaklaşımın mevcut kümeler için bileşen düzeyinde yükseltmeler uygulamak yerine yeni bir Kubernetes kümesi oluşturmak olduğu senaryolar vardır. Tamamen yeni kümeler oluşturmanın daha mantıklı olduğu iki kullanım durumu bulduk:

• AWS'nin yerinde küme yükseltmeleri sağladığı bir Kubernetes sürümüne yükseltme. Ancak, Kubeflow ve Kubernetes kaynaklarının her birinin amaçlandığı gibi çalışıp çalışmadığını ve bildirimlerin geriye dönük uyumluluğunu koruduğunu test etmek zorlaşır.
• Kubeflow'u, eklenen veya değiştirilen birkaç özelliğin bulunduğu daha yeni bir sürüme yükseltmek ve mevcut bir Kubernetes kümesinde yerinde yükseltmeler yapmak neredeyse her zaman umut verici bir fikir değildir.

Bu sorunu ele alırken, mevcut iş yüklerini etkilemeden güvenli küme değişimleri yapmamızı sağlayan bir strateji geliştirdik. Bunu başarmak için aşağıdaki kriterleri karşılamamız gerekiyordu:

• Eski kümenin temel hazırlığı kaldırılırken ardışık düzen meta verilerinin, ardışık düzen yapıtlarının ve kullanıcı verilerinin korunması için Kubeflow depolama ve işlem kaynaklarını ayırın
• AWS bildirimlerinde Kubeflow ile entegre edin, böylece bir Kubeflow sürüm yükseltmesi gerçekleştiğinde minimum değişiklik gerekir
• Küme yükseltmesinden sonra işler ters giderse geri almanın zahmetsiz bir yolunu bulun
• Aday kümeyi üretime yükseltmek için basit bir arayüze sahip olun

Aşağıdaki şema bu mimariyi göstermektedir.

Güvenli Kubeflow Küme Yükseltmesi. Kubeflow Adayının testi başarılı olduğunda, Route 53'e yapılan bir güncellemeyle Kubeflow Prod'a yükseltilir.

AWS bildirimlerinde Kubeflow, Amazon RDS ve Amazon S3 entegrasyonlarıyla önceden paketlenmiş olarak gelir. Ortak veri depoları olarak hareket eden bu yönetilen hizmetler ile mavi-yeşil bir dağıtım stratejisi oluşturabiliriz. Bunu başarmak için, işlem hattı meta verilerinin EKS kümesinden bağımsız olarak çalışan Amazon RDS'de kalıcı olmasını ve işlem hattı günlüklerinin ve yapılarının Amazon S3'te kalıcı olmasını sağladık. İşlem hattı meta verilerine ve yapılarına ek olarak, pod günlüklerini Amazon OpenSearch Service'e yönlendirmek için FluentD'yi de kurduk.

Bu, depolama katmanının bilgi işlem katmanından tamamen ayrılmasını sağlar ve böylece tamamen yeni bir EKS kümesinde Kubeflow sürüm güncellemeleri sırasında değişikliklerin test edilmesini sağlar. Tüm testler başarılı olduktan sonra, basitçe değiştirebiliyoruz. Amazon Rota 53 Kubeflow'u barındıran aday kümeye DNS kaydı. Ayrıca, eski kümeyi geri almamız gerekebilir diye birkaç gün boyunca yedek olarak çalışır durumda tutuyoruz.

ML ardışık düzenimiz için AWS'de Amazon EKS ve Kubeflow'un avantajları

Amazon EKS ve Kubeflow on AWS paketi, geliştirme iş akışımızı tekrarlanabilir model eğitimini güçlü bir şekilde teşvik eden bir kalıba taşıdı. Bu araçlar, tam olarak tanımlanmış kiracılarla tam olarak tanımlanmış kümelere sahip olmamızı ve tam olarak tanımlanmış kodu çalıştırmamızı sağlar.

Bu platformu oluşturmaktan elde edilen birçok kazanç daha az niceldir ve hem platform geliştiricileri hem de kullanıcılar için iş akışlarının nasıl geliştiğiyle daha çok ilgisi vardır. Örneğin, MinIO, bizi orijinal iş akışlarımıza yaklaştıran ve sürdürmemiz gereken hizmet sayısını azaltan Amazon S3'e doğrudan erişimle değiştirildi. Ayrıca, kümeler arasında daha kolay geçiş sağlayan ve işlem hatlarımızı her gece yedekleme olanağı sağlayan Kubeflow için arka uç olarak Amazon RDS'yi kullanabiliyoruz.

AWS tarafından yönetilen hizmetler ile Kubeflow entegrasyonundaki iyileştirmeleri de faydalı bulduk. Örneğin, Kubeflow on AWS bildirimlerinde önceden yapılandırılmış Amazon RDS, Amazon S3 ve Amazon Cognito ile, Kubeflow'un daha yeni dağıtımlarına güncelleme yapmak için zamandan ve emekten tasarruf ediyoruz. Resmi Kubeflow bildirimlerini manuel olarak değiştirdiğimizde, yeni bir sürüme güncelleme, tasarımdan teste kadar birkaç hafta sürerdi.

Amazon EKS'ye geçmek bize kümemizi Kustomize (artık Kubectl'in bir parçası) ve Terraform'da tanımlama fırsatı verir. Platform çalışması için Kubernetes ve Terraform'un öğrenmek için yeterli zaman ayırdıktan sonra çalışmak çok kolay olduğu ortaya çıktı. Birçok yinelemeden sonra, bize sunulan araçlar, bir bileşeni yükseltmek veya bir geliştirme kümesinin tamamını değiştirmek gibi standart platform işlemlerini gerçekleştirmeyi çok kolaylaştırır. İşlerin ham olarak çalıştırılmasıyla karşılaştırıldığında Amazon Elastik Bilgi İşlem Bulutu (Amazon EC2) örneklerinde, garantili kaynak temizleme ve yerleşik yeniden deneme mekanizmalarına sahip iyi tanımlanmış bölmelere sahip olmanın ne kadar büyük bir fark yarattığını karşılaştırmak zor.

Kubernetes harika güvenlik standartları sağlar ve biz çok kullanıcılı yalıtımın bize izin verdiğinin yalnızca yüzeyini kazıdık. Eğitim platformu üretim düzeyinde veriler ürettiğinde, çok kullanıcılı izolasyonu gelecekte daha fazla getirisi olan bir model olarak görüyoruz ve ekibimizin dışından geliştiriciler getiriyoruz.

Bu arada Kubeflow, tekrarlanabilir model eğitimine sahip olmamızı sağlıyor. Aynı verilerle bile, hiçbir eğitim aynı modelleri üretmez, ancak bir sonraki en iyi şeye sahibiz. Kubeflow ile bir modeli eğitmek için tam olarak hangi kodun ve verilerin kullanıldığını biliyoruz. İşe alım sürecimizdeki her adım açık ve programlı olarak tanımlandığı için büyük ölçüde iyileştirildi. Yeni veri bilimcilerin görevi bir hatayı düzeltme görevi olduğunda, kod çıktılarının aşamalar arasında nasıl kullanıldığına dair net bir yapı olduğundan çok daha az ele geçirmeye ihtiyaç duyarlar.

Kubeflow'u kullanmak, tek bir EC2 bulut sunucusunda çalıştırmaya kıyasla çok sayıda performans iyileştirmesi de sağlar. Genellikle model eğitiminde, veri bilimcileri ön işleme ve eğitim için farklı araçlara ve optimizasyonlara ihtiyaç duyar. Örneğin, ön işleme genellikle Spark gibi dağıtılmış veri işleme araçları kullanılarak yürütülürken eğitim genellikle GPU örnekleri kullanılarak yürütülür. Kubeflow işlem hatları ile işlem hattındaki farklı aşamalar için farklı örnek türleri belirtebilirler. Bu, bir aşamada güçlü GPU örneklerini ve başka bir aşamada dağıtılmış işleme için daha küçük makine filosunu kullanmalarına olanak tanır. Ayrıca, Kubeflow işlem hatları aşamalar arasındaki bağımlılıkları tanımladığından, işlem hatları aşamaları paralel olarak çalıştırabilir.

Son olarak, kümeye kiracı eklemek için bir süreç oluşturduğumuz için, artık ekipleri kümedeki bir kiracıya kaydetmenin daha resmi bir yolu var. EKS kümemizde maliyetleri izlemek için Kubecost kullandığımız için, tüm veri bilimi projelerini içeren hesap düzeyinde maliyet atfedilmesi yerine maliyeti tek bir projeye atfetmemize olanak tanır. Kubecost, boru hattını çalıştırmaktan sorumlu olan kiracı veya ekibe sıkı sıkıya bağlı olan ad alanı başına harcanan paranın bir raporunu sunar.

Tüm avantajlara rağmen, bu tür bir geçişi yalnızca kullanıcılardan tam bir katılım varsa gerçekleştirme konusunda dikkatli oluruz. Zaman harcayan kullanıcılar, Amazon EKS ve Kubernetes'i kullanmaktan birçok avantaj elde eder, ancak önemli bir öğrenme eğrisi vardır.

Sonuç

Uçtan uca ML altyapımızda Kubeflow on AWS ardışık düzeninin uygulanmasıyla, temel araçlarımızı (CI/CD ve model sunma gibi) korurken veri bilimi iş akışlarımızı konsolide edip standart hale getirdik. Veri bilimcilerimiz artık tamamen farklı bir araç setinin nasıl korunacağını öğrenme yükü olmadan bu iş akışına dayalı projeler arasında geçiş yapabilir. Bazı modellerimiz için, yeni iş akışının hızına (beş kat daha hızlı) hoş bir şekilde şaşırdık, bu da daha fazla eğitim yinelemesine ve sonuç olarak daha iyi tahminlere sahip modeller üretmeye izin verdi.

Ayrıca MLOps yeteneklerimizi artırmak ve projelerimizin sayısını ve boyutunu ölçeklendirmek için sağlam bir temel oluşturduk. Örneğin, model kökeni ve takibinde yönetim duruşumuzu sağlamlaştırdıkça, odağımızı 15'ten fazla iş akışından yalnızca bir iş akışına indirdik. Log4shell güvenlik açığı 2021'in sonlarında ortaya çıktığında, tek bir iş akışına odaklanabildik ve gerektiğinde hızla düzeltebildik ( Amazon Elastik Konteyner Kayıt Defteri (Amazon ECR) tarama yapar, Amazon OpenSearch Service'i yükseltir, araçlarımızı günceller ve daha fazlası) veri bilimcilerin devam eden çalışmalarına minimum etkiyle. AWS ve Kubeflow geliştirmeleri kullanıma sunuldukça bunları uygun gördüğümüz şekilde dahil edebiliriz.

Bu bizi AWS'nin benimsenmesiyle ilgili Kubeflow'umuzun önemli ve abartısız bir yönüne getiriyor. Bu yolculuğun kritik sonuçlarından biri, veri bilimcilerimiz için Kubeflow'taki yükseltmeleri ve geliştirmeleri sorunsuz bir şekilde kullanıma sunabilme yeteneğidir. Buna yaklaşımımızı daha önce tartışmış olsak da, AWS tarafından sağlanan Kubeflow bildirimlerine de güveniyoruz. Kubeflow yolculuğumuza, 2019 sürümünün yayınlanmasından önce 1.0.0'da bir konsept kanıtı olarak başladık. (Şu anda 1.4.1'deyiz, 1.5'i değerlendiriyoruz. AWS zaten 1.6 sürümü üzerinde çalışıyor.) Aradan geçen 3 yılda, önemli içeriğe sahip en az altı sürüm çıktı. AWS'deki Kubeflow ekibi, bu yükseltmeleri entegre etmeye ve doğrulamaya ve bildirimleri öngörülebilir, güvenilir bir programda yayınlamaya yönelik disiplinli yaklaşımları sayesinde, athenahealth MLOps ekibinin geliştirme yol haritamızı ve sonuç olarak kaynak tahsislerimizi ve odak alanlarımızı planlamasını sağlamada çok önemli olmuştur. , daha büyük bir güvenle geleceğe.

Sen takip edebilirsiniz AWS Labs GitHub deposu Kubeflow'a yapılan tüm AWS katkılarını izlemek için. AWS ekiplerini şu adreste de bulabilirsiniz: Kubeflow #AWS Slack Kanalı; buradaki geri bildirimleriniz, AWS'nin Kubeflow projesine katkıda bulunmak için sonraki özelliklere öncelik vermesine yardımcı olur.

---

yazarlar hakkında

Kanwaljit Khurmi Amazon Web Services'de Kıdemli Çözüm Mimarıdır. AWS müşterileriyle birlikte çalışarak, AWS'yi kullanırken çözümlerinin değerini artırmalarına yardımcı olan rehberlik ve teknik yardım sağlar. Kanwaljit, kapsayıcılı ve makine öğrenimi uygulamaları konusunda müşterilere yardımcı olma konusunda uzmanlaşmıştır.

Tyler Kalbach athenahealth'de Teknik Personel Asli Üyesidir. Tyler, Sağlık Alanında Analitik, Veri Bilimi, Sinir Ağları ve Makine Öğrenimi uygulamalarının geliştirilmesinde yaklaşık 7 yıllık deneyime sahiptir. Şu anda üretim trafiğine hizmet eden birkaç Makine Öğrenimi çözümüne katkıda bulunmuştur. Şu anda athenahealth'in Mühendislik organizasyonunda Baş Veri Bilimcisi olarak çalışan Tyler, bu çabanın başlangıcından itibaren athenahealth için yeni Makine Öğrenimi Eğitim Platformunu oluşturan ekibin bir parçası olmuştur.

Victor Krilov athenahealth'de Teknik Personel Asli Üyesidir. Victor, veri bilimcilerinin güvenli, hızlı makine öğrenimi ardışık düzenleri oluşturmasına yardımcı olan bir mühendis ve saldırı ustasıdır. Athenahealth'te arayüzler, klinik sipariş, reçeteler, çizelgeleme, analitik ve şimdi de makine öğrenimi üzerinde çalıştı. Temiz bir şekilde yazılmış ve iyi bir şekilde test edilmiş koda değer veriyor, ancak tek satırlık kodlara sağlıksız bir takıntısı var. Boş zamanlarında köpeğini gezdirirken podcast dinlemeyi seviyor.

Sasan Vemuri athenahealth'de Teknik Personelin Baş Üyesidir. Sağlık, sigorta ve biyoinformatik gibi alanlarda veri odaklı çözümler geliştirme konusunda deneyime sahiptir. Sasank şu anda AWS ve Kubernetes üzerinde makine öğrenimi eğitim ve çıkarım platformları tasarlamak ve geliştirmek için çalışıyor ve bu platformlar ML çözümlerinin geniş ölçekte eğitilmesine ve dağıtılmasına yardımcı oluyor.

Anu Tümkur athenahealth'de bir Mimardır. Anu, makine öğrenimi, bulut işlemleri, büyük veri, gerçek zamanlı dağıtılmış veri boru hatları, reklam teknolojisi, veri analitiği, sosyal medya analitiği alanlarında çeşitli yazılım ürünleri oluşturma konusunda yirmi yılı aşkın mimari, tasarım ve geliştirme deneyimine sahiptir. Anu şu anda athenahealth'in Ürün Mühendisliği organizasyonunda Machine Learning Platform ve Data Pipeline takımlarında mimar olarak çalışıyor.

William Tsen athenahealth'de Kıdemli Mühendislik Müdürüdür. Sağlık hizmetleri BT, büyük veri dağıtılmış bilgi işlem, akıllı optik ağlar, gerçek zamanlı video düzenleme sistemleri, kurumsal yazılım ve grup sağlık sigortası alanlarında çözümler oluşturma konusunda 20 yılı aşkın mühendislik liderliği deneyimine sahiptir. William şu anda athenahealth'te, Ürün Mühendisliği organizasyonunda Makine Öğrenimi Operasyonları ve DevOps mühendislik ekipleri olan iki harika ekibi yönetiyor.