स्केलेबिलिटी के बारे में सोचना कब शुरू करें? [बन्द है]


10

मैं एक अजीब लेकिन भयानक समस्या कर रहा हूँ। मैं एक नया (iPhone) ऐप लॉन्च करने वाला हूं। यह एक बारी आधारित मल्टीप्लेयर गेम है जो मेरे अपने कस्टम बैकएंड पर चल रहा है। लेकिन मुझे लॉन्च करने में डर लगता है।

किसी कारण से, मुझे लगता है कि यह कुछ बड़ा हो सकता है और इसकी लोकप्रियता मेरे गरीब एकल सर्वर + MySQL डेटाबेस को मार देगी।

एक तरफ मैं सोच रहा हूं कि अगर यह बढ़ रहा है, तो मैं बेहतर तरीके से तैयार हो जाऊंगा और पहले से ही एक स्केलेबल इंफ्रास्ट्रक्चर होगा।

दूसरी तरफ मुझे बस ऐसा लगता है कि इसे दुनिया में निकाल दिया जाए और देखें कि क्या होता है।

मैं अक्सर "समयपूर्व अनुकूलन सभी बुराई की जड़ है" जैसे सामान पढ़ता हूं या लोग कहते हैं कि आपको अभी अपने हत्यारे के खेल का निर्माण करना चाहिए, हाथ पर उपकरण के साथ, और बाद में स्केलेबिलिटी जैसे अन्य सामान के बारे में चिंता करना चाहिए।

मुझे इस पर विशेषज्ञों या लोगों के साथ अनुभव के साथ कुछ राय सुनना अच्छा लगेगा। धन्यवाद!


1
ऐसा लगता है कि हर कोई उस उद्धरण के पहले भाग को याद करता है: "हमें छोटी दक्षता के बारे में भूलना चाहिए, इस समय के 97% के बारे में कहना चाहिए" ... छोटी दक्षता + 97%
गाय सिरटन

इसे एक मुद्दा बनने दें, अगर इसे नहीं तोड़ा जाए तो इसे ठीक न करें। मैंने दर्जनों परियोजनाएं देखीं, जहां लोग स्केलेबिलिटी की चिंताओं से त्रस्त थे। अंदाज़ा लगाओ की क्या हुआ? कई परियोजनाओं ने इसे दरवाजे से बाहर कभी नहीं बनाया।
कोडार्ट

"इस समय के बारे में 97% का कहना है" अनुकूलन प्रक्रिया की एक समयपूर्व अनुकूलन की तरह लगता है। ;) </ मजाक>>
रोब

जवाबों:


22

यह वास्तव में काफी आसान विकल्प है।

अभी, आपके पास शून्य उपयोगकर्ता हैं, और मापनीयता कोई समस्या नहीं है।

आदर्श रूप से, आप उस बिंदु तक पहुंचना चाहते हैं जहां आपके लाखों उपयोगकर्ता हैं, और स्केलेबिलिटी एक समस्या बन जाती है।

अभी, आपको स्केलेबिलिटी की समस्या नहीं है; आपके पास उपयोगकर्ताओं की संख्या की समस्या है। यदि आप स्केलेबिलिटी की समस्या पर काम करते हैं, तो आप नंबर-ऑफ-यूज़र्स समस्या को ठीक नहीं करेंगे, जिसका अर्थ है कि आपने एक समस्या का समाधान किया होगा जो आपके पास अभी तक नहीं है, और आपके पास जो समस्या है, उसका समाधान नहीं किया जाएगा। सबसे संभावित परिणाम यह है कि आपका उत्पाद इसे नहीं बनाएगा, और आपका सारा काम कुछ नहीं होगा।

यदि आप नंबर-ऑफ़-यूज़र्स समस्या पर काम करते हैं, तो आप अभी आपके पास मौजूद एक समस्या को हल करेंगे, और फिर आप अगली समस्या पर ध्यान केंद्रित कर सकते हैं, जो स्केलेबिलिटी हो सकती है।

स्केलेबिलिटी समस्याओं के बारे में अच्छी बात यह है कि, परिभाषा के अनुसार, उनके लिए आमतौर पर इसका मतलब है कि व्यवसाय बहुत अच्छा है, और बदले में इसका मतलब है कि आप स्केलेबिलिटी के लिए अनुकूलन पर पैसा खर्च कर सकते हैं। आप रातों-रात शून्य उपयोगकर्ताओं से दस मिलियन तक नहीं जाते हैं, और यदि आप सिस्टम के प्रदर्शन पर नज़र रखते हैं, तो आपके पास समय आने पर अनुकूलित करने के लिए बहुत समय होगा।

बेशक यह आपको कोड लिखने के दौरान स्केलेबिलिटी को ध्यान में रखने में मदद करता है, जिसकी आपको अभी आवश्यकता है, लेकिन यह दर्जनों या यहां तक ​​कि सैकड़ों मानव-घंटे खर्च करने का कोई मतलब नहीं है, जिसमें से आपको पता नहीं है कि क्या आप 'कभी भी इसकी आवश्यकता होगी, और सबसे अधिक संभावना परिदृश्य यह है कि आप ऐसा नहीं करेंगे। अभी, आपकी मुख्य चिंता जहाज बनाने की है। उसके बाद क्या होता है; खैर, आप बाद में इस बारे में चिंता कर सकते हैं।


6

अनुकूलन का कोई कारण नहीं है जब तक आप जानते हैं कि अनुकूलन की आवश्यकता नहीं है। आप कैसे जानते हैं कि अनुकूलन की आवश्यकता है? तुम नाप लो।

यह मानते हुए कि आपके सर्वर में किसी प्रकार का वेब-आधारित इंटरफ़ेस है, आप ApacheMeter जैसे टूल का उपयोग करके बहुत से उपयोगकर्ताओं को अनुकरण कर सकते हैं । टूल का उपयोग करना सीखें, फिर अपने बैक-एंड पर तनाव परीक्षण शुरू करें। आपको यह जानने के लिए पर्याप्त सीखने में सक्षम होना चाहिए कि आपके सिस्टम की सीमाएं क्या हैं। तब आप उस जानकारी को जोड़ सकते हैं जो आपके पास उपयोगकर्ताओं की संख्या और औसत संख्या है जो एक समय में चल रही है, यह तय करने के लिए कि कब स्केल करना है।


6

TL; DR आपको कोड की पहली पंक्ति लिखे जाने से पहले मापनीयता के बारे में सोचना चाहिए।

पहली चीजें पहले। स्केलेबिलिटी! = अनुकूलन

कोड की पहली पंक्ति लिखे जाने से पहले आपको स्केलेबिलिटी के बारे में सोचना चाहिए। इसका मतलब यह नहीं है कि आप बंद मौके पर कुछ बड़े बुनियादी ढांचे का निर्माण करते हैं, जिससे आपका खेल हिट हो सकता है। स्केलेबिलिटी के बारे में सोचने का मतलब है:

  • यह सुनिश्चित करने के लिए कि कोड लिखा गया है, इसलिए यह तराजू है। मैंने बहुत सारी परियोजनाएँ देखी हैं जहाँ पैमाने की ज़रूरत को लेकर कोई विचार नहीं किया गया था। परिणाम एक कोडबेस हैं जो आपके द्वारा फेंके गए हार्डवेयर की परवाह किए बिना पैमाने पर नहीं होंगे, या बड़े पैमाने पर निषेधात्मक रूप से महंगे हैं।
  • अपनी स्केलिंग रणनीति देखें। सभी उपयोगकर्ताओं का समर्थन कैसे करें, इस पर एक योजना बनाएं। आपके पास एक MySQL db है, क्या आप इसे या क्लस्टर, या कुछ और करने जा रहे हैं। तीक्ष्णता जैसी रणनीतियों के लिए कुछ पूर्वाभास की आवश्यकता होती है क्योंकि यह वास्तुकला पर आवश्यकताओं को रखती है। क्लस्टरिंग, इतना कम। क्या आप सत्रों का समर्थन कर रहे हैं, और सत्र कई फ्रंट एंड सर्वर के साथ कैसे प्रतिक्रिया देंगे। क्या आपको अपने लोड बैलेंसर में स्टिकी सेशन की आवश्यकता होगी।
  • कार्यान्वयन रणनीति का चित्रण करें। क्या आप स्केलिंग के लिए AWS का उपयोग करने जा रहे हैं। क्या आप किसी भी उत्पाद या सेवाओं का लाभ उठा सकते हैं जो आपको बॉक्स से गतिशील स्केलिंग दे सकते हैं? इसमें आपकी लागतों को समझना भी शामिल है।

