Optimalkan penskalaan otomatis ECS layanan Amazon

ECSLayanan Amazon adalah kumpulan tugas yang dikelola. Setiap layanan memiliki definisi tugas terkait, jumlah tugas yang diinginkan, dan strategi penempatan opsional. Penskalaan otomatis ECS layanan Amazon diimplementasikan melalui layanan Application Auto Scaling. Application Auto Scaling menggunakan CloudWatch metrik sebagai sumber untuk menskalakan metrik. Ini juga menggunakan CloudWatch alarm untuk menetapkan ambang batas kapan harus menskalakan layanan Anda masuk atau keluar. Anda memberikan ambang batas untuk penskalaan, baik dengan menetapkan target metrik, disebut sebagai penskalaan pelacakan target, atau dengan menentukan ambang batas, yang disebut sebagai penskalaan langkah. Setelah Application Auto Scaling dikonfigurasi, ia terus menghitung jumlah tugas yang diinginkan yang sesuai untuk layanan. Ini juga memberi tahu Amazon ECS ketika jumlah tugas yang diinginkan harus berubah, baik dengan menskalakannya atau menskalakannya.

Untuk menggunakan penskalaan otomatis servis secara efektif, Anda harus memilih metrik penskalaan yang sesuai.

Aplikasi harus diskalakan jika permintaan diperkirakan lebih besar dari kapasitas saat ini. Sebaliknya, aplikasi dapat ditingkatkan untuk menghemat biaya ketika sumber daya melebihi permintaan.

Identifikasi metrik

Untuk menskalakan secara efektif, penting untuk mengidentifikasi metrik yang menunjukkan pemanfaatan atau saturasi. Metrik ini harus menunjukkan properti berikut agar berguna untuk penskalaan.

• Metrik harus berkorelasi dengan permintaan. Ketika sumber daya tetap stabil, tetapi permintaan berubah, nilai metrik juga harus berubah. Metrik harus meningkat atau menurun ketika permintaan meningkat atau menurun.

• Nilai metrik harus diskalakan sebanding dengan kapasitas. Ketika permintaan tetap konstan, menambahkan lebih banyak sumber daya harus menghasilkan perubahan proporsional dalam nilai metrik. Jadi, menggandakan jumlah tugas akan menyebabkan metrik berkurang 50%.

Cara terbaik untuk mengidentifikasi metrik pemanfaatan adalah melalui pengujian beban di lingkungan pra-produksi seperti lingkungan pementasan. Solusi pengujian beban komersial dan sumber terbuka tersedia secara luas. Solusi ini biasanya dapat menghasilkan beban sintetis atau mensimulasikan lalu lintas pengguna nyata.

Untuk memulai proses pengujian beban, buat dasbor untuk metrik pemanfaatan aplikasi Anda. Metrik ini meliputi CPU pemanfaatan, pemanfaatan memori, operasi I/O, kedalaman antrian I/O, dan throughput jaringan. Anda dapat mengumpulkan metrik ini dengan layanan seperti Wawasan Kontainer. Untuk informasi selengkapnya, lihat Pantau ECS kontainer Amazon menggunakan Wawasan Kontainer. Selama proses ini, pastikan Anda mengumpulkan dan memplot metrik untuk waktu respons aplikasi atau tingkat penyelesaian pekerjaan Anda.

Mulailah dengan permintaan kecil atau tingkat penyisipan pekerjaan. Pertahankan kecepatan ini stabil selama beberapa menit untuk memungkinkan aplikasi Anda memanas. Kemudian, perlahan-lahan tingkatkan laju dan tahan selama beberapa menit. Ulangi siklus ini, tingkatkan laju setiap kali hingga waktu respons atau penyelesaian aplikasi Anda terlalu lambat untuk memenuhi tujuan tingkat layanan Anda ()SLOs.

Saat pengujian beban, periksa masing-masing metrik pemanfaatan. Metrik yang meningkat seiring dengan beban adalah kandidat teratas untuk dijadikan metrik pemanfaatan terbaik Anda.

