Penskalaan Otomatis Layanan ECS dan Penyeimbangan Beban

jumlah yang diinginkan secara tetap pada layanan ECS tidak dapat menanggapi fluktuasi lalu lintas—Anda akan menyediakan kapasitas berlebih (membuang biaya) atau kekurangan kapasitas (menurunkan kinerja). Penskalaan Otomatis Layanan ECS secara otomatis menyesuaikan jumlah tugas yang diinginkan berdasarkan metrik CloudWatch. Di balik layar, fitur ini menggunakan layanan Application Auto Scaling—kerangka kerja yang sama yang digunakan oleh DynamoDB, Aurora, dan ElastiCache. Penskalaan otomatis layanan ECS mendukung kebijakan pelacakan target, penskalaan bertahap, dan penskalaan terjadwal.

Sebelum menambahkan kebijakan penskalaan, daftarkan layanan ECS sebagai target yang dapat diskalakan di Application Auto Scaling. Tentukan jumlah tugas minimum dan maksimum, nama cluster, serta nama layanan sebagai ID sumber daya. Tindakan ini menetapkan batas tempat penskalaan otomatis akan beroperasi. Jumlah minimum memastikan Anda selalu memiliki kapasitas dasar; jumlah maksimum mencegah penskalaan tak terkendali yang menghabiskan kapasitas Fargate atau instans EC2.

Pelacakan Target adalah kebijakan penskalaan otomatis yang direkomendasikan untuk sebagian besar layanan ECS. Metrik target yang paling umum adalah ECSServiceAverageCPUUtilization—tetapkan target sebesar 50–70%, lalu ECS akan menambah atau menghapus tugas untuk mempertahankan tingkat CPU tersebut. Metrik lain yang sangat berguna adalah jumlah permintaan ALB per target: lacak jumlah permintaan ALB per tugas dan lakukan penskalaan untuk mempertahankan tingkat permintaan target per instans. AWS secara otomatis menangani scale-out dan scale-in dengan periode cooldown yang sesuai.

Menghubungkan Application Load Balancer (ALB) ke layanan ECS akan mendistribusikan lalu lintas HTTP/HTTPS ke seluruh tugas yang sedang berjalan. Grup target ALB mendaftarkan IP setiap tugas (untuk Fargate/awsvpc) atau port kontainer (untuk mode bridge). ECS secara otomatis mendaftarkan tugas baru ke grup target saat tugas tersebut dimulai dan membatalkan pendaftarannya saat tugas berhenti. ALB melakukan pemeriksaan kesehatan pada setiap tugas; tugas yang tidak sehat akan dikuras (koneksi ditutup secara bertahap) sebelum layanan menghentikannya.

