Bangun alur kerja machine learning ujung-ke-ujung yang dapat diulang, aman, dan diperluas menggunakan Kubeflow di AWS

Ini adalah posting blog tamu yang ditulis bersama dengan athenahealth.

kesehatan penyedia terkemuka perangkat lunak dan layanan berkemampuan jaringan untuk kelompok medis dan sistem kesehatan nasional. Catatan kesehatan elektronik, manajemen siklus pendapatan, dan alat keterlibatan pasien memungkinkan akses kapan saja, di mana saja, mendorong hasil keuangan yang lebih baik bagi pelanggannya dan memungkinkan pelanggan penyedianya untuk memberikan perawatan berkualitas lebih baik.

Di ruang kecerdasan buatan (AI), athenahealth menggunakan ilmu data dan pembelajaran mesin (ML) untuk mempercepat proses bisnis dan memberikan rekomendasi, prediksi, dan wawasan di berbagai layanan. Dari implementasi pertamanya dalam layanan dokumen otomatis, pemrosesan jutaan dokumen penyedia-pasien tanpa sentuhan, hingga pekerjaan terbarunya dalam asisten virtual dan meningkatkan kinerja siklus pendapatan, athenahealth terus menerapkan AI untuk membantu mendorong efisiensi, kemampuan layanan, dan hasil yang lebih baik bagi penyedia dan pasien mereka.

Posting blog ini menunjukkan bagaimana athenahealth menggunakan Kubeflow di AWS (distribusi Kubeflow khusus AWS) untuk membangun dan merampingkan alur kerja data science end-to-end yang mempertahankan peralatan penting, mengoptimalkan efisiensi operasional, meningkatkan produktivitas ilmuwan data, dan menetapkan tahapan untuk memperluas kemampuan ML mereka dengan lebih mudah.

Kubeflow adalah platform ML open-source yang didedikasikan untuk membuat penerapan alur kerja ML di Kubernetes menjadi sederhana, portabel, dan skalabel. Kubeflow mencapai ini dengan memasukkan alat sumber terbuka yang relevan yang terintegrasi dengan baik dengan Kubernetes. Beberapa proyek ini termasuk Argo untuk orkestrasi pipeline, Istio untuk service mesh, Jupyter untuk notebook, Spark, TensorBoard, dan Katib. Kubeflow Pipelines membantu membangun dan menerapkan alur kerja ML portabel dan skalabel yang dapat mencakup langkah-langkah seperti ekstraksi data, prapemrosesan, pelatihan model, dan evaluasi model dalam bentuk pipeline yang dapat diulang.

AWS berkontribusi pada komunitas Kubeflow open-source dengan menyediakan distribusi Kubeflow sendiri (disebut Kubeflow di AWS) yang membantu organisasi seperti athenahealth membangun alur kerja ML yang sangat andal, aman, portabel, dan skalabel dengan pengurangan overhead operasional melalui integrasi dengan layanan terkelola AWS. AWS menyediakan berbagai opsi penerapan Kubeflow seperti penerapan dengan Amazon Kognito, penyebaran dengan Layanan Database Relasional Amazon (Amazon RDS) dan Layanan Penyimpanan Sederhana Amazon (Amazon S3), dan penyebaran vanilla. Untuk detail tentang integrasi layanan dan add-on yang tersedia untuk setiap opsi ini, lihat Penyebaran.

Hari ini, Kubeflow di AWS menyediakan jalur yang jelas untuk menggunakan Kubeflow, ditambah dengan layanan AWS berikut:

Banyak pelanggan AWS memanfaatkan distribusi Kubeflow di AWS, termasuk athenahealth.

Di sini, tim MLOps athenahealth mendiskusikan tantangan yang mereka hadapi dan solusi yang mereka buat dalam perjalanan Kubeflow mereka.

Tantangan dengan lingkungan ML sebelumnya

Sebelum kami mengadopsi Kubeflow di AWS, ilmuwan data kami menggunakan seperangkat alat standar dan proses yang memungkinkan fleksibilitas dalam teknologi dan alur kerja yang digunakan untuk melatih model tertentu. Contoh komponen alat standar mencakup API penyerapan data, alat pemindaian keamanan, saluran CI/CD yang dibuat dan dikelola oleh tim lain dalam athenahealth, dan platform penyajian umum yang dibuat dan dikelola oleh tim MLOps. Namun, seiring dengan semakin matangnya penggunaan AI dan ML, beragam alat dan infrastruktur yang dibuat untuk setiap model semakin bertambah. Meskipun kami masih dapat mendukung proses yang ada, kami melihat tantangan di depan mata sebagai berikut:

