Badoo मध्ये फोटो संग्रहित आणि शेअर करण्यासाठी आर्किटेक्चर

आर्टेम डेनिसोव्ह ( bo0rsh201, Badoo)

Badoo ही जगातील सर्वात मोठी डेटिंग साइट आहे. आमच्याकडे सध्या जगभरात सुमारे 330 दशलक्ष नोंदणीकृत वापरकर्ते आहेत. परंतु आजच्या आमच्या संभाषणाच्या संदर्भात जे जास्त महत्त्वाचे आहे ते म्हणजे आम्ही वापरकर्त्याचे सुमारे 3 पेटाबाइट्स फोटो संग्रहित करतो. दररोज आमचे वापरकर्ते सुमारे 3,5 दशलक्ष नवीन फोटो अपलोड करतात आणि वाचन लोड सुमारे आहे प्रति सेकंद 80 हजार विनंत्या. हे आमच्या बॅकएंडसाठी बरेच काही आहे आणि कधीकधी यामध्ये अडचणी येतात.

मी या प्रणालीच्या डिझाइनबद्दल बोलेन, जे सर्वसाधारणपणे फोटो संग्रहित करते आणि पाठवते आणि मी याकडे विकसकाच्या दृष्टिकोनातून पाहीन. ते कसे विकसित झाले यावर थोडक्यात पूर्वलक्ष्य असेल, जिथे मी मुख्य टप्पे सांगेन, परंतु आम्ही सध्या वापरत असलेल्या उपायांबद्दल मी फक्त अधिक तपशीलवार बोलेन.

आता सुरुवात करूया.

मी म्हटल्याप्रमाणे, हे एक पूर्वलक्षी असेल आणि ते कुठेतरी सुरू करण्यासाठी, सर्वात सामान्य उदाहरण घेऊ.

आमच्याकडे एक सामान्य कार्य आहे, आम्हाला वापरकर्त्याचे फोटो स्वीकारणे, संग्रहित करणे आणि पाठवणे आवश्यक आहे. या फॉर्ममध्ये, कार्य सामान्य आहे, आम्ही काहीही वापरू शकतो:

• आधुनिक मेघ संचयन,
• बॉक्स्ड सोल्यूशन, ज्यापैकी आता बरेच काही आहेत;
• आम्ही आमच्या डेटा सेंटरमध्ये अनेक मशीन्स सेट करू शकतो आणि त्यावर मोठ्या हार्ड ड्राइव्हस् ठेवू शकतो आणि फोटो तिथे ठेवू शकतो.

Badoo ऐतिहासिकदृष्ट्या - आता आणि नंतर दोन्ही (जेव्हा तो अगदी बाल्यावस्थेत होता) - त्याच्या स्वतःच्या सर्व्हरवर, आपल्या स्वतःच्या DC मध्ये राहतो. म्हणून, हा पर्याय आमच्यासाठी इष्टतम होता.

आम्ही नुकतीच अनेक मशीन घेतली, त्यांना "फोटो" म्हटले आणि आम्हाला एक क्लस्टर मिळाला जो फोटो संग्रहित करतो. पण काहीतरी चुकल्यासारखं वाटतंय. हे सर्व कार्य करण्यासाठी, आम्ही कोणत्या मशीनवर कोणते फोटो संग्रहित करू हे कसे तरी ठरवावे लागेल. आणि इथेही अमेरिका उघडायची गरज नाही.

आम्ही आमच्या स्टोरेजमध्ये वापरकर्त्यांच्या माहितीसह काही फील्ड जोडतो. ही शार्डिंग की असेल. आमच्या बाबतीत, आम्ही याला place_id म्हणतो, आणि हा प्लेस आयडी वापरकर्त्याचे फोटो जिथे संग्रहित केले जातात त्या ठिकाणाकडे निर्देश करतो. आम्ही नकाशे बनवतो.

पहिल्या टप्प्यावर, हे व्यक्तिचलितपणे देखील केले जाऊ शकते - आम्ही म्हणतो की अशा ठिकाणी असलेल्या या वापरकर्त्याचा फोटो अशा सर्व्हरवर येईल. या नकाशाबद्दल धन्यवाद, वापरकर्ता फोटो केव्हा अपलोड करतो, तो कुठे सेव्ह करायचा आणि तो कुठून द्यायचा हे आम्हाला नेहमीच माहीत असते.

ही एक अगदी क्षुल्लक योजना आहे, परंतु तिचे बरेच महत्त्वपूर्ण फायदे आहेत. पहिली गोष्ट म्हणजे, मी म्हटल्याप्रमाणे हे सोपे आहे आणि दुसरे म्हणजे या पद्धतीमुळे आपण सहजपणे नवीन गाड्या वितरित करून आणि नकाशावर जोडून क्षैतिज मापन करू शकतो. तुम्हाला दुसरे काही करण्याची गरज नाही.

काही काळ आमचं असंच होतं.

हे 2009 च्या आसपास होते. त्यांनी कार वितरीत केल्या, वितरण केले ...

आणि कधीतरी आमच्या लक्षात येऊ लागलं की या योजनेचे काही तोटे आहेत. तोटे काय आहेत?

सर्व प्रथम, मर्यादित क्षमता आहे. आम्ही एका भौतिक सर्व्हरवर आम्हाला पाहिजे तितक्या हार्ड ड्राइव्हस् क्रॅम करू शकत नाही. आणि कालांतराने आणि डेटासेटच्या वाढीसह ही एक विशिष्ट समस्या बनली आहे.

आणि दुसरा. ही मशीन्सची एक असामान्य संरचना आहे, कारण अशा मशीन्स इतर काही क्लस्टरमध्ये पुन्हा वापरणे कठीण आहे; ते अगदी विशिष्ट आहेत, म्हणजे. ते कार्यक्षमतेत कमकुवत असले पाहिजेत, परंतु त्याच वेळी मोठ्या हार्ड ड्राइव्हसह.

हे सर्व 2009 साठी होते, परंतु, तत्त्वतः, या आवश्यकता आजही संबंधित आहेत. आमच्याकडे पूर्वलक्ष्य आहे, म्हणून 2009 मध्ये यासह सर्व काही पूर्णपणे वाईट होते.

आणि शेवटचा मुद्दा म्हणजे किंमत.

त्यावेळी किंमत खूप वाढलेली होती आणि आम्हाला काही पर्याय शोधण्याची गरज होती. त्या. डेटा सेंटर्समधील जागा आणि हे सर्व ज्या भौतिक सर्व्हरवर आहे त्या दोन्हींचा अधिक चांगल्या प्रकारे उपयोग करणे आम्हाला आवश्यक आहे. आणि आमच्या सिस्टम अभियंत्यांनी एक मोठा अभ्यास सुरू केला ज्यामध्ये त्यांनी विविध पर्यायांचे पुनरावलोकन केले. त्यांनी पॉलीसेफ आणि लस्टर सारख्या क्लस्टर केलेल्या फाइल सिस्टमकडे देखील पाहिले. कार्यप्रदर्शन समस्या आणि जोरदार कठीण ऑपरेशन होते. त्यांनी नकार दिला. आम्ही संपूर्ण डेटासेट NFS द्वारे प्रत्येक कारवर माउंट करण्याचा प्रयत्न केला जेणेकरून ते कसेतरी मोठे होईल. वाचन देखील खराब झाले, आम्ही वेगवेगळ्या विक्रेत्यांकडून वेगवेगळ्या उपायांचा प्रयत्न केला.

