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

Kapasitas dan ketersediaan Amazon ECS

Ketersediaan aplikasi sangat penting untuk memberikan pengalaman bebas kesalahan dan untuk meminimalkan latensi aplikasi. Ketersediaan tergantung pada memiliki sumber daya yang dapat diakses dan memiliki kapasitas yang cukup untuk memenuhi permintaan. AWS menyediakan beberapa mekanisme untuk mengelola ketersediaan. Untuk aplikasi yang Anda host di Amazon ECS, ini termasuk penskalaan otomatis dan Availability Zones (). AZs Penskalaan otomatis mengelola jumlah tugas atau instance berdasarkan metrik yang Anda tentukan, sementara Availability Zone memungkinkan Anda untuk meng-host aplikasi Anda di lokasi yang terisolasi namun dekat secara geografis.

Seperti halnya ukuran tugas, kapasitas dan ketersediaan menyajikan trade-off tertentu yang harus Anda pertimbangkan. Idealnya, kapasitas akan sangat selaras dengan permintaan. Akan selalu ada kapasitas yang cukup untuk melayani permintaan dan memproses pekerjaan untuk memenuhi Tujuan Tingkat Layanan (SLOs) termasuk latensi rendah dan tingkat kesalahan. Kapasitas tidak akan pernah terlalu tinggi, menyebabkan biaya yang berlebihan; juga tidak akan pernah terlalu rendah, yang mengarah ke latensi tinggi dan tingkat kesalahan.

Autoscaling adalah proses laten. Pertama, CloudWatch harus menerima metrik real-time. Kemudian, CloudWatch perlu menggabungkan mereka untuk analisis, yang dapat memakan waktu hingga beberapa menit tergantung pada granularitas metrik. CloudWatch membandingkan metrik dengan ambang alarm untuk mengidentifikasi kekurangan atau kelebihan sumber daya. Untuk mencegah ketidakstabilan, Anda harus mengonfigurasi alarm agar ambang batas yang ditetapkan dilintasi selama beberapa menit sebelum alarm berbunyi. Hal ini juga membutuhkan waktu untuk menyediakan tugas-tugas baru dan untuk mengakhiri tugas-tugas yang tidak lagi diperlukan.

Karena potensi keterlambatan dalam sistem ini, Anda harus mempertahankan beberapa ruang kepala dengan penyediaan berlebihan. Penyediaan berlebih dapat membantu mengakomodasi ledakan permintaan jangka pendek. Ini juga membantu permintaan tambahan layanan aplikasi Anda tanpa mencapai saturasi. Sebagai praktik yang baik, Anda dapat menetapkan target penskalaan Anda antara 60-80% pemanfaatan. Ini membantu aplikasi Anda menangani semburan permintaan ekstra dengan lebih baik sementara kapasitas tambahan masih dalam proses penyediaan.

Alasan lain kami menyarankan Anda untuk menyediakan berlebihan adalah agar Anda dapat dengan cepat menanggapi kegagalan Availability Zone. AWS merekomendasikan agar beban kerja produksi dilayani dari beberapa Availability Zone. Ini karena, jika terjadi kegagalan Availability Zone, tugas Anda yang berjalan di Availability Zone yang tersisa masih dapat memenuhi permintaan. Jika aplikasi Anda berjalan di dua Availability Zones, Anda perlu menggandakan jumlah tugas normal Anda. Ini agar Anda dapat memberikan kapasitas langsung selama potensi kegagalan. Jika aplikasi Anda berjalan di tiga Availability Zones, kami sarankan Anda menjalankan 1,5 kali jumlah tugas normal Anda. Artinya, jalankan tiga tugas untuk setiap dua tugas yang dibutuhkan untuk penyajian biasa.

Memaksimalkan kecepatan penskalaan

Autoscaling adalah proses reaktif yang membutuhkan waktu untuk diterapkan. Namun, ada beberapa cara untuk membantu meminimalkan waktu yang diperlukan untuk meningkatkan skala.

Minimalkan ukuran gambar. Gambar yang lebih besar membutuhkan waktu lebih lama untuk diunduh dari repositori gambar dan membongkar. Oleh karena itu, menjaga ukuran gambar lebih kecil mengurangi jumlah waktu yang dibutuhkan wadah untuk memulai. Untuk mengurangi ukuran gambar, Anda dapat mengikuti rekomendasi spesifik ini:

Jaga agar gambar Anda tetap dekat. Semakin tinggi latensi jaringan, semakin lama waktu yang dibutuhkan untuk mengunduh gambar. Host gambar Anda di repositori di AWS Wilayah yang sama dengan beban kerja Anda. Amazon ECR adalah repositori gambar berkinerja tinggi yang tersedia di setiap Wilayah tempat Amazon ECS tersedia. Hindari melintasi Internet atau tautan VPN untuk mengunduh gambar kontainer. Hosting gambar Anda di Wilayah yang sama meningkatkan keandalan secara keseluruhan. Ini mengurangi risiko masalah konektivitas jaringan dan masalah ketersediaan di Wilayah yang berbeda. Atau, Anda juga dapat menerapkan replikasi lintas wilayah Amazon ECR untuk membantu hal ini.

Kurangi ambang batas pemeriksaan kesehatan penyeimbang beban. Load balancer melakukan pemeriksaan kesehatan sebelum mengirim lalu lintas ke aplikasi Anda. Konfigurasi pemeriksaan kesehatan default untuk grup target dapat memakan waktu 90 detik atau lebih lama. Selama ini, penyeimbang beban memeriksa status kesehatan dan menerima permintaan. Menurunkan interval pemeriksaan kesehatan dan jumlah ambang batas dapat membuat aplikasi Anda menerima lalu lintas lebih cepat dan mengurangi beban pada tugas lain.

Pertimbangkan kinerja start dingin. Beberapa aplikasi menggunakan runtime seperti kompilasi Java perform Just-In-Time (JIT). Proses kompilasi setidaknya saat dimulai dapat menunjukkan kinerja aplikasi. Solusinya adalah menulis ulang bagian penting latensi dari beban kerja Anda dalam bahasa yang tidak memberlakukan penalti kinerja awal yang dingin.

Gunakan penskalaan langkah, bukan kebijakan penskalaan pelacakan target. Anda memiliki beberapa opsi Application Auto Scaling untuk tugas Amazon ECS. Pelacakan target adalah mode termudah untuk digunakan. Dengan itu, yang perlu Anda lakukan adalah menetapkan nilai target untuk metrik, seperti pemanfaatan rata-rata CPU. Kemudian, auto scaler secara otomatis mengelola jumlah tugas yang diperlukan untuk mencapai nilai itu. Dengan penskalaan langkah, Anda dapat bereaksi lebih cepat terhadap perubahan permintaan, karena Anda menentukan ambang batas tertentu untuk metrik penskalaan Anda, dan berapa banyak tugas yang harus ditambahkan atau dihapus saat ambang batas dilintasi. Dan, yang lebih penting, Anda dapat bereaksi sangat cepat terhadap perubahan permintaan dengan meminimalkan jumlah waktu alarm ambang batas dilanggar. Untuk informasi lebih lanjut, lihat Service Auto Scaling dalam Panduan Pengembang Layanan Amazon Elastic Container.

Jika Anda menggunakan EC2 instans Amazon untuk menyediakan kapasitas klaster, pertimbangkan rekomendasi berikut:

Gunakan EC2 instans Amazon yang lebih besar dan volume Amazon EBS yang lebih cepat. Anda dapat meningkatkan kecepatan pengunduhan dan persiapan gambar dengan menggunakan EC2 instans Amazon yang lebih besar dan volume Amazon EBS yang lebih cepat. Dalam rangkaian EC2 instans Amazon tertentu, throughput maksimum jaringan dan Amazon EBS meningkat seiring dengan peningkatan ukuran instans (misalnya, dari m5.xlarge kem5.2xlarge). Selain itu, Anda juga dapat menyesuaikan volume Amazon EBS untuk meningkatkan throughput dan IOPS mereka. Misalnya, jika Anda menggunakan gp2 volume, gunakan volume yang lebih besar yang menawarkan lebih banyak throughput dasar. Jika Anda menggunakan gp3 volume, tentukan throughput dan IOPS saat Anda membuat volume.

Gunakan mode jaringan jembatan untuk tugas yang berjalan di EC2 instans Amazon. Tugas yang menggunakan mode bridge jaringan di Amazon EC2 dimulai lebih cepat daripada tugas yang menggunakan mode awsvpc jaringan. Saat mode awsvpc jaringan digunakan, Amazon ECS melampirkan elastic network interface (ENI) ke instance sebelum meluncurkan tugas. Ini memperkenalkan latensi tambahan. Ada beberapa pengorbanan untuk menggunakan jaringan jembatan. Tugas-tugas ini tidak mendapatkan grup keamanan mereka sendiri, dan ada beberapa implikasi untuk load balancing. Untuk informasi selengkapnya, lihat Grup target penyeimbang beban di Panduan Pengguna Elastic Load Balancing.