• Pemeliharaan dan pertumbuhan – Mereproduksi dan memelihara lingkungan pelatihan model membutuhkan lebih banyak upaya karena jumlah model yang diterapkan meningkat. Setiap proyek memelihara dokumentasi rinci yang menguraikan bagaimana setiap skrip digunakan untuk membangun model akhir. Dalam banyak kasus, ini adalah proses rumit yang melibatkan 5 hingga 10 skrip dengan beberapa keluaran masing-masing. Ini harus dilacak secara manual dengan instruksi rinci tentang bagaimana setiap output akan digunakan dalam proses selanjutnya. Mempertahankan ini dari waktu ke waktu menjadi rumit. Selain itu, karena proyek menjadi lebih kompleks, jumlah alat juga meningkat. Misalnya, sebagian besar model menggunakan Spark dan TensorFlow dengan GPU, yang membutuhkan lebih banyak variasi konfigurasi lingkungan. Seiring waktu, pengguna akan beralih ke versi alat yang lebih baru di lingkungan pengembangan mereka tetapi kemudian tidak dapat menjalankan skrip yang lebih lama ketika versi tersebut menjadi tidak kompatibel. Akibatnya, memelihara dan menambah proyek yang lebih tua membutuhkan lebih banyak waktu dan upaya rekayasa. Selain itu, saat ilmuwan data baru bergabung dengan tim, transfer pengetahuan dan orientasi membutuhkan lebih banyak waktu, karena menyinkronkan lingkungan lokal mencakup banyak dependensi yang tidak terdokumentasi. Beralih antar proyek menghadapi masalah yang sama karena setiap model memiliki alur kerjanya sendiri.
• Security – Kami menganggap serius keamanan, dan oleh karena itu memprioritaskan kepatuhan terhadap semua kewajiban kontrak, hukum, dan peraturan yang terkait dengan ML dan ilmu data. Data harus digunakan, disimpan, dan diakses dengan cara tertentu, dan kami telah menyematkan proses yang kuat untuk memastikan praktik kami mematuhi kewajiban hukum kami serta selaras dengan praktik terbaik industri. Sebelum adopsi Kubeflow, memastikan bahwa data disimpan dan diakses dengan cara tertentu melibatkan verifikasi rutin di beberapa alur kerja yang beragam. Kami tahu bahwa kami dapat meningkatkan efisiensi dengan menggabungkan beragam alur kerja ini ke dalam satu platform. Namun, platform itu harus cukup fleksibel untuk berintegrasi dengan baik dengan peralatan standar kami.
• Operasi – Kami juga melihat peluang untuk meningkatkan efisiensi dan manajemen operasional melalui pemusatan pencatatan dan pemantauan alur kerja. Karena setiap tim telah mengembangkan alat mereka sendiri, kami mengumpulkan informasi ini dari setiap alur kerja secara individual dan menggabungkannya.

Tim ilmu data mengevaluasi berbagai solusi untuk mengkonsolidasikan alur kerja. Selain memenuhi persyaratan ini, kami mencari solusi yang akan berintegrasi mulus dengan infrastruktur dan alat standar yang ada. Kami memilih Amazon EKS dan Kubeflow di AWS sebagai solusi alur kerja kami.

Siklus pengembangan ilmuwan data yang menggabungkan Kubeflow

Proyek ilmu data dimulai dengan awal yang bersih: tanpa data, tanpa kode, hanya masalah bisnis yang dapat diselesaikan dengan ML. Tugas pertama adalah proof of concept (POC) untuk mengetahui apakah data memiliki sinyal yang cukup untuk membuat model ML efektif dalam memecahkan masalah bisnis, dimulai dengan meminta dataset mentah dari gudang data Snowflake kami. Tahap ini berulang, dan ilmuwan data menggunakan pod Kubernetes atau notebook Kubeflow Jupyter selama proses ini.

Cluster Kubeflow kami menggunakan autoscaler cluster Karpenter, yang membuat pemintalan sumber daya menjadi mudah bagi ilmuwan data karena mereka hanya perlu fokus untuk menentukan jenis instans yang diinginkan, sementara pekerjaan penyediaan dilakukan oleh satu set penyedia Karpenter yang telah ditentukan sebelumnya. Kami memiliki penyedia terpisah untuk jenis instans CPU dan GPU, dan semua instans yang didukung oleh Amazon EKS termasuk dalam salah satu dari dua kategori ini sesuai dengan konfigurasi penyedia kami. Ilmuwan data memilih jenis instans menggunakan pemilih simpul, dan Karpenter menangani manajemen siklus hidup simpul.

Setelah kueri dikembangkan, ilmuwan data mengekstrak data mentah ke lokasi di Amazon S3, lalu meluncurkan notebook Jupyter dari UI AWS Kubeflow untuk menjelajahi data. Tujuannya adalah untuk membuat set fitur yang akan digunakan untuk melatih model pertama. Hal ini memungkinkan para ilmuwan data untuk menentukan apakah ada cukup sinyal dalam data untuk memenuhi kebutuhan bisnis pelanggan.

