Bagaimana cara menghitung persyaratan server untuk aplikasi web

Saya mengembangkan backend di mana saya akan mengekspos API untuk aplikasi seluler saya. Pengguna dapat mendaftar, menambahkan produk, membagikan tautan produk melalui email / sms / di mana saja dan orang lain dapat mengkliknya dan membeli produk. Ini adalah alur kerja sederhana dari aplikasi seluler. Aplikasi ini adalah aplikasi intensif gambar yang akan memiliki unggahan dan pengambilan gambar yang akan dilakukan oleh layanan cloud pihak ketiga. JADI bagian gambar tidak ditangani oleh backend saya.

Sekarang saya dari tim pengembangan dan memiliki sedikit pengalaman di sisi server perangkat keras. Ketika saya memberikan persyaratan untuk infrastruktur, mereka memberi saya pertanyaan-pertanyaan berikut.

1. Aplikasi / Penyimpanan Throughput
2. Throughput aplikasi (Jumlah koneksi bersamaan dalam 3 bulan, 6 bulan dan 1 tahun)
3. Throughput penyimpanan (Pertumbuhan data dalam 3 bulan, 6 bulan dan 1 tahun)
4. Persyaratan HA
5. Persyaratan DR

Saya tidak yakin bagaimana cara memperkirakan 3 poin di atas. Bagaimana cara menghitung put? Saya akan memperkirakan akan ada 10.000 pengguna mendaftar pada aplikasi saya di bulan pertama di mana 5.000 akan menjadi pengguna aktif. Pada login rata-rata ke aplikasi akan ada 10 hit API per pengguna yang akan mengarah ke 5000 * 10 = 50.000 hit per bulan yang akan menjadi 1 hit API per menit, yaitu ~ 2 koneksi bersamaan di bulan pertama.

Apakah perhitungannya seperti ini? dan bagaimana cara menghitung pertumbuhan data? Apakah ini berarti, pengguna mendaftar, menciptakan produk dan jika saya totalkan ukuran basis data yang dikonsumsi untuk itu, apakah itu yang disebut pertumbuhan data?

Pertanyaan ini tampaknya menyedihkan, tetapi saya benar-benar membutuhkan bantuan dalam mencari tahu bagaimana throughput dihitung untuk persyaratan server.

Tiga poin pertama adalah perencanaan kapasitas. Organisasi ini mencoba membuat anggaran dan memprediksi untuk masa depan. Sayangnya, tidak ada cara sederhana atau diterima untuk memprediksi kinerja dan skalabilitas. Setiap aplikasi dan lingkungan berbeda. Karena itu, cara terbaik untuk menjawab ini adalah dengan mengukur.

Secara khusus:

1. Diskusikan dengan manajemen atau pemilik produk Anda apa kemungkinan pertumbuhan pengguna dan jenis-jenis pengguna yang berbeda. Jika mereka tidak tahu, tebak tetapi dokumentasikan bahwa ini adalah tebakan.
2. Buat menjalankan otomatis melalui jalur umum aplikasi Anda. Anda dapat merekam aktivitas atau memasukkan sendiri ke dalam aplikasi pengujian beban seperti JMeter .
3. Buat lingkungan pengujian yang cocok dengan perangkat keras Anda saat ini atau yang diproyeksikan. Perhatikan hal-hal seperti bandwidth, penyimpanan, SSL, pencatatan atau aspek yang sering terlupakan lainnya yang dapat memengaruhi kinerja. Mock out layanan gambar pihak ketiga jika Anda bisa, menggunakan gambar yang lebih kecil atau representatif.
4. Gunakan aplikasi pengujian beban untuk membuat yang diusulkan untuk jumlah pengguna yang diproyeksikan pada waktu yang berbeda.
5. Gunakan alat manajemen kinerja aplikasi, seperti AppDynamics atau DynaTrace , untuk mengukur kinerja dan mengidentifikasi kemacetan.

Selain persyaratan di atas, ini dapat membantu Anda:

1. Konfirmasikan lingkungan Anda mendukung pemuatan yang diminta.
2. Temukan beban maksimum yang didukung lingkungan Anda.
3. Temukan hambatan yang membatasi kinerja atau skalabilitas Anda.
4. Percobaan dengan konfigurasi berbeda untuk melihat bagaimana performanya atau skala.
5. Amati bagaimana sistem mengatasi ketika Anda memicu kegagalan.

Dua poin terakhir, persyaratan HA (ketersediaan tinggi) dan DR (pemulihan bencana, mungkin RPO (sasaran titik pemulihan) dan RTO (sasaran waktu pemulihan) ), lebih sulit diprediksi karena ini benar-benar persyaratan bisnis. Diskusikan dengan manajemen atau pemilik produk Anda kemungkinan kegagalan dan berapa biayanya untuk memitigasi atau memperbaiki . Jika Anda berdua baru dalam hal ini, berharap banyak menebak dan larut malam di pihak Anda.