लेकिन ऐसा लगता है कि आपके पास पहले से ही एक कोडबेस है। अब सवाल यह है कि स्केलिंग कब शुरू की जाए। यह पूरी तरह से आपके कोड पर निर्भर है।

यदि आपका कोड खुद को स्केलिंग के लिए उधार देता है, तो आपके पास कठिन हिस्सा है। आप AWS खाता प्राप्त कर सकते हैं, आवश्यकतानुसार सर्वरों को स्पिन कर सकते हैं और दूर जा सकते हैं।

यदि आपके कोड में पैमाना नहीं है या अड़चन है तो आपके पास काम करने के लिए है। आपको यह पहचानने की जरूरत है कि आपकी अड़चनें क्या हैं और उन्हें ठीक करें। "जब" वास्तव में जानना कठिन है। कुछ सेवाओं पठार, कुछ तेजी से वृद्धि, और कुछ विस्फोट। स्केलिंग जैसी चीज़ों पर संसाधनों को फेंकने का निर्णय लेना आमतौर पर व्यापार का एक कार्य है और यह जोखिमों का मूल्यांकन है।

आपकी स्थिति में , मैं "बीटा" के रूप में जारी कर सकता हूं और उपयोगकर्ता की अपेक्षाओं को प्रबंधित कर सकता हूं। इस तरह मैं उत्पाद को बाहर निकाल सकता हूं, और देख सकता हूं कि यह कैसे सामने आता है।


5
यह भयानक सलाह है। एक नया उद्यम शुरू करने के बारे में सोचने के लिए पर्याप्त है, स्केलेबिलिटी अंतिम आइटम होना चाहिए। शीर्ष पर यह होना चाहिए कि जिस तरीके से आपने निर्माण किया है उस पर उपयोगी प्रतिक्रिया कैसे प्राप्त करें। दूसरा एक होना चाहिए कि कैसे अपने आप को एक कोने में चित्रित न करें। हालांकि इन दिनों आप आसानी से प्रति घंटे लाखों डायनामिक पेजों के लिए एक सरल डेटाबेस समर्थित वेबसाइट स्केल बना सकते हैं (मुझे पता होना चाहिए, मैंने इसे किया है)। इससे पहले कि आपका पहला उपयोगकर्ता पीछे की ओर है, चिंता करना कि डेटाबेस एक अड़चन होगी।
btilly

इस तरह के भविष्य-आधारित भविष्यवाणी को व्यावहारिक रूप से बनाने की कोशिश करने का मतलब है कि हर वर्ग में हर एक चर एक व्यक्तिगत उदाहरण नहीं, बल्कि एक संग्रह होना चाहिए। (MasterServer MasterServerCollection बन जाता है, व्यूपोर्ट एक क्लायंटडेविस में स्टोर किया गया व्यूपोर्ट कॉलेक्शन बन जाता है, एक सर्वर का SceneGraph WorldInstanceCollection हो जाता है) ... hindsight 20-20 है। यदि आप संभावित मुद्दों के बारे में बहुत आगे जानते हैं, तो आप यह सुनिश्चित कर सकते हैं कि उन समायोजन को करना आसान है। उनमे से कुछ।
कटाना ३१४

1
बहुत अच्छी बात है। पहली बड़ी अनुबंध परियोजना मुझे लगाई गई थी, किसी कारण से मैंने स्केलेबिलिटी के बारे में सोचा था, भले ही यह आवश्यकताओं में न हो। मैंने समय पर पहुंचाया और कोई समस्या नहीं थी। कुछ साल बाद सहकर्मी ने मुझे यह बताने के लिए फोन किया कि यह कितना आश्चर्यजनक था जब उन्हें सिस्टम को स्केल करने के लिए कहा गया था और मैंने जिन हिस्सों को बनाया था, वे बहुत आसान थे! लेकिन यह वर्षों बाद था, और केवल मुझे कुछ प्रशंसा प्रदान करने के लिए।
रायबरग

3

तो, स्केलिबिलिटी के बारे में दो बार सोचना चाहिए।

पहले, आपको कोड की एक पंक्ति लिखने से पहले इसे धीरे से विचार करना चाहिए। यह सुनिश्चित करने के लिए है कि आप अपने आप को एक स्केलेबिलिटी छेद में न लिखें और यह सुनिश्चित करने के लिए कि आपका कोड आपको दूसरी बार आवश्यक माप देने के लिए यंत्रीकृत है।

स्केलेबिलिटी पर विचार करने का दूसरा समय अस्वीकार्य रूप से धीमी गति से बनने वाली चीजों के अग्रिम में है। इसका मतलब है कि आपको यह जानना होगा कि "बहुत धीमी गति" का अर्थ क्या है और आपकी बात कैसे लोड के तहत प्रतिक्रिया करती है। यदि आपके पास एक ऐसी सेवा है जिसका ड्राइवर (शायद qps) प्रति माह N% की वृद्धि करता है, तो आपके पास "95% मशीन संसाधनों की खपत" से अलग-अलग समय है यदि आपके संसाधन का उपयोग लोड-स्क्वैयर या लोड में रैखिक है।

टर्न-आधारित गेम के साथ, आपके पास सुरक्षा का एक अच्छा मार्जिन होना चाहिए (आप शायद एक गेम की दुनिया में नहीं हैं, और यदि आप करते हैं, तो शायद एक आंतरिक ज्यामिति है, जिसका अर्थ है कि आपके पास "हर कोई हर किसी के साथ बातचीत नहीं करता है" बारी "समस्याओं)।

बारीकियों को जानने के बिना, मुझे यह सोचने में एक या दो दिन लगेंगे कि आपके पास समस्याएँ कहाँ हैं और उनके समाधान के लिए आपके पास क्या संभव रणनीतियाँ हैं। लेकिन, यह महत्वपूर्ण है, थिंक अबाउट। नहीं, बस सोचो (और दस्तावेज़)। जब तक आपके पास स्केलेबिलिटी की समस्या है जो कुछ सौ उपयोगकर्ताओं पर प्रकट होने लगती है, तब आपके पास लोड की जांच करने और अधिक बैक-एंड संसाधनों को स्पिन करने का समय होना चाहिए।


2

आपके विवरण से ऐसा लगता है कि दो संभावित परिणाम हैं:

  • खेल एक विफलता है और फिर आप परवाह नहीं करते हैं।
  • खेल सफल है और फिर आपका बैकएंड लोड से निपटने में सक्षम नहीं होगा और परिणाम एक विफलता होगी।

हममम।

यहाँ अपने आप से पूछने के लिए कुछ प्रश्न हैं:

  • स्वीकार्य प्रदर्शन के साथ आपके वर्तमान बैकएंड कितने उपयोगकर्ता संभाल सकते हैं?
  • क्या आपके पास वर्तमान उपयोगकर्ताओं पर प्रभाव को सीमित करने के लिए किसी प्रकार की योजना है यदि आप किसी प्रकार की तीव्र वृद्धि देख रहे हैं (उदाहरण के लिए ऐप स्टोर से खेल को अस्थायी रूप से खींच लें)
  • यदि आप सफल हैं तो आप कितनी जल्दी बेहतर बैकेंड के साथ आ सकते हैं?
  • प्रतीक्षा के व्यावसायिक निहितार्थ क्या हैं। क्या आप अपने आप को खिला सकते हैं? उसके खतरे क्या हैं?
  • अब जारी करने के व्यावसायिक निहितार्थ क्या हैं, ऊपर दिए गए प्रश्न के उत्तर दिए गए हैं।

इन पर विचार करने के बाद आपके प्रश्न का उत्तर स्पष्ट हो जाना चाहिए। कोई भी विशेषज्ञ आपको यह नहीं बता सकता है कि अधिक जानकारी के बिना क्या करना है क्योंकि हर प्रणाली अलग है और हर व्यवसाय अलग है।


1

आपके सर्वर का उपयोग उपयोगकर्ताओं द्वारा अंतःक्रियात्मक रूप से किया जाएगा। इसका मतलब यह है कि विलंबता उपयोगकर्ता-अनुभव को बहुत गहराई से प्रभावित कर रही है। खराब विलंबता का परिणाम हमेशा खराब उपयोगकर्ता-अनुभव होता है।

ब्रायन द्वारा वर्णित के रूप में कम से कम कुछ तदर्थ लोड-परीक्षण करते हैं।


अधिक गंभीर दृष्टिकोण

कुछ सिमुलेशन चलाएं और पता करें कि आपके उपयोगकर्ता-अनुभव (या तो नेटवर्क विलंब सिमुलेशन का उपयोग करके या आपके आवेदन के अंदर सिर्फ नींद) के लिए विलंबता क्या करती है। पता करें कि किस विलंबता पर ध्यान दिया जा रहा है, कष्टप्रद हो रहा है और बेकार हो रहा है।

फिर अनुकूलन की दिशा में पहला कदम आता है। अपने सर्वर के लिए एक SLA पर निर्णय लें: जैसे कि कष्टप्रद विलंबता के साथ सबसे खराब 10% कॉल और अनुपयोगी विलंबता के साथ 1% कॉल। उन सीमाओं के साथ आप यह जानने के लिए लोड-परीक्षण का उपयोग कर सकते हैं कि आपका सर्वर कितने उपयोगकर्ताओं का समर्थन कर सकता है।

विलंबता को मापने के बिना शुद्ध थ्रूपुट परीक्षण (या लोड परीक्षण के दौरान कम से कम सर्वर का उपयोग करके मैन्युअल रूप से) यह उपयोगी नहीं है क्योंकि यह आपको यह नहीं बताता है कि मापा थ्रूपुट संख्या में बीबरल उपयोगकर्ता-अनुभव का परिणाम है या नहीं।

गिल टेने द्वारा विलंबता को मापने के बारे में एक बहुत अच्छी प्रस्तुति: http://www.infoq.com/pretations/latency-pitfall


1

व्यावसायिक आवश्यकताओं के चरण में, जो तब वास्तुकला, ऑप्स, विकास, QA और उत्पादों की निगरानी जैसे सभी तत्वों के लिए प्रदर्शन के लिए एक सामान्य समझ स्थापित करने के लिए उपयोग किया जाता है। यदि आप सामने वाले की आवश्यकता के लिए एक सामान्य समझ स्थापित नहीं करते हैं, तो आपके पास संगठन के प्रत्येक भाग में प्रदर्शन के बारे में धारणाएं बनाना होगा (या उनके बारे में बिल्कुल नहीं सोचना) जब जीवन भर के विशेष कार्यों में संलग्न होते हैं आवेदन। यह सच है कि क्या आप जलप्रपात, लघु जलप्रपात, फुर्तीले या जो कुछ भी हो, विकास की कार्यप्रणाली फिर से शुरू करने वाली सूची में गर्म है।

प्रदर्शन और मापनीयता कठिन है। कार्यक्षमता आसान है। खराब स्केलिंग कोड आपके द्वारा प्रदान किए जाने वाले संसाधन पूल को भरने के लिए बढ़ेगा, इसलिए बड़े हार्डवेयर खरीदकर लागत बुलबुले को स्थानांतरित करना केवल आपको अभी तक ले जाता है इससे पहले कि आपको अक्षम कोड को ठीक करना होगा या कभी अधिक हार्डवेयर खरीदना होगा। इसे प्राथमिकता में अंतिम रूप से छोड़ना भी बहुत महंगा है। आर्किटेक्चर और डिज़ाइन निर्णय हैं जो आवेदन के जीवन चक्र में जल्दी किए जाते हैं जो प्रदर्शन से संबंधित देर से पहुंचने की आवश्यकता को पूरा करने के लिए पूरी तरह से उलट हो सकते हैं - एक उच्च प्रदर्शन स्पोर्ट्स कार के बारे में सोचें कि कार एल्यूमीनियम से स्विच करने के लिए कार्बन फाइबर डिजाइन चक्र में देरी से एक शक्ति / वजन अनुपात प्रदर्शन से संबंधित है और यह कैसे टूलींग, प्रशिक्षण, कार के निर्माण, आदि को प्रभावित करता है ...

अपने संगठन में आर्किटेक्ट, डेवलपर्स और ऑप्स लोगों से पूछें कि आवेदन के लिए प्रदर्शन आवश्यकताएं क्या हैं। यदि ये व्यवसाय से कैप्चर नहीं किए जाते हैं, तो आश्चर्यचकित न हों अगर आपको एक ही समूह के भीतर भी अलग-अलग व्यक्तियों से अलग-अलग उत्तर (या कोई जवाब नहीं) मिलते हैं। वे "धारणाएं" हमेशा तैनाती में संगठन को स्मैक देने के लिए वापस आती हैं।


"अपने संगठन में आर्किटेक्ट, डेवलपर्स और ऑप्स लोगों से पूछें ..." - सवाल में कुछ भी इंगित नहीं करता है कि यह एक संगठन के लिए है, यह सिर्फ इस लड़के का पक्ष है।
ग्राहम
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.