Membangun API yang Dapat Diskalakan di AWS Spot Instance

Halo semua! Nama saya Kirill, saya CTO di Adapty. Sebagian besar arsitektur kami ada di AWS, dan hari ini saya akan berbicara tentang bagaimana kami mengurangi biaya server sebanyak 3 kali lipat dengan menggunakan instans spot di lingkungan produksi, serta cara mengatur penskalaan otomatisnya. Pertama akan ada gambaran umum tentang cara kerjanya, dan kemudian petunjuk rinci untuk memulai.

Apa itu Instans Spot?

Titik instans adalah server pengguna AWS lain yang saat ini menganggur, dan mereka menjualnya dengan diskon besar (Amazon menulis hingga 90%, menurut pengalaman kami ~3x, bervariasi bergantung pada wilayah, AZ, dan jenis instans). Perbedaan utama mereka dari yang biasa adalah mereka dapat dimatikan kapan saja. Oleh karena itu, untuk waktu yang lama kami percaya bahwa menggunakannya untuk lingkungan perawan, atau untuk tugas menghitung sesuatu adalah hal yang normal, dengan hasil antara disimpan di S3 atau di database, tetapi tidak untuk penjualan. Ada solusi pihak ketiga yang memungkinkan Anda menggunakan titik dalam produksi, tetapi ada banyak penopang untuk kasus kami, jadi kami tidak menerapkannya. Pendekatan yang dijelaskan dalam artikel ini berfungsi sepenuhnya dalam fungsionalitas AWS standar, tanpa skrip tambahan, mahkota, dll.

Di bawah ini adalah beberapa tangkapan layar yang menunjukkan riwayat harga untuk instans spot.

m5.large di wilayah eu-west-1 (Irlandia). Harga sebagian besar stabil selama 3 bulan, saat ini hemat 2.9x.

m5.large di wilayah us-east-1 (N. Virginia). Harga terus berubah selama 3 bulan, saat ini hemat dari 2.3x menjadi 2.8x tergantung zona ketersediaan.

t3.kecil di wilayah us-east-1 (Virginia Utara). Harga stabil selama 3 bulan, saat ini hemat 3.4x.

Arsitektur layanan

Arsitektur dasar layanan yang akan kita bahas dalam artikel ini ditunjukkan pada diagram di bawah.

Penyeimbang Beban Aplikasi → Grup Target EC2 → Layanan Kontainer Elastis

Application Load Balancer (ALB) digunakan sebagai penyeimbang, yang mengirimkan permintaan ke EC2 Target Group (TG). TG bertanggung jawab untuk membuka port pada instans untuk ALB dan menghubungkannya ke port kontainer Elastic Container Service (ECS). ECS adalah analog dari Kubernetes di AWS, yang mengelola container Docker.

Satu instance dapat memiliki beberapa container yang berjalan dengan port yang sama, jadi kami tidak dapat mengaturnya secara tetap. ECS memberi tahu TG bahwa ia meluncurkan tugas baru (dalam terminologi Kubernetes ini disebut pod), ECS memeriksa port gratis pada instance dan menugaskan salah satunya ke tugas yang diluncurkan. TG juga secara rutin memeriksa apakah instance dan API berfungsi menggunakan health check, dan jika melihat ada masalah, TG akan berhenti mengirim permintaan ke sana.

Grup Auto Scaling EC2 + Penyedia Kapasitas ECS

Diagram di atas tidak menunjukkan layanan EC2 Auto Scaling Groups (ASG). Dari namanya Anda dapat memahami bahwa ini bertanggung jawab untuk menskalakan instance. Namun, hingga saat ini, AWS tidak memiliki kemampuan bawaan untuk mengelola jumlah mesin yang berjalan dari ECS. ECS memungkinkan untuk menskalakan jumlah tugas, misalnya berdasarkan penggunaan CPU, RAM, atau jumlah permintaan. Namun jika tugas memenuhi semua instance gratis, maka mesin baru tidak dibuat secara otomatis.