Setelah hasilnya memuaskan, para ilmuwan data pindah ke tahap berikutnya dari siklus pengembangan dan mengubah penemuan mereka menjadi jalur yang kuat. Mereka mengubah kode POC menjadi kode kualitas produksi yang berjalan dalam skala besar. Untuk memastikan kepatuhan melalui penggunaan pustaka yang disetujui, wadah dibuat dengan gambar Docker dasar yang sesuai. Untuk ilmuwan data kami, kami telah menemukan bahwa menyediakan gambar dasar Python, TensorFlow, dan Spark standar memberikan fleksibilitas yang cukup untuk sebagian besar, jika tidak semua, beban kerja. Mereka kemudian dapat menggunakan Dockerfile dari komponen mereka untuk lebih menyesuaikan lingkungan pengembangan mereka. Dockerfile ini kemudian digunakan oleh proses CI/CD untuk membangun image komponen yang akan digunakan dalam produksi, sehingga menjaga konsistensi antara lingkungan pengembangan dan produksi.

Kami memiliki alat yang memberi para ilmuwan data kemampuan untuk meluncurkan lingkungan pengembangan mereka dalam pod yang berjalan di Kubernetes. Saat pod ini berjalan, ilmuwan data kemudian dapat melampirkan IDE Kode Visual Studio langsung ke pod dan men-debug kode model mereka. Setelah kode berjalan dengan sukses, mereka kemudian dapat mendorong perubahan mereka ke git dan lingkungan pengembangan baru dibuat dengan perubahan terbaru.

Pipa ilmu data standar terdiri dari tahapan yang mencakup ekstraksi, pra-pemrosesan, pelatihan, dan evaluasi. Setiap tahapan dalam pipeline muncul sebagai komponen di Kubeflow, yang terdiri dari pod Kubernetes yang menjalankan perintah dengan beberapa informasi yang diteruskan sebagai parameter. Parameter ini dapat berupa nilai statis atau referensi ke output dari komponen sebelumnya. Gambar Docker yang digunakan dalam pod dibangun dari proses CI/CD. Detail tentang proses ini muncul di alur kerja CI/CD yang dibahas di bagian berikutnya.

Siklus Pengembangan di Kubeflow. Alur kerja pengembangan dimulai di sebelah kiri dengan POC. Model yang telah selesai diterapkan ke platform penyajian model athenahealth yang berjalan di Amazon ECS.

Proses CI/CD yang mendukung alur kerja otomatis

Sebagai bagian dari proses CI/CD kami, kami menggunakan Jenkins untuk membangun dan menguji semua gambar komponen Kubeflow secara paralel. Setelah berhasil diselesaikan, template komponen pipeline berisi pointer referensi ke gambar, dan pipeline yang dihasilkan diunggah ke Kubeflow. Parameter di pipeline Jenkins memungkinkan pengguna meluncurkan pipeline dan menjalankan pengujian pelatihan model mereka setelah build berhasil.

Atau, untuk mempertahankan siklus pengembangan yang singkat, ilmuwan data juga dapat meluncurkan pipeline dari mesin lokal mereka, memodifikasi parameter pipeline apa pun yang mungkin mereka uji.

Ada perkakas untuk memastikan penunjuk referensi dari build CI/CD digunakan secara default. Jika ada artefak yang dapat diterapkan dalam repo, maka logika CI/CD akan terus menerapkan artefak ke platform penyajian model athenahealth (Layanan Prediksi) yang berjalan di Amazon ECS dengan Fargate AWS. Setelah semua tahapan ini berlalu, ilmuwan data menggabungkan kode ke cabang utama. Pipeline dan artefak yang dapat digunakan kemudian didorong ke produksi.

Alur kerja Penerapan CI/CD. Diagram ini menjelaskan alur kerja pembuatan dan penerapan Ilmu Data. Proses CI/CD didorong oleh Jenkins.

Security

Dalam mengkonsolidasikan alur kerja ilmu data kami, kami dapat memusatkan pendekatan kami untuk mengamankan alur pelatihan. Di bagian ini, kami membahas pendekatan kami terhadap keamanan data dan cluster.

Keamanan data

Keamanan data adalah yang paling penting di athenahealth. Untuk alasan ini, kami mengembangkan dan memelihara infrastruktur yang sepenuhnya sesuai dengan peraturan dan standar yang melindungi keamanan dan integritas data ini.