Menangani guncangan permintaan

Beberapa aplikasi mengalami guncangan besar yang tiba-tiba dalam permintaan. Ini terjadi karena berbagai alasan: acara berita, penjualan besar, acara media, atau peristiwa lain yang menjadi viral dan menyebabkan lalu lintas meningkat dengan cepat dan signifikan dalam rentang waktu yang sangat singkat. Jika tidak direncanakan, ini dapat menyebabkan permintaan dengan cepat melampaui sumber daya yang tersedia.

Cara terbaik untuk menangani guncangan permintaan adalah dengan mengantisipasi dan merencanakannya dengan tepat. Karena penskalaan otomatis dapat memakan waktu, kami menyarankan Anda untuk menskalakan aplikasi Anda sebelum kejutan permintaan dimulai. Untuk hasil terbaik, kami sarankan memiliki rencana bisnis yang melibatkan kolaborasi erat antara tim yang menggunakan kalender bersama. Tim yang merencanakan acara harus bekerja sama dengan tim yang bertanggung jawab atas aplikasi terlebih dahulu. Ini memberi tim itu cukup waktu untuk memiliki rencana penjadwalan yang jelas. Mereka dapat menjadwalkan kapasitas untuk skala sebelum acara dan untuk skala setelah acara. Untuk informasi lebih lanjut, lihat Penskalaan terjadwal dalam Panduan Pengguna Application Auto Scaling.

Jika Anda memiliki paket Enterprise Support, pastikan juga untuk bekerja dengan Technical Account Manager (TAM) Anda. TAM Anda dapat memverifikasi kuota layanan Anda dan memastikan bahwa kuota yang diperlukan dinaikkan sebelum acara dimulai. Dengan cara ini, Anda tidak secara tidak sengaja mencapai kuota layanan apa pun. Mereka juga dapat membantu Anda dengan melakukan pemanasan awal seperti penyeimbang beban untuk memastikan acara Anda berjalan lancar.

Menangani guncangan permintaan yang tidak terjadwal adalah masalah yang lebih sulit. Guncangan tak terjadwal, jika amplitudo cukup besar, dapat dengan cepat menyebabkan permintaan melebihi kapasitas. Ini juga dapat melampaui kemampuan autoscaling untuk bereaksi. Cara terbaik untuk mempersiapkan guncangan yang tidak terjadwal adalah dengan menyediakan sumber daya yang berlebihan. Anda harus memiliki sumber daya yang cukup untuk menangani permintaan lalu lintas maksimum yang diantisipasi setiap saat.

Mempertahankan kapasitas maksimum untuk mengantisipasi guncangan permintaan yang tidak terjadwal bisa mahal. Untuk mengurangi dampak biaya, temukan metrik indikator utama atau peristiwa yang memprediksi guncangan permintaan besar akan segera terjadi. Jika metrik atau peristiwa secara andal memberikan pemberitahuan awal yang signifikan, segera mulailah proses penskalaan saat peristiwa terjadi atau saat metrik melewati ambang batas tertentu yang Anda tetapkan.

Jika aplikasi Anda rentan terhadap guncangan permintaan tak terjadwal yang tiba-tiba, pertimbangkan untuk menambahkan mode kinerja tinggi ke aplikasi Anda yang mengorbankan fungsionalitas non-kritis tetapi mempertahankan fungsionalitas penting bagi pelanggan. Misalnya, asumsikan bahwa aplikasi Anda dapat beralih dari menghasilkan respons khusus yang mahal menjadi menyajikan halaman respons statis. Dalam skenario ini, Anda dapat meningkatkan throughput secara signifikan tanpa menskalakan aplikasi sama sekali.

Terakhir, Anda dapat mempertimbangkan untuk memecah layanan monolitik untuk mengatasi guncangan permintaan dengan lebih baik. Jika aplikasi Anda adalah layanan monolitik yang mahal untuk dijalankan dan lambat untuk skala, Anda mungkin dapat mengekstrak atau menulis ulang bagian penting kinerja dan menjalankannya sebagai layanan terpisah. Layanan baru ini kemudian dapat diskalakan secara independen dari komponen yang kurang kritis. Memiliki fleksibilitas untuk meningkatkan fungsionalitas penting kinerja secara terpisah dari bagian lain dari aplikasi Anda dapat mengurangi waktu yang diperlukan untuk menambah kapasitas dan membantu menghemat biaya.