हमने 30 सर्वर से 2 तक कैसे स्विच किया: जाओ
जब हमने लगभग 3 साल पहले आयरनवर्कर का पहला संस्करण जारी किया था, तो इसे रूबी में लिखा गया था, और एपीआई रेल्स में लिखा गया था। कुछ समय बाद, लोड तेजी से बढ़ने लगा और हम जल्दी से अपने रूबी अनुप्रयोगों की सीमा तक पहुंच गए। संक्षेप में, हमने गो पर स्विच किया। और यदि आप विवरण जानना चाहते हैं, तो पढ़ें ...
पहला संस्करण
सबसे पहले, थोड़ा सा इतिहास: हमने आयरनवर्कर का पहला संस्करण लिखा, जिसे मूल रूप से सिंपलवॉकर कहा जाता है (बुरा नहीं है, क्या यह है?) हम अन्य कंपनियों के लिए एप्लिकेशन बनाने वाली एक परामर्श कंपनी थे, और उस समय 2 लोकप्रिय चीजें थीं: अमेज़ॅन वेब सर्विसेज और रूबी ऑन रेल्स। और इसलिए हमने रूबी और एडब्ल्यूएस पर रूबी का उपयोग करके एप्लिकेशन बनाए, और नए ग्राहकों को आकर्षित किया। हमने आयरनवर्कर को पैदा करने का कारण "खरोंच करना है जहां यह खुजली करता है।" हमारे पास उपकरणों का उपयोग करने वाले कई ग्राहक थे जो लगातार 24/7 डेटा भेजते थे और हमें इस डेटा को कुछ उपयोगी में प्राप्त करना और बदलना था। इस समस्या को हर घंटे, हर दिन और इतने पर डेटा संसाधित करने वाली अनुसूची पर भारी प्रक्रियाएं शुरू करके हल किया गया था। हमने कुछ ऐसा बनाने का फैसला किया, जिसका उपयोग हम अपने सभी ग्राहकों के लिए कर सकते हैं, बिना इसके डेटा को संसाधित करने के लिए उनमें से प्रत्येक के लिए एक अलग बुनियादी ढांचे को लगातार बढ़ाने और बनाए रखने की आवश्यकता के बिना। इस प्रकार, हमने एक "सेवा के रूप में हैंडलर" बनाया, जिसे हमने पहली बार अपने कार्यों के लिए उपयोग किया था, और फिर हमने फैसला किया कि शायद किसी और को भी इसी तरह की सेवा की आवश्यकता होगी और हमने इसे सार्वजनिक किया। इसलिए आयरनवर्कर का जन्म हुआ।
हमारे सर्वर पर प्रोसेसर का लगातार लोड होना लगभग 50-60% था। जब भार बढ़ता गया, तो हमने प्रोसेसर को लगभग 50% पर रखने के लिए अधिक सर्वर जोड़े। यह हमारे अनुकूल है जबकि हम इतने सारे सर्वरों के लिए भुगतान की गई कीमत से संतुष्ट थे। बड़ी समस्या यह थी कि हम लोड सर्ज से कैसे निपटे। लोड (ट्रैफ़िक) में अगली छलांग ने एक डोमिनोज़ प्रभाव पैदा किया, जो एक पूरे क्लस्टर को निष्क्रिय कर सकता था। लोड में ऐसी छलांग के दौरान, जो सामान्य से केवल 50% अधिक है, हमारे रेल सर्वर ने प्रोसेसर का 100% उपयोग करना शुरू कर दिया और जवाब देना बंद कर दिया। इससे लोड बैलेंसर को लगता है कि यह सर्वर क्रैश हो गया और अन्य सर्वरों के बीच लोड को फिर से विभाजित किया। और, चूंकि, दुर्घटनाग्रस्त सर्वर के लिए प्रसंस्करण अनुरोधों के अलावा, शेष सर्वरों को पीक लोड को संभालना था, आमतौर पर यह थोड़ा समय लगता था जब तक कि अगला सर्वर दुर्घटनाग्रस्त न हो जाए, जिसे फिर से बैलेंसर पूल से बाहर रखा गया था, और इसी तरह। बहुत जल्द, सभी सर्वर नीचे चले गए। इस घटना को कोलोसल क्लॉफ ** के (
+ ब्लेक मोसेरनी) के रूप में भी जाना जाता है
हमारे पास उस समय मौजूद अनुप्रयोगों के साथ इससे बचने का एकमात्र तरीका है कि हमारे सर्वर पर लोड को कम करने और चोटी के भार के लिए तैयार रहने के लिए बड़ी संख्या में अतिरिक्त क्षमताओं का उपयोग करना। लेकिन इसका मतलब था कि बड़ी रकम खर्च करना। कुछ बदलना पड़ा।
हमने इसे फिर से लिखा
हमने एपीआई को फिर से लिखने का फैसला किया। यह एक सरल समाधान था। ईमानदारी से, रूबी ऑन रेल्स में लिखा हमारा एपीआई स्केलेबल नहीं था। जावा में समान चीजों को विकसित करने के कई वर्षों के अनुभव के आधार पर, रूबी ऑन रेल्स की तुलना में बहुत कम संसाधनों का उपयोग करके बहुत अधिक कार्यभार संभाल सकता है, मुझे पता था कि हम इसे बहुत बेहतर कर सकते हैं। तो समाधान नीचे आया कि किस भाषा का उपयोग करें।
भाषा का चयन
मैं नए विचारों के लिए खुला था, क्योंकि आखिरी चीज जो मैं करना चाहता था वह जावा में वापस आ गई थी। जावा है (था?) एक अद्भुत भाषा जिसमें कई फायदे हैं, जैसे कि प्रदर्शन, लेकिन कई वर्षों तक रूबी कोड लिखने के बाद, मुझे खुशी हुई कि मैं कैसे उत्पाद कोड लिख सकता हूं। रूबी एक सुविधाजनक, समझने योग्य और सरल भाषा है।
हमने रूबी (जो आसान था) से बेहतर प्रदर्शन वाली अन्य स्क्रिप्टिंग भाषाओं को देखा, जैसे कि पायथन और जावास्क्रिप्ट / Node.s.s. हमने जेवीएम-आधारित स्काला और क्लोजर, और अन्य भाषाओं जैसे एर्लैंग (जो एडब्ल्यूएस का उपयोग करता है) और गो (गोलंग) को देखा।
जीत गए । वह प्रतिस्पर्धात्मकता भाषा का एक मौलिक हिस्सा था जो उत्कृष्ट था; मानक कर्नेल लाइब्रेरी में एपीआई बनाने के लिए आवश्यक लगभग सब कुछ था; यह कैपेसिटिव है; यह जल्दी से संकलन करता है; गो में प्रोग्रामिंग सिर्फ अच्छी है - जैसे रूबी में, और अंत में, संख्या झूठ नहीं है। प्रोटोटाइप के निर्माण और प्रदर्शन का परीक्षण करने के बाद, हमने महसूस किया कि हम बिना किसी समस्या के बड़े लोड को संभाल सकते हैं। और, टीम के साथ कुछ चर्चाओं के बाद ("सब कुछ ठीक है, Google इसका समर्थन करता है"), हमने गोलंग का उपयोग करने का फैसला किया।
जब हमने पहली बार गो की कोशिश करने का फैसला किया, तो यह एक जोखिम भरा फैसला था। एक बड़ा समुदाय नहीं था, बड़ी संख्या में खुले स्रोत परियोजनाएं नहीं थीं, उत्पादन में गो का उपयोग करने के कोई सफल मामले नहीं थे। हमें यह भी पक्का नहीं था कि अगर हमने गो को चुना तो हम प्रतिभाशाली प्रोग्रामर्स को हायर कर सकते हैं। लेकिन हमें जल्द ही एहसास हुआ कि हम सबसे अच्छे प्रोग्रामर को हायर कर सकते हैं
क्योंकि हमने गो को चुना था। हम उत्पादन में गो के उपयोग की सार्वजनिक रूप से घोषणा करने वाली पहली कंपनियों में से एक थे, और पहली कंपनी जो गोलंग मेलिंग सूची पर रिक्ति की घोषणा के बाद थी। उसके बाद, सर्वश्रेष्ठ डेवलपर्स हमारे लिए काम करना चाहते थे, क्योंकि वे गो इन वर्क का उपयोग कर सकते थे।
जाने के बाद
हमने गो पर संस्करण लॉन्च करने के बाद, हमने सर्वरों की संख्या दो कर दी (विश्वसनीयता के लिए दूसरे की अधिक आवश्यकता है)। सर्वर लोड न्यूनतम हो गया, जैसे कि कुछ भी संसाधनों का उपयोग नहीं किया। प्रोसेसर लोड 5% से कम था, और अनुप्रयोग ने रेल अनुप्रयोगों की तुलना में कई सौ केबी मेमोरी (स्टार्टअप पर) का उपयोग किया, जो कि ~ 50 एमबी (स्टार्टअप पर) की खपत थी। इसकी तुलना JVM से करें! काफी समय बीत चुका है। और तब से हमने फिर से कॉलॉज़ल क्लस्टरफ़ ** k नहीं किया।
हम तब से बहुत बड़े हो गए हैं। अब हमारे पास बहुत अधिक ट्रैफ़िक है, हमने अतिरिक्त सेवाएं (आयरनएमक्यू और आयरनकैच) लॉन्च की हैं, और अब हम ग्राहकों की जरूरतों को पूरा करने के लिए सैकड़ों सर्वरों का उपयोग करते हैं। और पूरे बैकएंड को गो पर लागू किया जाता है। रेट्रोस्पेक्ट में, गो को चुनना एक शानदार निर्णय था, क्योंकि इसने हमें बड़े उत्पादों को विकसित करने और बड़े पैमाने पर बनाने की अनुमति दी, साथ ही प्रतिभाशाली लोगों को आकर्षित किया। और, मुझे लगता है कि बनाया गया विकल्प भविष्य में हमें आगे बढ़ने में मदद करता रहेगा।
PS ट्रैविस से अनुमति के साथ अनुवाद किया गया था, और यदि आपके कोई प्रश्न हैं, तो वह और अन्य लौह ।io टीम के सदस्य उन्हें जवाब देने में प्रसन्न होंगे।