Selanjutnya, identifikasi sumber daya yang mencapai saturasi. Pada saat yang sama, periksa juga metrik pemanfaatan untuk melihat mana yang rata pada tingkat tinggi terlebih dahulu, atau mencapai puncak dan kemudian crash aplikasi Anda terlebih dahulu. Misalnya, jika CPU pemanfaatan meningkat dari 0% menjadi 70-80% saat Anda menambahkan beban, maka tetap pada tingkat itu setelah lebih banyak beban ditambahkan, maka aman untuk mengatakan bahwa sudah jenuhCPU. Tergantung pada CPU arsitekturnya, mungkin tidak akan pernah mencapai 100%. Misalnya, asumsikan bahwa pemanfaatan memori meningkat saat Anda menambahkan beban, dan kemudian aplikasi Anda tiba-tiba macet ketika mencapai tugas atau batas memori EC2 instans Amazon. Dalam situasi ini, kemungkinan memori telah dikonsumsi sepenuhnya. Beberapa sumber daya dapat dikonsumsi oleh aplikasi Anda. Oleh karena itu, pilih metrik yang mewakili sumber daya yang habis terlebih dahulu.

Terakhir, coba muat pengujian lagi setelah menggandakan jumlah tugas atau EC2 instans Amazon. Asumsikan bahwa metrik kunci meningkat, atau menurun, pada setengah tingkat seperti sebelumnya. Jika ini masalahnya, maka metrik sebanding dengan kapasitas. Ini adalah metrik pemanfaatan yang baik untuk penskalaan otomatis.

Sekarang pertimbangkan skenario hipotetis ini. Misalkan Anda memuat uji aplikasi dan menemukan bahwa CPU pemanfaatannya akhirnya mencapai 80% pada 100 permintaan per detik. Ketika lebih banyak beban ditambahkan, itu tidak membuat CPU pemanfaatan meningkat lagi. Namun, itu membuat aplikasi Anda merespons lebih lambat. Kemudian, Anda menjalankan uji beban lagi, menggandakan jumlah tugas tetapi menahan laju pada nilai puncak sebelumnya. Jika Anda menemukan CPU pemanfaatan rata-rata turun menjadi sekitar 40%, maka CPU pemanfaatan rata-rata adalah kandidat yang baik untuk metrik penskalaan. Di sisi lain, jika CPU pemanfaatan tetap pada 80% setelah meningkatkan jumlah tugas, maka CPU pemanfaatan rata-rata bukanlah metrik penskalaan yang baik. Dalam hal ini, diperlukan lebih banyak penelitian untuk menemukan metrik yang sesuai.

Model aplikasi umum dan properti penskalaan

Perangkat lunak dari semua jenis dijalankan AWS. Banyak beban kerja yang homegrown, sedangkan yang lain didasarkan pada perangkat lunak open-source populer. Terlepas dari mana asalnya, kami telah mengamati beberapa pola desain umum untuk layanan. Cara menskalakan secara efektif sebagian besar tergantung pada pola.

Server CPU terikat yang efisien

Server CPU terikat yang efisien hampir tidak menggunakan sumber daya selain CPU dan throughput jaringan. Setiap permintaan dapat ditangani oleh aplikasi saja. Permintaan tidak bergantung pada layanan lain seperti database. Aplikasi ini dapat menangani ratusan ribu permintaan bersamaan, dan secara efisien dapat memanfaatkan beberapa CPUs untuk melakukannya. Setiap permintaan dilayani oleh thread khusus dengan overhead memori rendah, atau ada loop peristiwa asinkron yang berjalan pada setiap permintaan layanan tersebut. CPU Setiap replika aplikasi sama-sama mampu menangani permintaan. Satu-satunya sumber daya yang mungkin habis sebelumnya CPU adalah bandwidth jaringan. Dalam CPU layanan batas, pemanfaatan memori, bahkan pada throughput puncak, adalah sebagian kecil dari sumber daya yang tersedia.

Jenis aplikasi ini cocok untuk penskalaan otomatis CPU berbasis. Aplikasi ini menikmati fleksibilitas maksimum dalam hal penskalaan. Ini dapat diskalakan secara vertikal dengan menyediakan EC2 instance Amazon yang lebih besar atau Fargate untuk itu. vCPUs Dan, itu juga dapat diskalakan secara horizontal dengan menambahkan lebih banyak replika. Menambahkan lebih banyak replika, atau menggandakan ukuran instans, memotong CPU pemanfaatan rata-rata relatif terhadap kapasitas hingga setengahnya.

Jika Anda menggunakan EC2 kapasitas Amazon untuk aplikasi ini, pertimbangkan untuk menempatkannya pada instans yang dioptimalkan komputasi seperti atau keluarga. c5 c6g

Server terikat memori yang efisien