आणि शेवटी, आम्ही तथाकथित स्टोरेज एरिया नेटवर्क वापरण्यावर सेटल झालो.

हे मोठे SHD आहेत जे विशेषतः मोठ्या प्रमाणात डेटा संचयित करण्यासाठी डिझाइन केलेले आहेत. ते डिस्कसह शेल्फ आहेत जे अंतिम ऑप्टिकल आउटपुट मशीनवर आरोहित आहेत. ते. आमच्याकडे काही प्रकारच्या मशीन्सचा पूल आहे, अगदी लहान, आणि हे SHD, जे आमच्या पाठवण्याच्या तर्कानुसार पारदर्शक आहेत, म्हणजे. आमच्या nginx किंवा इतर कोणालाही या फोटोंच्या विनंत्या देण्यासाठी.

या निर्णयाचे स्पष्ट फायदे होते. हे SHD आहे. हे फोटो संग्रहित करण्याचा उद्देश आहे. हार्ड ड्राइव्हसह मशीन सुसज्ज करण्यापेक्षा हे स्वस्त आहे.

दुसरा प्लस.

हे असे आहे की क्षमता खूप मोठी झाली आहे, म्हणजे. आम्ही खूप कमी व्हॉल्यूममध्ये जास्त स्टोरेज सामावून घेऊ शकतो.

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

आमच्या फोटोंप्रमाणेच, कारण फोटोंची विनंती विसंगतपणे केली जाते आणि यामुळे त्यांच्या कार्यक्षमतेवर मोठ्या प्रमाणात परिणाम होईल.

आजच्या आकडेवारीनुसार, स्टोरेज कनेक्ट केलेल्या मशीनवर फोटोंसाठी 500 पेक्षा जास्त RPS मिळाल्यास, समस्या आधीच सुरू होतात. आणि हे आमच्यासाठी पुरेसे वाईट होते, कारण वापरकर्त्यांची संख्या वाढत आहे, गोष्टी फक्त वाईट होणार आहेत. हे कसे तरी ऑप्टिमाइझ करणे आवश्यक आहे.

ऑप्टिमाइझ करण्यासाठी, आम्ही त्या वेळी निश्चितपणे लोड प्रोफाइल पाहण्याचा निर्णय घेतला - काय, सर्वसाधारणपणे, काय होत आहे, काय ऑप्टिमाइझ करणे आवश्यक आहे.

आणि येथे सर्वकाही आपल्या हातात खेळते.

मी पहिल्या स्लाइडमध्ये आधीच सांगितले आहे: आमच्याकडे प्रति सेकंद 80 हजार वाचन विनंत्या आहेत आणि दररोज फक्त 3,5 दशलक्ष अपलोड आहेत. म्हणजेच, हा परिमाणाच्या तीन क्रमांचा फरक आहे. हे उघड आहे की वाचन ऑप्टिमाइझ करणे आवश्यक आहे आणि ते कसे ते व्यावहारिकदृष्ट्या स्पष्ट आहे.

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

त्या. आमच्याकडे खूप लहान हॉट डेटासेट आहे. पण त्याच वेळी त्याच्यासाठी खूप विनंत्या आहेत. आणि येथे एक पूर्णपणे स्पष्ट उपाय म्हणजे कॅशे जोडणे.

LRU सह कॅशे आमच्या सर्व समस्या सोडवेल. आपण काय करत आहेत?

आम्ही स्टोरेजसह आमच्या मोठ्या क्लस्टरच्या समोर आणखी एक तुलनेने लहान जोडतो, ज्याला फोटोकॅच म्हणतात. हे मूलत: फक्त एक कॅशिंग प्रॉक्सी आहे.

ते आतून कसे कार्य करते? हा आमचा वापरकर्ता आहे, येथे स्टोरेज आहे. सर्व काही पूर्वीसारखेच आहे. आम्ही दरम्यान काय जोडू?

हे फक्त एक भौतिक स्थानिक डिस्कसह एक मशीन आहे, जे वेगवान आहे. हे SSD सह आहे, उदाहरणार्थ. आणि या डिस्कवर काही प्रकारचे स्थानिक कॅशे संग्रहित केले आहे.

Как это выглядит? Пользователь посылает запрос за фоткой. NGINX ищет ее сначала в локальном кэше. Если нет, то делает просто proxy_pass на наш storage, скачивает фотографию оттуда и дает ее пользователю.

परंतु हे अतिशय सामान्य आहे आणि आत काय चालले आहे हे स्पष्ट नाही. हे असे काहीतरी कार्य करते.

कॅशे तार्किकदृष्ट्या तीन स्तरांमध्ये विभागलेला आहे. जेव्हा मी "तीन स्तर" म्हणतो, तेव्हा याचा अर्थ असा नाही की एक प्रकारची जटिल प्रणाली आहे. नाही, फाइल सिस्टममध्ये या सशर्त फक्त तीन निर्देशिका आहेत:

1. हा एक बफर आहे जिथे नुकतेच प्रॉक्सी गो वरून डाउनलोड केलेले फोटो.
2. हे एक हॉट कॅशे आहे जे सध्या सक्रियपणे विनंती केलेले फोटो संग्रहित करते.
3. आणि एक कोल्ड कॅशे, जिथे फोटो कमी विनंत्या येतात तेव्हा हळूहळू हॉट कॅशेमधून बाहेर ढकलले जातात.

हे कार्य करण्यासाठी, आम्हाला हे कॅशे कसेतरी व्यवस्थापित करणे आवश्यक आहे, आम्हाला त्यातील फोटोंची पुनर्रचना करणे आवश्यक आहे, इ. ही देखील एक अतिशय आदिम प्रक्रिया आहे.

Nginx प्रत्येक विनंतीसाठी फक्त RAMDisk access.log वर लिहितो, ज्यामध्ये तो सध्या दिलेल्या फोटोचा मार्ग सूचित करतो (सापेक्ष मार्ग, अर्थातच), आणि कोणते विभाजन दिले गेले आहे. त्या. ते "फोटो 1" आणि नंतर एकतर बफर, किंवा हॉट कॅशे, किंवा कोल्ड कॅशे किंवा प्रॉक्सी म्हणू शकते.

यावर अवलंबून, आम्हाला फोटोचे काय करायचे ते कसे तरी ठरवावे लागेल.

आमच्याकडे प्रत्येक मशीनवर एक लहान डिमन चालू आहे जो सतत हा लॉग वाचतो आणि त्याच्या मेमरीमध्ये विशिष्ट छायाचित्रांच्या वापराची आकडेवारी संग्रहित करतो.

तो तिथे फक्त गोळा करतो, काउंटर ठेवतो आणि वेळोवेळी खालील गोष्टी करतो. तो सक्रियपणे विनंती केलेले फोटो हलवतो, ज्यासाठी अनेक विनंत्या आहेत, हॉट कॅशेवर, ते कुठेही आहेत.

क्वचितच विनंती केलेले आणि कमी वेळा विनंती केलेले फोटो हळूहळू हॉट कॅशेमधून थंडीत ढकलले जातात.

आणि जेव्हा आमची कॅशेमध्ये जागा संपते, तेव्हा आम्ही कोल्ड कॅशेमधून सर्व काही बिनदिक्कतपणे हटवण्यास सुरवात करतो. आणि तसे, हे चांगले कार्य करते.

