Pilar ElastiCache Efisiensi Kinerja Lensa Well-Architected Amazon - Amazon ElastiCache
PE 1: Bagaimana Anda memantau kinerja ElastiCache cluster Amazon Anda?PE 2: Bagaimana Anda mendistribusikan pekerjaan di seluruh node ElastiCache Cluster Anda?PE 3: Untuk beban kerja caching, bagaimana cara melacak dan melaporkan efektivitas dan performa cache Anda? PE 4: Bagaimana beban kerja Anda mengoptimalkan penggunaan sumber daya dan koneksi jaringan?PE 5: Bagaimana cara mengelola penghapusan dan/atau pengosongan kunci?PE 6: Bagaimana Anda memodelkan dan berinteraksi dengan data ElastiCache? PE 7: Bagaimana Anda mencatat perintah yang berjalan lambat di ElastiCache cluster Amazon Anda?PE8: Bagaimana Auto Scaling membantu dalam meningkatkan kinerja cluster? ElastiCache

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

Pilar ElastiCache Efisiensi Kinerja Lensa Well-Architected Amazon

Pilar efisiensi performa berfokus pada penggunaan sumber daya TI dan komputasi secara efisien. Topik utamanya meliputi pemilihan jenis dan ukuran sumber daya yang tepat berdasarkan persyaratan beban kerja, pemantauan performa, dan pembuatan keputusan berdasarkan informasi untuk mempertahankan efisiensi seiring dengan berkembangnya kebutuhan bisnis.

PE 1: Bagaimana Anda memantau kinerja ElastiCache cluster Amazon Anda?

Pengantar tingkat pertanyaan: Dengan memahami metrik pemantauan yang ada, Anda dapat mengidentifikasi pemanfaatan saat ini. Pemantauan yang tepat dapat membantu mengidentifikasi potensi hambatan yang memengaruhi performa klaster Anda.

Manfaat tingkat pertanyaan: Memahami metrik yang terkait dengan klaster Anda dapat membantu memandu teknik pengoptimalan yang dapat mengurangi latensi dan meningkatkan throughput.

  • [Wajib] Pengujian performa dasar menggunakan subset beban kerja Anda.

    • Anda harus memantau performa beban kerja aktual menggunakan mekanisme seperti pengujian beban.

    • Pantau CloudWatch metrik saat menjalankan tes ini untuk mendapatkan pemahaman tentang metrik yang tersedia, dan untuk menetapkan garis dasar kinerja.

  • [Terbaik] Untuk beban kerja ElastiCache (RedisOSS), ganti nama perintah yang mahal secara komputasi, sepertiKEYS, untuk membatasi kemampuan pengguna menjalankan perintah pemblokiran pada cluster produksi.

    • ElastiCache (RedisOSS) beban kerja menjalankan engine 6.x, dapat memanfaatkan kontrol akses berbasis peran untuk membatasi perintah tertentu. Akses ke perintah dapat dikontrol dengan membuat Pengguna dan Grup Pengguna dengan AWS Konsol atauCLI, dan mengaitkan Grup Pengguna ke klaster ElastiCache (RedisOSS). Di Redis OSS 6, ketika RBAC diaktifkan, kita dapat menggunakan “- @dangerous" dan itu akan melarang perintah mahal sepertiKEYS,, MONITORSORT, dll. untuk pengguna itu.

    • Untuk versi mesin 5.x, ganti nama perintah menggunakan rename-commands parameter pada grup parameter cluster ElastiCache (RedisOSS).

  • [Lebih Baik] Analisis kueri lambat dan cari teknik pengoptimalan.

    • Untuk beban kerja ElastiCache (RedisOSS), pelajari lebih lanjut tentang kueri Anda dengan menganalisis Log Lambat. Misalnya, Anda dapat menggunakan perintah berikut, valkey-cli slowlog get 10 untuk menampilkan 10 perintah terakhir yang melebihi ambang batas latensi (10 detik secara default).

    • Kueri tertentu dapat dilakukan dengan lebih efisien menggunakan struktur data kompleks ElastiCache (RedisOSS). Sebagai contoh, untuk pencarian rentang gaya numerik, aplikasi dapat mengimplementasikan indeks numerik sederhana dengan Sorted Set. Mengelola indeks ini dapat mengurangi pemindaian yang dilakukan pada set data, dan menampilkan data dengan efisiensi performa yang lebih baik.

    • Untuk beban kerja ElastiCache (RedisOSS), redis-benchmark menyediakan antarmuka sederhana untuk menguji kinerja perintah yang berbeda menggunakan input yang ditentukan pengguna seperti jumlah klien, dan ukuran data.

    • Karena Memcached hanya mendukung perintah tingkat kunci sederhana, pertimbangkan untuk membangun kunci tambahan sebagai indeks untuk menghindari iterasi melalui ruang kunci untuk melayani kueri klien.

  • [Sumber Daya]:

PE 2: Bagaimana Anda mendistribusikan pekerjaan di seluruh node ElastiCache Cluster Anda?

Pengenalan tingkat pertanyaan: Cara aplikasi Anda terhubung ke ElastiCache node Amazon dapat memengaruhi kinerja dan skalabilitas klaster.

Manfaat tingkat pertanyaan: Memanfaatkan simpul yang tersedia di klaster dengan tepat akan memastikan bahwa pekerjaan didistribusikan ke seluruh sumber daya yang tersedia. Teknik-teknik berikut juga membantu menghindari sumber daya idle.

  • [Wajib] Minta klien terhubung ke ElastiCache titik akhir yang tepat.

    • ElastiCache (RedisOSS) mengimplementasikan titik akhir yang berbeda berdasarkan mode cluster yang digunakan. Untuk mode cluster diaktifkan, ElastiCache akan menyediakan titik akhir konfigurasi. Untuk mode cluster dinonaktifkan, ElastiCache menyediakan titik akhir utama, biasanya digunakan untuk menulis, dan titik akhir pembaca untuk menyeimbangkan pembacaan di seluruh replika. Menerapkan titik akhir ini dengan tepat akan menghasilkan performa yang lebih baik, dan operasi penskalaan yang lebih mudah. Hindari menghubungkan ke titik akhir simpul individual kecuali jika ada persyaratan khusus untuk melakukan tindakan ini.

    • Untuk cluster Memcached multi-node, ElastiCache menyediakan titik akhir konfigurasi yang memungkinkan Auto Discovery. Sebaiknya gunakan algoritma hashing untuk mendistribusikan pekerjaan secara merata di seluruh simpul cache. Banyak pustaka klien Memcached menerapkan hashing yang konsisten. Periksa dokumentasi untuk pustaka yang Anda gunakan untuk melihat apakah pustaka tersebut mendukung hashing konsisten dan cara menerapkannya. Anda dapat menemukan informasi selengkapnya tentang penerapan fitur-fitur ini di sini.

  • [Lebih baik] Manfaatkan mode cluster ElastiCache (RedisOSS) yang diaktifkan untuk meningkatkan skalabilitas.

    • ElastiCache (RedisOSS) (mode cluster diaktifkan) cluster mendukung operasi penskalaan online (out/in dan atas/down) untuk membantu mendistribusikan data secara dinamis di seluruh pecahan. Menggunakan Titik Akhir Konfigurasi akan memastikan klaster Anda yang sadar klien dapat menyesuaikan perubahan dalam topologi klaster.

    • Anda juga dapat menyeimbangkan kembali cluster dengan memindahkan hashslots di antara pecahan yang tersedia di cluster ElastiCache (RedisOSS) (mode cluster diaktifkan) Anda. Tindakan ini membantu mendistribusikan pekerjaan secara lebih efisien di seluruh serpihan yang tersedia.

  • [Lebih Baik] Terapkan strategi untuk mengidentifikasi dan memulihkan hot key dalam beban kerja Anda.

    • Pertimbangkan dampak struktur OSS data Valkey atau Redis multi-dimensi seperti daftar, aliran, set, dll. Struktur data ini disimpan dalam Keys tunggal, yang berada pada satu node. Kunci multi-dimensi yang sangat besar memiliki potensi untuk memanfaatkan lebih banyak kapasitas jaringan dan memori daripada jenis data lainnya dan dapat menyebabkan penggunaan simpul yang tidak proporsional. Jika memungkinkan, rancang beban kerja Anda untuk menyebarkan akses data di banyak Kunci diskrit.

    • Hot key dalam beban kerja dapat memengaruhi performa simpul yang digunakan. Untuk beban kerja ElastiCache (RedisOSS), Anda dapat mendeteksi tombol pintas menggunakan valkey-cli --hotkeys jika ada kebijakan LFU memori maksimum.

    • Pertimbangkan untuk mereplikasi hot key di beberapa simpul untuk mendistribusikan akses ke sana secara lebih merata. Pendekatan ini mengharuskan klien untuk menulis ke beberapa node primer (node Valkey atau Redis OSS itu sendiri tidak akan menyediakan fungsi ini) dan untuk mempertahankan daftar nama kunci untuk dibaca, selain nama kunci asli.

    • ElastiCache dengan Valkey 7.2 ke atas dan Redis OSS versi 6 ke atas mendukung caching sisi klien yang dibantu server. Hal ini memungkinkan aplikasi untuk menunggu perubahan pada kunci sebelum membuat panggilan jaringan kembali keElastiCache.

  • [Sumber Daya]:

PE 3: Untuk beban kerja caching, bagaimana cara melacak dan melaporkan efektivitas dan performa cache Anda?

Pengenalan tingkat pertanyaan: Caching adalah beban kerja yang umum ditemui ElastiCache dan penting bagi Anda untuk memahami cara mengelola efektivitas dan kinerja cache Anda.

Manfaat tingkat pertanyaan: Aplikasi Anda mungkin menunjukkan tanda-tanda performa yang lamban. Kemampuan Anda untuk menggunakan metrik khusus cache untuk menginformasikan keputusan Anda tentang cara meningkatkan performa aplikasi sangat penting untuk beban kerja cache Anda.

  • [Wajib] Ukur dan lacak dari waktu ke waktu rasio hit cache. Efisiensi cache Anda ditentukan oleh 'rasio cache hit'. Rasio cache hit ditentukan oleh total hit kunci dibagi dengan total hit dan miss. Semakin dekat ke 1 rasionya, semakin efektif cache Anda. Rasio cache hit yang rendah disebabkan oleh volume cache miss. Cache miss terjadi ketika kunci yang diminta tidak ditemukan di cache. Kunci tidak ada dalam cache karena telah dikosongkan atau dihapus, telah habis masa berlakunya, atau tidak pernah ada. Pahami mengapa kunci tidak ada dalam cache dan kembangkan strategi yang tepat untuk menyimpan kunci dalam cache.

    [Sumber Daya]:

  • [Wajib] Ukur dan kumpulkan kinerja cache aplikasi Anda bersama dengan nilai latensi dan CPU pemanfaatan untuk memahami apakah Anda perlu melakukan penyesuaian pada komponen aplikasi Anda time-to-live atau lainnya. ElastiCache menyediakan satu set CloudWatch metrik untuk latensi agregat untuk setiap struktur data. Metrik latensi ini dihitung menggunakan statistik commandstats dari INFO perintah ElastiCache (RedisOSS) dan tidak termasuk jaringan dan waktu I/O. Ini hanya waktu yang dikonsumsi oleh ElastiCache (RedisOSS) untuk memproses operasi.

    [Sumber Daya]:

  • [Terbaik] Pilih strategi caching yang tepat untuk kebutuhan Anda. Rasio cache hit yang rendah disebabkan oleh volume cache miss. Jika beban kerja Anda dirancang untuk memiliki volume cache miss yang rendah (seperti komunikasi waktu nyata), sebaiknya tinjau strategi caching Anda dan terapkan solusi yang paling tepat untuk beban kerja Anda, seperti instrumentasi kueri untuk mengukur memori dan performa. Strategi aktual yang Anda gunakan untuk mengisi dan memelihara cache Anda akan tergantung pada data apa yang perlu di-cache oleh klien dan pola akses ke data tersebut. Misalnya, Anda cenderung tidak akan menggunakan strategi yang sama untuk rekomendasi yang dipersonalisasi pada aplikasi streaming, dan untuk berita yang sedang tren.

    [Sumber Daya]:

PE 4: Bagaimana beban kerja Anda mengoptimalkan penggunaan sumber daya dan koneksi jaringan?

Pengenalan tingkat pertanyaan: ElastiCache (RedisOSS) dan ElastiCache (Memcached) didukung oleh banyak klien aplikasi, dan implementasi dapat bervariasi. Anda perlu memahami manajemen jaringan dan koneksi yang diterapkan untuk menganalisis potensi dampak performa.