Untuk memastikan kami memenuhi standar kepatuhan data, kami menyediakan infrastruktur AWS kami sesuai dengan pedoman perusahaan athenahealth kami. Dua penyimpanan utama untuk data adalah Amazon RDS untuk metadata pipeline yang sangat skalabel dan Amazon S3 untuk artefak pipeline dan model. Untuk Amazon S3, kami memastikan bucket dienkripsi, endpoint HTTPS diterapkan, dan kebijakan bucket dan Identitas AWS dan Manajemen Akses Peran (IAM) mengikuti prinsip hak istimewa paling rendah saat mengizinkan akses ke data. Hal ini juga berlaku untuk data Amazon RDS: enkripsi selalu diaktifkan, dan grup keamanan serta akses kredensial mengikuti prinsip hak istimewa terkecil. Standarisasi ini memastikan bahwa hanya pihak yang berwenang yang memiliki akses ke data, dan akses ini dilacak.

Selain langkah-langkah ini, platform juga menjalani penilaian ancaman keamanan dan pemindaian keamanan dan kepatuhan yang berkelanjutan.

Kami juga menangani persyaratan retensi data melalui manajemen siklus hidup data untuk semua bucket S3 yang berisi data sensitif. Kebijakan ini secara otomatis memindahkan data ke Gletser Amazon S3 setelah 30 hari pembuatan. Pengecualian untuk ini dikelola melalui permintaan pengambilan data dan disetujui atau ditolak berdasarkan kasus per kasus. Ini memastikan bahwa semua alur kerja mematuhi kebijakan penyimpanan data. Ini juga memecahkan masalah dengan memulihkan data jika model berkinerja buruk, dan pelatihan ulang diperlukan, atau ketika model baru harus dievaluasi terhadap iterasi historis dari kumpulan data model lama.

Untuk membatasi akses ke Amazon S3 dan Amazon RDS dari dalam Kubeflow di AWS dan Amazon EKS, kami menggunakan IRSA (IAM Roles for Service Accounts), yang menyediakan penyediaan izin berbasis IAM untuk sumber daya dalam Kubernetes. Setiap tenant di Kubeflow memiliki akun layanan unik yang telah dibuat sebelumnya yang kami ikat ke peran IAM yang dibuat khusus untuk memenuhi persyaratan akses tenant. Akses pengguna ke penyewa juga dibatasi menggunakan keanggotaan grup kumpulan pengguna Amazon Cognito untuk setiap pengguna. Saat pengguna diautentikasi ke cluster, token yang dihasilkan berisi klaim grup, dan Kubernetes RBAC menggunakan informasi ini untuk mengizinkan atau menolak akses ke sumber daya tertentu di cluster. Pengaturan ini dijelaskan secara lebih rinci di bagian selanjutnya.

Keamanan cluster menggunakan isolasi multi-pengguna

Seperti yang kami sebutkan di bagian sebelumnya, ilmuwan data melakukan analisis data eksplorasi, menjalankan analisis data, dan melatih model ML. Untuk mengalokasikan sumber daya, mengatur data, dan mengelola alur kerja berdasarkan proyek, Kubeflow di AWS menyediakan isolasi berdasarkan ruang nama Kubernetes. Isolasi ini berfungsi untuk berinteraksi dengan UI Kubeflow; namun, itu tidak menyediakan alat apa pun untuk mengontrol akses ke API Kubernetes menggunakan Kubectl. Ini berarti bahwa akses pengguna dapat dikontrol di UI Kubeflow tetapi tidak melalui Kubernetes API melalui Kubectl.

Arsitektur yang dijelaskan dalam diagram berikut mengatasi masalah ini dengan menyatukan akses ke proyek di Kubeflow berdasarkan keanggotaan grup. Untuk mencapai ini, kami memanfaatkan manifes Kubeflow di AWS, yang memiliki integrasi dengan kumpulan pengguna Amazon Cognito. Selain itu, kami menggunakan kontrol akses berbasis peran (RBAC) Kubernetes untuk mengontrol otorisasi dalam cluster. Izin pengguna disediakan berdasarkan keanggotaan grup Amazon Cognito. Informasi ini diteruskan ke cluster dengan token yang dihasilkan oleh klien OIDC. Proses ini disederhanakan berkat fungsionalitas Amazon EKS bawaan yang memungkinkan penyedia identitas OIDC yang terkait untuk mengautentikasi dengan klaster.

Secara default, autentikasi Amazon EKS dilakukan oleh autentikator IAM, yang merupakan alat yang memungkinkan autentikasi dengan klaster EKS menggunakan kredensial IAM. Metode otentikasi ini memiliki kelebihan; namun, ini tidak cocok untuk kasus penggunaan kami karena athenahealth menggunakan Microsoft Azure Active Directory untuk layanan identitas di seluruh organisasi.

Isolasi namespace Kubernetes. Ilmuwan Data dapat memperoleh keanggotaan ke satu atau beberapa kelompok sesuai kebutuhan untuk pekerjaan mereka. Akses ditinjau secara teratur dan dihapus sebagaimana mestinya.

