Bagaimana mencegah pelukan maut di EC2 Instance?

Saya memiliki aplikasi iOS di app store dan baru-baru ini saya menerima lonjakan lalu lintas yang sangat besar ke halaman arahan saya yang dihosting di EC2 dan mengakibatkan halaman tersebut tidak merespons, untungnya saya berhasil memulihkannya dengan memulai kembali dan memutakhirkan instance ke t2.medium.

Sekarang saya ingin mempekerjakan seseorang untuk mengimplementasikan teknologi untuk mencegah kematian yang sama lagi. Pengalaman saya hanya sejauh itu memungkinkan saya untuk memahami hal-hal dasar devops tetapi tidak cukup untuk load balancer di AWS, saya ingin tahu apa implementasi yang terjangkau untuk contoh saya.

Halaman pendaratan saya dan backend aplikasi iOS di-host pada instance yang sama.

Jika Anda menginginkan sesuatu yang cepat untuk disortir ini tanpa banyak pengetahuan, saya akan merekomendasikan beanstalk elastis. Ini adalah aplikasi AWS lain yang akan menangani konfigurasi load balancer dan penskalaan instan untuk Anda.

Tidak ada biaya tambahan di atas penyeimbang beban dan instance sehingga Anda dapat tetap menggunakan instance tipe t2 tetapi biarkan skala batang kacang elastis sebanyak yang Anda mau bantu.

Penskalaan otomatis tidak instan dan pada saat lonjakan lalu lintas akan membutuhkan waktu singkat, biasanya beberapa menit, untuk dapat menangani lonjakan tetapi itu akan jauh lebih baik daripada secara manual mengubah ukuran contoh dan sangat mudah untuk mengatasi dengan.

Saya akan merekomendasikan penskalaan otomatis seperti yang disebutkan di atas dengan penambahan beberapa alarm CloudWatch untuk memulai proses penskalaan otomatis ketika ambang tertentu mulai meningkat, bukan saat sudah jauh.

Sebagai contoh; konfigurasikan CloudWatch untuk memantau server Anda, ketika CPU berada pada 50% atau lebih tinggi untuk jangka waktu 30 detik atau lebih, memulai proses penskalaan otomatis.

Ini mungkin tidak sepenuhnya sempurna tetapi mudah dilakukan melalui beberapa panduan online dan semua dapat dikonfigurasi melalui GUI.

Juga, jika halaman arahan Anda statis mengapa tidak meng-host-nya pada t2.micro tingkat-gratis dan menggunakan tingkat-bebas t2.micro lain untuk aplikasi Anda?

Saya ingin membantu dengan ini jika Anda mencari bantuan. Tergantung pada halaman Anda, Anda mungkin tidak perlu EC2 sama sekali. Misalnya jika Anda menyajikan sesuatu yang statis atau JavaScript, ia dapat disajikan dari s3 dengan distribusi cloudfront. Atau kita bisa menggunakan grup penskalaan otomatis jika benar-benar diperlukan.

Ada dua strategi umum untuk menghadapi lonjakan lalu lintas: meningkatkan kapasitas dan mengurangi biaya.

Peningkatan kapasitas berarti penskalaan otomatis, yang semua orang sangat senang ketika awan publik pertama kali tersedia. Dalam pengertian yang paling mendasar, ini akan mem-boot lebih banyak server web untuk Anda berdasarkan pada beban dan menambahkannya ke penyeimbang beban, tetapi karena dapat menyulitkan untuk mengelola, ada solusi yang lebih otomatis juga, seperti Elastic Beanstalk.

Masalah dengan ekspansi kapasitas otomatis adalah ekspansi tagihannya yang otomatis - lalu lintas normal 10x berarti server 10x berarti uang 10x yang harus Anda bayar. Itu sebabnya, walaupun ini adalah strategi yang berguna untuk diingat, saya pikir Anda harus selalu mulai dengan melihat seberapa banyak Anda bisa menipu.

Yang saya maksud dengan cheat adalah cache, yang bertumpu pada gagasan bahwa sebagian besar waktu Anda dapat memberikan data yang sedikit ketinggalan zaman kepada pengguna dan mereka tidak akan melihatnya, dan itu dapat menghemat banyak waktu bagi Anda. Bayangkan Anda memiliki halaman yang Anda putuskan tidak apa-apa jika lima detik kedaluwarsa, dan ia mendapat 20 req / s. Tanpa caching, Anda menjalankan perhitungan itu 1.200 kali per menit, sedangkan dengan caching hanya 12. Anda dapat melihat bagaimana ini dapat membuat perbedaan yang luar biasa.

Tentu saja ada banyak jenis caching, dan situs web yang sukses akan menggunakan beberapa dari mereka. Tetapi untuk use case Anda, ada dua opsi yang cukup bagus dan mudah.

Yang pertama adalah membuat situs sepenuhnya statis. Ini mengasumsikan bahwa Anda dapat melakukannya, tetapi jika Anda bisa, maka Anda hanya perlu Nginx melayani html secara langsung, dan dapat melayani banyak permintaan tanpa keringat.

Jika Anda memerlukan tingkat kedinamisan, maka melakukan caching satu halaman penuh adalah pilihan yang baik. Nginx memiliki beberapa kemampuan untuk melakukan ini, tetapi saya sangat suka Varnish karena fleksibilitasnya.

Apa pun opsi atau opsi yang Anda gunakan, pastikan Anda melakukan uji muat untuk memvalidasi bahwa Anda telah mengaturnya dengan benar; kadang-kadang memperbaiki satu tempat memperlihatkan kemacetan baru.

Saya ingin berbagi pengalaman kami dengan AWS. Kami menggunakan aplikasi kami di EC2 dan menghadapi masalah yang sama dan juga biaya tinggi. Kami menggunakan aplikasi Amazon EC2 Container Service kami meskipun aplikasi kami monolitik, tetapi kami berhasil

• Ketersediaan
• Hemat Biaya
• Skalabilitas

Penyeimbang beban aplikasi akan menangani lalu lintas dan akan merutekan lalu lintas ke contoh yang sehat dan Anda dapat menjalankan beberapa tugas layanan yang sama tanpa khawatir meningkatkan dan menyeimbangkan beban.

Arsitektur ini membuatnya lebih mudah untuk mengimplementasikan isolasi kegagalan. Teknik seperti pemeriksaan kesehatan, caching, bulkhead, atau pemutus sirkuit memungkinkan Anda untuk mengurangi radius ledakan komponen yang gagal dan untuk meningkatkan ketersediaan keseluruhan aplikasi yang diberikan.

Ini sangat tergantung pada arsitektur spesifik, tetapi misalnya:

• Muat di depan situs web Anda dengan CloudFront untuk mengurangi beban pada host
• Gunakan layanan hosting sisi klien dalam sesuatu seperti S3 untuk skala
• Elastic Load Balancer dengan grup Autoscaling