Realitas menjalankan aplikasi Node produksi di AWS Elastic Beanstalk

Pelajaran yang dipetik dari 2 tahun menjalankan aplikasi Node produksi di platform ELB AWS

Materi Depan

Jujur saja, kalkulator harga AWS membingungkan. Sebagian karena metode pembayaran a la carte yang ditawarkan AWS. Hal ini membuat upaya memberikan penawaran yang bagus kepada klien menjadi sulit. Semoga artikel ini dapat memberikan penjelasan tentang berapa biaya untuk menjalankan aplikasi, serta beberapa cara untuk mengurangi biaya.

Biaya Nyata Menjalankan Aplikasi

Saya telah mengelola aplikasi web node di ELB selama sekitar dua tahun sekarang. Tahun pertama sangat bagus, mereka memberi Anda segalanya secara gratis (kebanyakan)! Setelah itu, Anda harus mulai membayar hal-hal, seperti instans EC2.

Artikel ini akan berfokus pada persyaratan aplikasi khusus saya, yang merupakan aplikasi ekspres berbasis node yang dihosting di Elastic Beanstalk.

Untuk detail lengkap tentang build, lihat artikel saya sebelumnya di sini.

Kerusakan

Inilah yang saat ini saya jalankan di AWS:

Lingkungan EBS Tunggal (Wilayah Barat AS):

  • 1 Penyeimbang Beban Klasik
  • 1 instans t2.micro EC2
  • S3 Bucket yang menyimpan gambar (7 GB pada saat penulisan)
  • 1 Route 53 Hosted Zone

$ 18 (Load Balancer) + $ 5 (EC2 dengan RI) + $ 0,50 (Route 53) + $ 0,17 (S3) + $ 0,21 (Transfer Data) = Sekitar $ 25 sebulan.

Selain itu, saya menghosting MongoDB di tempat lain, jadi jika Anda berencana menghosting DB di AWS, itu akan menimbulkan biaya tambahan. Mari kita uraikan berbagai biaya.

Load Balancer

Ini adalah bagian paling mahal dari tumpukan. Ini berharga:

  • $ 0,025 per jam Classic Load Balancer (atau sebagian jam)
  • $ 0,008 per GB data yang diproses oleh Classic Load Balancer

Artinya, jika Anda menjalankan aplikasi 24 jam sehari, biayanya kira-kira $ 18 + biaya data, setiap bulan.

Instans EC2

Instans EC2 Sesuai Permintaan lebih mahal dari yang seharusnya. Untuk menghemat uang di sini, lihat bagian di bawah ini tentang Instans EC2 yang Dicadangkan. Jika Anda bertanya-tanya, biayanya $ 8,40 untuk menjalankan jenis instans EC2 yang sama seperti yang disebutkan di atas, sesuai permintaan.

S3

Saya memiliki beberapa ember S3. Satu untuk halaman beranda statis saya, satu untuk menyimpan gambar dan satu lagi untuk menyimpan versi aplikasi. Setahu saya, ELB otomatis membuatkan untuk mengatur versi aplikasi.

S3 cukup murah, jadi saya tidak terlalu khawatir untuk mencoba mendapatkan keuntungan dari itu, tetapi ada cara untuk menghemat uang melalui sistem Glacier mereka.

Database

Saya meng-host DB MongoDB saya di mLab, yang akan segera ditiadakan. Jadi saya akan memperbarui ini ketika saya memilah berapa biaya sebenarnya setelah saya dipaksa untuk pindah ke Mongo's Atlas.

Instans EC2 yang Dicadangkan

Mari kita bicara tentang Instans Cadangan (RI). Sistem penagihan Amazon yang berbelit-belit adalah bagian yang paling membingungkan tentang mengelola apa pun di AWS. Instans Cadangan dapat mengurangi sebagian biaya, tetapi terlalu membingungkan.

Setelah banyak membaca dan berbicara dengan layanan pelanggan AWS, inilah yang saya kira.

Pertama, ada dua cara berbeda untuk melakukan reservasi di mana RI berada: Regional dan Availability Zone. Artinya Regional, khusus untuk salah satu wilayah utama, mis. us-west-2 (Oregon). Zona ketersediaan (AZ) khusus untuk zona dalam wilayah itu, misalnya us-west-2 a (Oregon).

Saya membeli RI dalam us-west-2 dan itu secara otomatis diterapkan ke instans saya yang berjalan di area itu. Jika Anda membelinya di dalam AZ, ini hanya akan berlaku untuk AZ tertentu, misalnya us-west-2a, jadi jika ELB memutar instans EC2 di us-west2b, ​​Anda kurang beruntung.

Selain itu, ada tipe RI “standar” dan “konvertibel”. Saya tidak 100% tentang apa artinya, tetapi dari apa yang saya pahami, convertible lebih fleksibel dalam hal apa Anda dapat menukarnya, tetapi lebih mahal.

Terakhir, ada tiga jenis pembayaran: No Up-front, partial Up-front, All Up-Front. Ini sangat mudah, Anda tidak perlu membayar apa pun, sebagian atau semua saat Anda memesan instans. Tidak ada keuntungan biaya, yang bisa saya lihat. Namun, sebagai akun baru, Anda kemungkinan besar tidak dapat melakukan no di muka.