Azure Active Directory, sebagai layanan identitas seluruh perusahaan, adalah sumber kebenaran untuk mengontrol akses pengguna ke klaster Kubeflow. Penyiapan untuk ini termasuk membuat Aplikasi Azure Enterprise yang bertindak sebagai prinsip layanan dan menambahkan grup untuk berbagai penyewa yang memerlukan akses ke kluster. Penyiapan di Azure ini dicerminkan di Amazon Cognito dengan menyiapkan penyedia identitas OIDC gabungan yang mengalihkan tanggung jawab autentikasi ke Azure. Akses ke grup Azure dikendalikan oleh SailPoint IdentityIQ, yang mengirimkan permintaan akses ke pemilik proyek untuk mengizinkan atau menolak sebagaimana mestinya. Di kumpulan pengguna Amazon Cognito, dua klien aplikasi dibuat: satu digunakan untuk mengatur autentikasi untuk klaster Kubernetes menggunakan penyedia identitas OIDC, dan yang lainnya untuk mengamankan autentikasi Kubeflow ke UI Kubeflow. Klien ini dikonfigurasi untuk meneruskan klaim grup setelah otentikasi dengan cluster, dan klaim grup ini digunakan bersama RBAC untuk menyiapkan otorisasi dalam cluster.

Role binding Kubernetes RBAC diatur antara grup dan peran cluster Kubeflow-edit, yang dibuat setelah menginstal Kubeflow di cluster. Pengikatan peran ini memastikan setiap pengguna yang berinteraksi dengan cluster setelah masuk melalui OIDC dapat mengakses ruang nama yang mereka miliki izinnya seperti yang ditentukan dalam klaim grup mereka. Meskipun ini berfungsi untuk pengguna yang berinteraksi dengan cluster menggunakan Kubectl, UI Kubeflow saat ini tidak menyediakan akses ke pengguna berdasarkan keanggotaan grup karena tidak menggunakan RBAC. Sebagai gantinya, ia menggunakan sumber daya Kebijakan Otorisasi Istio untuk mengontrol akses bagi pengguna. Untuk mengatasi tantangan ini, kami mengembangkan pengontrol kustom yang menyinkronkan pengguna dengan polling grup Amazon Cognito dan menambahkan atau menghapus binding peran yang sesuai untuk setiap pengguna, bukan berdasarkan grup. Pengaturan ini memungkinkan pengguna untuk memiliki tingkat izin yang sama saat berinteraksi dengan UI Kubeflow dan Kubectl.

Efisiensi operasional

Di bagian ini, kami membahas bagaimana kami memanfaatkan sumber terbuka dan alat AWS yang tersedia bagi kami untuk mengelola dan men-debug alur kerja kami serta meminimalkan dampak operasional peningkatan Kubeflow.

Logging dan pemantauan

Untuk logging, kami menggunakan FluentD untuk mendorong semua log container kami ke Layanan Pencarian Terbuka Amazon dan metrik sistem ke Prometheus. Kami kemudian menggunakan Kibana dan Grafana UI untuk mencari dan memfilter log dan metrik. Diagram berikut menjelaskan bagaimana kami mengatur ini.

Pencatatan Kubeflow. Kami menggunakan Grafana UI dan Kibana untuk melihat dan menyaring log

Tangkapan layar berikut adalah tampilan UI Kibana dari saluran kami.

Contoh Tampilan UI Kibana. Kibana memungkinkan tampilan yang disesuaikan.

Pembaruan cluster Kubeflow yang aman

Saat kami mengarahkan pengguna ke Kubeflow di AWS, kami mempertahankan pengalaman pengguna yang andal dan konsisten sambil memungkinkan tim MLOps tetap gesit dengan merilis dan mengintegrasikan fitur-fitur baru. Di permukaan, Kustomize tampaknya modular bagi kami untuk memungkinkan kerja dan peningkatan satu komponen pada satu waktu tanpa memengaruhi yang lain, sehingga memungkinkan kami untuk menambahkan kemampuan baru dengan gangguan minimal kepada pengguna. Namun, dalam praktiknya ada skenario di mana pendekatan terbaik adalah dengan membuat cluster Kubernetes baru daripada menerapkan upgrade tingkat komponen untuk cluster yang ada. Kami menemukan dua kasus penggunaan yang lebih masuk akal untuk membuat kluster yang benar-benar baru:

• Memutakhirkan ke versi Kubernetes di mana AWS menyediakan pemutakhiran klaster di tempat. Namun, menjadi sulit untuk menguji apakah masing-masing sumber daya Kubeflow dan Kubernetes berfungsi sebagaimana mestinya dan manifes mempertahankan kompatibilitas ke belakang.
• Mengupgrade Kubeflow ke rilis yang lebih baru di mana ada beberapa fitur yang ditambahkan atau dimodifikasi dan hampir selalu bukan ide yang menjanjikan untuk melakukan upgrade di tempat pada cluster Kubernetes yang ada.

