Hai, semuanya, dan selamat datang kembali.
Sekarang, dalam video hari ini, kita akan membahas tentang arsitektur penskalaan berdasarkan SKU Amazon
secara garis besar.
Sekarang, di banyak organisasi, jumlah EC dua instance yang akan berjalan di lingkungan produksi secara
langsung berkorelasi dengan jumlah pesan yang menjadi bagian dari penyelamatan.
Sebagai contoh, katakanlah ada sepuluh pesan dalam antrean AS, dan karena ada dua EC dua instance
yang berjalan, masing-masing EC dua instance akan menangani dan memproses lima pesan dan setelah diproses, mereka
akan mengunggah artefak ke bucket S3.
Sekarang katakanlah besok ada obral besar yang sedang berlangsung dan di AS, alih-alih sepuluh pesan,
ada 10.000 pesan.
Sekarang, karena ada banyak pesan dalam antrean, ada dua pilihan.
Pertama, Anda hanya menyimpan dua contoh yang mudah dijalankan dan pemrosesan 10.000 pesan akan memakan banyak
waktu.
Jadi, itu adalah pilihan pertama.
Opsi kedua adalah Anda meningkatkan jumlah EC dua instance yang berjalan di lingkungan produksi,
katakanlah dari 2 menjadi 20.
Jadi sekarang 20 adalah dua contoh yang berjalan, 10.000 pesan akan diproses dengan cara yang jauh lebih cepat.
Namun, meningkatkan jumlah EC dua contoh juga akan meningkatkan biaya.
Sekarang, setelah penjualan selesai, jumlah pesan dalam antrean telah berkurang dari 10.000 menjadi
sepuluh.
Jadi, sekarang apa yang harus Anda lakukan, Anda harus menghentikan EC ekstra.
Dua contoh yang kami jalankan untuk mengurangi biaya keseluruhan.
Sekarang di lingkungan produksi, Anda ingin mengimplementasikan arsitektur seperti itu di mana dua
instance EC diluncurkan dan dihentikan berdasarkan jumlah pesan dalam antrian.
Dan pada kenyataannya di banyak organisasi, Anda akan melihat arsitektur semacam ini diimplementasikan.
Jadi, pada tinjauan tingkat tinggi, mari kita lihat dengan cepat apa saja yang perlu dilakukan untuk
mencapai arsitektur semacam ini.
Sekarang, jika Anda menggunakan grup penskalaan otomatis, maka dalam kasus seperti itu Anda bisa mengonfigurasikannya untuk meluncurkan
atau menghentikan dua contoh yang mudah berdasarkan jumlah pesan yang menjadi bagian dari penyelamatan.
Sekarang, hal ini dapat dijelaskan dengan diagram ini di mana Anda memiliki aplikasi yang membaca
jumlah pesan yang menjadi bagian dari antrean dan menyimpan datanya di cloud watch.
Sekarang, bergantung pada data di cloud watch, penskalaan otomatis akan meluncurkan set instance baru atau menghentikan
set instance tambahan yang sedang kita jalankan.
Sekarang pertanyaan yang muncul adalah bagaimana aplikasi khusus ini mengetahui berapa banyak pesan yang ada dalam penyelamatan?
Dan jawabannya adalah salah satu dari enam kolom atribut, perkiraan jumlah pesan.
Jadi, mari kita lanjutkan dan segera melihatnya.
Sekarang, untuk demo hari ini, saya memiliki penyelamatan dan ada dua pesan yang tersedia.
Jadi, jika kita membuka penyelamatan, kita akan mendapatkan URL antrian.
Dan berdasarkan URL ini, Anda dapat melanjutkan dan memeriksa berapa banyak pesan yang ada.
Jadi, mari kita lanjutkan dan segera melihatnya.
Jadi saya memiliki perintah CLI panggil kita delapan kita mendapatkan atribut, kita tentukan URL antrean di sini dan
kita tentukan nama atribut dan nama atribut di sini adalah perkiraan jumlah pesan.
Hal ini sangat mirip dengan apa yang sedang kita diskusikan dan wilayahnya adalah AP Tenggara.
Sekarang jika saya dengan cepat menekan enter di sini, Anda akan melihat bahwa jumlah pesan yang ditampilkan adalah dua dan ini adalah
hal yang sama yang dapat dilakukan oleh aplikasi dan dapat mempublikasikannya ke layanan pusat dari mana penskalaan
otomatis akan meluncurkan dan menghentikan instance sesuai kebutuhan.
Jadi, ini adalah salah satu desain arsitektur yang dapat diimplementasikan jika Anda memiliki kasus penggunaan di mana Anda
ingin meluncurkan dan menghentikan instance berdasarkan jumlah pesan.
Jadi dengan ini akan menyimpulkan video hari ini.