Hal ini telah berubah dengan munculnya Penyedia Kapasitas ECS (ECS CP). Sekarang setiap layanan di ECS dapat dikaitkan dengan ASG, dan jika tugas tidak sesuai dengan instance yang sedang berjalan, maka tugas baru akan dimunculkan (tetapi dalam batas ASG yang ditetapkan). Ini juga bekerja dalam arah yang berlawanan, jika ECS CP melihat instance menganggur tanpa tugas, maka ECS akan memberikan perintah ASG untuk mematikannya. ECS CP memiliki kemampuan untuk menentukan persentase target beban instans, sehingga sejumlah mesin selalu bebas untuk melakukan penskalaan tugas dengan cepat; Saya akan membicarakannya nanti.

Templat Peluncuran EC2

Layanan terakhir yang akan saya bicarakan sebelum membahas secara detail tentang pembuatan infrastruktur ini adalah EC2 Launch Templates. Ini memungkinkan Anda membuat templat yang sesuai dengan semua mesin yang akan dijalankan, agar tidak mengulanginya dari awal setiap saat. Di sini Anda dapat memilih jenis mesin yang akan dijalankan, grup keamanan, image disk, dan banyak parameter lainnya. Anda juga dapat menentukan data pengguna yang akan diunggah ke semua instance yang diluncurkan. Anda dapat menjalankan skrip di data pengguna, misalnya Anda dapat mengedit konten file Konfigurasi agen ECS.

Salah satu parameter konfigurasi terpenting untuk artikel ini adalah ECS_ENABLE_SPOT_INSTANCE_DRAINING=benar. Jika parameter ini diaktifkan, maka segera setelah ECS menerima sinyal bahwa instance spot sedang diambil, ECS akan mentransfer semua tugas yang mengerjakannya ke status Draining. Tidak ada tugas baru yang akan ditetapkan ke instance ini; jika ada tugas yang ingin diluncurkan ke instance ini sekarang, tugas tersebut akan dibatalkan. Permintaan dari penyeimbang juga berhenti berdatangan. Pemberitahuan penghapusan instance datang 2 menit sebelum kejadian sebenarnya. Oleh karena itu, jika layanan Anda tidak menjalankan tugas lebih dari 2 menit dan tidak menyimpan apa pun ke disk, Anda dapat menggunakan instans spot tanpa kehilangan data.

Mengenai disk - AWS baru-baru ini lakukan Dimungkinkan untuk menggunakan Elastic File System (EFS) bersama dengan ECS; dengan skema ini, bahkan disk bukanlah halangan, tetapi kami tidak mencobanya, karena pada prinsipnya kami tidak memerlukan disk untuk menyimpan status. Secara default, setelah menerima SIGINT (dikirim ketika tugas ditransfer ke status Pengurasan), semua tugas yang berjalan akan dihentikan setelah 30 detik, meskipun tugas tersebut belum selesai; Anda dapat mengubah waktu ini menggunakan parameter ECS_CONTAINER_STOP_TIMEOUT. Hal utama adalah jangan menyetelnya lebih dari 2 menit untuk mesin spot.

Membuat layanan

Mari beralih ke pembuatan layanan yang dijelaskan. Dalam prosesnya, saya juga akan menjelaskan beberapa poin berguna yang tidak disebutkan di atas. Secara umum, ini adalah petunjuk langkah demi langkah, tetapi saya tidak akan mempertimbangkan beberapa kasus yang sangat mendasar atau, sebaliknya, kasus yang sangat spesifik. Semua tindakan dilakukan di konsol visual AWS, tetapi dapat direproduksi secara terprogram menggunakan CloudFormation atau Terraform. Di Adapty kami menggunakan Terraform.

Templat Peluncuran EC2

Layanan ini membuat konfigurasi mesin yang akan digunakan. Templat dikelola di bagian EC2 -> Instances -> Launch templates.

Gambar mesin Amazon (AMI) — tentukan image disk yang akan digunakan untuk meluncurkan semua instance. Untuk ECS, dalam banyak kasus, sebaiknya gunakan gambar yang dioptimalkan dari Amazon. Ini diperbarui secara berkala dan berisi semua yang diperlukan agar ECS dapat berfungsi. Untuk mengetahui ID gambar saat ini, buka halaman AMI yang dioptimalkan Amazon ECS, pilih wilayah yang Anda gunakan dan salin ID AMI untuk wilayah tersebut. Misalnya, untuk wilayah us-east-1, ID saat ini pada saat penulisan adalah ami-00c7c1cf5bdc913ed. ID ini harus dimasukkan ke dalam item Tentukan nilai khusus.