Dalam mengatasi masalah ini, kami mengembangkan strategi yang memungkinkan kami untuk memiliki penggantian cluster yang aman tanpa memengaruhi beban kerja yang ada. Untuk mencapai ini, kami harus memenuhi kriteria berikut:

• Pisahkan penyimpanan Kubeflow dan sumber daya komputasi sehingga metadata pipeline, artefak pipeline, dan data pengguna dipertahankan saat melakukan deprovisioning pada cluster yang lebih lama
• Integrasikan dengan Kubeflow pada manifes AWS sehingga ketika terjadi peningkatan versi Kubeflow, perubahan minimal diperlukan
• Dapatkan cara mudah untuk memutar kembali jika terjadi kesalahan setelah peningkatan klaster
• Memiliki antarmuka sederhana untuk mempromosikan kluster kandidat ke produksi

Diagram berikut menggambarkan arsitektur ini.

Peningkatan Kluster Kubeflow Aman. Setelah pengujian Kandidat Kubeflow berhasil, itu dipromosikan ke Kubeflow Prod melalui pembaruan ke Route 53.

Manifes Kubeflow di AWS sudah dikemas sebelumnya dengan integrasi Amazon RDS dan Amazon S3. Dengan layanan terkelola ini yang bertindak sebagai penyimpanan data umum, kami dapat menyiapkan strategi penerapan biru-hijau. Untuk mencapai hal ini, kami memastikan bahwa metadata pipeline dipertahankan di Amazon RDS, yang bekerja secara independen dari klaster EKS, dan log pipeline serta artefak dipertahankan di Amazon S3. Selain metadata dan artefak pipeline, kami juga menyiapkan FluentD untuk merutekan log pod ke Amazon OpenSearch Service.

Ini memastikan bahwa lapisan penyimpanan benar-benar terpisah dari lapisan komputasi dan dengan demikian memungkinkan pengujian perubahan selama pembaruan versi Kubeflow pada klaster EKS yang benar-benar baru. Setelah semua tes berhasil, kami hanya dapat mengubah Amazon Route 53 Data DNS ke kandidat cluster yang menghosting Kubeflow. Selain itu, kami menjaga cluster lama tetap berjalan sebagai cadangan selama beberapa hari untuk berjaga-jaga jika kami perlu memutar kembali.

Manfaat Amazon EKS dan Kubeflow di AWS untuk pipeline ML kami

Amazon EKS dan paket Kubeflow on AWS memindahkan alur kerja pengembangan kami ke pola yang sangat mendorong pelatihan model berulang. Alat-alat ini memungkinkan kita untuk memiliki cluster yang sepenuhnya ditentukan dengan penyewa yang sepenuhnya ditentukan dan menjalankan kode yang ditentukan sepenuhnya.

Banyak kemenangan dari membangun platform ini kurang kuantitatif dan lebih berkaitan dengan bagaimana alur kerja meningkat untuk pengembang dan pengguna platform. Misalnya, MinIO diganti dengan akses langsung ke Amazon S3, yang membuat kami lebih dekat dengan alur kerja asli kami dan mengurangi jumlah layanan yang harus kami pertahankan. Kami juga dapat memanfaatkan Amazon RDS sebagai backend untuk Kubeflow, yang memungkinkan migrasi yang lebih mudah antar klaster dan memberi kami kemampuan untuk mencadangkan pipeline kami setiap malam.

Kami juga menemukan peningkatan dalam integrasi Kubeflow dengan layanan terkelola AWS bermanfaat. Misalnya, dengan Amazon RDS, Amazon S3, dan Amazon Cognito yang telah dikonfigurasikan sebelumnya dalam manifes Kubeflow di AWS, kami menghemat waktu dan tenaga untuk memperbarui ke distribusi Kubeflow yang lebih baru. Saat kami biasa memodifikasi manifes resmi Kubeflow secara manual, memperbarui ke versi baru akan memakan waktu beberapa minggu, mulai dari desain hingga pengujian.

Beralih ke Amazon EKS memberi kami kesempatan untuk mendefinisikan klaster kami di Kustomize (sekarang bagian dari Kubectl) dan Terraform. Ternyata untuk pekerjaan platform, Kubernetes dan Terraform sangat mudah digunakan setelah meluangkan waktu yang cukup untuk belajar. Setelah banyak iterasi, alat yang tersedia untuk kami membuatnya sangat mudah untuk melakukan operasi platform standar seperti memutakhirkan komponen atau menukar seluruh kluster pengembangan. Dibandingkan dengan menjalankan pekerjaan mentah Cloud komputasi elastis Amazon (Amazon EC2), sulit untuk membandingkan apa perbedaan besar yang dibuatnya untuk memiliki pod yang terdefinisi dengan baik dengan pembersihan sumber daya yang dijamin dan mekanisme coba lagi yang ada di dalamnya.

