Saya baru-baru ini memutuskan untuk bereksperimen dengan API di situs web CardGames.io kami dan mencoba kerangka Serverless . Selama beberapa tahun terakhir, ini telah menjadi topik hangat di dunia teknologi, dan saya menunda-nunda. Saya ingin terus memperbarui keterampilan teknis saya dan mencoba sesuatu yang baru. Oleh karena itu, saya memutuskan untuk menghabiskan beberapa jam mempelajari Serverless dan melihat apakah ada arti dalam penempatan API semacam itu.

Konfigurasi saat ini

CardGames.io berjalan pada AWS. Semua halaman html, CSS, JavaScript dan gambar disimpan dalam S3. Kami memiliki C # API yang di-host di Elastic Beanstalk, ini berjalan pada server Linux yang menjalankan .NET Core with Docker. Akhirnya, kami menggunakan CloudFront CDN sebelum statika pada S3 dan API. Di bawah ini adalah skor EC2 untuk Agustus 2019. Kami memiliki beberapa contoh lain, tetapi API bekerja pada m1.small (ya, t2.small mungkin bekerja lebih baik) dengan load balancing klasik. Jika Anda meringkas yang disorot dalam warna merah, maka $ 164,21 sebulan keluar, tidak buruk. Saya bahkan memasukkan EBS di sana, karena saya tidak yakin bagaimana cara memecah biaya ini, kami memiliki beberapa proyek di EC2.


Akun AWS untuk Elastic Beanstalk

Kami memiliki dua lingkungan dengan 1-3 contoh di masing-masing: aktif dan tidak aktif, karena penyebaran .NET Core di Docker pada AWS membutuhkan waktu beberapa menit, jadi kami melakukannya dalam lingkungan yang tidak aktif, dan kemudian mengalihkan catatan CNAME ke yang baru-baru ini digunakan. Penempatan yang lambat adalah salah satu alasan saya ingin mencoba sesuatu yang baru. Kami memiliki beberapa server dengan aplikasi node.js di Beanstalk - dan mereka disebarkan dalam hitungan detik. Saya ingin itu sama untuk API.

Beralih ke Serverless

Saya mempelajari tutorial hosting ASP.NET Web API yang sangat bagus dengan kerangka Serverless dan menemukan bahwa Anda hanya perlu menambahkan file konfigurasi sederhana, satu ketergantungan dan kelas startup kecil ke proyek API yang ada. Penyebaran memakan waktu sekitar dua puluh detik - jauh lebih baik daripada di Beanstalk. Saya pikir berkat dukungan bawaan untuk .NET Core di Lambda (namun, hanya 2.2), sementara di Beanstalk hanya didukung jika Anda menggunakan buruh pelabuhan independen. Bagaimanapun, saya senang tanpa memikirkan tentang grup penskalaan otomatis, instance maks, dan sejenisnya.

Pengujian kinerja

Serverless di AWS adalah Lambda, yang benar-benar meng-host fitur Anda, dan API Gateway Depan, yang memungkinkan Anda untuk menambahkan hal-hal seperti batas kecepatan, kunci API, dan banyak lagi. Saya meng-host fitur Lambda di wilayah us-west-2, di mana server Beanstalk berada. Kemudian saya mengonfigurasi instance CloudFront untuk merutekan permintaan dari salah satu game kami ke konfigurasi tanpa server yang baru, dan yang lainnya ke konfigurasi Beanstalk yang lama. Lalu ia meluncurkan tes sederhana pada dua URL: satu Serverless, yang lain Beanstalk. Kedua URL menggunakan API yang sama, menyimpan acara yang sama dalam database. Saya menjalankan 100 pertanyaan untuk masing-masing, berikut hasilnya:


Perbandingan kinerja

Dalam beberapa kali menjalankan, konfigurasi Serverless 15% lebih lambat (jika ada, saya menjalankannya dari Islandia, maka ping yang besar). Kecepatannya mengecewakan, tetapi tetap cukup tinggi - saya menyadari bahwa ada beberapa overhead untuk bagian depan API Gateway di depan API kami: ada terlalu banyak fungsi, bahkan jika kami tidak menggunakannya. Jadi, sedih, tapi tidak kritis!

Harga

Jujur, pada awalnya saya tidak memikirkan harga. Saya baru saja memutuskan bahwa membayar untuk penggunaan aktual mungkin akan lebih murah daripada membayar untuk instance 24/7. Oleh karena itu, itu memungkinkan instalasi tanpa server baru untuk bekerja selama beberapa hari, dan kemudian mulai memeriksa akun. Ups! Tagihan untuk Lambda + API Gateway telah melebihi seratus dolar! Pada awalnya saya mulai mengotak-atik setup Lambda, mengalokasikan lebih sedikit memori untuk menyimpannya, tetapi ketika saya melihat apa yang terjadi dengan baik, menjadi jelas bahwa masalahnya ada di gateway. Berikut adalah tarif Gateway API:


Tarif API Gateway

API kami menerima sekitar 10 juta permintaan per hari. Ini sekitar $ 35 per gateway hanya setiap hari . Selain itu, biaya Lambda sekitar $ 10 per hari, meskipun ini dapat dikurangi dengan mengalokasikan lebih sedikit memori. Bersama-sama itu ternyata sekitar $ 45 per hari, atau $ 1350 per bulan , versus $ 164 per bulan di Elastic Beanstalk. Delapan kali lebih mahal ! Saya suka teknologi baru dan penyebaran cepat, tapi saya tidak akan membayar tambahan $ 1.200 per bulan untuk ini. Kembali ke Pohon Kacang!

Kesimpulan

Mungkin, saya harus membiasakan diri dengan harga di muka dan membuat beberapa perhitungan matematis! Tapi tentu saja, maka saya harus melakukan pekerjaan nyata, dan tidak belajar keterampilan teknis yang berharga! Saya yakin bahwa dalam beberapa situasi, Gateway dan Lambda API lebih baik daripada Elastic Beanstalk. Itu bukan kasus kami. Mungkin jika Anda menggunakan kunci API, batas kecepatan, dan fitur API Gateway lainnya, maka masuk akal untuk membayar $ 3,50 per juta permintaan. Kami akan lebih baik hanya menempatkan penyeimbang beban normal di depan Lambda. Sejauh yang saya tahu, ini tidak mungkin, Gateway API diperlukan untuk akses http ke Lambda.

Tetapi bahkan jika kita hanya membayar untuk Lambda, dengan $ 10 per hari itu akan menghasilkan $ 300 per bulan, bukan $ 164. Kami memiliki banyak permintaan, tetapi setiap kueri tidak banyak berpengaruh: pada dasarnya, satu panggilan DB per kueri. Mungkin pertanyaan yang lebih berat yang menggunakan lebih banyak waktu komputasi lebih cocok untuk Lambda, tempat Anda membayar waktu komputasi 100 ms. Di bawah ini adalah laporan untuk satu permintaan. Seperti yang Anda lihat, kami menggunakan waktu komputasi 3,50 ms, tetapi faktur ditetapkan untuk 100 ms, ini bukan pembulatan yang lemah.


Laporan Lambda untuk satu permintaan

Akhirnya, saya sama sekali tidak mengkritik Gateway, Lambda atau Serverless APIs. Hanya menunjukkan bahwa untuk beberapa beban kerja mereka jauh lebih mahal daripada EC2 tua dan Beanstalk yang membosankan. Tentang apa kita akan tetap. Mungkin juga ada cara yang jauh lebih baik atau lebih efisien untuk mengkonfigurasi sistem, saya sama sekali tidak ahli AWS, jadi jika Anda melihat kesalahan yang mencolok, pastikan untuk menunjukkan dalam komentar.