Jenis instance — menunjukkan jenis instans. Pilih salah satu yang paling sesuai dengan tugas Anda.

Pasangan kunci (masuk) — tentukan sertifikat yang dapat Anda gunakan untuk terhubung ke instance melalui SSH, jika perlu.

pengaturan jaringan — tentukan parameter jaringan. Platform jaringan dalam kebanyakan kasus, harus ada Virtual Private Cloud (VPC). Kelompok keamanan — grup keamanan untuk instans Anda. Karena kita akan menggunakan penyeimbang di depan instance, saya sarankan menentukan grup di sini yang mengizinkan koneksi masuk hanya dari penyeimbang. Artinya, Anda akan memiliki 2 grup keamanan, satu untuk penyeimbang, yang mengizinkan koneksi masuk dari mana saja pada port 80 (http) dan 443 (https), dan yang kedua untuk mesin, yang mengizinkan koneksi masuk pada port mana pun dari grup penyeimbang . Koneksi keluar di kedua grup harus dibuka menggunakan protokol TCP ke semua port ke semua alamat. Anda dapat membatasi port dan alamat untuk koneksi keluar, tetapi Anda harus terus memantau bahwa Anda tidak mencoba mengakses sesuatu pada port tertutup.

Penyimpanan (volume) — tentukan parameter disk untuk mesin. Ukuran disk tidak boleh kurang dari yang ditentukan dalam AMI; untuk ECS Optimized adalah 30 GiB.

Detail lanjutan — tentukan parameter tambahan.

Opsi pembelian — apakah kita ingin membeli instans spot. Kami ingin, tapi kami tidak akan mencentang kotak ini di sini; kami akan mengonfigurasinya di Grup Auto Scaling, ada lebih banyak opsi di sana.

Profil instans IAM — menunjukkan peran yang akan digunakan untuk meluncurkan instance. Agar instance dapat berjalan di ECS, instance tersebut memerlukan izin, yang biasanya terdapat dalam peran tersebut ecsInstanceRole. Dalam beberapa kasus dapat dibuat, jika tidak, maka di sini pengajaran tentang cara melakukan ini. Setelah pembuatan, kami menunjukkannya di templat.
Berikutnya ada banyak parameter, pada dasarnya Anda dapat membiarkan nilai default di mana saja, tetapi masing-masing memiliki penjelasan yang jelas. Saya selalu mengaktifkan instans yang dioptimalkan EBS dan opsi T2/T3 Tidak Terbatas jika digunakan mudah meledak contoh.

Waktu Pengguna — menunjukkan data pengguna. Kami akan mengedit file tersebut /etc/ecs/ecs.config, yang berisi konfigurasi agen ECS.
Contoh tampilan data pengguna:

#!/bin/bash
echo ECS_CLUSTER=DemoApiClusterProd >> /etc/ecs/ecs.config
echo ECS_ENABLE_SPOT_INSTANCE_DRAINING=true >> /etc/ecs/ecs.config
echo ECS_CONTAINER_STOP_TIMEOUT=1m >> /etc/ecs/ecs.config
echo ECS_ENGINE_AUTH_TYPE=docker >> /etc/ecs/ecs.config
echo "ECS_ENGINE_AUTH_DATA={"registry.gitlab.com":{"username":"username","password":"password"}}" >> /etc/ecs/ecs.config

ECS_CLUSTER=DemoApiClusterProd — parameter menunjukkan bahwa instance tersebut termasuk dalam cluster dengan nama yang diberikan, yaitu cluster ini akan dapat menempatkan tugasnya di server ini. Kami belum membuat cluster, tapi kami akan menggunakan nama ini saat membuatnya.

ECS_ENABLE_SPOT_INSTANCE_DRAINING=true — parameter menentukan bahwa ketika sinyal diterima untuk mematikan instance spot, semua tugas di dalamnya harus ditransfer ke status Draining.

ECS_CONTAINER_STOP_TIMEOUT=1m - parameter menentukan bahwa setelah menerima sinyal SIGINT, semua tugas memiliki waktu 1 menit sebelum dihentikan.

ECS_ENGINE_AUTH_TYPE=docker — parameter menunjukkan bahwa skema Docker digunakan sebagai mekanisme otorisasi

