Mail.Ru मेल का 64-बिट आर्किटेक्चर में संक्रमण: यह कैसा था

कई महीनों के लिए, Mail.Ru मेल के मोर्चें 64 बिट बन गए हैं। देर से कभी नहीं, हमने फैसला किया और आज हम आपको बताएंगे कि हमने ऐसा क्यों किया, इसके लिए हम क्या कर गए और हमने यह कैसे किया।



और इसलिए यह काम करता है

लंबे समय तक, हमारे मेल ने पहले अपाचे और पर्ल 5.8 पर चलने वाले CentOS में 32 बिट्स पर काम किया। अधिक आधुनिक सॉफ्टवेयर और 64-बिट आर्किटेक्चर को आगे बढ़ाने का विचार लंबे समय से हमारे दिमाग में घूम रहा है: डेढ़ साल पहले, केवल दो लोग - एक व्यवस्थापक और एक डेवलपर - नींद के बिना कुछ हफ़्ते के लिए उन्होंने एक परीक्षण सर्वर उठाया, जिस पर हमारा उज्ज्वल भविष्य घूम रहा था। हालांकि, उन दिनों में हमारे पास अधिक आवश्यक कार्य थे, और हम सुरक्षित रूप से सर्वर के बारे में भूल गए। समय-समय पर, वे इस विचार पर लौट आए, लेकिन "अगर ऐसा है तो क्या हुआ?" "ओह, कुछ टूट गया है!" - और फिर से सब कुछ वापस लुढ़का और एक लंबी दराज में डाल दिया गया।

समय आ गया

अंत में, यह एक बदलाव का समय है। कुछ बिंदु पर, हमने महसूस किया कि यह आगे नहीं बढ़ सकता है: 2014 में CentOS 5 के लिए पूर्ण समर्थन समाप्त हो गया, कुछ कार्यों पर पर्ल 5.10 ने गति में 30% की वृद्धि दिखाई, यह उल्लेख नहीं करने के लिए कि 21 वीं सदी में 32-बिट वास्तुकला कुछ हद तक है इच्छित के पीछे पीछे।
इसके अलावा, हमने HTTPS को मेल ट्रांसफर करने के बाद, फ्रंट-एंड सर्वर पर लोड एवरेज बढ़ाया, जिससे एक अधिक उत्पादक पर्ल पहले से कहीं अधिक प्रासंगिक हो गया।

संक्रमण कठिनाइयों

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

बाइनरी प्रोटोकॉल

Mail.Ru मेल में, बाइनरी प्रोटोकॉल के माध्यम से अक्सर बातचीत होती है। सबसे पहले, यह हमारे टारेंटूल डेटा वेयरहाउस के साथ संचार है। डेटाबेस के अलावा, यहां तक ​​कि हमारी सेवाओं के बीच भी, उदाहरण के लिए, एक पर्ल सर्वर और सी सर्वर, डेटा बाइनरी रूप में प्रेषित होता है। यह अच्छा, तेज और सुविधाजनक है, जब तक कि यह वास्तुकला के बदलाव की बात नहीं करता।
हर बार डेटा को एन्क्रिप्ट करना या मोडुलो को जोड़ना आवश्यक है, संभावना है कि x32 और x64 पर ऑपरेशन के परिणाम अलग-अलग गैर-शून्य हो जाएंगे। यह इस तथ्य से जटिल है कि ये अंतर केवल विशिष्ट डेटा पर दिखाई देते हैं, इसलिए इन मामलों को खोजना, पकड़ना और रिकॉर्ड करना कोई तुच्छ कार्य नहीं है।
उदाहरण के लिए, नीचे दिए गए कोड की पहली पंक्ति विभिन्न आर्किटेक्चर पर अलग-अलग तरीके से काम करती है।
मेरे $ क्रिप्टेड_सुअरिड = $ उपयोगकर्ता -> {'आईडी'} ^ 41262125215;
getpage ('project_url_api; user_id ='। $ crypted_userid);
व्यवहार में यह अंतर पूरी तरह से अप्रत्याशित स्थानों और यहां तक ​​कि विभिन्न परियोजनाओं में समस्याओं की ओर जाता है। उदाहरण के लिए, उपयोगकर्ता आईडी के साथ कोड निष्पादन के नए परिणामों ने इस तथ्य को जन्म दिया कि, हमारे सामान्य प्राधिकरण प्रणाली के लिए धन्यवाद, एक उपयोगकर्ता द्वारा एक पासवर्ड को बदलना एक अन्य सेवा से पूरी तरह से अलग उपयोगकर्ता को लॉग आउट करना चाहिए।
मेल में ही एन्क्रिप्शन की समस्या का पता चला था। पत्र भेजने के बाद, उपयोगकर्ता को URL पर भेजा जाता है, जिसमें अन्य बातों के अलावा, एन्क्रिप्टेड प्राप्तकर्ता होते हैं (कोई भी नहीं चाहता कि उसका ईमेल स्पष्ट पाठ में पता पट्टी पर भेजा जाए)। 64-बिट आर्किटेक्चर पर URL जनरेट करने के बाद क्या हुआ, यह अनुमान लगाना मुश्किल नहीं था: प्राप्तकर्ता सूची के बजाय एक यादृच्छिक चरित्र सेट दिखाई दिया।
बेशक, अब इन समस्याओं का समाधान हो गया है, लेकिन उनके कब्जे में काफी समय लगा।

