Kapan mulai berpikir tentang skalabilitas? [Tutup]

Saya memiliki masalah yang lucu tetapi juga mengerikan. Saya akan meluncurkan aplikasi (iPhone) baru. Ini adalah permainan multipemain berbasis giliran yang berjalan di backend kustom saya sendiri. Tapi saya takut untuk memulai.

Untuk beberapa alasan, saya pikir itu mungkin menjadi sesuatu yang besar dan popularitasnya akan membunuh server tunggal saya yang miskin + database MySQL.

Di satu sisi saya berpikir bahwa jika itu tumbuh, saya lebih baik bersiap dan memiliki infrastruktur yang skalabel sudah ada.

Di sisi lain saya merasa ingin mengeluarkannya ke dunia dan melihat apa yang terjadi.

Saya sering membaca hal-hal seperti "optimisasi prematur adalah akar dari semua kejahatan" atau orang-orang mengatakan bahwa Anda harus membangun game pembunuh Anda sekarang, dengan alat di tangan, dan khawatir tentang hal-hal lain seperti skalabilitas nanti.

Saya ingin mendengar beberapa pendapat tentang ini dari para ahli atau orang yang berpengalaman dengan ini. Terima kasih!

Ini sebenarnya pilihan yang cukup mudah.

Saat ini, Anda memiliki nol pengguna, dan skalabilitas bukan masalah.

Idealnya, Anda ingin mencapai titik di mana Anda memiliki jutaan pengguna, dan skalabilitas menjadi masalah.

Saat ini, Anda tidak memiliki masalah skalabilitas; Anda memiliki sejumlah masalah pengguna. Jika Anda mengerjakan masalah skalabilitas, Anda tidak akan memperbaiki masalah jumlah pengguna, yang berarti Anda akan menyelesaikan masalah yang belum Anda miliki, dan Anda tidak akan menyelesaikan masalah yang Anda miliki. Hasil yang paling mungkin adalah bahwa produk Anda tidak akan berhasil, dan semua pekerjaan Anda akan sia-sia.

Jika Anda mengerjakan masalah jumlah pengguna, Anda akan memecahkan masalah yang Anda miliki sekarang, dan kemudian Anda bisa fokus pada masalah berikutnya, yang mungkin skalabilitas.

Yang menyenangkan tentang masalah skalabilitas adalah bahwa, menurut definisi, memilikinya biasanya berarti bisnis sangat bagus, dan ini pada gilirannya berarti Anda mampu mengeluarkan uang untuk mengoptimalkan skalabilitas. Anda tidak beralih dari nol pengguna menjadi sepuluh juta dalam semalam, dan jika Anda mengawasi kinerja sistem, Anda akan memiliki banyak waktu untuk mengoptimalkan ketika saatnya tiba.

Tentu saja membantu untuk menjaga skalabilitas dalam pikiran saat menulis kode yang Anda butuhkan saat ini, tetapi itu tidak masuk akal untuk menghabiskan puluhan atau bahkan ratusan jam kerja pada fitur yang Anda tidak tahu jika Anda akan membutuhkannya, dan skenario yang paling mungkin adalah Anda tidak akan melakukannya. Saat ini, perhatian utama Anda adalah mengirim. Apa yang terjadi setelah itu; yah, Anda bisa khawatir tentang itu nanti.

Tidak ada alasan untuk mengoptimalkan hingga Anda tahu bahwa optimasi diperlukan. Bagaimana Anda tahu optimasi diperlukan? Anda mengukur.

Dengan anggapan bahwa server Anda memiliki semacam antarmuka berbasis web, Anda dapat mensimulasikan banyak pengguna dengan menggunakan alat-alat seperti Apache JMeter . Pelajari cara menggunakan alat ini, lalu mulailah menguji stres back-end Anda. Anda harus bisa belajar cukup banyak untuk mengetahui apa batasannya untuk sistem Anda. Anda kemudian dapat menggabungkan informasi itu dengan jumlah pengguna yang Anda miliki dan jumlah rata-rata yang berjalan pada satu waktu, untuk memutuskan kapan untuk meningkatkan.

TL; DR Anda harus memikirkan skalabilitas sebelum baris pertama kode ditulis.

Hal pertama yang pertama. Scalabilty! = Optimasi

Anda harus memikirkan skalabilitas sebelum baris kode pertama ditulis. Ini tidak berarti Anda membangun beberapa infrastruktur besar jika game Anda sukses. Berpikir tentang skalabilitas berarti:

• Memastikan kode ditulis sehingga skala. Saya telah melihat banyak proyek di mana tidak ada pemikiran untuk perlu skala. Hasilnya adalah basis kode yang tidak akan skala terlepas dari perangkat keras yang Anda lemparkan, atau terlalu mahal untuk skala.
• Cari tahu strategi penskalaan Anda. Buat rencana tentang bagaimana mendukung semua pengguna. Anda memiliki MySQL db, apakah Anda akan shard atau cluster, atau yang lainnya. Strategi seperti sharding memerlukan beberapa pemikiran karena menempatkan persyaratan pada arsitektur. Clustering, kurang begitu. Apakah Anda mendukung sesi, dan bagaimana sesi akan bereaksi dengan beberapa server front end. Apakah Anda perlu sesi lengket, di load balancer Anda.
• Mencari tahu strategi implementasi. Apakah Anda akan menggunakan AWS untuk penskalaan. Bisakah Anda memanfaatkan produk atau layanan apa pun yang memberi Anda penskalaan dinamis di luar kotak? Ini juga melibatkan memahami biaya Anda.

TAPI sepertinya Anda sudah memiliki basis kode. Pertanyaannya sekarang adalah kapan harus memulai penskalaan. Ini sepenuhnya tergantung pada kode Anda.

Jika kode Anda cocok untuk penskalaan maka Anda telah menyelesaikan bagian yang sulit. Anda bisa mendapatkan akun AWS, memutar server yang diperlukan dan pergi.

Jika kode Anda tidak skala atau memiliki kemacetan maka Anda harus bekerja. Anda perlu mengidentifikasi apa hambatan Anda dan memperbaikinya. "Kapan" itu benar-benar sulit diketahui. Beberapa layanan dataran tinggi, beberapa naik dengan mantap, dan beberapa meledak. Memutuskan kapan harus membuang sumber daya pada sesuatu seperti penskalaan biasanya merupakan fungsi bisnis dan evaluasi risikonya.

Di posisi Anda , saya mungkin merilis sebagai "beta" dan mengelola harapan pengguna. Dengan begitu saya bisa mengeluarkan produk, dan melihat bagaimana produk itu dibuka.

Jadi, ada dua kali Anda harus memikirkan skalabilitas.

Pertama, itu harus dipertimbangkan dengan lembut sebelum Anda menulis satu baris kode. Ini untuk memastikan Anda tidak menulis diri Anda sendiri ke dalam lubang skalabilitas dan untuk memastikan kode Anda diinstrumentasi untuk memberi Anda pengukuran yang Anda butuhkan untuk kedua kalinya.

Waktu kedua untuk mempertimbangkan skalabilitas adalah cukup banyak kemajuan hal menjadi lambat tidak dapat diterima. Itu berarti Anda perlu tahu apa artinya "terlalu lambat" dan bagaimana hal Anda bereaksi di bawah beban. Jika Anda memiliki layanan yang drivernya (mungkin qps) meningkat sebesar N% per bulan, Anda memiliki waktu yang agak berbeda dari "95% sumber daya mesin yang dikonsumsi" jika penggunaan sumber daya Anda adalah kuadrat-beban atau linear dalam beban.

Dengan permainan berbasis giliran, Anda harus memiliki margin keselamatan yang layak (Anda mungkin tidak memiliki dunia permainan tunggal, dan jika Anda melakukannya, mungkin ada geometri internal, yang berarti Anda tidak memiliki "semua orang saling berinteraksi dengan setiap orang turn "masalah).

Tanpa mengetahui secara spesifik, saya perlu satu atau dua hari untuk memikirkan di mana Anda memiliki masalah penskalaan dan strategi apa yang Anda miliki untuk menyelesaikannya. Tapi, ini penting, Pikirkan. Tidak, hanya berpikir (dan mendokumentasikan). Kecuali Anda memiliki masalah skalabilitas yang mulai bermanifestasi pada beberapa ratus pengguna, maka Anda harus punya waktu untuk memeriksa beban dan memutar lebih banyak sumber daya back-end.

Dari uraian Anda, sepertinya ada dua hasil yang mungkin:

• Gim ini gagal dan Anda tidak peduli.
• Permainan ini berhasil dan kemudian backend Anda tidak akan mampu menangani beban dan hasilnya akan gagal.

Hmmm.

Berikut beberapa pertanyaan untuk Anda tanyakan pada diri sendiri:

• Berapa banyak pengguna yang dapat menangani backend Anda saat ini dengan kinerja yang dapat diterima?
• Apakah Anda memiliki semacam rencana untuk membatasi dampaknya kepada pengguna saat ini jika Anda melihat semacam pertumbuhan yang cepat (mis. Menarik game untuk sementara waktu dari app store)
• Seberapa cepat Anda bisa mendapatkan backend yang lebih baik jika Anda berhasil?
• Apa implikasi bisnis dari menunggu. Bisakah Anda memberi makan diri sendiri? Apa risikonya?
• Apa implikasi bisnis dari rilis sekarang diberikan jawaban atas pertanyaan di atas.

Jawaban atas pertanyaan Anda harus jelas setelah Anda mempertimbangkannya. Tidak ada ahli yang dapat memberi tahu Anda apa yang harus dilakukan tanpa informasi lebih lanjut karena setiap sistem berbeda dan setiap bisnis berbeda.

Server Anda akan digunakan secara interaktif oleh pengguna. Ini berarti bahwa latensi memengaruhi pengalaman pengguna dengan cara yang sangat mendalam. Latensi buruk selalu menghasilkan pengalaman pengguna yang buruk.

Setidaknya lakukan beberapa pengujian beban ad-hoc seperti yang dijelaskan oleh Bryan.

Pendekatan yang lebih serius

Lakukan beberapa simulasi berjalan dan cari tahu apa yang latensi lakukan untuk pengalaman pengguna Anda (baik menggunakan simulasi penundaan jaringan atau hanya tidur () di dalam aplikasi Anda). Cari tahu pada latensi apa yang terlihat, menjengkelkan, dan tidak dapat digunakan.

Kemudian datang langkah pertama ke arah optimalisasi. Tentukan SLA untuk server Anda: mis. Pada 10% panggilan terburuk dengan latensi yang mengganggu dan 1% panggilan dengan latensi yang tidak dapat digunakan. Dengan batas-batas itu, Anda dapat menggunakan pengujian beban untuk mengetahui berapa banyak pengguna yang dapat didukung server Anda.

Pengujian throughput murni tanpa mengukur latensi (atau setidaknya secara manual menggunakan server selama uji beban) tidak begitu berguna karena tidak memberi tahu Anda apakah angka throughput yang diukur menghasilkan pengalaman pengguna yang dapat ditanggung.

Presentasi yang sangat bagus tentang pengukuran latensi oleh Gil Tene: http://www.infoq.com/presentations/latency-pitfalls

Pada tahap persyaratan bisnis, yang kemudian digunakan untuk membangun pemahaman bersama tentang kinerja untuk semua elemen hilir seperti arsitektur, ops, pengembangan, QA dan pemantauan di prod. Jika Anda tidak membangun pemahaman bersama untuk apa yang diperlukan di muka maka Anda akan meminta masing-masing bagian organisasi membuat asumsi tentang kinerja (atau tidak memikirkannya sama sekali) ketika terlibat dalam tugas-tugas tertentu di seluruh siklus hidup perusahaan. aplikasi. Ini benar apakah Anda terlibat dalam air terjun, air terjun pendek, lincah atau apa pun metodologi pengembangan saat ini panas di daftar kata kunci resume.

Kinerja dan skalabilitas sulit. Fungsionalitas mudah. Kode penskalaan yang buruk akan tumbuh untuk mengisi kumpulan sumber daya apa pun yang Anda berikan padanya, jadi menggeser gelembung biaya dengan membeli perangkat keras yang lebih besar hanya akan membawa Anda sejauh ini sebelum Anda harus memperbaiki kode yang tidak efisien atau membeli lebih banyak perangkat keras. Meninggalkan ini untuk bertahan dalam prioritas juga sangat mahal. Ada arsitektur dan keputusan desain yang dibuat awal dalam siklus hidup aplikasi yang mungkin harus sepenuhnya terbalik untuk mencapai persyaratan kedatangan terlambat terkait dengan kinerja - Pikirkan manufaktur mobil sport performa tinggi harus beralih dari aluminium ke serat karbon terlambat dalam siklus desain untuk mencapai rasio daya / berat terkait dengan kinerja dan bagaimana hal ini berdampak pada perkakas, pelatihan, konstruksi mobil, dll ...

Tanyakan kepada arsitek, pengembang dan ops orang di organisasi Anda apa persyaratan kinerja untuk aplikasi. Jika ini tidak diambil dari bisnis maka jangan kaget jika Anda menerima jawaban yang berbeda (atau tidak ada jawaban) dari individu yang berbeda bahkan dalam kelompok yang sama. "Asumsi" itu selalu kembali menampar organisasi dalam penyebaran.