ECS_ENGINE_AUTH_DATA=... — parameter koneksi ke registri kontainer pribadi, tempat gambar Docker Anda disimpan. Jika bersifat publik, maka Anda tidak perlu menentukan apa pun.

Untuk keperluan artikel ini, saya akan menggunakan image publik dari Docker Hub, jadi tentukan parameternya ECS_ENGINE_AUTH_TYPE и ECS_ENGINE_AUTH_DATA tidak perlu.

berguna untuk mengetahui: Disarankan untuk memperbarui AMI secara berkala, karena versi baru memperbarui versi Docker, Linux, agen ECS, dll. Untuk tidak melupakan hal ini, Anda dapat mengatur notifikasi tentang rilis versi baru. Anda dapat menerima pemberitahuan melalui email dan memperbarui secara manual, atau Anda dapat menulis fungsi Lambda yang secara otomatis akan membuat Templat Peluncuran versi baru dengan AMI yang diperbarui.

Grup Penskalaan Otomatis EC2

Auto Scaling Group bertanggung jawab untuk meluncurkan dan menskalakan instans. Grup dikelola di bagian EC2 -> Auto Scaling -> Auto Scaling Groups.

Luncurkan templat — pilih template yang dibuat pada langkah sebelumnya. Kami meninggalkan versi default.

Opsi pembelian dan jenis instans — menentukan jenis instans untuk klaster. Templat Patuhi peluncuran menggunakan jenis instans dari Templat Peluncuran. Menggabungkan opsi pembelian dan jenis instans memungkinkan Anda mengonfigurasi jenis instans secara fleksibel. Kami akan menggunakannya.

Basis Sesuai Permintaan opsional — jumlah instance reguler dan non-spot yang akan selalu berfungsi.

Persentase Sesuai Permintaan di atas dasar — rasio persentase instance reguler dan spot, 50-50 akan didistribusikan secara merata, 20-80 untuk setiap instance reguler, 4 spot akan dinaikkan. Untuk keperluan contoh ini, saya akan menunjukkan 50-50, namun kenyataannya kita paling sering melakukan 20-80, dalam beberapa kasus 0-100.

Jenis instance — di sini Anda dapat menentukan jenis instans tambahan yang akan digunakan dalam klaster. Kami tidak pernah menggunakannya karena saya tidak begitu mengerti maksud ceritanya. Mungkin hal ini disebabkan oleh keterbatasan pada jenis instans tertentu, namun instans tersebut dapat ditingkatkan dengan mudah melalui dukungan. Jika Anda mengetahui aplikasinya, saya akan dengan senang hati membacanya di komentar)

jaringan — pengaturan jaringan, pilih VPC dan subnet untuk mesin, dalam banyak kasus Anda harus memilih semua subnet yang tersedia.

Penyeimbang beban - pengaturan penyeimbang, tetapi kami akan melakukannya secara terpisah, kami tidak akan menyentuh apa pun di sini. Pemeriksaan kesehatan juga akan dikonfigurasi nanti.

Ukuran grup — kami menunjukkan batasan jumlah mesin di cluster dan jumlah mesin yang diinginkan di awal. Jumlah mesin dalam cluster tidak akan pernah kurang dari jumlah minimum yang ditentukan dan lebih dari jumlah maksimum, meskipun penskalaan harus dilakukan sesuai dengan metrik.

Kebijakan penskalaan — parameter penskalaan, tetapi kami akan menskalakan berdasarkan tugas ECS yang sedang berjalan, jadi kami akan mengonfigurasi penskalaan nanti.

Perlindungan peningkatan skala instance — perlindungan instance dari penghapusan saat memperkecil skala. Kami mengaktifkannya agar ASG tidak menghapus mesin yang sedang menjalankan tugas. Penyedia Kapasitas ECS akan menonaktifkan perlindungan untuk instance yang tidak memiliki tugas.

Tambahkan tanda — Anda dapat menentukan tag untuk instance (untuk ini, kotak centang Tandai instance baru harus dicentang). Saya sarankan menentukan tag Nama, maka semua instance yang diluncurkan dalam grup akan memiliki nama yang sama, dan akan lebih mudah untuk melihatnya di konsol.

Setelah membuat grup, buka dan buka bagian Konfigurasi lanjutan... Mengapa tidak semua opsi terlihat di konsol pada tahap pembuatan.