Saya akan mengusulkan dasar yang lebih objektif. Buka log HTTP yang ada. Dengan asumsi ini adalah pembaruan untuk yang sudah ada di aplikasi lapangan, cukup tarik log dan periksa permintaan HTTP yang disertakan. Ini memberikan dasar objektif mutlak untuk pemodelan beban Anda alih-alih jari yang dibasahi di udara untuk menguji angin.

Juga, ingatlah dari perspektif QA. Anda tidak dapat memiliki persyaratan dan validasinya. Jadi, Anda dapat menggunakan data objektif dari log untuk membantu membangun informasi model pemuatan, tetapi seseorang dalam bisnis perlu menandatangani definisi yang sebenarnya. Mengapa? Karena Anda menyuntikkan persyaratan dalam aliran yang hingga saat ini belum tersedia untuk pengembang, arsitek, manajer platform, dll ... jika Anda gagal aplikasi, Anda ingin bisnis di belakang Anda bahwa angkanya akurat.

Apa yang bisa Anda tarik log?

• Tingkat transaksi tertinggi per jam (jumlah permintaan diblokir per jam)
• Pengguna tertinggi per jam (hitung alamat IP yang diblokir oleh jam)
• Alur Data Pengguna (Lihat tag referensi pada permintaan untuk membangun pohon permintaan sebelumnya)
• Waktu respons yang ada (jika bidang w3c diaktifkan untuk panggilan layanan web Anda). Ini dapat digunakan untuk menetapkan harapan untuk rilis di masa mendatang dengan dasar objektif untuk mencapai atau melampaui model saat ini
• Pikirkan waktu dari penundaan antara permintaan dengan IP. Anda dapat memodelkan titik sampel aktual pada waktu antara dua permintaan dengan meraih tag pengarah dan mencekal berdasarkan alamat IP untuk membuat kumpulan sampel. Anda kemudian dapat menarik statistik pada sampel-sampel itu untuk waktu berpikir min, maks, rata-rata, persentil ke-90. Heck, beberapa paket statistik bahkan akan memberi Anda fungsi yang dapat Anda masukkan angka acak untuk mendapatkan distribusi yang sesuai untuk produksi
• Jika Anda memiliki log untuk periode waktu sebelumnya, Anda dapat memproyeksikan model pertumbuhan untuk diamati versus yang diinginkan (proyeksi penjualan atau penggunaan)

Saya lebih suka Splunk untuk jenis pekerjaan ini. Untuk sebagian besar organisasi, Anda harus dapat menarik log selama 30 hari ke tingkat gratis tanpa harus khawatir tentang menyiapkan setengah lusin aplikasi yang berbeda bersama-sama seperti yang Anda lakukan dengan tumpukan ELK.

Dapatkan persyaratan yang salah dan Anda mungkin mengejar hantu rekayasa yang tidak akan pernah terjadi dalam produksi dan tidak benar-benar mengurangi risiko apa pun. Pastikan seseorang di sisi bisnis menandatangani persyaratan Anda atau Anda bisa memiliki sendiri kelebihan anggaran untuk mengejar non cacat.

Saya sangat suka pertanyaan Anda. Ini bagus. Saya tidak berpikir ada jawaban nyata untuk ini tetapi saya akan coba. Saat membuat / merancang Server baru, yang terpenting adalah memilih
Lingkungan dan Metode yang tepat. Tidak semua Lingkungan adalah scalabale, sebagian besar hanya dalam cara yang terbatas. Apa yang coba dihitung oleh Tim-Perangkat Keras adalah, jenis sistem file dan Antarmuka apa yang dapat mereka gunakan. Beberapa sistem file mudah diatur tetapi sulit diperluas. Lainnya sulit untuk diatur tetapi mudah dikelola dan diperluas.

Hal terbaik menurut saya adalah, untuk berhubungan dengan orang-orang yang menanyakan pertanyaan-pertanyaan ini kepada Anda dan menjelaskan kepada mereka mengapa Anda tidak bisa menjawabnya sekarang. Saat meluncurkan Aplikasi atau Sistem baru, tidak seorang pun dapat mengatakan bagaimana ini semua berkembang terutama ketika tidak ada Sistem lain yang dapat Anda bandingkan. Tetapi Anda memiliki pengetahuan tentang API yang Anda rancang dan "Hardware-Man" memiliki pengetahuan tentang bagaimana Lingkungan / Server-nya bekerja. Bersama-sama Anda dapat memecahkan pertanyaan ini dengan pasti.

Semoga ini bisa membantu Anda.