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 autoscaling dan Availability Zones (AZ). Penskalaan otomatis mengelola jumlah tugas atau instans berdasarkan metrik yang Anda tentukan, sementara Availability Zone memungkinkan Anda untuk meng-host aplikasi Anda di lokasi yang terisolasi namun dekat secara geografis.

Seperti ukuran tugas, kapasitas dan ketersediaan menghadirkan pertukaran tertentu yang harus Anda pertimbangkan. Idealnya, kapasitas akan 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 menyebabkan tingkat latensi dan kesalahan yang tinggi.

Penskalaan otomatis adalah proses laten. Pertama, CloudWatch harus menerima metrik real-time. Kemudian, CloudWatch perlu mengumpulkan mereka untuk analisis, yang dapat memakan waktu hingga beberapa menit tergantung pada granularitas metrik. CloudWatch membandingkan metrik terhadap 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. Ini juga membutuhkan waktu untuk menyediakan tugas baru dan untuk mengakhiri tugas yang tidak lagi diperlukan.

Karena potensi penundaan dalam sistem ini, Anda harus mempertahankan beberapa ruang kepala dengan penyediaan berlebihan. Over-provisioning 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 antara 60-80% pemanfaatan. Ini membantu aplikasi Anda menangani ledakan permintaan ekstra dengan lebih baik sementara kapasitas tambahan masih dalam proses penyediaan.

Alasan lain yang kami sarankan Anda melakukan penyediaan berlebihan adalah agar Anda dapat dengan cepat merespons kegagalan Zona Ketersediaan. AWS merekomendasikan agar beban kerja produksi dilayani dari beberapa Zona Ketersediaan. Ini karena, jika kegagalan Zona Ketersediaan terjadi, tugas Anda yang berjalan di Zona Ketersediaan yang tersisa masih dapat melayani permintaan. Jika aplikasi Anda berjalan di dua Zona Ketersediaan, Anda perlu menggandakan jumlah tugas normal Anda. Ini agar Anda dapat memberikan kapasitas langsung selama potensi kegagalan. Jika aplikasi Anda berjalan di tiga Zona Ketersediaan, sebaiknya jalankan 1,5 kali jumlah tugas normal Anda. Artinya, jalankan tiga tugas untuk setiap dua yang diperlukan untuk penyajian biasa.

Memaksimalkan kecepatan penskalaan

Autoscaling adalah proses reaktif yang membutuhkan waktu untuk berlaku. 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 dibongkar. Oleh karena itu, menjaga ukuran gambar lebih kecil mengurangi jumlah waktu yang diperlukan untuk memulai wadah. Untuk mengurangi ukuran gambar, Anda dapat mengikuti rekomendasi khusus ini:

Jaga agar gambar Anda tetap dekat. Semakin tinggi latensi jaringan, semakin lama waktu yang dibutuhkan untuk mengunduh gambar. Simpan gambar Anda di repositori di Wil AWS ayah yang sama tempat beban kerja Anda berada. 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 dalam hal ini.

Kurangi ambang batas pemeriksaan kesehatan penyeimbang beban. Penyeimbang beban melakukan pemeriksaan kesehatan sebelum mengirim lalu lintas ke aplikasi Anda. Konfigurasi pemeriksaan kesehatan default untuk kelompok 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 cold start. 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 mengenakan penalti kinerja cold start.

Gunakan penskalaan langkah, bukan kebijakan penskalaan pelacakan target. Anda memiliki beberapa opsi Penskalaan Otomatis Aplikasi 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, scaler otomatis 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 akan 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 melanggar. Untuk informasi lebih lanjut, lihat Service Auto Scaling dalam Panduan Pengembang Layanan Amazon Elastic Container.

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

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

Gunakan mode jaringan jembatan untuk tugas yang berjalan di instans Amazon EC2. 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 antarmuka jaringan elastis (ENI) ke instans sebelum meluncurkan tugas. Ini memperkenalkan latensi tambahan. Ada beberapa pengorbanan untuk menggunakan jaringan jembatan sekalipun. Tugas-tugas ini tidak mendapatkan grup keamanannya sendiri, dan ada beberapa implikasi untuk penyeimbangan beban. Untuk informasi selengkapnya, lihat Grup target penyeimbang beban di Panduan Pengguna Penyeimbangan Beban Elastis.

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 acara 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 mengantisipasinya dan merencanakannya sesuai dengan itu. Karena penskalaan otomatis dapat memakan waktu, kami sarankan Anda meningkatkan skala aplikasi Anda sebelum guncangan permintaan dimulai. Untuk hasil terbaik, kami sarankan memiliki rencana bisnis yang melibatkan kolaborasi ketat 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 meningkatkan skala sebelum acara dan untuk meningkatkan skala setelah acara. Untuk informasi lebih lanjut, lihat Penskalaan terjadwal dalam Panduan Pengguna Application Auto Scaling.

Jika Anda memiliki paket Dukungan Perusahaan, pastikan juga untuk bekerja dengan Manajer Akun Teknis (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 layanan pemanasan awal seperti penyeimbang beban untuk memastikan acara Anda berjalan lancar.

Menangani guncangan permintaan yang tidak terjadwal adalah masalah yang lebih sulit. Guncangan yang tidak 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 secara 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 kejutan permintaan besar akan segera terjadi. Jika metrik atau peristiwa secara andal memberikan pemberitahuan sebelumnya yang signifikan, mulailah proses penskalaan segera saat peristiwa terjadi atau saat metrik melewati ambang batas tertentu yang Anda tetapkan.

Jika aplikasi Anda rentan terhadap guncangan permintaan yang tiba-tiba tidak terjadwal, 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 ke 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 menangani guncangan permintaan dengan lebih baik. Jika aplikasi Anda adalah layanan monolitik yang mahal untuk dijalankan dan lambat untuk diskalakan, 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 penting. Memiliki fleksibilitas untuk meningkatkan fungsionalitas penting kinerja secara terpisah dari bagian lain aplikasi Anda dapat mengurangi waktu yang diperlukan untuk menambah kapasitas dan membantu menghemat biaya.