Kebijakan penghentian — aturan yang diperhitungkan saat menghapus instance. Mereka diterapkan secara berurutan. Kami biasanya menggunakan yang ada pada gambar di bawah ini. Pertama, instance dengan Template Peluncuran terlama akan dihapus (misalnya, jika kami memperbarui AMI, kami membuat versi baru, tetapi semua instance berhasil beralih ke versi tersebut). Kemudian instans yang paling dekat dengan jam penagihan berikutnya dipilih. Dan kemudian yang terlama dipilih berdasarkan tanggal peluncuran.

berguna untuk mengetahui: untuk memperbarui semua mesin dalam sebuah cluster, mudah digunakan Penyegaran Instans. Jika Anda menggabungkan ini dengan fungsi Lambda dari langkah sebelumnya, Anda akan memiliki sistem pembaruan instans yang sepenuhnya otomatis. Sebelum memperbarui semua mesin, Anda harus menonaktifkan perlindungan penurunan skala instans untuk semua instans dalam grup. Bukan konfigurasi dalam grup, tetapi perlindungan dari mesin itu sendiri, ini dilakukan pada tab Manajemen Instance.

Penyeimbang Beban Aplikasi dan Grup Target EC2

Penyeimbang dibuat di bagian EC2 → Load Balancing → Load Balancers. Kami akan menggunakan Application Load Balancer; perbandingan berbagai jenis penyeimbang dapat dibaca di halaman layanan.

Pendengar - masuk akal untuk membuat port 80 dan 443 dan mengalihkan dari 80 ke 443 menggunakan aturan penyeimbang nanti.

Zona Ketersediaan — pada umumnya, kami memilih zona aksesibilitas untuk semua orang.

Konfigurasikan Pengaturan Keamanan — sertifikat SSL untuk penyeimbang ditunjukkan di sini, opsi yang paling nyaman adalah membuat sertifikat di ACM. Tentang perbedaannya Kebijakan Keamanan dapat dibaca di dokumentasi, Anda dapat membiarkannya dipilih secara default ELBSecurityPolicy-2016-08. Setelah membuat penyeimbang, Anda akan melihatnya Nama DNS, yang Anda perlukan untuk mengonfigurasi CNAME untuk domain Anda. Misalnya seperti ini tampilannya di Cloudflare.

Grup Keamanan — membuat atau memilih grup keamanan untuk penyeimbang, saya menulis lebih banyak tentang ini tepat di atas di bagian Templat Peluncuran EC2 → Pengaturan jaringan.

Kelompok sasaran — kami membuat grup yang bertanggung jawab untuk merutekan permintaan dari penyeimbang ke mesin dan memeriksa ketersediaannya untuk menggantikannya jika terjadi masalah. Jenis target harus Instance, Protokol и pelabuhan apa pun, jika Anda menggunakan HTTPS untuk komunikasi antara penyeimbang dan instans, maka Anda perlu mengunggah sertifikat ke instans tersebut. Untuk keperluan contoh ini, kami tidak akan melakukan ini, kami hanya akan meninggalkan port 80.

Pemeriksaan kesehatan — parameter untuk memeriksa fungsionalitas layanan. Dalam layanan nyata, ini harus berupa permintaan terpisah yang mengimplementasikan bagian penting dari logika bisnis; untuk keperluan contoh ini, saya akan membiarkan pengaturan default. Selanjutnya, Anda dapat memilih interval permintaan, batas waktu, kode sukses, dll. Dalam contoh kami, kami akan menunjukkan kode Sukses 200-399, karena image Docker yang akan digunakan mengembalikan kode 304.

Daftarkan Target — di sini mobil untuk grup dipilih, namun dalam kasus kita ini akan dilakukan oleh ECS, jadi kita lewati saja langkah ini.

berguna untuk mengetahui: pada level penyeimbang Anda dapat mengaktifkan log yang akan disimpan di S3 pada waktu tertentu format. Dari sana, kueri tersebut dapat diekspor ke layanan pihak ketiga untuk analitik, atau Anda dapat membuat kueri SQL langsung pada data di S3 dengan menggunakan Athena. Nyaman dan berfungsi tanpa kode tambahan apa pun. Saya juga merekomendasikan pengaturan penghapusan log dari bucket S3 setelah jangka waktu tertentu.

Definisi Tugas ECS