बफरवर प्रॉक्सी करताना फोटो त्वरित जतन करण्यासाठी, आम्ही proxy_store निर्देश वापरतो आणि बफर देखील एक RAMDisk आहे, उदा. वापरकर्त्यासाठी ते खूप लवकर कार्य करते. हे कॅशिंग सर्व्हरच्या अंतर्गत भागांशी संबंधित आहे.

या सर्व्हरवर विनंत्या कशा वितरित करायच्या हा उर्वरित प्रश्न आहे.

समजा वीस स्टोरेज मशीन आणि तीन कॅशिंग सर्व्हरचा क्लस्टर आहे (हे असेच घडले).

कोणत्या विनंत्या कोणत्या फोटोंसाठी आहेत आणि ते कुठे उतरवायचे हे आम्हाला कसे तरी ठरवायचे आहे.

सर्वात सामान्य पर्याय म्हणजे राउंड रॉबिन. किंवा ते अपघाताने करावे?

याचे स्पष्टपणे अनेक तोटे आहेत कारण अशा परिस्थितीत आम्ही कॅशे अतिशय अकार्यक्षमपणे वापरत असू. विनंत्या काही यादृच्छिक मशीनवर उतरतील: येथे ते कॅशे केले होते, परंतु पुढील एकावर ते आता नाही. आणि जर हे सर्व चालले तर ते खूप वाईट होईल. क्लस्टरमध्ये कमी संख्येने मशिन्स असूनही.

कोणत्या सर्व्हरवर कोणती विनंती उतरवायची हे आम्हाला कसे तरी निःसंदिग्धपणे ठरवावे लागेल.

एक सामान्य मार्ग आहे. आम्ही URL वरून हॅश किंवा URL मध्ये असलेल्या आमच्या शार्डिंग की वरून हॅश घेतो आणि सर्व्हरच्या संख्येने विभाजित करतो. चालेल? होईल.

त्या. आमच्याकडे 2% विनंती आहे, उदाहरणार्थ, काही “example_url” साठी ती नेहमी इंडेक्स “XNUMX” सह सर्व्हरवर उतरते आणि कॅशेची सतत शक्य तितक्या चांगल्या प्रकारे विल्हेवाट लावली जाईल.

परंतु अशा योजनेत रीशार्डिंगमध्ये समस्या आहे. रीशार्डिंग - म्हणजे सर्व्हरची संख्या बदलणे.

चला असे गृहीत धरू की आमचे कॅशिंग क्लस्टर यापुढे सामना करू शकत नाही आणि आम्ही दुसरे मशीन जोडण्याचे ठरवू.

जोडूया.

आता प्रत्येक गोष्ट तीनने नाही तर चारने भागली जाते. अशाप्रकारे, आमच्याकडे असलेल्या जवळजवळ सर्व कळा, जवळजवळ सर्व URL आता इतर सर्व्हरवर राहतात. संपूर्ण कॅशे फक्त एका क्षणासाठी अवैध झाले. सर्व विनंत्या आमच्या स्टोरेज क्लस्टरवर पडल्या, ते अस्वस्थ झाले, सेवा अयशस्वी आणि असंतुष्ट वापरकर्ते. मला तसे करायचे नाही.

हा पर्याय आम्हालाही शोभत नाही.

ते. आपण काय केले पाहिजे? आम्ही कसा तरी कॅशेचा कार्यक्षम वापर केला पाहिजे, त्याच सर्व्हरवर पुन्हा पुन्हा तीच विनंती केली पाहिजे, परंतु पुन्हा सामायिक करण्यास प्रतिरोधक असले पाहिजे. आणि असा एक उपाय आहे, तो इतका क्लिष्ट नाही. त्याला सातत्यपूर्ण हॅशिंग म्हणतात.

ते कशासारखे दिसते?

आपण शार्डिंग की मधून काही फंक्शन घेतो आणि त्याची सर्व व्हॅल्यू वर्तुळावर पसरवतो. त्या. बिंदू 0 वर, त्याची किमान आणि कमाल मूल्ये एकत्र होतात. पुढे, आम्ही आमचे सर्व सर्व्हर एकाच वर्तुळावर अंदाजे या प्रकारे ठेवतो:

प्रत्येक सर्व्हर एका बिंदूद्वारे परिभाषित केला जातो आणि त्याप्रमाणे घड्याळाच्या दिशेने जाणारा सेक्टर या होस्टद्वारे दिला जातो. जेव्हा आमच्याकडे विनंत्या येतात, तेव्हा आम्ही लगेच पाहतो की, उदाहरणार्थ, विनंती A - त्यात हॅश आहे - आणि ते सर्व्हर 2 द्वारे दिले जाते. B विनंती - सर्व्हर 3. आणि असेच.

रीशार्डिंग दरम्यान या परिस्थितीत काय होते?

आम्ही पूर्वीप्रमाणे संपूर्ण कॅशे अवैध करत नाही आणि सर्व कळा बदलत नाही, परंतु आम्ही प्रत्येक सेक्टर थोड्या अंतरावर हलवतो जेणेकरून, तुलनेने, आमचा सहावा सर्व्हर, जो आम्हाला जोडायचा आहे, मोकळ्या जागेत बसेल आणि आम्ही ते तिथे जोडतो.

अर्थात, अशा स्थितीत चाव्याही बाहेर जातात. पण ते पूर्वीपेक्षा खूपच कमकुवत बाहेर पडतात. आणि आम्ही पाहतो की आमच्या पहिल्या दोन की त्यांच्या सर्व्हरवर राहिल्या आणि फक्त शेवटच्या कीसाठी कॅशिंग सर्व्हर बदलला. हे बर्‍यापैकी कार्यक्षमतेने कार्य करते आणि जर तुम्ही नवीन होस्ट्स वाढीव प्रमाणात जोडले तर येथे कोणतीही मोठी समस्या नाही. तुम्ही एका वेळी थोडेसे जोडा आणि जोडा, कॅशे पुन्हा भरेपर्यंत प्रतीक्षा करा आणि सर्वकाही चांगले कार्य करते.

फक्त नकारांचा प्रश्न उरतो. चला असे गृहीत धरू की काही प्रकारची कार ऑर्डरच्या बाहेर आहे.

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

हे कॅशिंग सिस्टमबद्दल आहे. चला परिणाम पाहूया.

असे दिसते की येथे काहीही क्लिष्ट नाही. परंतु कॅशे व्यवस्थापित करण्याच्या या पद्धतीमुळे आम्हाला सुमारे 98% चा युक्ती दर मिळाला. त्या. प्रति सेकंद या 80 हजार विनंत्यांपैकी फक्त 1600 रिक्वेस्ट स्टोरेजपर्यंत पोहोचतात आणि हा पूर्णपणे सामान्य भार आहे, ते शांतपणे सहन करतात, आमच्याकडे नेहमीच राखीव असतो.

आम्ही हे सर्व्हर आमच्या तीन DC मध्ये ठेवले आणि आम्हाला तीन पॉइंट्स ऑफ प्रेझेशन मिळाले - प्राग, मियामी आणि हाँगकाँग.

ते. ते आमच्या प्रत्येक लक्ष्य बाजारपेठेत कमी-अधिक प्रमाणात स्थानिक पातळीवर स्थित आहेत.

आणि एक छान बोनस म्हणून, आम्हाला ही कॅशिंग प्रॉक्सी मिळाली, ज्यावर सीपीयू प्रत्यक्षात निष्क्रिय आहे, कारण सामग्री देण्यासाठी त्याची आवश्यकता नाही. आणि तिथे, NGINX+ Lua वापरून, आम्ही बरेच उपयुक्ततावादी तर्क लागू केले.

उदाहरणार्थ, आम्ही webp किंवा प्रगतीशील jpeg (हे प्रभावी आधुनिक स्वरूप आहेत) सह प्रयोग करू शकतो, ते रहदारीवर कसा परिणाम करते ते पाहू शकतो, काही निर्णय घेऊ शकतो, विशिष्ट देशांसाठी ते सक्षम करू शकतो, इ. डायनॅमिक आकार बदला किंवा फ्लायवर फोटो क्रॉप करा.

उदाहरणार्थ, तुमच्याकडे फोटो दाखवणारे मोबाइल अॅप्लिकेशन असते आणि मोठ्या फोटोची विनंती करताना आणि नंतर त्याचा आकार बदलून एका विशिष्ट आकारात ढकलण्यासाठी मोबाइल अॅप्लिकेशन क्लायंटचा CPU वाया घालवू इच्छित नाही तेव्हा हा एक चांगला वापर आहे. दृश्य. आम्ही UPort कंडिशनल URL मध्ये काही पॅरामीटर्स डायनॅमिकरित्या निर्दिष्ट करू शकतो आणि फोटो कॅशे फोटोचा आकार बदलेल. नियमानुसार, ते आमच्याकडे भौतिकरित्या डिस्कवर असलेला आकार निवडेल, विनंती केलेल्याच्या शक्य तितक्या जवळ असेल आणि विशिष्ट निर्देशांकांमध्ये त्याची विक्री करेल.

तसे, आम्ही हाय-लोड सिस्टमच्या विकासकांच्या कॉन्फरन्सच्या गेल्या पाच वर्षांचे व्हिडिओ रेकॉर्डिंग सार्वजनिकरित्या उपलब्ध केले आहेत. HighLoad++. पहा, शिका, शेअर करा आणि सदस्यता घ्या YouTube चॅनेल.

आम्ही तेथे बरेच उत्पादन तर्क देखील जोडू शकतो. उदाहरणार्थ, आम्ही URL पॅरामीटर्स वापरून भिन्न वॉटरमार्क जोडू शकतो, आम्ही फोटो अस्पष्ट, अस्पष्ट किंवा पिक्सेलेट करू शकतो. जेव्हा आम्हाला एखाद्या व्यक्तीचा फोटो दाखवायचा असतो, परंतु आम्हाला त्याचा चेहरा दाखवायचा नाही, तेव्हा हे चांगले कार्य करते, हे सर्व येथे लागू केले आहे.

आम्हाला काय मिळाले? आम्हाला उपस्थितीचे तीन गुण मिळाले, एक चांगला युक्ती दर आणि त्याच वेळी आमच्याकडे या मशीनवर निष्क्रिय CPU नाही. तो आता अर्थातच पूर्वीपेक्षा अधिक महत्त्वाचा झाला आहे. आम्हाला स्वतःला अधिक मजबूत कार देण्याची गरज आहे, परंतु ते फायदेशीर आहे.

हे छायाचित्रे परत करण्याशी संबंधित आहे. येथे सर्व काही अगदी स्पष्ट आणि स्पष्ट आहे. मला वाटते की मी अमेरिका शोधली नाही, जवळजवळ कोणतीही सीडीएन अशा प्रकारे कार्य करते.

आणि, बहुधा, एक अत्याधुनिक श्रोत्याला प्रश्न असू शकतो: फक्त सर्वकाही सीडीएनमध्ये का बदलू नये? हे सारखेच असेल; सर्व आधुनिक CDN हे करू शकतात. आणि अनेक कारणे आहेत.

प्रथम छायाचित्रे आहेत.

आमच्या पायाभूत सुविधांपैकी हा एक महत्त्वाचा मुद्दा आहे आणि आम्हाला त्यावर शक्य तितके नियंत्रण हवे आहे. जर हा तृतीय-पक्ष विक्रेत्याकडून काही प्रकारचा उपाय असेल आणि तुमचा त्यावर कोणताही अधिकार नसेल, तर तुमच्याकडे मोठा डेटासेट असताना आणि तुमच्याकडे खूप मोठा प्रवाह असेल तेव्हा त्याच्यासोबत राहणे तुमच्यासाठी खूप कठीण होईल. वापरकर्ता विनंत्या.

मी तुम्हाला एक उदाहरण देतो. आता, आमच्या पायाभूत सुविधांसह, आम्ही, उदाहरणार्थ, काही समस्या किंवा भूमिगत ठोठावण्याच्या बाबतीत, मशीनवर जाऊ शकतो आणि तुलनेने बोलणे, तेथे गोंधळ घालू शकतो. आम्ही काही मेट्रिक्सचा संग्रह जोडू शकतो ज्याची आम्हाला फक्त गरज आहे, आम्ही कसा तरी प्रयोग करू शकतो, याचा आलेखांवर कसा परिणाम होतो ते पाहू शकतो, इत्यादी. आता या कॅशिंग क्लस्टरवर बरीच आकडेवारी गोळा केली जात आहे. आणि आम्ही वेळोवेळी ते पाहतो आणि काही विसंगती शोधण्यात बराच वेळ घालवतो. जर ते सीडीएनच्या बाजूने असेल तर ते नियंत्रित करणे खूप कठीण होईल. किंवा, उदाहरणार्थ, जर काही प्रकारचा अपघात झाला, तर काय झाले हे आपल्याला माहित आहे, त्याच्याशी कसे जगायचे आणि त्यावर मात कशी करायची हे आपल्याला माहित आहे. हा पहिला निष्कर्ष आहे.

दुसरा निष्कर्ष देखील ऐवजी ऐतिहासिक आहे, कारण ही प्रणाली बर्याच काळापासून विकसित होत आहे, आणि वेगवेगळ्या टप्प्यांवर अनेक भिन्न व्यावसायिक आवश्यकता होत्या आणि ते नेहमी CDN संकल्पनेत बसत नाहीत.

आणि मागील एक पासून खालील मुद्दा आहे

याचे कारण असे की फोटो कॅशेवर आमच्याकडे बरेच विशिष्ट तर्क आहे, जे नेहमी विनंती केल्यावर जोडले जाऊ शकत नाही. तुमच्या विनंतीनुसार कोणतीही CDN तुम्हाला काही सानुकूल गोष्टी जोडेल अशी शक्यता नाही. उदाहरणार्थ, क्लायंटने काहीतरी बदलू नये असे तुम्हाला वाटत असल्यास URL कूटबद्ध करणे. तुम्हाला सर्व्हरवरील URL बदलून एन्क्रिप्ट करायचे आहे आणि नंतर काही डायनॅमिक पॅरामीटर्स येथे पाठवायचे आहेत.

हा कोणता निष्कर्ष सुचवतो? आमच्या बाबतीत, CDN हा फार चांगला पर्याय नाही.

आणि तुमच्या बाबतीत, तुमच्याकडे काही विशिष्ट व्यवसाय आवश्यकता असल्यास, मी तुम्हाला स्वतःला दाखवलेल्या गोष्टी तुम्ही अगदी सहजपणे अंमलात आणू शकता. आणि हे समान लोड प्रोफाइलसह उत्तम प्रकारे कार्य करेल.

परंतु आपल्याकडे काही प्रकारचे सामान्य समाधान असल्यास आणि कार्य फारसे विशिष्ट नसल्यास, आपण पूर्णपणे सुरक्षितपणे सीडीएन घेऊ शकता. किंवा जर तुमच्यासाठी वेळ आणि संसाधने नियंत्रणापेक्षा जास्त महत्त्वाची असतील.

आणि आधुनिक CDN मध्ये जवळजवळ सर्व काही आहे जे मी तुम्हाला आता सांगितले आहे. प्लस किंवा मायनस काही वैशिष्ट्यांचा अपवाद वगळता.

हे फोटो देण्याबद्दल आहे.

आता आपल्या पूर्वलक्ष्यातून थोडे पुढे जाऊया आणि स्टोरेजबद्दल बोलूया.

2013 सरत होते.

कॅशिंग सर्व्हर जोडले गेले, कार्यप्रदर्शन समस्या दूर झाल्या. सर्व काही ठीक आहे. डेटासेट वाढत आहे. 2013 पर्यंत, आमच्याकडे स्टोरेजशी सुमारे 80 सर्व्हर कनेक्ट केलेले होते आणि प्रत्येक DC मध्ये सुमारे 40 कॅशिंग सर्व्हर होते. हा प्रत्येक DC वर 560 टेराबाइट डेटा आहे, म्हणजे. एकूण सुमारे एक पेटाबाइट.

आणि डेटासेटच्या वाढीसह, ऑपरेटिंग खर्चात लक्षणीय वाढ होऊ लागली. याचा अर्थ काय होता?

काढलेल्या या आकृतीमध्ये - SAN सह, मशीन आणि कॅशे त्याच्याशी जोडलेले आहेत - अपयशाचे बरेच मुद्दे आहेत. जर आम्ही आधीपासून कॅशिंग सर्व्हरच्या अपयशाचा सामना केला असेल, तर सर्व काही कमी-अधिक अंदाजे आणि समजण्यासारखे होते, परंतु स्टोरेजच्या बाजूने सर्वकाही खूपच वाईट होते.

प्रथम, स्टोरेज एरिया नेटवर्क (SAN) स्वतः, जे अयशस्वी होऊ शकते.

दुसरे म्हणजे, ते ऑप्टिक्सद्वारे एंड मशीनशी जोडलेले आहे. ऑप्टिकल कार्ड आणि स्पार्क प्लगमध्ये समस्या असू शकतात.

अर्थात, त्यापैकी बरेच SAN सारखे नाहीत, परंतु तरीही, हे देखील अपयशाचे मुद्दे आहेत.

पुढे मशीन स्वतः आहे, जी स्टोरेजशी जोडलेली आहे. ते अयशस्वी देखील होऊ शकते.

एकूण, आमच्याकडे अपयशाचे तीन गुण आहेत.

पुढे, अयशस्वी होण्याच्या बिंदूंव्यतिरिक्त, स्टोरेजची स्वतःची मोठ्या प्रमाणात देखभाल केली जाते.

ही एक जटिल बहु-घटक प्रणाली आहे आणि सिस्टम अभियंत्यांना तिच्यासह कार्य करणे कठीण होऊ शकते.

आणि शेवटचा, सर्वात महत्वाचा मुद्दा. या तीनपैकी कोणत्याही बिंदूवर अपयश आल्यास, आमच्याकडे वापरकर्ता डेटा गमावण्याची शून्य नसलेली शक्यता आहे कारण फाइल सिस्टम क्रॅश होऊ शकते.

समजा आमची फाइल सिस्टीम तुटलेली आहे. प्रथम, त्याच्या पुनर्प्राप्तीसाठी बराच वेळ लागतो - मोठ्या प्रमाणात डेटासह एक आठवडा लागू शकतो. आणि दुसरे म्हणजे, सरतेशेवटी आम्ही बहुधा न समजण्याजोग्या फायलींचा एक समूह असू शकतो ज्यांना वापरकर्त्याच्या फोटोंमध्ये कसे तरी एकत्र करणे आवश्यक आहे. आणि आम्ही डेटा गमावण्याचा धोका असतो. धोका खूप जास्त आहे. आणि अशा परिस्थिती जितक्या जास्त वेळा घडतात आणि या संपूर्ण साखळीत जितक्या जास्त समस्या निर्माण होतात तितका हा धोका जास्त असतो.

यावर काहीतरी करायला हवे होते. आणि आम्ही ठरवले की आम्हाला फक्त डेटाचा बॅकअप घ्यायचा आहे. हे प्रत्यक्षात एक स्पष्ट उपाय आहे आणि एक चांगला आहे. आम्ही काय केले आहे?

आमचा सर्व्हर आधी स्टोरेजशी कनेक्ट होता तेव्हा असे दिसत होते. हा एक मुख्य विभाग आहे, हे फक्त एक ब्लॉक डिव्हाइस आहे जे ऑप्टिक्सद्वारे रिमोट स्टोरेजसाठी माउंटचे प्रतिनिधित्व करते.

आम्ही नुकताच दुसरा विभाग जोडला.

आम्ही त्याच्या शेजारी दुसरे स्टोरेज ठेवले (सुदैवाने, पैशाच्या बाबतीत ते इतके महाग नाही), आणि त्याला बॅकअप विभाजन म्हटले. हे ऑप्टिक्सद्वारे देखील जोडलेले आहे आणि त्याच मशीनवर स्थित आहे. परंतु आम्हाला त्यांच्या दरम्यान डेटा कसा तरी सिंक्रोनाइझ करणे आवश्यक आहे.

येथे आपण जवळपास एक असिंक्रोनस रांग बनवतो.

ती फार व्यस्त नाही. आम्हाला माहित आहे की आमच्याकडे पुरेसे रेकॉर्ड नाहीत. रांग म्हणजे MySQL मधील एक टेबल आहे ज्यामध्ये “तुम्हाला या फोटोचा बॅकअप घेणे आवश्यक आहे” अशा ओळी लिहिलेल्या आहेत. कोणत्याही बदल किंवा अपलोडसह, आम्ही एसिंक्रोनस किंवा काही प्रकारचे बॅकग्राउंड वर्कर वापरून मुख्य विभाजनापासून बॅकअपवर कॉपी करतो.

आणि अशा प्रकारे आपल्याकडे नेहमी दोन सुसंगत विभाग असतात. जरी या प्रणालीचा एक भाग अयशस्वी झाला तरीही, आम्ही नेहमी बॅकअपसह मुख्य विभाजन बदलू शकतो आणि सर्वकाही कार्य करत राहील.

परंतु यामुळे, वाचनाचा भार खूप वाढतो, कारण... मुख्य विभागातून वाचलेल्या क्लायंटच्या व्यतिरिक्त, कारण ते प्रथम तिथला फोटो पाहतात (ते तिथे अगदी अलीकडचे आहे), आणि नंतर बॅकअपवर शोधतात, जर त्यांना तो सापडला नाही (परंतु NGINX फक्त हे करतो), आमची प्रणाली देखील एक प्लस बॅकअप आहे आता मुख्य विभाजनातून वाचली जाते. असे नाही की ही अडचण होती, परंतु मला त्याचप्रमाणे भार वाढवायचा नव्हता.

आणि आम्ही तिसरी डिस्क जोडली, जी एक लहान SSD आहे, आणि त्याला बफर म्हटले.

ते आता कसे कार्य करते.

वापरकर्ता बफरवर एक फोटो अपलोड करतो, त्यानंतर एक इव्हेंट रांगेत टाकला जातो जो सूचित करतो की तो दोन विभागांमध्ये कॉपी करणे आवश्यक आहे. त्याची कॉपी केली जाते आणि फोटो बफरवर काही काळ राहतो (म्हणा, एक दिवस), आणि त्यानंतरच तेथून शुद्ध केले जाते. हे वापरकर्त्याच्या अनुभवामध्ये मोठ्या प्रमाणात सुधारणा करते, कारण वापरकर्ता फोटो अपलोड करतो, नियमानुसार, विनंत्या त्वरित फॉलो करणे सुरू होते किंवा त्याने स्वतः पृष्ठ अद्यतनित केले आणि ते रीफ्रेश केले. परंतु हे सर्व अपलोड करणार्‍या अनुप्रयोगावर अवलंबून असते.

किंवा, उदाहरणार्थ, इतर लोक ज्यांना त्याने स्वतःला दाखवायला सुरुवात केली या फोटोनंतर लगेच विनंत्या पाठवल्या. हे अद्याप कॅशेमध्ये नाही; पहिली विनंती खूप लवकर होते. मूलत: फोटो कॅशे प्रमाणेच. स्लो स्टोरेजचा यात अजिबात सहभाग नाही. आणि जेव्हा एका दिवसानंतर ते शुद्ध केले जाते, तेव्हा ते एकतर आमच्या कॅशिंग लेयरवर आधीच कॅश केलेले असते किंवा बहुधा कोणालाही त्याची आवश्यकता नसते. त्या. अशा साध्या हाताळणीमुळे येथे वापरकर्ता अनुभव खूप चांगला वाढला आहे.

ठीक आहे, आणि सर्वात महत्त्वाचे म्हणजे: आम्ही डेटा गमावणे थांबवले.

आपण थांबलो म्हणूया संभाव्य डेटा गमावला, कारण आम्ही तो खरोखर गमावला नाही. पण धोका होता. आपण पाहतो की हा उपाय अर्थातच चांगला आहे, परंतु समस्येची लक्षणे पूर्णपणे सोडवण्याऐवजी ती गुळगुळीत करण्यासारखे आहे. आणि काही समस्या येथे राहतात.

प्रथम, हा भौतिक यजमानाच्या रूपात अपयशाचा एक मुद्दा आहे ज्यावर ही सर्व यंत्रणा चालते; ती दूर झालेली नाही.

दुसरे म्हणजे, SAN मध्ये अजूनही समस्या आहेत, त्यांची जड देखभाल, इ. तो एक गंभीर घटक होता असे नाही, परंतु मला त्याशिवाय कसे तरी जगण्याचा प्रयत्न करायचा होता.

आणि आम्ही तिसरी आवृत्ती बनवली (खरं तर दुसरी) - आरक्षण आवृत्ती. काय दिसले?

हे असे होते -

आमच्या मुख्य समस्या या वस्तुस्थितीसह आहेत की हे भौतिक होस्ट आहे.

प्रथम, आम्ही SAN काढून टाकत आहोत कारण आम्हाला प्रयोग करायचे आहेत, आम्हाला फक्त स्थानिक हार्ड ड्राइव्हस् वापरायचे आहेत.

हे आधीच 2014-2015 आहे, आणि त्या वेळी डिस्कसह परिस्थिती आणि एका होस्टमध्ये त्यांची क्षमता अधिक चांगली झाली. आम्ही प्रयत्न का करू नये हे ठरवले.

आणि मग आम्ही आमचे बॅकअप विभाजन घेतो आणि ते एका वेगळ्या मशीनवर भौतिकरित्या हस्तांतरित करतो.

अशाप्रकारे, आम्हाला ही आकृती मिळते. आमच्याकडे दोन कार आहेत ज्या समान डेटासेट संग्रहित करतात. ते एकमेकांचा पूर्णपणे बॅकअप घेतात आणि त्याच MySQL मधील असिंक्रोनस रांगेद्वारे नेटवर्कवर डेटा सिंक्रोनाइझ करतात.

हे चांगले का कार्य करते कारण आमच्याकडे काही रेकॉर्ड आहेत. त्या. जर लेखन वाचनाशी तुलना करता आले असते, तर कदाचित आमच्याकडे काही प्रकारचे नेटवर्क ओव्हरहेड आणि समस्या असतील. थोडे लेखन आहे, भरपूर वाचन आहे - ही पद्धत चांगली कार्य करते, म्हणजे. आम्ही क्वचितच या दोन सर्व्हरमधील फोटो कॉपी करतो.

हे कसे कार्य करते, जर आपण थोडे अधिक तपशीलवार पाहिले तर.

अपलोड करा. बॅलन्सर सहजपणे जोडीसह यादृच्छिक होस्ट निवडतो आणि त्यावर अपलोड करतो. त्याच वेळी, तो नैसर्गिकरित्या आरोग्य तपासणी करतो आणि कार बाहेर पडणार नाही याची खात्री करतो. त्या. तो फक्त लाइव्ह सर्व्हरवर फोटो अपलोड करतो आणि नंतर अॅसिंक्रोनस रांगेद्वारे हे सर्व त्याच्या शेजाऱ्याकडे कॉपी केले जाते. अपलोड सह सर्वकाही अत्यंत सोपे आहे.

काम थोडे अधिक कठीण आहे.

लुआने आम्हाला येथे मदत केली, कारण व्हॅनिला एनजीआयएनएक्सवर असे तर्क करणे कठीण होऊ शकते. आम्ही प्रथम प्रथम सर्व्हरला विनंती करतो, फोटो आहे की नाही ते पहा, कारण संभाव्यतः तो अपलोड केला जाऊ शकतो, उदाहरणार्थ, शेजारी, परंतु अद्याप येथे आलेला नाही. फोटो असेल तर छान. आम्ही ते ताबडतोब क्लायंटला देतो आणि शक्यतो कॅशे करतो.

जर ते तिथे नसेल, तर आम्ही आमच्या शेजाऱ्याला विनंती करतो आणि तेथून ते मिळवण्याची हमी दिली जाते.

ते. पुन्हा आम्ही म्हणू शकतो: कार्यप्रदर्शनात समस्या असू शकतात, कारण सतत फेऱ्या मारल्या जातात - फोटो अपलोड केला गेला होता, तो येथे नाही, आम्ही एक ऐवजी दोन विनंत्या करत आहोत, हे हळू चालले पाहिजे.

आमच्या परिस्थितीत, हे हळूहळू कार्य करत नाही.

आम्ही या प्रणालीवर मेट्रिक्सचा एक समूह गोळा करतो आणि अशा यंत्रणेचा सशर्त स्मार्ट दर सुमारे 95% आहे. त्या. या बॅकअपचा अंतर कमी आहे, आणि यामुळे आम्ही जवळजवळ हमी देतो, फोटो अपलोड झाल्यानंतर, आम्ही प्रथमच तो घेऊ आणि दोनदा कुठेही जावे लागणार नाही.

मग आमच्याकडे अजून काय छान आहे?

पूर्वी, आमच्याकडे मुख्य बॅकअप विभाजन होते आणि आम्ही त्यांच्याकडून अनुक्रमे वाचतो. त्या. आम्ही नेहमी प्रथम मुख्य शोधतो आणि नंतर बॅकअपवर. ती एक चाल होती.