केवल दो

संक्रमण में ही दो महीने लग गए। ऐसा होने से पहले, लगभग छह महीनों के लिए, हमारे पोस्ट ने पुराने मोर्चों और नए दोनों पर काम किया। हमने इन दो प्रणालियों के व्यवहार की सावधानीपूर्वक निगरानी की: हमारे डैशबोर्ड पर दो अलग-अलग रेखांकन थे, जिसके अनुसार हमने पीछा किया जहां अधिक त्रुटियां थीं और जो तेजी से काम करता है। उनके साथ एक मजेदार कहानी जुड़ी हुई है - एक बार रात के मध्य में सभी को कानों के पास उठाया गया था, क्योंकि नए मोर्चों के प्रदर्शन चार्ट पर रेखाएं अधिक चलती थीं - यह पता चला कि वे बहुत धीरे-धीरे काम करते हैं। फिर, हालांकि, यह पता चला कि हमने इतना अनुकूलित किया था कि नए मोर्चों के लिए पैमाने स्वतः ही परिमाण के क्रम से बदल गए, और वास्तव में, उन्होंने 10 गुना तेजी से काम किया। फिर भी, हम डरने में कामयाब रहे।
इसके अलावा, दो प्रणालियों की शर्तों में, आप अपाचे अनुरोध को सिर्फ ले और संसाधित नहीं कर सकते। हमें निम्नलिखित कार्य करने होंगे:
उप GetApacheRequest {
$ ENV {MOD_PERL} = ~ m {mod_perl / 2}? Apache2 :: RequestUtil-> अनुरोध (): Apache-> अनुरोध ();
}
मेल के लिए संकुल की असेंबली भी प्रपत्र की शर्तों के साथ चकाचौंध करने लगी
% अगर 0% {? सेंटोस} == 6
...
% अगर 0% {? सेंटोस} == 5
...
और ऐसे बहुत सारे स्थान हैं।
एक बार में दो शाखाओं की निगरानी और परिवर्तन करने के अलावा, हमें, बेशक, दो बार नए पुनरावृत्तियों का परीक्षण करना था, लेकिन हमारे परीक्षक कामयाब रहे।

काम का इनाम

तो, इस श्रमसाध्य और कभी-कभी घबराए हुए काम के परिणामस्वरूप हमें क्या मिला?

• पूर्ण CentOS 6 समर्थन - नए पैच, वर्तमान सिस्टम स्थिति
• पर्ल 5.10 में फास्ट रेगुलर। यह बताता है कि पार्स और पार्स तेजी से उड़ते हैं
• अपाचे 2 एक नया कॉन्फिगरेशन और स्क्रिप्ट्स को बिना रिस्टार्ट करता है। कोड और कॉन्फ़िगरेशन का लेआउट 500 वीं त्रुटि की ओर नहीं जाता है (सैद्धांतिक रूप से, पहला अपाचे भी ऐसा करने में सक्षम था, हालांकि, लोड से मोर्चे को डिस्कनेक्ट किए बिना इसे सामान्य रूप से करना यह कल्पना के दायरे से एक कार्य है)
• कुल रिफैक्टरिंग। नए सॉफ़्टवेयर में संक्रमण अनावश्यक निर्भरता, अनावश्यक संस्थाओं और अप्रयुक्त मॉड्यूल से छुटकारा पाने का एक बड़ा कारण है
• कठपुतली का उपयोग करना । हमने उस तरह टहलने का फैसला किया, और उसी समय हमने पपेट पर स्विच किया। अब नई सुविधाओं का लेआउट और हॉटफ़िक्स की तैनाती बहुत आसान हो गई है।

यह उम्मीद की जानी थी कि 32 से 64 बिट्स का संक्रमण एपाचे की मेमोरी खपत पर प्रतिकूल प्रभाव डालेगा, जो पहले से ही सब कुछ खाने की कोशिश करता है जो इसे देता है। एक प्रक्रिया के लिए आवंटित स्मृति की मात्रा, निश्चित रूप से बढ़ी है, इससे कोई बच नहीं है। हालांकि, सब कुछ तेजी से काम करना शुरू कर दिया, इसलिए कम प्रक्रियाएं कार्यों से सामना करती हैं, इसलिए समग्र स्मृति लागत में वृद्धि नहीं हुई है। लाभ के आसपास।
पर्ल 5.10, वैसे, हमें एक अतिरिक्त लाभ देता है: 5.8.8 से दर्दनाक संक्रमण की तुलना में 5.16 में संक्रमण में आसानी। तो हमारे मेल में नए पर्ल का इंतजार करें।
यदि आपके कोई प्रश्न हैं, तो मैं उन्हें टिप्पणियों में चर्चा करने का सुझाव देता हूं।

इल्या ज़ेरेत्स्की,
मेल डेवलपमेंट बैकएंड टीम लीडर