Server yang terikat memori yang efisien mengalokasikan sejumlah besar memori per permintaan. Pada konkurensi maksimum, tetapi belum tentu throughput, memori habis sebelum sumber daya habis. CPU Memori yang terkait dengan permintaan dibebaskan saat permintaan berakhir. Permintaan tambahan dapat diterima selama ada memori yang tersedia.

Jenis aplikasi ini cocok untuk penskalaan otomatis berbasis memori. Aplikasi ini menikmati fleksibilitas maksimum dalam hal penskalaan. Ini dapat diskalakan baik secara vertikal dengan menyediakan sumber daya memori Amazon atau EC2 Fargate yang lebih besar untuknya. Dan, itu juga dapat diskalakan secara horizontal dengan menambahkan lebih banyak replika. Menambahkan lebih banyak replika, atau menggandakan ukuran instans, dapat memotong pemanfaatan memori rata-rata relatif terhadap kapasitas hingga setengahnya.

Jika Anda menggunakan EC2 kapasitas Amazon untuk aplikasi ini, pertimbangkan untuk menempatkannya pada instance yang dioptimalkan memori seperti atau keluarga. r5 r6g

Beberapa aplikasi yang terikat memori tidak membebaskan memori yang terkait dengan permintaan ketika itu berakhir, sehingga pengurangan konkurensi tidak menghasilkan pengurangan memori yang digunakan. Untuk ini, kami tidak menyarankan Anda menggunakan penskalaan berbasis memori.

Server berbasis pekerja

Server berbasis pekerja memproses satu permintaan untuk setiap thread pekerja individu satu demi satu. Benang pekerja bisa berupa benang ringan, seperti POSIX utas. Mereka juga bisa menjadi benang yang lebih berat, seperti proses. UNIX Apa pun utas mereka, selalu ada konkurensi maksimum yang dapat didukung aplikasi. Biasanya batas konkurensi diatur secara proporsional dengan sumber daya memori yang tersedia. Jika batas konkurensi tercapai, permintaan tambahan ditempatkan ke antrean backlog. Jika antrian backlog meluap, permintaan masuk tambahan segera ditolak. Aplikasi umum yang sesuai dengan pola ini termasuk server web Apache dan Gunicorn.

Request concurrency biasanya merupakan metrik terbaik untuk menskalakan aplikasi ini. Karena ada batas konkurensi untuk setiap replika, penting untuk menskalakan sebelum batas rata-rata tercapai.

Cara terbaik untuk mendapatkan metrik konkurensi permintaan adalah meminta aplikasi Anda melaporkannya. CloudWatch Setiap replika aplikasi Anda dapat mempublikasikan jumlah permintaan bersamaan sebagai metrik kustom pada frekuensi tinggi. Sebaiknya frekuensinya diatur setidaknya sekali setiap menit. Setelah beberapa laporan dikumpulkan, Anda dapat menggunakan konkurensi rata-rata sebagai metrik penskalaan. Metrik ini dihitung dengan mengambil konkurensi total dan membaginya dengan jumlah replika. Misalnya, jika total konkurensi adalah 1000 dan jumlah replika adalah 10, maka konkurensi rata-rata adalah 100.

Jika aplikasi Anda berada di belakang Application Load Balancer, Anda juga dapat menggunakan ActiveConnectionCount metrik untuk penyeimbang beban sebagai faktor dalam metrik penskalaan. ActiveConnectionCountMetrik harus dibagi dengan jumlah replika untuk mendapatkan nilai rata-rata. Nilai rata-rata harus digunakan untuk penskalaan, sebagai lawan dari nilai hitungan mentah.

Agar desain ini bekerja paling baik, standar deviasi latensi respons harus kecil pada tingkat permintaan rendah. Kami merekomendasikan bahwa, selama periode permintaan rendah, sebagian besar permintaan dijawab dalam waktu singkat, dan tidak ada banyak permintaan yang membutuhkan waktu lebih lama daripada waktu rata-rata untuk merespons. Waktu respons rata-rata harus mendekati waktu respons persentil ke-95. Jika tidak, luapan antrian mungkin terjadi sebagai hasilnya. Ini mengarah pada kesalahan. Kami menyarankan Anda memberikan replika tambahan jika diperlukan untuk mengurangi risiko meluap.

Server yang menunggu