Pada langkah sebelumnya, kita membuat segala sesuatu yang berhubungan dengan infrastruktur layanan; sekarang kita beralih ke mendeskripsikan container yang akan kita luncurkan. Hal ini dilakukan di bagian ECS → Definisi Tugas.

Kompatibilitas jenis peluncuran - pilih EC2.

Peran IAM eksekusi tugas - memilih ecsTaskExecutionRole. Dengan menggunakannya, log ditulis, akses ke variabel rahasia diberikan, dll.

Di bagian Definisi Kontainer, klik Tambahkan Kontainer.

Gambar — tautan ke gambar dengan kode proyek; untuk contoh ini saya akan menggunakan gambar publik dari Docker Hub bitnami/contoh-simpul:0.0.1.

Batas Memori — batas memori untuk container. Batas Keras — batas keras, jika container melampaui nilai yang ditentukan, perintah docker kill akan dijalankan, container akan langsung mati. Batas Lunak — batas lunak, wadah dapat melampaui nilai yang ditentukan, namun parameter ini akan diperhitungkan saat menempatkan tugas pada mesin. Misalnya, jika mesin memiliki RAM sebesar 4 GiB, dan batas lunak suatu container adalah 2048 MiB, maka mesin ini dapat menjalankan maksimal 2 tugas yang berjalan dengan container ini. Pada kenyataannya, RAM 4 GiB sedikit kurang dari 4096 MiB, hal ini dapat dilihat pada tab ECS Instances di cluster. Batas lunak tidak boleh lebih besar dari batas keras. Penting untuk dipahami bahwa jika ada beberapa kontainer dalam satu tugas, maka batasannya akan dijumlahkan.

Pemetaan pelabuhan - di Pelabuhan tuan rumah Kami menunjukkan 0, ini berarti port akan ditetapkan secara dinamis dan akan dipantau oleh Grup Sasaran. Pelabuhan Kontainer — port tempat aplikasi Anda berjalan sering kali ditentukan dalam perintah eksekusi, atau ditetapkan dalam kode aplikasi Anda, Dockerfile, dll. Sebagai contoh, kita akan menggunakan 3000 karena terdaftar di Dockerfile gambar yang sedang digunakan.

Cek kesehatan — parameter pemeriksaan kesehatan kontainer, jangan bingung dengan yang dikonfigurasi di Grup Target.

Lingkungan Hidup - pengaturan lingkungan. Unit CPU - mirip dengan batas Memori, hanya tentang prosesor. Setiap inti prosesor berjumlah 1024 unit, jadi jika server memiliki prosesor inti ganda dan container disetel ke 512, maka 4 tugas dengan container ini dapat diluncurkan di satu server. Unit CPU selalu sesuai dengan jumlah inti; jumlahnya tidak boleh kurang, seperti halnya dengan memori.

perintah — perintah untuk memulai layanan di dalam wadah, semua parameter ditentukan dipisahkan dengan koma. Ini bisa berupa gunicorn, npm, dll. Jika tidak ditentukan, nilai arahan CMD dari Dockerfile akan digunakan. Kami menunjukkan npm,start.

Variabel lingkungan — variabel lingkungan kontainer. Ini bisa berupa data teks sederhana atau variabel rahasia Manajer Rahasia или Toko Parameter.

Penyimpanan dan Pencatatan — di sini kita akan menyiapkan logging di CloudWatch Logs (layanan untuk log dari AWS). Untuk melakukan hal ini, cukup aktifkan kotak centang Konfigurasi Otomatis CloudWatch Logs. Setelah membuat Ketentuan Tugas, sekelompok log akan secara otomatis dibuat di CloudWatch. Secara default, log disimpan di dalamnya tanpa batas waktu; Saya sarankan mengubah periode Retensi dari Never Expire ke periode yang diperlukan. Ini dilakukan di grup CloudWatch Log, Anda perlu mengklik periode saat ini dan memilih periode baru.

Klaster ECS dan Penyedia Kapasitas ECS

Buka bagian ECS → Clusters untuk membuat cluster. Kami memilih EC2 Linux + Networking sebagai template.

Nama klaster - sangat penting, di sini kami membuat nama yang sama seperti yang ditentukan dalam parameter Template Peluncuran ECS_CLUSTER, dalam kasus kami - DemoApiClusterProd. Centang kotak Buat klaster kosong. Secara opsional, Anda dapat mengaktifkan Container Insights untuk melihat metrik layanan di CloudWatch. Jika Anda melakukan semuanya dengan benar, maka di bagian ECS Instances Anda akan melihat mesin yang dibuat di grup Auto Scaling.

Pergi ke tab Penyedia Kapasitas dan membuat yang baru. Izinkan saya mengingatkan Anda bahwa ini diperlukan untuk mengontrol pembuatan dan penghentian mesin tergantung pada jumlah tugas ECS yang berjalan. Penting untuk dicatat bahwa penyedia hanya dapat ditugaskan ke satu grup.

Grup Penskalaan Otomatis — pilih grup yang dibuat sebelumnya.

Penskalaan yang dikelola — aktifkan agar penyedia dapat meningkatkan skala layanan.

Kapasitas target % — berapa persentase mesin yang memuat tugas yang kita perlukan. Jika Anda menentukan 100%, maka semua mesin akan selalu sibuk dengan tugas yang sedang berjalan. Jika Anda menentukan 50%, maka setengah dari mobil akan selalu gratis. Dalam hal ini, jika terjadi lonjakan muatan yang tajam, taksi baru akan langsung mendapatkan mobil gratis, tanpa harus menunggu petugas dikerahkan.

Perlindungan terminasi terkelola — aktifkan, parameter ini memungkinkan penyedia untuk menghapus perlindungan instance dari penghapusan. Hal ini terjadi ketika tidak ada tugas aktif pada mesin dan mengizinkan Target capacity%.

Layanan ECS dan pengaturan penskalaan

Langkah terakhir :) Untuk membuat layanan, Anda harus masuk ke cluster yang dibuat sebelumnya pada tab Layanan.

Jenis peluncuran — Anda perlu mengklik strategi Beralih ke penyedia kapasitas dan memilih penyedia yang dibuat sebelumnya.

Definisi Tugas — pilih Definisi Tugas yang dibuat sebelumnya dan revisinya.

Nama layanan — untuk menghindari kebingungan, kami selalu menunjukkan hal yang sama dengan Definisi Tugas.

Jenis Layanan - selalu Replika.

Jumlah tugas — jumlah tugas aktif yang diinginkan dalam layanan. Parameter ini dikontrol melalui penskalaan, namun tetap harus ditentukan.

Persentase sehat minimal и Persentase maksimum — menentukan perilaku tugas selama penerapan. Nilai defaultnya adalah 100 dan 200, yang menunjukkan bahwa pada saat penerapan, jumlah tugas akan bertambah beberapa kali lipat, dan kemudian kembali ke nilai yang diinginkan. Jika Anda menjalankan 1 tugas, min=0, dan maks=100, maka selama penerapan tugas tersebut akan dihentikan, dan setelah itu tugas baru akan dimunculkan, yaitu waktu henti. Jika 1 tugas berjalan, min=50, maks=150, maka penerapan tidak akan terjadi sama sekali, karena 1 tugas tidak dapat dibagi dua atau ditambah satu setengah kali lipat.

Jenis penerapan — tinggalkan pembaruan berkelanjutan.

Templat Penempatan — aturan untuk menempatkan tugas pada mesin. Standarnya adalah AZ Balanced Spread - ini berarti bahwa setiap tugas baru akan ditempatkan pada instans baru hingga mesin di semua zona ketersediaan meningkat. Kami biasanya melakukan BinPack - CPU dan Spread - AZ; dengan kebijakan ini, tugas ditempatkan sepadat mungkin pada satu mesin per CPU. Jika perlu membuat mesin baru, mesin tersebut dibuat di zona ketersediaan baru.

Jenis penyeimbang beban — pilih Penyeimbang Beban Aplikasi.

Peran IAM layanan - memilih ecsServiceRole.

Nama penyeimbang beban — pilih penyeimbang yang dibuat sebelumnya.

Masa tenggang pemeriksaan kesehatan — jeda sebelum melakukan pemeriksaan kesehatan setelah meluncurkan tugas baru, kami biasanya menyetelnya ke 60 detik.

Kontainer untuk memuat keseimbangan — di item Nama grup target, pilih grup yang dibuat sebelumnya, dan semuanya akan terisi secara otomatis.