Kubernetes memberikan standar keamanan yang luar biasa, dan kami hanya menggores permukaan dari apa yang dimungkinkan oleh isolasi multi-pengguna. Kami melihat isolasi multi-pengguna sebagai pola yang memiliki hasil lebih di masa depan ketika platform pelatihan menghasilkan data tingkat produksi, dan kami mendatangkan pengembang dari luar tim kami.

Sementara itu, Kubeflow memungkinkan kita untuk memiliki pelatihan model yang dapat direproduksi. Bahkan dengan data yang sama, tidak ada pelatihan yang menghasilkan model yang identik, tetapi kami memiliki hal terbaik berikutnya. Dengan Kubeflow, kita tahu persis kode dan data apa yang digunakan untuk melatih model. Orientasi telah meningkat pesat karena setiap langkah dalam pipeline kami didefinisikan dengan jelas dan terprogram. Ketika data scientist baru memiliki tugas untuk memperbaiki bug, mereka membutuhkan lebih sedikit pegangan karena ada struktur yang jelas tentang bagaimana output kode digunakan di antara tahapan.

Menggunakan Kubeflow juga menghasilkan banyak peningkatan kinerja dibandingkan dengan menjalankan pada satu instans EC2. Seringkali dalam pelatihan model, ilmuwan data memerlukan alat dan pengoptimalan yang berbeda untuk prapemrosesan dan pelatihan. Misalnya, prapemrosesan sering dijalankan menggunakan alat pemrosesan data terdistribusi, seperti Spark, sedangkan pelatihan sering dijalankan menggunakan instans GPU. Dengan pipeline Kubeflow, mereka dapat menentukan tipe instance yang berbeda untuk tahapan yang berbeda dalam pipeline. Hal ini memungkinkan mereka untuk menggunakan instans GPU yang kuat dalam satu tahap dan armada mesin yang lebih kecil untuk pemrosesan terdistribusi di tahap lain. Selain itu, karena pipeline Kubeflow menggambarkan dependensi antar tahapan, pipeline dapat menjalankan tahapan secara paralel.

Terakhir, karena kami membuat proses untuk menambahkan penyewa ke klaster, sekarang ada cara yang lebih formal untuk mendaftarkan tim ke penyewa di klaster. Karena kami menggunakan Kubecost untuk melacak biaya di klaster EKS kami, ini memungkinkan kami untuk mengatribusikan biaya ke satu proyek daripada memiliki biaya yang diatribusikan di tingkat akun, yang mencakup semua proyek ilmu data. Kubecost menyajikan laporan uang yang dihabiskan per namespace, yang digabungkan erat dengan penyewa atau tim yang bertanggung jawab untuk menjalankan pipeline.

Terlepas dari semua manfaatnya, kami akan berhati-hati untuk hanya melakukan migrasi semacam ini jika ada dukungan total dari pengguna. Pengguna yang meluangkan waktu mendapatkan banyak manfaat dari menggunakan Amazon EKS dan Kubernetes, tetapi ada kurva pembelajaran yang signifikan.

Kesimpulan

Dengan implementasi pipeline Kubeflow on AWS di infrastruktur ML end-to-end kami, kami dapat mengkonsolidasikan dan menstandardisasi alur kerja ilmu data kami sambil mempertahankan alat penting kami (seperti CI/CD dan penyajian model). Ilmuwan data kami sekarang dapat berpindah antar proyek berdasarkan alur kerja ini tanpa biaya tambahan untuk mempelajari cara memelihara perangkat yang sama sekali berbeda. Untuk beberapa model kami, kami juga terkejut dengan kecepatan alur kerja baru (lima kali lebih cepat), yang memungkinkan lebih banyak iterasi pelatihan dan akibatnya menghasilkan model dengan prediksi yang lebih baik.

Kami juga telah membangun fondasi yang kuat untuk meningkatkan kemampuan MLOps kami dan menskalakan jumlah dan ukuran proyek kami. Misalnya, saat kami memperkuat postur tata kelola kami dalam garis keturunan dan pelacakan model, kami telah mengurangi fokus kami dari lebih dari 15 alur kerja menjadi hanya satu. Dan ketika kerentanan Log4shell terungkap pada akhir tahun 2021, kami dapat fokus pada satu alur kerja dan dengan cepat melakukan perbaikan sesuai kebutuhan (melakukan Registry Kontainer Elastis Amazon (Amazon ECR) scan, upgrade Amazon OpenSearch Service, update tooling kami, dan banyak lagi) dengan dampak minimal pada pekerjaan yang sedang berlangsung oleh para ilmuwan data. Saat peningkatan AWS dan Kubeflow tersedia, kami dapat menggabungkannya sesuai keinginan.