Manfaat tingkat pertanyaan: Penggunaan sumber daya jaringan yang efisien dapat meningkatkan efisiensi performa klaster Anda. Rekomendasi berikut dapat mengurangi tuntutan jaringan, dan meningkatkan latensi dan throughput klaster.

  • [Wajib] Secara proaktif mengelola koneksi ke ElastiCache klaster Anda.

    • Pooling koneksi dalam aplikasi mengurangi jumlah overhead pada klaster yang dibuat dengan membuka dan menutup koneksi. Pantau perilaku koneksi di Amazon CloudWatch menggunakan CurrConnections danNewConnections.

    • Hindari kebocoran koneksi dengan menutup koneksi klien dengan benar sesuai keperluan. Strategi manajemen koneksi termasuk menutup dengan benar koneksi yang tidak digunakan, dan pengaturan waktu habis koneksi.

    • Untuk beban kerja Memcached, ada jumlah memori yang dapat dikonfigurasi yang dicadangkan untuk menangani koneksi yang disebut, memcached_connections_overhead.

  • [Lebih Baik] Kompres objek besar untuk mengurangi memori, dan meningkatkan throughput jaringan.

    • Kompresi data dapat mengurangi jumlah throughput jaringan yang diperlukan (Gbps), tetapi meningkatkan jumlah pekerjaan pada aplikasi untuk mengompres dan mendekompresi data.

    • Kompresi juga mengurangi jumlah memori yang dikonsumsi oleh kunci

    • Berdasarkan kebutuhan aplikasi Anda, pertimbangkan kompromi antara rasio kompresi dan kecepatan kompresi.

  • [Sumber Daya]:

PE 5: Bagaimana cara mengelola penghapusan dan/atau pengosongan kunci?

Pengenalan tingkat pertanyaan: Beban kerja memiliki persyaratan yang berbeda, dan perilaku yang diharapkan saat node cluster mendekati batas konsumsi memori. ElastiCache (RedisOSS) memiliki kebijakan yang berbeda untuk menangani situasi ini.

Manfaat tingkat pertanyaan: Manajemen yang tepat atas memori yang tersedia, dan pemahaman tentang kebijakan pengosongan akan membantu memastikan kesadaran perilaku klaster ketika batas memori instans terlampaui.

  • [Wajib] Instrumentasi akses data untuk mengevaluasi kebijakan mana yang akan diterapkan. Identifikasi kebijakan max-memory yang sesuai untuk mengontrol apakah dan bagaimana pengosongan dilakukan di klaster.

    • Pengosongan terjadi ketika max-memory pada klaster dikonsumsi dan kebijakan diberlakukan untuk memungkinkan pengosongan. Perilaku klaster dalam situasi ini tergantung pada kebijakan pengosongan yang ditentukan. Kebijakan ini dapat dikelola menggunakan grup parameter klaster ElastiCache (RedisOSS) maxmemory-policy pada (Redis).

    • Kebijakan default volatile-lru membebaskan memori dengan mengusir kunci dengan waktu kedaluwarsa (nilai) yang ditetapkan. TTL Kebijakan yang paling jarang digunakan (LFU) dan yang paling jarang digunakan (LRU) menghapus kunci berdasarkan penggunaan.

    • Untuk beban kerja Memcached, ada LRU kebijakan default yang mengatur penggusuran di setiap node. Jumlah penggusuran di ElastiCache klaster Amazon Anda dapat dipantau menggunakan metrik Penggusuran di Amazon. CloudWatch

  • [Lebih Baik] Lakukan standarisasi perilaku penghapusan untuk mengontrol dampak performa pada klaster Anda untuk menghindari kemacetan performa yang tidak terduga.

    • Untuk beban kerja ElastiCache (RedisOSS), ketika secara eksplisit menghapus kunci dari cluster, UNLINK sepertiDEL: menghapus kunci yang ditentukan. Namun, perintah ini mengklaim kembali memori yang sebenarnya di thread yang berbeda, sehingga tidak memblokir, sedangkan DEL memblokir. Penghapusan yang sebenarnya akan terjadi nanti secara asinkron.

    • Untuk beban kerja ElastiCache (RedisOSS) 6.x, perilaku DEL perintah dapat dimodifikasi dalam grup parameter menggunakan parameter. lazyfree-lazy-user-del

  • [Sumber Daya]:

PE 6: Bagaimana Anda memodelkan dan berinteraksi dengan data ElastiCache?

Pengenalan tingkat pertanyaan: ElastiCache sangat bergantung pada struktur data dan model data yang digunakan, tetapi juga perlu mempertimbangkan penyimpanan data yang mendasarinya (jika ada). Pahami struktur data ElastiCache (RedisOSS) yang tersedia dan pastikan Anda menggunakan struktur data yang paling tepat untuk kebutuhan Anda.

