Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.

Mengoptimalkan penskalaan otomatis layanan Amazon ECS

Layanan Amazon ECS adalah kumpulan tugas yang dikelola. Setiap layanan memiliki definisi tugas terkait, jumlah tugas yang diinginkan, dan strategi penempatan opsional.

Penskalaan otomatis layanan Amazon ECS bekerja melalui layanan Penskalaan Otomatis Aplikasi. Aplikasi Auto Scaling menggunakan CloudWatch metrik sebagai sumber untuk metrik penskalaan. Ini juga menggunakan CloudWatch alarm untuk mengatur ambang batas kapan harus meningkatkan skala layanan Anda masuk atau keluar.

Anda memberikan ambang batas untuk penskalaan. Anda dapat menetapkan target metrik, yang disebut penskalaan pelacakan target. Anda juga dapat menentukan ambang batas, yang disebut penskalaan langkah.

Setelah Anda mengonfigurasi Penskalaan Otomatis Aplikasi, aplikasi terus menghitung jumlah tugas yang diinginkan 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 layanan secara efektif, Anda harus memilih metrik penskalaan yang sesuai. Kami membahas cara memilih metrik di bagian berikut.

Mengkarakterisasi aplikasi Anda

Menskalakan aplikasi dengan benar mengharuskan Anda mengetahui kondisi di mana Anda harus menskalakan aplikasi Anda dan kapan Anda harus menskalakannya.

Intinya, Anda harus meningkatkan aplikasi Anda jika permintaan diperkirakan melampaui kapasitas. Sebaliknya, Anda dapat menskalakan aplikasi Anda untuk menghemat biaya ketika sumber daya melebihi permintaan.

Mengidentifikasi metrik pemanfaatan

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

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

Untuk memulai proses pengujian beban, Anda harus terlebih dahulu membuat dasbor untuk metrik pemanfaatan aplikasi Anda. Metrik ini termasuk pemanfaatan CPU, pemanfaatan memori, I/O operasi, kedalaman I/O antrian, dan throughput jaringan. Anda dapat mengumpulkan metrik ini dengan layanan seperti Con CloudWatch tainer Insights. Anda juga dapat mengumpulkannya dengan menggunakan Amazon Managed Service for Prometheus bersama dengan Amazon Managed Grafana. Selama proses ini, pastikan Anda mengumpulkan dan memplot metrik untuk waktu respons aplikasi Anda atau tingkat penyelesaian pekerjaan.

Saat Anda memuat tes, mulailah dengan permintaan kecil atau tingkat penyisipan pekerjaan. Jaga laju ini tetap stabil selama beberapa menit agar aplikasi Anda memanas. Kemudian, perlahan-lahan tingkatkan laju dan tahan stabil selama beberapa menit. Ulangi siklus ini, tingkatkan kecepatan setiap kali hingga respon atau waktu penyelesaian aplikasi Anda terlalu lambat untuk memenuhi tujuan tingkat layanan (SLOs) Anda.

Saat Anda memuat tes, periksa setiap metrik pemanfaatan. Metrik yang meningkat seiring dengan beban adalah kandidat teratas untuk berfungsi sebagai metrik pemanfaatan terbaik Anda.

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

Terakhir, coba muat pengujian lagi setelah Anda menggandakan jumlah tugas atau instans Amazon EC2. 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 tes aplikasi dan menemukan bahwa pemanfaatan CPU akhirnya mencapai 80% pada 100 permintaan per detik. Ketika Anda menambahkan lebih banyak beban, itu tidak membuat pemanfaatan CPU 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 pemanfaatan CPU rata-rata turun menjadi sekitar 40%, maka pemanfaatan CPU rata-rata adalah kandidat yang baik untuk metrik penskalaan. Di sisi lain, jika pemanfaatan CPU tetap pada 80% setelah meningkatkan jumlah tugas, maka pemanfaatan CPU rata-rata bukanlah metrik penskalaan yang baik. Dalam hal ini, Anda memerlukan penelitian lebih lanjut untuk menemukan metrik yang sesuai.

Model aplikasi umum dan properti penskalaan

Anda dapat menjalankan semua jenis perangkat lunak AWS. Banyak beban kerja yang tumbuh di rumah, sedangkan yang lain didasarkan pada perangkat lunak sumber terbuka yang populer. Terlepas dari mana asalnya, kami telah mengamati beberapa pola desain umum untuk layanan. Bagaimana Anda menskalakan secara efektif sebagian besar tergantung pada polanya.

CPU-bound Server yang efisien

CPU-bound Server 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 dapat secara efisien memanfaatkan beberapa CPU untuk melakukannya. Setiap permintaan dilayani oleh thread khusus dengan overhead memori rendah, atau ada loop peristiwa asinkron yang berjalan pada setiap CPU yang diminta layanan. Setiap replika aplikasi sama-sama mampu menangani permintaan. Satu-satunya sumber daya yang mungkin habis sebelum CPU adalah bandwidth jaringan. Dalam layanan terbatas CPU, pemanfaatan memori, bahkan pada throughput puncak, adalah sebagian kecil dari sumber daya yang tersedia.

Anda dapat menggunakan penskalaan CPU-based otomatis untuk jenis aplikasi ini. Aplikasi ini menikmati fleksibilitas maksimum dalam hal penskalaan. Anda dapat menskalakannya secara vertikal dengan menyediakan instans Amazon EC2 yang lebih besar atau vCPU Fargate. Dan, Anda juga dapat menskalakannya secara horizontal dengan menambahkan lebih banyak replika. Menambahkan lebih banyak replika, atau menggandakan ukuran instance, mengurangi pemanfaatan CPU rata-rata relatif terhadap kapasitas hingga setengahnya.

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

Server terikat memori yang efisien

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

Anda dapat menggunakan penskalaan otomatis berbasis memori untuk jenis aplikasi ini. Aplikasi ini menikmati fleksibilitas maksimum dalam hal penskalaan. Anda dapat menskalakannya secara vertikal dengan menyediakan sumber daya memori Amazon EC2 atau Fargate yang lebih besar untuknya. Dan, Anda juga dapat menskalakannya secara horizontal dengan menambahkan lebih banyak replika. Menambahkan lebih banyak replika, atau menggandakan ukuran instance, dapat mengurangi pemanfaatan memori rata-rata relatif terhadap kapasitas hingga setengahnya.

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

Beberapa aplikasi yang terikat memori tidak membebaskan memori yang terkait dengan permintaan saat 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. Utas pekerja dapat berupa utas ringan, seperti utas POSIX. Mereka juga bisa menjadi utas yang lebih berat, seperti proses UNIX. Apa pun utasnya, selalu ada konkurensi maksimum yang dapat didukung aplikasi. Biasanya batas konkurensi diatur secara proporsional dengan sumber daya memori yang tersedia. Jika batas konkurensi tercapai, aplikasi menempatkan permintaan tambahan ke dalam antrian backlog. Jika antrian backlog meluap, aplikasi segera menolak permintaan masuk tambahan. Aplikasi umum yang sesuai dengan pola ini termasuk server web Apache dan Gunicorn.

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

Cara terbaik untuk mendapatkan metrik konkurensi permintaan adalah dengan meminta aplikasi Anda melaporkannya CloudWatch. Setiap replika aplikasi Anda dapat mempublikasikan jumlah permintaan bersamaan sebagai metrik khusus pada frekuensi tinggi. Kami menyarankan agar frekuensi diatur setidaknya sekali setiap menit. Setelah beberapa laporan dikumpulkan, Anda dapat menggunakan konkurensi rata-rata sebagai metrik penskalaan. Anda menghitung metrik ini 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. Anda harus membagi ActiveConnectionCount metrik dengan jumlah replika untuk mendapatkan nilai rata-rata. Anda harus menggunakan nilai rata-rata 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 menyarankan bahwa, selama periode permintaan rendah, sebagian besar permintaan dijawab dalam waktu singkat, dan tidak ada banyak permintaan yang membutuhkan waktu jauh lebih lama dari waktu rata-rata untuk merespons. Waktu respons rata-rata harus mendekati waktu respons persentil ke-95. Jika tidak, akibatnya mungkin terjadi luapan antrian. Ini mengarah pada kesalahan. Sebaiknya berikan replika tambahan jika diperlukan untuk mengurangi risiko luapan.

Server yang menunggu

Server menunggu melakukan beberapa pemrosesan untuk setiap permintaan, tetapi sangat bergantung pada satu atau lebih layanan hilir untuk berfungsi. Aplikasi kontainer sering menggunakan banyak layanan hilir seperti database dan layanan API lainnya. Diperlukan beberapa waktu bagi layanan ini untuk merespons, terutama dalam skenario kapasitas tinggi atau konkurensi tinggi. Ini karena aplikasi ini cenderung menggunakan sedikit sumber daya CPU dan memanfaatkan konkurensi maksimum mereka 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.

Java-based Server

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

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

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

Server yang menggunakan runtime lain yang dikumpulkan sampah

Banyak aplikasi server didasarkan pada runtime yang melakukan pengumpulan sampah seperti.NET dan 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 pemanfaatan CPU jika aplikasi terikat CPU. Jika tidak, sebaiknya Anda menskalakan throughput rata-rata atau konkurensi rata-rata, berdasarkan hasil pengujian beban Anda.

Prosesor pekerjaan

Banyak beban kerja melibatkan pemrosesan pekerjaan asinkron. Mereka termasuk aplikasi yang tidak menerima permintaan secara real time, tetapi berlangganan ke 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, menyediakan CloudWatch metrik yang dapat digunakan untuk penskalaan. Untuk Amazon SQS, ApproximateNumberOfMessagesVisible adalah metrik terbaik. Untuk Kinesis Data Streams, pertimbangkan untuk menggunakan MillisBehindLatest metrik yang diterbitkan oleh Kinesis Client Library (KCL). Metrik ini harus dirata-ratakan di semua konsumen sebelum menggunakannya untuk penskalaan.