Ini membawa kita ke aspek penting dan sederhana dari adopsi Kubeflow di AWS. Salah satu hasil penting dari perjalanan ini adalah kemampuan untuk meluncurkan peningkatan dan penyempurnaan Kubeflow secara mulus bagi para ilmuwan data kami. Meskipun kami membahas pendekatan kami sebelumnya, kami juga mengandalkan manifes Kubeflow yang disediakan oleh AWS. Kami memulai perjalanan Kubeflow sebagai bukti konsep pada tahun 2019, sebelum rilis versi 1.0.0. (Saat ini kami sedang mengerjakan 1.4.1, mengevaluasi 1.5. AWS sudah mengerjakan versi 1.6.) Dalam 3 tahun berikutnya, setidaknya ada enam rilis dengan konten substansial. Melalui pendekatan disiplin mereka untuk mengintegrasikan dan memvalidasi peningkatan ini dan merilis manifes pada jadwal yang dapat diprediksi dan andal, tim Kubeflow di AWS sangat penting dalam memungkinkan tim MLOps athenahealth untuk merencanakan peta jalan pengembangan kami, dan akibatnya alokasi sumber daya dan area fokus kami , lebih jauh ke masa depan dengan keyakinan yang lebih besar.

Anda bisa mengikuti Repositori GitHub AWS Labs untuk melacak semua kontribusi AWS ke Kubeflow. Anda juga dapat menemukan tim AWS di Saluran Kubeflow #AWS Slack; umpan balik Anda membantu AWS memprioritaskan fitur berikutnya untuk berkontribusi pada proyek Kubeflow.

---

Tentang penulis

Kanwaljit Khurmi adalah Arsitek Solusi Senior di Amazon Web Services. Dia bekerja dengan pelanggan AWS untuk memberikan panduan dan bantuan teknis yang membantu mereka meningkatkan nilai solusi mereka saat menggunakan AWS. Kanwaljit mengkhususkan diri dalam membantu pelanggan dengan aplikasi kemas dan pembelajaran mesin.

Tyler Kalbach adalah Anggota Utama Staf Teknis di athenahealth. Tyler memiliki sekitar 7 tahun pengalaman di bidang Analisis, Ilmu Data, Jaringan Saraf Tiruan, dan pengembangan aplikasi Pembelajaran Mesin di bidang Perawatan Kesehatan. Dia telah berkontribusi pada beberapa solusi Machine Learning yang saat ini melayani lalu lintas produksi. Saat ini bekerja sebagai Ilmuwan Data Utama di organisasi Teknik athenahealth, Tyler telah menjadi bagian dari tim yang telah membangun Platform Pelatihan Pembelajaran Mesin baru untuk athenahealth sejak awal upaya tersebut.

Victor Krylov adalah Anggota Utama Staf Teknis di athenahealth. Victor adalah seorang insinyur dan master scrum, yang membantu ilmuwan data membangun jalur pembelajaran mesin cepat yang aman. Di athenahealth dia telah mengerjakan antarmuka, pemesanan klinis, resep, penjadwalan, analitik, dan sekarang pembelajaran mesin. Dia menghargai kode yang ditulis dengan bersih dan unit yang diuji dengan baik, tetapi memiliki obsesi yang tidak sehat dengan kode satu baris. Di waktu luangnya, dia suka mendengarkan podcast sambil berjalan-jalan dengan anjingnya.

Sasak Vemuri adalah Anggota Utama Staf Teknis di athenahealth. Dia memiliki pengalaman bekerja dengan mengembangkan solusi berbasis data di seluruh domain seperti perawatan kesehatan, asuransi, dan bioinformatika. Sasank saat ini bekerja dengan merancang dan mengembangkan pelatihan pembelajaran mesin dan platform inferensi di AWS dan Kubernetes yang membantu pelatihan dan penerapan solusi ML dalam skala besar.

Anu Tumkur adalah seorang Arsitek di athenahealth. Anu memiliki lebih dari dua dekade arsitektur, desain, pengalaman pengembangan membangun berbagai produk perangkat lunak dalam pembelajaran mesin, operasi cloud, data besar, saluran data terdistribusi real-time, teknologi iklan, analitik data, analitik media sosial. Anu saat ini bekerja sebagai arsitek di organisasi Rekayasa Produk athenahealth di tim Platform Pembelajaran Mesin dan Pipa Data.

William Tsen adalah Manajer Teknik Senior di athenahealth. Dia memiliki lebih dari 20 tahun pengalaman kepemimpinan teknik dalam membangun solusi di bidang TI perawatan kesehatan, komputasi terdistribusi data besar, jaringan optik cerdas, sistem pengeditan video waktu nyata, perangkat lunak perusahaan, dan penjaminan perawatan kesehatan grup. William saat ini memimpin dua tim hebat di athenahealth, tim teknik Operasi Pembelajaran Mesin dan DevOps, di organisasi Rekayasa Produk.