Manfaat tingkat pertanyaan: Pemodelan data ElastiCache memiliki beberapa lapisan, termasuk kasus penggunaan aplikasi, tipe data, dan hubungan antar elemen data. Selain itu, setiap tipe data dan perintah ElastiCache (RedisOSS) memiliki tanda tangan kinerja yang terdokumentasi dengan baik.

  • [Terbaik] Praktik terbaiknya adalah mengurangi penimpaan data yang tidak disengaja. Gunakan konvensi penamaan yang meminimalkan tumpang-tindih nama kunci. Penamaan struktur data secara konvensional menggunakan metode hierarkis seperti: APPNAME:CONTEXT:ID, misalnya ORDER-APP:CUSTOMER:123.

    [Sumber Daya]:

  • Perintah [Best] ElastiCache (RedisOSS) memiliki kompleksitas waktu yang ditentukan oleh notasi Big O. Kompleksitas waktu perintah ini adalah representasi algoritmik/matematis dari dampaknya. Saat memperkenalkan jenis data baru dalam aplikasi, Anda perlu meninjau kompleksitas waktu perintah terkait dengan cermat. Perintah dengan kompleksitas waktu O(1) bersifat konstan dalam waktu dan tidak bergantung pada ukuran input, namun perintah dengan kompleksitas waktu O(N) bersifat linier dalam waktu dan menyesuaikan ukuran input. Karena desain ulir tunggal ElastiCache (RedisOSS), volume besar operasi kompleksitas waktu tinggi akan menghasilkan kinerja yang lebih rendah dan potensi batas waktu operasi.

    [Sumber Daya]:

  • [Terbaik] Gunakan APIs untuk mendapatkan GUI visibilitas ke dalam model data di cluster Anda.

    [Sumber Daya]:

PE 7: Bagaimana Anda mencatat perintah yang berjalan lambat di ElastiCache cluster Amazon Anda?

Pengantar tingkat pertanyaan: Manfaat penyesuaian performa melalui pengambilan, agregasi, dan notifikasi perintah yang berjalan lama. Dengan memahami berapa lama waktu yang dibutuhkan untuk menjalankan perintah, Anda dapat menentukan perintah mana yang menghasilkan kinerja yang buruk serta perintah yang menghalangi mesin agar tidak berkinerja optimal. ElastiCache (RedisOSS) juga memiliki kemampuan untuk meneruskan informasi ini ke Amazon CloudWatch atau Amazon Kinesis Data Firehose.

Manfaat tingkat pertanyaan: Pencatatan log ke lokasi permanen khusus dan penyediaan peristiwa notifikasi untuk perintah lambat dapat membantu analisis performa terperinci dan dapat digunakan untuk memicu peristiwa otomatis.

  • [Diperlukan] Amazon ElastiCache (RedisOSS) menjalankan engine versi 6.0 atau yang lebih baru, grup parameter yang dikonfigurasi dengan benar dan SLOWLOG logging diaktifkan di cluster.

    • Parameter yang diperlukan hanya tersedia ketika kompatibilitas versi engine diatur ke Valkey 7.2 dan lebih tinggi, atau Redis OSS versi 6.0 atau lebih tinggi.

    • SLOWLOGlogging terjadi ketika waktu eksekusi server dari suatu perintah membutuhkan waktu lebih lama dari nilai yang ditentukan. Perilaku klaster tergantung pada parameter Grup Parameter terkait yaitu slowlog-log-slower-than dan slowlog-max-len.

    • Perubahan akan diterapkan segera.

  • [Terbaik] Manfaatkan CloudWatch atau kemampuan Kinesis Data Firehose.

    • Gunakan kemampuan pemfilteran dan alarm, Wawasan CloudWatch Log CloudWatch, dan Layanan Pemberitahuan Sederhana Amazon untuk mencapai pemantauan kinerja dan pemberitahuan peristiwa.

    • Gunakan kemampuan streaming Kinesis Data Firehose SLOWLOG untuk mengarsipkan log ke penyimpanan permanen atau untuk memicu penyetelan parameter cluster otomatis.

    • Tentukan apakah JSON atau TEXT format polos paling sesuai dengan kebutuhan Anda.

    • Memberikan IAM izin untuk mempublikasikan ke CloudWatch atau Kinesis Data Firehose.

  • [Lebih Baik] Konfigurasikan slowlog-log-slower-than ke nilai selain default.

    • Parameter ini menentukan berapa lama perintah dapat dijalankan di dalam OSS mesin Valkey atau Redis sebelum dicatat sebagai perintah yang berjalan lambat. Nilai default-nya adalah 10.000 mikrodetik (10 milidetik). Nilai default mungkin terlalu tinggi untuk beberapa beban kerja.

    • Tentukan nilai yang lebih sesuai untuk beban kerja Anda berdasarkan kebutuhan aplikasi dan hasil pengujian; namun, nilai yang terlalu rendah dapat menghasilkan data yang berlebihan.

  • [Lebih Baik] Biarkan slowlog-max-len pada nilai default.

    • Parameter ini menentukan batas atas berapa banyak perintah yang berjalan lambat ditangkap dalam OSS memori Valkey atau Redis pada waktu tertentu. Nilai 0 secara efektif menonaktifkan penangkapan. Semakin tinggi nilainya, semakin banyak entri yang akan disimpan dalam memori, sehingga mengurangi kemungkinan informasi penting dikosongkan sebelum dapat ditinjau. Nilai default-nya adalah 128.

    • Nilai default tersebut sesuai untuk sebagian besar beban kerja. Jika ada kebutuhan untuk menganalisis data dalam jendela waktu yang diperluas dari valkey-cli melalui SLOWLOG perintah, pertimbangkan untuk meningkatkan nilai ini. Ini memungkinkan lebih banyak perintah untuk tetap berada di memori Valkey atau RedisOSS.

      Jika Anda memancarkan SLOWLOG data ke CloudWatch Log atau Kinesis Data Firehose, data akan bertahan dan dapat dianalisis di luar sistem, mengurangi kebutuhan untuk menyimpan sejumlah besar perintah yang berjalan lambat di memori Valkey atau Redis. ElastiCache OSS

  • [Sumber Daya]:

PE8: Bagaimana Auto Scaling membantu dalam meningkatkan kinerja cluster? ElastiCache

Pengenalan tingkat pertanyaan: Dengan menerapkan fitur penskalaan OSS otomatis Valkey atau Redis, ElastiCache komponen Anda dapat menyesuaikan dari waktu ke waktu untuk menambah atau mengurangi pecahan atau replika yang diinginkan secara otomatis. Ini dapat dilakukan dengan menerapkan kebijakan pelacakan target atau penskalaan terjadwal.

Manfaat tingkat pertanyaan: Memahami dan merencanakan lonjakan beban kerja dapat memastikan peningkatan kinerja caching dan kelangsungan bisnis. ElastiCache (RedisOSS) Auto Scaling terus memantau pemanfaatan /Memory CPU Anda untuk memastikan klaster Anda beroperasi pada tingkat kinerja yang Anda inginkan.

  • [Wajib] Saat meluncurkan cluster untuk ElastiCache (RedisOSS):

    1. Pastikan mode Klaster diaktifkan

    2. Pastikan instans berasal dari keluarga jenis dan ukuran tertentu yang mendukung Auto Scaling

    3. Pastikan klaster tidak berjalan di Penyimpanan Data Global, Outposts, atau Zona Lokal

    [Sumber Daya]:

  • [Terbaik] Identifikasi apakah beban kerja Anda menjalankan operasi baca atau tulis yang berat untuk menentukan kebijakan penskalaan. Untuk performa terbaik, gunakan hanya satu metrik pelacakan. Sebaiknya hindari beberapa kebijakan untuk setiap dimensi, karena kebijakan Auto Scaling akan menskalakan keluar saat target tercapai, namun menskalakan masuk hanya jika semua kebijakan pelacakan target siap untuk diskalakan.

    [Sumber Daya]:

  • [Terbaik] Memantau performa dari waktu ke waktu dapat membantu Anda mendeteksi perubahan beban kerja yang tidak akan terdeteksi jika dipantau pada titik waktu tertentu. Anda dapat menganalisis CloudWatch metrik yang sesuai untuk pemanfaatan klaster selama periode empat minggu untuk menentukan ambang nilai target. Jika Anda masih tidak yakin nilai apa yang harus dipilih, sebaiknya mulai dengan nilai metrik standar minimum yang didukung.

    [Sumber Daya]:

  • [Lebih Baik] Kami menyarankan untuk menguji aplikasi Anda dengan beban kerja minimum dan maksimum yang diharapkan, guna mengidentifikasi jumlah pasti serpihan/replika yang diperlukan klaster untuk mengembangkan kebijakan penskalaan dan mengurangi masalah ketersediaan.

    [Sumber Daya]: