एवरनोट सर्विस आर्किटेक्चर ओवरव्यू

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

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

चलो ऊपर प्रस्तुत योजना से शुरू करते हैं। संकेत दिए गए सभी आंकड़े 17 मई, 2011 को दिए गए हैं।

नेटवर्क: लगभग सभी ट्रैफिक एवरनोट से / HTTPS पोर्ट 443 के माध्यम से www.evernote.com पर जाते हैं। इसमें " थ्रिफ्ट- आधारित एपीआई" के माध्यम से सभी "वेब गतिविधि" और सभी सॉफ्टवेयर क्लाइंट के साथ सिंक्रनाइज़ेशन शामिल है। कुल मिलाकर, प्रति दिन लगभग 150 मिलियन HTTPS अनुरोध लगभग 250 Mbit / s के पीक ट्रैफिक के साथ उत्पन्न होते हैं। प्रशासकों की हमारी रात की पारी इस परिस्थिति के लिए विशेष रूप से "खुश" है, क्योंकि दैनिक शिखर लगभग 6:30 बजे प्रशांत समय पर होता है।

हम अपने प्राथमिक ( NTT ) और अतिरिक्त ( स्तर 3 ) प्रदाताओं द्वारा प्रदान किए गए चैनलों के पूरी तरह से स्वतंत्र नेटवर्क के माध्यम से सीधे ट्रैफ़िक भेजने के लिए BGP का उपयोग करते हैं। यह व्याट के माध्यम से ए 10 लोड बैलेन्सर के रास्ते में फ़िल्टर किया जाता है जिसे हमने जनवरी में स्थापित किया था जब हम अपने पुराने बैलेन्कर्स के लिए एसएसएलएफ प्रदर्शन सीमा तक पहुंच गए थे। जबकि हमारे लिए एक AX 2500 के साथ-साथ एक विफल-सुरक्षित सर्वर का उपयोग करके मौजूदा ट्रैफ़िक को संसाधित करना काफी सुविधाजनक है, हम भविष्य के विकास के लिए तैयार रहने के लिए अपना क्लस्टर बनाते समय उनके N + 1 कॉन्फ़िगरेशन का परीक्षण करने की तैयारी कर रहे हैं।

शेयर: एवरनोट सेवा का मूल एक सर्वर फ़ार्म है, जिसे हम शार्क कहते हैं। प्रत्येक शार्क 100,000 एवरनोट उपयोगकर्ताओं के एक समूह के लिए सभी डेटा और सभी ट्रैफ़िक (वेब ​​और एपीआई) को संसाधित करती है। चूंकि हमारे पास पहले से ही 9 मिलियन से अधिक उपयोगकर्ता हैं, इसलिए हमें लगभग 90 शार्क मिलती हैं।

प्रत्येक शार्प इंटेल डुअल-कोर प्रोसेसर, विशाल रैम के साथ सुपरमाइक्रो सर्वरों की एक जोड़ी है और पूरी तरह से बंद सीगेट औद्योगिक ड्राइव को प्रतिबिंबित RAID सरणियों में कॉन्फ़िगर किया गया है। प्रत्येक सर्वर के प्रमुख पर, हमारे पास एक डेबियन होस्ट होता है जो एक जोड़ी वर्चुअल मशीन का प्रबंधन करता है। अनुप्रयोगों के निम्नलिखित सेट से मुख्य मुख्य वर्चुअल मशीन में लॉन्च किया गया है: डेबियन + जावा 6 + टॉम्कट + हाइबरनेट + एहचेक + स्ट्रिप + जीडब्ल्यूटी + मायक्यूएल (मेटाडेटा के लिए) + पदानुक्रम स्थानीय फ़ाइल सिस्टम (फ़ाइल डेटा के लिए)।

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

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

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

UserStore: यद्यपि सभी डेटा का अधिकांश भाग तार्किक रूप से स्वतंत्र शार्क ("नोटस्टोर") पर संग्रहीत होता है, लेकिन ये सभी खातों के एक एकल डेटाबेस "UserStore" (MySQL पर भी काम करता है) के साथ प्रत्येक खाते की थोड़ी मात्रा में जानकारी के साथ जुड़े होते हैं, जैसे कि उपयोगकर्ता नाम, एमडी 5 फ़ंक्शन पासवर्ड और उपयोगकर्ता शार्क आईडी। यह डेटाबेस रैम में फिट होने के लिए काफी छोटा है, लेकिन हम माध्यमिक और रात के बैकअप के लिए दर्पण और आरएबी और डीआरबीडी प्रतिकृति के समान संयोजन के साथ एक ही विश्वसनीय बैकअप भी प्रदान करते हैं।

छवि पहचान फ़ार्म: आपके नोटों में छवियों के अंदर शब्दों की खोज प्रदान करने के लिए, हमने 28 सर्वरों का एक पूल आवंटित किया है जो नई छवियों को संसाधित करने के लिए प्रतिदिन अपने 8-कोर प्रोसेसर का उपयोग करते हैं। व्यस्त दिनों में, प्रवाह 1.3 या 1.4 मिलियन व्यक्तिगत छवियों तक पहुंच सकता है। वर्तमान में, लिनक्स और विंडोज का एक संयोजन वहां उपयोग किया जाता है, लेकिन दूसरे दिन हम अनावश्यक निर्भरता से छुटकारा पाने के लिए डेबियन में प्रवास को पूरा करने की योजना बनाते हैं।

ये सर्वर मान्यता प्रक्रिया प्रदान करते हैं जिसे हम AIR ("उन्नत इमेजिंग और मान्यता") कहते हैं। इसके लिए सॉफ्टवेयर को हमारी R & D टीम द्वारा विकसित किया गया था। यह सॉफ़्टवेयर प्रत्येक छवि को संसाधित करता है, पाठ वाले क्षेत्रों की पहचान करता है, और फिर "मान्यता इंजन" का उपयोग करके प्रत्येक शब्द के लिए संभावित मैचों की एक भारित सूची को संकलित करने की कोशिश करता है जो मान्यताओं के सेट उत्पन्न करते हैं। काम हमारी टीम द्वारा विकसित दोनों तंत्रों का उपयोग करता है जो आकाशवाणी (उदाहरण के लिए, लिखावट की पहचान) और वाणिज्यिक भागीदारों से लाइसेंस प्राप्त प्रौद्योगिकियों को अपने उद्योग में सबसे अच्छे विकास के साथ उपयोग करते हैं।

अन्य सेवाएँ: सांता क्लारा, कैलिफोर्निया में हमारे डेटा सेंटर के रैक में उपरोक्त सभी सर्वर जोड़े हैं। सेवा के मूल संचालन को प्रदान करने वाले हार्डवेयर के अलावा, हमारे पास सरल कार्यों के लिए छोटे सर्वर समूह भी हैं जिनके लिए एक या दो एक्सएन सर्वर या आभासी मशीनों की आवश्यकता होती है। उदाहरण के लिए, इनकमिंग मेल के लिए हमारे SMTP गेटवे का संचालन पोस्टबोन के साथ डेबियन सर्वरों की एक जोड़ी और एक विशेष मेल प्रोसेसर द्वारा प्रदान किया गया है जो जावा में लिखा गया है जो बौने के ऊपर स्थापित है। @Myen का उपयोग करके आपके खाते में नोट्स भेजने के लिए हमारा ट्विटर गेटवे twitter4j का उपयोग करके एक छोटी सी स्क्रिप्ट है।

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

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

हम अगले कुछ महीनों में इन सवालों के अधिक विस्तार से उत्तर देने का प्रयास करेंगे।