Menyusun ulang beban kerja alur kerja berbasis peristiwa (EDW) untuk Azure Kubernetes Service (AKS)
Sekarang setelah Anda memahami beberapa perbedaan platform utama antara AWS dan Azure yang relevan dengan beban kerja ini, mari kita lihat arsitektur alur kerja dan kita dapat mengubahnya untuk mengerjakan AKS.
Beban kerja AWS adalah contoh dasar pola desain konsumen yang bersaing. Implementasi AWS adalah arsitektur referensi untuk mengelola skala dan biaya untuk alur kerja berbasis peristiwa menggunakan Kubernetes, Kubernetes Event-driven Autoscaling (KEDA), dan Karpenter.
Aplikasi produsen menghasilkan beban melalui pengiriman pesan ke antrean, dan aplikasi konsumen yang berjalan dalam pod Kubernetes memproses pesan dan menulis hasilnya ke database. KEDA mengelola penskalaan otomatis pod melalui pengikatan deklaratif ke antrean produsen, dan Karpenter mengelola penskalaan otomatis simpul hanya dengan komputasi yang cukup untuk mengoptimalkan biaya. Autentikasi ke antrean dan database menggunakan proyeksi volume token akun layanan berbasis OAuth.
Beban kerja terdiri dari kluster AWS EKS untuk mengatur konsumen yang membaca pesan dari Amazon Simple Queue Service (SQS) dan menyimpan pesan yang diproses ke tabel Amazon DynamoDB. Aplikasi produsen menghasilkan pesan dan mengantrekannya dalam antrean Amazon SQS. KEDA dan Karpenter secara dinamis menskalakan jumlah simpul eks dan pod yang digunakan untuk konsumen.
Diagram berikut mewakili arsitektur beban kerja EDW di AWS:
Untuk membuat ulang beban kerja AWS di Azure dengan perubahan minimal, gunakan Azure yang setara untuk setiap layanan AWS dan pertahankan metode autentikasi yang mirip dengan yang asli. Contoh ini tidak memerlukan fitur lanjutan Azure Bus Layanan atau Azure Event Hubs. Sebagai gantinya, Anda dapat menggunakan Azure Queue Storage untuk mengantrekan pekerjaan, dan penyimpanan Azure Table untuk menyimpan hasil.
Tabel berikut ini meringkas pemetaan layanan:
Pemetaan layanan | Layanan AWS | Layanan Azure |
---|---|---|
Antrian | Layanan Antrean Sederhana | Azure Queue Storage |
Persistensi | DynamoDB (Tanpa SQL) | Azure Table Storage |
Orkestrasi | Layanan Kube Elastik (Elastic Kubernetes Service; EKS) | Azure Kubernetes Service (AKS) |
Identitas | AWS IAM | Microsoft Entra |
Diagram berikut mewakili arsitektur beban kerja Azure EDW menggunakan pemetaan layanan AWS ke Azure:
Tergantung pada pertimbangan biaya dan ketahanan terhadap kemungkinan pengeluaran node, Anda dapat memilih dari berbagai jenis komputasi.
Di AWS, Anda dapat memilih antara komputasi sesuai permintaan (lebih mahal tetapi tidak ada risiko pengeluaran) atau instans Spot (lebih murah tetapi dengan risiko pengeluaran). Di AKS, Anda dapat memilih kumpulan simpul sesuai permintaan atau kumpulan simpul Spot tergantung pada kebutuhan beban kerja Anda.
Microsoft mempertahankan artikel ini. Kontributor berikut awalnya menulisnya:
- Ken Kilty | TPM Utama
- Russell de Pina | TPM Utama
- Jenny Hayes | Pengembang Konten Senior
- Carol Smith | Pengembang Konten Senior
- Erin Schaffer | Pengembang Konten 2
Umpan balik Azure Kubernetes Service
Azure Kubernetes Service adalah proyek sumber terbuka. Pilih tautan untuk memberikan umpan balik: