कैसे आठ लोग एक हाईलोड प्रोजेक्ट को स्केल करते हैं। अनुभवहीन अनुभव

फोटो: एलेक्स स्मिथ | Unsplash

शुभ दोपहर

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

Unsplash विकास में सबसे मजेदार चीजों में से एक उत्पाद का सरासर पैमाने और लोकप्रियता है।

एक विशिष्ट दिन पर, हमारी एपीआई unsplash.com से 10 मिलियन से अधिक अनुरोधों और तीसरे-पक्षीय अनुप्रयोगों के हजारों प्रोसेस करती है, लाखों घटनाएं हमारे डेटा प्रोसेसिंग पाइपलाइन से गुजरती हैं, 60 मिलियन अपडेट हमारे फीड में जुड़ जाते हैं, और हम 60 मिलियन छवियों की सेवा करते हैं।

उसी समय, हमारी टीम अपेक्षाकृत छोटी है: दो डिजाइनर, फ्रंटएंड के साथ काम करने वाले तीन लोग, बैकएंड के साथ दो और एक डेटा इंजीनियर। हमारे पास एक अलग DevOps इंजीनियर नहीं है, और प्रत्येक टीम का सदस्य अपना अधिकांश समय उत्पाद के आगे के विकास को सुनिश्चित करने के लिए नई सुविधाओं का प्रयोग और विकास करने में खर्च करता है।

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

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

1. उबाऊ स्पष्ट समाधान का उपयोग करें

या व्यावहारिक हो।

एक नया उपकरण, एक डेटाबेस (RethinkDB, RocksDB, आदि) की शुरूआत पर शुरू करने से पहले, एक नया पैटर्न ("सब कुछ कार्यात्मक है!"), या एक नया आर्किटेक्चर ("माइक्रोसोर्सेज, हेल्प!"), सभी स्पष्ट विकल्पों का प्रयास करें।

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

2. उपयोगकर्ता की समस्याओं को सुलझाने पर ध्यान दें, न कि प्रौद्योगिकी पर

Unsplash एक उत्पाद है, न कि एक प्रौद्योगिकी कंपनी। हमने निवेशकों से बहुत पैसा प्राप्त किया, ताकि हमारे उत्पादों और बाजार की समस्याओं को हल करने पर ध्यान केंद्रित किया जा सके, बजाय इसके कि आम प्रौद्योगिकियों के उपयोग के लिए परिचालन लागत में तीन प्रतिशत की कमी लाने की कोशिश की जाए।
हम अपना समय तैयार तकनीकों का उपयोग करने में बिताते हैं जो हमारे उपयोगकर्ताओं की समस्याओं को हल करने में मदद करेगा और अनस्प्लैश समुदाय को बढ़ाएगा। ये अनस्प्लैश के लिए अद्वितीय कार्य हैं, और यदि हम कुछ नया और मूल्यवान बनाने में सफल होते हैं, तो हम अनुकूलन को बाद की तारीख तक स्थगित कर सकते हैं, जब ये 3% अनुकूलन विकास का मुख्य स्रोत बन सकते हैं।

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

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

3. तकनीकी समस्याओं को हल करने पर पैसा खर्च करना

उत्पाद के मुद्दों पर फ़्लिप पक्ष ऑफ़-द-शेल्फ प्रौद्योगिकियों और तृतीय-पक्ष सेवाओं तक पहुंच की अतिरिक्त लागत है।

यह हमारी टीम के अंदर एक मजाक बन गया। वे कहते हैं कि किसी भी समस्या पर मेरी पहली प्रतिक्रिया सवाल होगी: "क्या आपने इसे पैसे से हल करने की कोशिश की है?"। लेकिन यह एक मजाक नहीं है, बल्कि समस्याओं को हल करने के लिए मेरे पसंदीदा दृष्टिकोणों में से एक है।

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

जब हम तकनीकी समस्याओं को हल करने पर पैसा खर्च करते हैं, तो हम टीम के हाथों को खोल देते हैं, जिससे वर्तमान तिमाही में आवर्ती जटिल समस्याओं पर ध्यान केंद्रित करने की अनुमति मिलती है जैसे कि वर्तमान तिमाही में उपयोगकर्ता आधार का आकार 40% तक बढ़ाने का तरीका।

---

तो, ये तीन काफी सरल, लेकिन सार सिद्धांत हैं जिनका हम पालन करते हैं।

लेकिन वे अभ्यास में क्या दिखते हैं?

यदि आप अनप्लाश वास्तुकला को देखते हैं, तो आप देखेंगे कि यह बहुत सरल और लगभग उबाऊ है (कम से कम 2017 के मानकों से)।


मुख्य भागों का एक सरलीकृत आरेख जो अनस्प्लैश करता है

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