Layanan Auto Scaling — parameter penskalaan layanan. Pilih Konfigurasikan Layanan Auto Scaling untuk menyesuaikan jumlah layanan yang Anda inginkan. Kami menetapkan jumlah tugas minimum dan maksimum saat melakukan penskalaan.

Peran IAM untuk Layanan Auto Scaling - memilih AWSServiceRoleForApplicationAutoScaling_ECSService.

Kebijakan penskalaan tugas otomatis — aturan untuk penskalaan. Ada 2 jenis:

1. Pelacakan target — melacak metrik target (penggunaan CPU/RAM atau jumlah permintaan untuk setiap tugas). Misalnya kita ingin rata-rata beban prosesor menjadi 85%, bila lebih tinggi maka tugas baru akan ditambahkan hingga mencapai nilai target. Jika bebannya lebih rendah, maka tugas akan dihapus, sebaliknya, kecuali perlindungan terhadap penurunan skala diaktifkan (Nonaktifkan peningkatan skala).
2. Penskalaan langkah - reaksi terhadap peristiwa yang sewenang-wenang. Di sini Anda dapat mengonfigurasi reaksi terhadap peristiwa apa pun (CloudWatch Alarm), ketika itu terjadi, Anda dapat menambah atau menghapus jumlah tugas yang ditentukan, atau menentukan jumlah tugas yang tepat.

Suatu layanan mungkin memiliki beberapa aturan penskalaan, ini bisa berguna, yang utama adalah memastikan bahwa aturan tersebut tidak bertentangan satu sama lain.

Kesimpulan

Jika Anda mengikuti instruksi dan menggunakan image Docker yang sama, layanan Anda akan mengembalikan halaman seperti ini.

1. Kami telah membuat templat yang sesuai dengan peluncuran semua mesin di layanan. Kami juga mempelajari cara memperbarui mesin saat templat berubah.
2. Kami telah mengonfigurasi pemrosesan sinyal berhenti instans spot, sehingga dalam satu menit setelah menerimanya, semua tugas yang berjalan akan dihapus dari mesin, sehingga tidak ada yang hilang atau terganggu.
3. Kami menaikkan penyeimbang untuk mendistribusikan beban secara merata ke seluruh alat berat.
4. Kami telah menciptakan layanan yang berjalan pada instans spot, yang mengurangi biaya mesin sekitar 3 kali lipat.
5. Kami telah mengonfigurasi penskalaan otomatis di kedua arah untuk menangani peningkatan beban kerja tanpa menimbulkan biaya waktu henti.
6. Kami menggunakan Penyedia Kapasitas agar aplikasi mengelola infrastruktur (mesin) dan bukan sebaliknya.
7. Kami hebat.

Jika Anda memiliki lonjakan beban yang dapat diprediksi, misalnya Anda beriklan di kampanye email besar, Anda dapat menyiapkan penskalaan dengan jadwal.

Anda juga dapat menskalakan berdasarkan data dari berbagai bagian sistem Anda. Misalnya, kami memiliki fungsionalitas mengirimkan penawaran promosi individu pengguna aplikasi seluler. Terkadang kampanye dikirim ke lebih dari 1 juta orang. Setelah distribusi seperti itu, selalu ada peningkatan besar dalam permintaan ke API, karena banyak pengguna yang masuk ke aplikasi pada saat yang bersamaan. Jadi jika kami melihat ada lebih banyak indikator standar dalam antrean pengiriman pemberitahuan push promosi, kami dapat segera meluncurkan beberapa mesin dan tugas tambahan agar siap dimuat.

Saya akan senang jika Anda memberi tahu saya di komentar kasus menarik penggunaan instance spot dan ECS atau sesuatu tentang penskalaan.

Akan segera ada artikel tentang cara kami memproses ribuan peristiwa analitis per detik pada tumpukan yang sebagian besar tidak memiliki server (dengan uang) dan cara kerja penerapan layanan menggunakan GitLab CI dan Terraform Cloud.

Berlanggananlah kepada kami, itu akan menarik!

Hanya pengguna terdaftar yang dapat berpartisipasi dalam survei. Masuk, silakan.

Apakah Anda menggunakan instans spot dalam produksi?

• 22,2%Ya6

• 66,7%No18

• 11,1%Saya mempelajarinya dari sebuah artikel dan berencana menggunakannya3

27 pengguna memilih. 5 pengguna abstain.

Sumber: www.habr.com