आता आपण एकाच वेळी दोन मशीनमधून वाचन वापरतो. आम्ही राउंड रॉबिन वापरून विनंत्या वितरित करतो. थोड्या टक्के प्रकरणांमध्ये आम्ही दोन विनंत्या करतो. पण एकंदरीत, आता आमच्याकडे पूर्वीपेक्षा दुप्पट वाचन साठा आहे. आणि पाठवणा-या मशीनवर आणि थेट स्टोरेज मशीनवर लोड मोठ्या प्रमाणात कमी झाला होता, जो त्यावेळी आमच्याकडे होता.

दोष सहिष्णुतेसाठी म्हणून. वास्तविक, यासाठीच आपण प्रामुख्याने लढलो. दोष सहिष्णुतेसह, येथे सर्व काही छान झाले.

एक गाडी बिघडली.

काही हरकत नाही! सिस्टम अभियंता कदाचित रात्री उठू शकत नाही, तो सकाळपर्यंत थांबेल, काहीही वाईट होणार नाही.

जरी हे मशीन अयशस्वी झाले तरीही, रांग सुव्यवस्थित आहे, एकतर कोणतीही समस्या नाही, लॉग फक्त लिव्हिंग मशीनवर जमा केला जाईल, आणि नंतर तो रांगेत जोडला जाईल आणि नंतर कारमध्ये जोडला जाईल. काही काळानंतर ऑपरेशनमध्ये जा.

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

या रिडंडंसी योजनेतून कोणते निष्कर्ष काढले जाऊ शकतात?

आम्हाला दोष सहिष्णुता मिळाली.

वापरण्यास सोप. मशिनमध्ये स्थानिक हार्ड ड्राइव्हस् असल्याने, त्याच्यासोबत काम करणाऱ्या अभियंत्यांच्या ऑपरेशनल दृष्टिकोनातून हे अधिक सोयीचे आहे.

आम्हाला दुप्पट वाचन भत्ता मिळाला.

दोष सहिष्णुतेव्यतिरिक्त हा खूप चांगला बोनस आहे.

पण समस्या देखील आहेत. आता आमच्याकडे याशी संबंधित काही वैशिष्ट्यांचा अधिक जटिल विकास आहे, कारण प्रणाली अखेरीस 100% सुसंगत झाली आहे.

काही पार्श्वभूमीच्या कामात, आपण सतत विचार केला पाहिजे: "आम्ही आता कोणत्या सर्व्हरवर चालत आहोत?", "येथे खरोखर वर्तमान फोटो आहे का?" इ. हे, अर्थातच, सर्व गुंडाळलेले आहे, आणि प्रोग्रामर जो व्यवसाय तर्क लिहितो, तो पारदर्शक आहे. परंतु, तरीही, हा मोठा जटिल थर दिसू लागला आहे. परंतु त्यातून मिळालेल्या गुडीच्या बदल्यात आम्ही हे सहन करण्यास तयार आहोत.

आणि इथे पुन्हा काही संघर्ष निर्माण होतो.

मी सुरुवातीला सांगितले की स्थानिक हार्ड ड्राइव्हवर सर्वकाही संग्रहित करणे वाईट आहे. आणि आता मी म्हणतो की आम्हाला ते आवडले.

होय, खरंच, कालांतराने परिस्थिती खूप बदलली आहे आणि आता या दृष्टिकोनाचे बरेच फायदे आहेत. प्रथम, आम्हाला बरेच सोपे ऑपरेशन मिळते.

दुसरे म्हणजे, ते अधिक उत्पादनक्षम आहे, कारण आमच्याकडे हे स्वयंचलित नियंत्रक किंवा डिस्क शेल्फशी कनेक्शन नाहीत.

तेथे मोठ्या प्रमाणात यंत्रसामग्री आहे आणि या फक्त काही डिस्क्स आहेत ज्या येथे मशीनवर एका छाप्यात एकत्र केल्या जातात.

पण तोटे देखील आहेत.

आजच्या किमतींमध्ये SAN वापरण्यापेक्षा हे अंदाजे 1,5 पट जास्त महाग आहे. म्हणून, आम्ही आमच्या संपूर्ण मोठ्या क्लस्टरला स्थानिक हार्ड ड्राइव्हसह कारमध्ये रूपांतरित न करण्याचा निर्णय घेतला आणि हायब्रिड सोल्यूशन सोडण्याचा निर्णय घेतला.

आमची अर्धी मशीन हार्ड ड्राइव्हसह कार्य करते (चांगले, अर्ध्या नाही - कदाचित 30 टक्के). आणि बाकीच्या जुन्या गाड्या आहेत ज्यात आधी आरक्षण योजना असायची. आम्ही त्यांना फक्त पुन्हा माउंट केले, कारण आम्हाला नवीन डेटा किंवा इतर कशाचीही आवश्यकता नाही, आम्ही फक्त माउंट्स एका भौतिक होस्टवरून दोनमध्ये हलवले.

आणि आता आमच्याकडे वाचनाचा मोठा साठा आहे आणि आम्ही तो वाढवला आहे. जर पूर्वी आम्ही एका मशीनवर एक स्टोरेज माउंट केले असेल, तर आता आम्ही चार माउंट केले आहे, उदाहरणार्थ, एका जोडीवर. आणि ते चांगले कार्य करते.

आपण काय साध्य केले, आपण कशासाठी लढलो आणि आपण यशस्वी झालो की नाही याचा थोडक्यात सारांश घेऊ.

परिणाम

आमच्याकडे वापरकर्ते आहेत - तब्बल 33 दशलक्ष.

आमच्याकडे तीन बिंदू आहेत - प्राग, मियामी, हाँगकाँग.

त्यामध्ये कॅशिंग लेयर असते, ज्यामध्ये फास्ट लोकल डिस्क्स (एसएसडी) असलेल्या कार असतात, ज्यावर NGINX ची साधी मशिनरी, त्याचे access.log आणि Python डिमन चालतात, जे या सर्वांवर प्रक्रिया करतात आणि कॅशे व्यवस्थापित करतात.

तुमची इच्छा असल्यास, तुम्ही तुमच्या प्रकल्पात असाल, जर फोटो तुमच्यासाठी तितके महत्त्वाचे नसतील जितके ते आमच्यासाठी आहेत, किंवा ट्रेड-ऑफ नियंत्रण विरुद्ध विकास गती आणि संसाधन खर्च तुमच्यासाठी दुसऱ्या दिशेने असल्यास, तुम्ही ते सुरक्षितपणे बदलू शकता. CDN सह, आधुनिक CDN ते चांगले काम करतात.

पुढे स्टोरेज लेयर येतो, ज्यावर आमच्याकडे मशीन्सच्या जोड्यांचे क्लस्टर आहेत जे एकमेकांचा बॅकअप घेतात, फायली जेव्हाही बदलतात तेव्हा त्या एकमेकांपासून अतुल्यकालिकपणे कॉपी केल्या जातात.

शिवाय, यापैकी काही मशीन स्थानिक हार्ड ड्राइव्हसह कार्य करतात.

यापैकी काही यंत्रे SAN शी जोडलेली आहेत.

आणि, एकीकडे, ते वापरण्यास अधिक सोयीस्कर आणि थोडे अधिक उत्पादनक्षम आहे, तर दुसरीकडे, प्लेसमेंट घनता आणि प्रति गीगाबाइट किंमतीच्या बाबतीत ते सोयीस्कर आहे.

आम्हाला काय मिळाले आणि हे सर्व कसे विकसित झाले याच्या आर्किटेक्चरचा हा थोडक्यात आढावा आहे.

कर्णधाराकडून आणखी काही टिप्स, अगदी सोप्या.