Server menunggu melakukan beberapa pemrosesan untuk setiap permintaan, tetapi sangat tergantung pada satu atau lebih layanan hilir untuk berfungsi. Aplikasi kontainer sering menggunakan layanan hilir seperti database dan layanan lainnyaAPI. Butuh beberapa waktu bagi layanan ini untuk merespons, terutama dalam skenario berkapasitas tinggi atau konkurensi tinggi. Ini karena aplikasi ini cenderung menggunakan sedikit CPU sumber daya dan memanfaatkan konkurensi maksimumnya dalam hal memori yang tersedia.

Layanan tunggu cocok baik dalam pola server terikat memori atau pola server berbasis pekerja, tergantung pada bagaimana aplikasi dirancang. Jika konkurensi aplikasi hanya dibatasi oleh memori, maka pemanfaatan memori rata-rata harus digunakan sebagai metrik penskalaan. Jika konkurensi aplikasi didasarkan pada batas pekerja, maka konkurensi rata-rata harus digunakan sebagai metrik penskalaan.

Server berbasis Java

Jika server berbasis Java Anda CPU terikat dan menskalakan secara proporsional dengan CPU sumber daya, maka itu mungkin cocok untuk pola server terikat yang efisienCPU. Jika itu masalahnya, CPU pemanfaatan rata-rata mungkin sesuai sebagai metrik penskalaan. Namun, banyak aplikasi Java tidak CPU terikat, membuatnya sulit untuk diskalakan.

Untuk kinerja terbaik, kami sarankan Anda mengalokasikan memori sebanyak mungkin ke heap Java Virtual Machine (JVM). Versi terbaruJVM, termasuk pembaruan Java 8 191 atau yang lebih baru, secara otomatis mengatur ukuran tumpukan sebesar mungkin agar sesuai dengan wadah. Ini berarti bahwa, di Jawa, pemanfaatan memori jarang sebanding dengan pemanfaatan aplikasi. Ketika tingkat permintaan dan konkurensi meningkat, pemanfaatan memori tetap konstan. Karena itu, kami tidak menyarankan penskalaan server berbasis Java berdasarkan pemanfaatan memori. Sebagai gantinya, kami biasanya merekomendasikan penskalaan pada CPU pemanfaatan.

Dalam beberapa kasus, server berbasis Java mengalami kelelahan sebelum kelelahan. CPU Jika aplikasi Anda rentan terhadap kelelahan heap pada konkurensi tinggi, maka koneksi rata-rata adalah metrik penskalaan terbaik. Jika aplikasi Anda rentan terhadap heap exhaustion pada throughput tinggi, maka tingkat permintaan rata-rata adalah metrik penskalaan terbaik.

Server yang menggunakan runtime yang dikumpulkan sampah lainnya

Banyak aplikasi server didasarkan pada runtime yang melakukan pengumpulan sampah seperti. NETdan Ruby. Aplikasi server ini mungkin cocok dengan salah satu pola yang dijelaskan sebelumnya. Namun, seperti halnya Java, kami tidak merekomendasikan penskalaan aplikasi ini berdasarkan memori, karena pemanfaatan memori rata-rata yang diamati seringkali tidak berkorelasi dengan throughput atau konkurensi.

Untuk aplikasi ini, kami sarankan Anda menskalakan CPU pemanfaatan jika aplikasi CPU terikat. Jika tidak, kami menyarankan Anda menskalakan throughput rata-rata atau konkurensi rata-rata, berdasarkan hasil pengujian beban Anda.

Prosesor Job

Banyak beban kerja melibatkan pemrosesan pekerjaan asinkron. Mereka termasuk aplikasi yang tidak menerima permintaan secara real time, tetapi berlangganan antrian kerja untuk menerima pekerjaan. Untuk jenis aplikasi ini, metrik penskalaan yang tepat hampir selalu kedalaman antrian. Pertumbuhan antrian merupakan indikasi bahwa pekerjaan yang tertunda melebihi kapasitas pemrosesan, sedangkan antrian kosong menunjukkan bahwa ada lebih banyak kapasitas daripada pekerjaan yang harus dilakukan.

AWS Layanan pesan, seperti Amazon SQS dan Amazon Kinesis Data Streams CloudWatch, menyediakan metrik yang dapat digunakan untuk penskalaan. Untuk AmazonSQS, ApproximateNumberOfMessagesVisible adalah metrik terbaik. Untuk Kinesis Data Streams, pertimbangkan untuk MillisBehindLatest menggunakan metrik, yang diterbitkan oleh Kinesis Client Library (). KCL Metrik ini harus dirata-ratakan di semua konsumen sebelum menggunakannya untuk penskalaan.