Per Dukungan AWS:

Tidak Ada Instans Cadangan di Muka (RI) yang dapat menimbulkan risiko penagihan yang signifikan ke akun baru, karena merupakan kewajiban kontrak untuk membayar bulanan untuk seluruh masa RI. Karena alasan ini, akun baru dan akun yang jarang digunakan tidak dapat mendaftar untuk RI Tanpa Uang Muka hingga riwayat penagihan yang berhasil dibuat bersama kami.

Anda mungkin mengalami kesalahan ini jika Anda mencoba dan membeli no di muka.

Kesalahan: Kuota Anda saat ini tidak memungkinkan Anda untuk membeli jumlah instans cadangan yang diperlukan (Layanan: AmazonEC2; Kode Status: 400; Kode Kesalahan: ReservedInstancesLimitExceeded;)

Peringatan: Untuk alasan apa pun, diperlukan sedikit untuk contoh yang dipesan untuk "kick-in" yang berarti hari pertama setiap bulan selalu lebih mahal. Saya tidak yakin mengapa ini terjadi, tetapi jika saya mengetahuinya, saya akan memperbarui ini. Lihat grafik di bawah ini:

Poin Sakit

Ini hanya beberapa keluhan kecil tentang keseluruhan EBS, yang menurut saya akan saya sertakan sebagai tambahan pada artikel asli saya, jika Anda penasaran.

Pembaruan otomatis tidak terlalu otomatis

Versi node tidak berbaris dari versi ke versi.

Lihat langkah di bawah ini tentang cara saya mengelola perubahan versi Linux saat Node tidak berfungsi.

Menjalankan lebih dari satu lingkungan

Memiliki lingkungan pengembangan dan produksi yang berjalan pada waktu yang sama itu mudah, tetapi mahal. Faktanya, itu menggandakannya. Oleh karena itu, saya biasanya menghancurkan lingkungan dev segera setelah saya selesai.

Dokumentasi menghebohkan

AWS terlalu besar untuk kebaikannya sendiri. Itulah bagian dari mengapa saya menulis ini. Sangat sulit untuk menemukan jawaban atas kebutuhan khusus saya.

Bagaimana saya mengelola Pembaruan

Saya memiliki dua contoh terpisah dari repo Git saya yang diinstal di laptop saya. Saya punya satu untuk dev, dan satu untuk produksi.

Saya menggunakan lingkungan dev untuk, ya, berkembang! Cukup mudah. Saya menggunakan folder produksi hanya untuk tujuan menarik pembaruan dari cabang master Git, menjalankan konfigurasi webpack saya, dan menerapkannya ke server produksi.

Alasan mereka terpisah adalah karena saya dapat mempertahankan konfigurasi pohon kacang elastis yang terpisah dan tidak perlu khawatir tentang penempatan ke tempat yang salah.

Pembaruan tidak memerlukan perubahan Lingkungan Linux

Untuk pembaruan yang tidak memerlukan perubahan apa pun pada lingkungan linux, itu semudah menjalankan eb deploydi terminal. Sungguh menakjubkan dan membutuhkan waktu sekitar 10 menit untuk menyebar.

Pembaruan membutuhkan perubahan Lingkungan Linux

Kadang-kadang, Anda ingin memperbarui lingkungan Linux tetapi juga tidak dapat karena AWS sangat bodoh (saya yakin ada alasannya) dan hanya mengizinkan versi Node tertentu pada setiap build Linux. Untuk ini, ini sedikit lebih rumit, tetapi dapat diatur.

  1. Dorong ke konfigurasi produksi di bawah new env. Terakhir kali saya melakukan ini, saya baru saja membuat contoh baru melalui eb create prod-1. Ini akan melakukan apa yang diperlukan dan menerapkan aplikasi Anda ke lingkungan baru.
  2. Pastikan semua pembaruan Anda berfungsi. Tampaknya cukup jelas, tetapi ini saat yang tepat untuk memastikan tidak ada masalah dengan build baru tersebut.
  3. Pastikan env vars Anda diatur dengan benar. Ini adalah bagian dari versi sebelumnya, tetapi pastikan Anda menarik dari DB yang tepat, atau apa pun.
  4. Pastikan penyeimbang beban Anda memiliki sertifikat SSL yang sama (jika berlaku). Fakta menarik, jika Anda mencoba mengakses instance ELB di https tanpa sertifikat, itu akan gagal!
  5. Tukar instance. Terakhir, setelah semuanya terlihat bagus, ada tombol di konsol untuk menukar url instance. MUDAH MUDAH. Anda tidak perlu mengubah apa pun di Route 53, itu semua untuk Anda.

Jadi, begitulah. Bagaimana mengelola pembaruan Anda. Sangat mudah.

Pikiran Akhir

Jika Anda memiliki saran untuk membuatnya lebih murah / mudah, saya akan senang mendengarnya. Saya suka diskusi tentang alat dan opsi seperti halnya pengembang berikutnya!

Dengan itu, saya akan pergi dengan ini: Selamat membuat kode!