प्रथम, जर तुम्ही अचानक ठरवले की तुम्हाला तुमच्या फोटो इन्फ्रास्ट्रक्चरमध्ये तातडीने सर्वकाही सुधारण्याची गरज आहे, तर प्रथम मोजमाप करा, कारण कदाचित काहीही सुधारण्याची गरज नाही.

मी तुम्हाला एक उदाहरण देतो. आमच्याकडे मशीन्सचा एक क्लस्टर आहे जो चॅटमध्ये संलग्नकांमधून फोटो पाठवतो आणि ही योजना 2009 पासून तेथे कार्यरत आहे आणि कोणालाही त्याचा त्रास होत नाही. प्रत्येकजण ठीक आहे, प्रत्येकाला सर्वकाही आवडते.

मोजण्यासाठी, प्रथम मेट्रिक्सचा एक समूह लटकवा, ते पहा आणि नंतर आपण कशावर नाखूष आहात आणि काय सुधारणे आवश्यक आहे ते ठरवा. हे मोजण्यासाठी, आमच्याकडे पिनबा नावाचे एक छान साधन आहे.

हे तुम्हाला प्रत्येक विनंती आणि प्रतिसाद कोडसाठी NGINX कडून अतिशय तपशीलवार आकडेवारी आणि वेळेचे वितरण - तुम्हाला हवे ते गोळा करण्याची परवानगी देते. हे सर्व प्रकारच्या विविध विश्लेषण प्रणालींना बंधनकारक आहे, आणि नंतर आपण ते सर्व सुंदरपणे पाहू शकता.

प्रथम आम्ही ते मोजले, नंतर आम्ही ते सुधारले.

पुढील. आम्ही कॅशेसह वाचन, शार्डिंगसह लेखन ऑप्टिमाइझ करतो, परंतु हा एक स्पष्ट मुद्दा आहे.

पुढील. जर तुम्ही आत्ताच तुमची सिस्टीम बनवायला सुरुवात करत असाल, तर अपरिवर्तनीय फाइल्स म्हणून फोटो बनवणे जास्त चांगले आहे. कारण तुम्ही ताबडतोब कॅशे अवैधतेसह, तर्कशास्त्राने फोटोची योग्य आवृत्ती कशी शोधली पाहिजे इत्यादी समस्यांचा संपूर्ण वर्ग गमावला आहे.

समजा तुम्ही शंभर अपलोड केले, नंतर ते फिरवले, असे बनवा की ती भौतिकदृष्ट्या वेगळी फाइल होती. त्या. विचार करण्याची गरज नाही: आता मी थोडी जागा वाचवीन, त्याच फाईलवर लिहीन, आवृत्ती बदलेन. हे नेहमीच चांगले काम करत नाही आणि नंतर खूप डोकेदुखी होते.

पुढचा मुद्दा. फ्लाय वर आकार बदला बद्दल.

पूर्वी, जेव्हा वापरकर्त्यांनी फोटो अपलोड केला, तेव्हा आम्ही ताबडतोब सर्व प्रसंगांसाठी, वेगवेगळ्या क्लायंटसाठी आकारांचा संपूर्ण समूह कापला आणि ते सर्व डिस्कवर होते. आता आम्ही हे सोडून दिले आहे.

आम्ही फक्त तीन मुख्य आकार सोडले: लहान, मध्यम आणि मोठे. आम्ही फक्त Uport वर आम्हाला विचारलेल्या आकाराच्या मागे असलेल्या आकारापासून बाकी सर्व गोष्टी कमी करतो, आम्ही फक्त डाउनस्केल करतो आणि वापरकर्त्याला देतो.

येथे कॅशिंग लेयरचा CPU प्रत्येक स्टोरेजवर हे आकार सतत पुन्हा निर्माण केले तर त्यापेक्षा खूपच स्वस्त आहे. समजा आम्हाला एक नवीन जोडायचे आहे, यास एक महिना लागेल - सर्वत्र एक स्क्रिप्ट चालवा जी क्लस्टर नष्ट न करता हे सर्व व्यवस्थितपणे करेल. त्या. तुम्हाला आता निवडण्याची संधी असल्यास, शक्य तितक्या कमी भौतिक आकार तयार करणे चांगले आहे, परंतु किमान काही वितरण, म्हणा, तीन. आणि बाकी सर्व काही तयार मॉड्यूल्स वापरून फ्लायवर फक्त आकार बदलू शकतो. हे सर्व आता खूप सोपे आणि प्रवेश करण्यायोग्य आहे.

आणि वाढीव असिंक्रोनस बॅकअप चांगला आहे.

आमच्या सरावाने दाखवल्याप्रमाणे, ही योजना बदललेल्या फाइल्सच्या विलंबित कॉपीसह उत्तम कार्य करते.

शेवटचा मुद्दाही उघड आहे. तुमच्या इन्फ्रास्ट्रक्चरमध्ये आता अशा समस्या नसतील, पण काही तरी मोडू शकते, ते जरा जास्त झाल्यावर नक्कीच तुटेल. म्हणून, याबद्दल आगाऊ विचार करणे चांगले आहे आणि त्यात समस्या न अनुभवणे चांगले आहे. मला एवढेच सांगायचे होते.

संपर्क

» bo0rsh201
» Badoo ब्लॉग

हा अहवाल उच्च-लोड सिस्टमच्या विकासकांच्या परिषदेतील सर्वोत्तम भाषणांपैकी एक उतारा आहे HighLoad++. HighLoad++ 2017 परिषदेला एक महिन्यापेक्षा कमी कालावधी शिल्लक आहे.

आमच्याकडे ते आधीच तयार आहे परिषद कार्यक्रम, वेळापत्रक आता सक्रियपणे तयार केले जात आहे.

या वर्षी आम्ही आर्किटेक्चर आणि स्केलिंग विषय एक्सप्लोर करणे सुरू ठेवतो:

• अब्जावधी वापरकर्त्यांना सेवा कशी द्यावी आणि रहदारीचा टेराबिट कसा द्यावा / इगोर वासिलिव्ह
• व्हीकॉन्टाक्टे वैयक्तिक संदेश डेटाबेस सुरवातीपासून कसा लिहायचा आणि डाउनटाइमशिवाय त्यावर स्थलांतरित कसे करावे / दिमित्री एगोरोव
• विक्रीद्वारे मृत्यू: Yandex.Money ने ब्लॅक फ्रायडेला गती देण्याचा आणि जगण्याचा कसा प्रयत्न केला / अनातोली प्लास्कोव्स्की
• बँकेच्या फ्रंट-एंड सिस्टमचे दोष-सहिष्णु आर्किटेक्चर / रोमन शेखोव्हत्सोव्ह, अलेक्सी ग्रोमॅटचिकोव्ह
• पेमेंट सिस्टम आर्किटेक्चर: जवळजवळ एंटरप्राइझ / फिलिप डेलगाडो

हाय-लोड सिस्टम विकसित करण्याच्या आमच्या ऑनलाइन प्रशिक्षण कोर्समध्ये आम्ही यापैकी काही सामग्री देखील वापरतो हायलोड.मार्गदर्शक खास निवडलेली अक्षरे, लेख, साहित्य, व्हिडिओ यांची साखळी आहे. आमच्या पाठ्यपुस्तकात आधीच 30 पेक्षा जास्त अनन्य साहित्य आहे. कनेक्ट करा!

स्त्रोत: www.habr.com