Salah satu pola yang sangat berguna adalah merutekan jalur URL yang berbeda ke layanan ECS yang berbeda menggunakan perutean berbasis jalur ALB. Satu ALB dengan satu listener HTTPS dapat merutekan: /api/orders/* ke layanan ECS Orders, /api/users/* ke layanan ECS Users, dan /api/products/* ke layanan ECS Products—masing-masing didukung oleh layanan ECS sendiri dengan penskalaan independen. Cara ini menghilangkan kebutuhan akan load balancer terpisah untuk setiap layanan mikro, sehingga mengurangi biaya dan menyederhanakan pengelolaan DNS.

Saat tugas ECS akan dihentikan (selama scale-in atau deployment), ALB menandainya sebagai sedang dikuras dan berhenti merutekan permintaan baru kepadanya, tetapi tetap mengizinkan permintaan yang sedang berlangsung hingga selesai. Penundaan pembatalan pendaftaran (default 300 detik, dapat dikonfigurasi dari 0–3600 detik) adalah waktu tunggu ALB sebelum menutup koneksi secara paksa. Untuk ECS dengan durasi permintaan singkat, tetapkan penundaan pembatalan pendaftaran yang lebih rendah (30–60 detik) agar deployment dan operasi scale-in berlangsung lebih cepat. Untuk koneksi yang berlangsung lama (WebSocket, unggahan file), pertahankan penundaan yang lebih tinggi.

Selain CPU dan memori, publikasikan metrik CloudWatch khusus dari aplikasi Anda (kedalaman antrean, sesi aktif, KPI bisnis), lalu gunakan metrik tersebut untuk menggerakkan penskalaan. Misalnya, jika setiap tugas ECS dapat menangani 50 pesan antrean secara bersamaan, publikasikan kedalaman antrean SQS sebagai metrik khusus dan buat kebijakan pelacakan target dengan sasaran 50 pesan per tugas. Dengan demikian, penskalaan didorong langsung oleh logika bisnis, bukan bergantung pada metrik infrastruktur yang mungkin tidak berkorelasi dengan beban aplikasi.

Serupa dengan EC2 Auto Scaling, ECS mendukung perlindungan scale-in tugas. Tugas yang sedang berjalan dapat menetapkan tanda perlindungan scale-in-nya sendiri melalui API ECS untuk mencegah penghentian selama scale-in ketika sedang memproses pekerjaan penting. Hal ini berguna untuk tugas ECS yang bertindak sebagai pekerja SQS—pekerja yang baru saja mengambil pekerjaan panjang dari antrean dapat melindungi dirinya sendiri, menyelesaikan pekerjaan tersebut, lalu menghapus perlindungan. Tanpa fitur ini, scale-in dapat menghentikan tugas yang sedang memproses pekerjaan sehingga menyebabkan duplikasi pekerjaan atau kehilangan data.

Pilih metrik penskalaan dengan cermat. Penggunaan CPU adalah default dan cocok untuk beban kerja yang terikat komputasi. Penggunaan memori (ECSServiceAverageMemoryUtilization) berguna untuk aplikasi yang terikat memori, tetapi meningkatkan memori memerlukan penambahan tugas—jika tugas Anda dibatasi oleh memori per tugas, bukan oleh pemrosesan bersamaan, memperbaiki alokasi memori pada definisi tugas mungkin lebih baik. Jumlah permintaan ALB per target berkorelasi langsung dengan pengalaman pengguna dan merupakan metrik yang paling dapat ditindaklanjuti untuk API web—lakukan penskalaan berdasarkan tingkat permintaan aktual per tugas.

Pemutus Sirkuit Deployment ECS secara otomatis mendeteksi deployment yang gagal dan melakukan rollback ke versi stabil terakhir. Tanpanya, deployment yang bermasalah (kontainer yang gagal dalam pemeriksaan kesehatan) akan membuat ECS terus mencoba meluncurkan tugas baru tanpa batas. Dengan pemutus sirkuit diaktifkan, jika persentase tertentu dari tugas yang baru diluncurkan gagal dalam pemeriksaan kesehatan selama jendela deteksi, ECS menandai deployment sebagai FAILED dan secara otomatis melakukan rollback ke revisi definisi tugas sebelumnya. Hal ini mencegah penurunan kualitas layanan berkepanjangan akibat deployment yang bermasalah.

Arsitektur API web berbasis kontainer yang siap produksi: Route 53 menerjemahkan domain ke nama DNS ALB; ALB menghentikan HTTPS (sertifikat ACM), menerapkan aturan WAF, dan merutekan permintaan ke grup target layanan ECS; tugas Fargate di subnet privat pada 3 AZ menangani permintaan; Penskalaan Otomatis Layanan ECS dengan pelacakan target berdasarkan jumlah permintaan ALB per target menyesuaikan jumlah tugas dari 2 hingga 50; tugas terhubung ke RDS Aurora dan ElastiCache di subnet privat. Semua log dikirim ke CloudWatch Logs; metrik menggerakkan dasbor dan alarm CloudWatch.

Dalam pelajaran ini Anda mempelajari bahwa: Penskalaan Otomatis Layanan ECS menggunakan Application Auto Scaling dengan pelacakan target (CPU, permintaan ALB, atau metrik khusus) untuk menyesuaikan jumlah tugas di antara batas minimum dan maksimum yang dikonfigurasi; perutean berbasis jalur ALB memungkinkan satu load balancer melayani beberapa layanan mikro ECS dengan merutekan jalur URL ke grup target yang berbeda; dan Pemutus Sirkuit Deployment secara otomatis melakukan rollback terhadap deployment yang gagal sebelum menyebabkan penurunan kualitas layanan berkepanjangan. Modul ECS dan kontainer ini selesai—selanjutnya kita akan mempelajari Amazon EKS untuk Kubernetes di AWS.