हम आक्रामक रूप से उस कोड की मात्रा को कम करते हैं जो हम एप्लिकेशन के व्यावसायिक तर्क (चित्र में बैंगनी क्षेत्रों) के लिए लिखते हैं। इसे लिखते समय, हम सक्रिय रूप से अन्य लोगों द्वारा बनाई गई रूपरेखाओं का उपयोग करते हैं, जो अपने क्षेत्रों में विशेषज्ञों के रूप में विकसित हुए हैं, जो हमारे उपयोग के 95% मामलों में सफलतापूर्वक काम करते हैं।

हम सक्रिय रूप से उत्पादन में Redis, Elasticsearch और Postgres का उपयोग करते हैं। अतीत में, हमने अन्य डेटाबेस की कोशिश की, लेकिन हमेशा इन तीनों पर लौट आए, क्योंकि हमें यकीन है कि हम समझते हैं कि वे कैसे लोड के तहत व्यवहार करते हैं।

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

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

हम अपने स्वयं के StatsD या ELK स्टैक को तैनात करने और बनाए रखने के बजाय, Datadog , New Relic , Sentry और Logentries जैसी क्लाउड मॉनिटरिंग सेवाओं के एक पूरे सेट का उपयोग करते हैं।

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

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

हम स्वयं छवि पहचान एल्गोरिदम को प्रशिक्षित नहीं करते हैं, बल्कि इसके बजाय रिवर्स इमेज सर्च के लिए टिनई का उपयोग करते हैं और छवि मान्यता और वर्गीकरण के लिए Google विजन का उपयोग करते हैं।

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

---

साथ ही, हम अनस्प्लैश के उन हिस्सों पर ध्यान केंद्रित कर रहे हैं जो हमारी मुख्य योग्यता में सुधार प्रदान कर सकते हैं।

पिछले एक साल में, हमने रेल्स एप्लिकेशन पर रेल एपीआई, नोड.जेएस + रिएक्ट वेब एप्लिकेशन में अपनी एकल रूबी को विभाजित किया है और एक अलग डेटा एप्लिकेशन बनाया है जो हमारे सभी आंतरिक और उत्पाद मैट्रिक्स को इकट्ठा और संसाधित करता है।

इसने हमारी टीम को कार्यक्षमता बनाने की अनुमति दी जो हमारे पुराने स्टैक पर लगभग असंभव लग रही थी जिसमें केवल रेल शामिल थी। हमारे अनुप्रयोगों की समस्याओं और प्रौद्योगिकियों को साझा करने के बाद, हमारी टीम को प्रत्येक क्षेत्र में सर्वश्रेष्ठ उपकरणों का उपयोग करने का अवसर मिला:

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

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

हम प्रयोगों, नई सुविधाओं और उत्पादों की पुनरावृत्ति में तेजी लाने के लिए ग्राफकॉल पर आधारित एक नई आंतरिक एपीआई का विकास कर रहे हैं, जो एक दूसरे पर निर्भर नहीं हैं, क्योंकि हमने महसूस किया है कि डेटा, डिज़ाइन, फ्रंट-एंड और बैक-एंड टीमों के बीच समन्वय के बिना हमारा REST- आधारित API टूट जाता है - बेहतर हम इस समय को JSON में नहीं, सुविधाओं पर खर्च करेंगे।

हालांकि इन परिवर्तनों पर काम करना दिलचस्प है, हम उन्हें नहीं बनाते हैं क्योंकि हम अपने प्रोग्रामर की खुजली को बुझाना चाहते हैं, लेकिन क्योंकि यह हमारी वास्तविक समस्याओं को हल करता है जो हमें कार्यक्षमता और विकास को जल्दी देने से रोकते हैं।

मुझे लगता है कि ज्यादातर लोग जो इस जगह पर पढ़े हैं, उनके सिर में तीन निष्कर्ष हैं:

1. Unsplash बहुत सरल है, इसलिए आप इस दृष्टिकोण का उपयोग कर सकते हैं। मैं जो करता हूं वह अधिक जटिल है, इसलिए हम चीजों को अलग तरीके से करने के लिए मजबूर होते हैं।
   
2. मैं एक डेवलपर हूं। यह बहुत उबाऊ लगता है - मैं एक नई उच्च-लोड छवि मान्यता प्रणाली बनाना चाहता हूं!
   
3. कूल! मुझे परवाह नहीं है, बस मुझे सुंदर मुफ्त तस्वीरें दें जो मैं उपयोग कर सकता हूं।
   

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

निष्कर्ष संख्या 2 वाले लोग, यह इस बात पर निर्भर करता है कि आप क्या दिलचस्प पाते हैं। यदि आप प्रौद्योगिकी की सीमाओं को आगे बढ़ाना चाहते हैं, तो उस कंपनी के लिए काम करें, जिसका मिशन ऐसा करना है। उनमें से कई नहीं हैं, लेकिन ज्यादातर अन्य कंपनियां बस ऐसा नहीं करती हैं।

निष्कर्ष संख्या 3 वाले लोगों के लिए, मैं कहूंगा: "हां, यह सही है!" अंत में, यह वही है जिसके लिए हम यह सब कर रहे हैं।

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