Penskalaan Otomatis EC2 dengan Instansi Spot dan On-Demand?

Saya ingin mengoptimalkan biaya grup EC2 penskalaan otomatis kami dengan meminta mereka meluncurkan instance spot alih-alih instance sesuai permintaan.

Apa yang saya benar-benar inginkan adalah dapat menjaga beberapa server dalam grup sebagai instance on-demand, terlepas dari apa yang terjadi pada pasar penetapan harga spot spot. Lalu saya ingin server tambahan dalam grup, di atas minimum yang saya konfigurasikan, menjadi instance spot. Saya biasanya setuju dengan keterlambatan dalam menambahkan server melalui permintaan tempat.

Sepertinya saya tidak dapat menemukan cara untuk melakukan ini dan saya telah mencoba membaca dokumentasi AWS. Tampaknya ASG dapat berupa on-demand atau spot, tetapi bukan hibrida.

Saya mungkin bisa secara manual menambahkan instance on-demand ke Elastic Load Balancer yang ditugaskan untuk grup penskalaan otomatis, tetapi kemudian beban server itu tidak akan dimasukkan dalam pengukuran dan pemicu penskalaan otomatis.

Saya kira saya bisa memasukkan harga penawaran yang sangat tinggi untuk memastikan bahwa saya selalu mendapatkan server yang saya butuhkan, tetapi kemudian saya melihat sejarah harga dan melihat lonjakan besar yang sesekali terjadi.

Dokumentasi AWS bertentangan dengan dirinya sendiri, karena di satu tempat dikatakan bahwa jika Anda memasukkan server minimum, jumlah itu "dipastikan" ada di sana. Tetapi ketika Anda membaca tentang contoh spot, tidak ada jaminan. Perbedaan harga untuk spot cukup meyakinkan, jadi saya ingin memanfaatkan sebanyak yang saya bisa sambil tetap mempertahankan garis dasar yang selalu aktif. Apakah ini mungkin?

Saat ini Anda dapat mencampur ondemand dan melihat instance di ASG tunggal

Amazon EC2 Auto Scaling sekarang memungkinkan Anda menyediakan dan secara otomatis skala contoh di seluruh opsi pembelian, Zona Ketersediaan (AZ), dan keluarga contoh dalam satu grup Penskalaan Otomatis (ASG), untuk mengoptimalkan skala, kinerja, dan biaya. Sekarang Anda dapat menyertakan Instance Spot dengan On-Demand dan RIs dalam ASG tunggal , untuk menghemat hingga 90% pada perhitungan.

Pendekatan yang dibahas di atas akan sedikit berantakan, dan tidak begitu fleksibel. Pendekatan yang lebih kanonik adalah dengan hanya membuat 2 ASG (satu untuk tempat, satu untuk on-demand) dan kemudian mendaftarkan keduanya dengan ELB yang sama (dibahas di sini ). Ini memberi Anda kemampuan untuk mengendalikan masing-masing secara independen daripada mencoba untuk membuang dengan LC swap dalam ASG tunggal.

Ini hybrid Auto Scaling pendekatan tampaknya tidak akan tersedia dari kotak memang, sayangnya.

Namun, Anda mungkin dapat mengatasi keterbatasan ini sebagai berikut (belum teruji, hanya desain sistem yang telah saya juggling untuk sementara waktu):

Solusi Potensial

Sebagaimana diuraikan dalam Menggunakan Penskalaan Otomatis untuk Meluncurkan Mesin Virtual Spot , tawaran harga spot adalah parameter dari Konfigurasi Peluncuran yang digunakan. Seperti yang Anda tunjukkan, tidak ada konfigurasi peluncuran hybrid yang tersedia, melainkan harus on-demand atau spot, yang berarti use case membutuhkan dua konfigurasi peluncuran yang berbeda.

Ini sepertinya tidak segera membantu, karena Anda hanya dapat melampirkan satu konfigurasi peluncuran ke grup Penskalaan Otomatis pada suatu waktu , dengan kendala (sebagian usang) berikut ini (lihat Konfigurasi Peluncuran ):

Saat Anda melampirkan konfigurasi peluncuran baru atau yang diperbarui ke grup Penskalaan Otomatis Anda, setiap instance baru akan diluncurkan menggunakan parameter konfigurasi baru. Mesin virtual yang ada tidak terpengaruh . Ketika Penskalaan Otomatis perlu diturunkan, pertama-tama menghentikan instance yang memiliki konfigurasi peluncuran yang lebih lama . [penekanan milikku]

Bagian-bagian yang ditekankan adalah kunci, dengan yang pertama mencakup persyaratan untuk menjaga instance on-demand tetap berjalan setelah berubah dari konfigurasi peluncuran on-demand awal masing-masing ke konfigurasi peluncuran spot tambahan, dan yang terakhir tidak selalu menjadi kasus lagi karena Kebijakan Pengakhiran Penskalaan Otomatis yang baru-baru ini diperkenalkan (untuk perubahan, biasanya tidak ada keriuhan melalui posting blog AWS yang menyertainya), yang didokumentasikan dalam Kebijakan Pengakhiran Instans untuk Grup Penskalaan Otomatis Anda :

Sebelum Penskalaan Otomatis memilih sebuah instance untuk diakhiri, ia terlebih dahulu mengidentifikasi Zona Ketersediaan yang memiliki lebih banyak instance daripada Zona Ketersediaan lainnya yang digunakan oleh grup. Jika semua Zona Ketersediaan memiliki jumlah instance yang sama, ini mengidentifikasi Zona Ketersediaan acak. Di dalam Zona Ketersediaan yang diidentifikasi, Penskalaan Otomatis menggunakan kebijakan penghentian untuk memilih contoh penghentian . [penekanan milikku]

Seperti yang diuraikan dalam Bagaimana Kebijakan Pengakhiran Anda Bekerja , Anda sekarang dapat menentukan LatestInstance , jika Anda ingin instance yang diluncurkan terakhir dihentikan , yang akan menjadi salah satu instance spot yang baru diluncurkan:

Penskalaan Otomatis menggunakan waktu peluncuran instance untuk mengidentifikasi instance yang diluncurkan terakhir.

Jelas mungkin ada sedikit lebih dari ini, misalnya Anda dapat menentukan salah satu kebijakan sebagai kebijakan mandiri, atau Anda dapat membuat daftar beberapa kebijakan dalam daftar yang dipesan , tetapi pendekatan ini harus memastikan beban semua contoh diperhitungkan dalam pengukuran dan pemicu skala otomatis ; satu peringatan tetap:

Peringatan

Jika penyeimbang beban mengakhiri salah satu contoh saat diminta untuk alasan lain (misalnya karena itu sendiri menjadi tidak sehat), itu tidak akan digantikan oleh mesin virtual sesuai permintaan secara otomatis. Jadi, Anda perlu memantau dan memperhitungkan acara ini secara terpisah, misalnya dengan mengaktifkan sementara konfigurasi peluncuran sesuai permintaan lagi.

Semoga berhasil!

Saya mengambil inspirasi dari jawaban di sini untuk menghasilkan https://github.com/ashwanthkumar/matsya

Ini membantu Anda melakukan hal berikut

• Anda selalu membutuhkan armada mesin untuk persyaratan cluster Hadoop / Mesos / YARN Anda
• Anda ingin menghemat uang dengan menggunakan Spot tetapi juga mundur ke OD karena Anda membutuhkan kekuatan pemrosesan untuk memenuhi SLA Anda
• Beralih kembali ke Spot sekali di OD untuk menghemat uang lagi.

Jika Anda hanya ingin 1 ASG dengan jumlah statis saat diminta, yang berikut ini akan berfungsi:

• Buat grup Auto Scaling berdasarkan konfigurasi Spot Instance Launch.

• Tangguhkan Penskalaan Otomatis pada ASG

• Secara manual tambahkan instance on-demand (beban dasar statis) ke ASG dan nyalakan perlindungan instance untuk instance tersebut.

• Lanjutkan Autoscaling pada ASG

• Kebijakan penskalaan otomatis default sekarang akan mengabaikan instance on-demand (karena perlindungan) dan menghentikan jumlah instance spot yang sama dengan instance on-demand untuk mencapai jumlah grup yang diinginkan. Setiap kegiatan skala-dalam atau luar hanya akan meluncurkan atau menghentikan mesin virtual tempat.