अमेज़न SQS बनाम RabbitMQ

परिचय

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

इस लेख में, हम मध्यम और बड़े वेब अनुप्रयोगों की वास्तुकला को डिजाइन करने के संदर्भ में अमेज़ॅन वेब सेवाओं को देखेंगे।

ऐसे आवेदन की योजना पर विचार करें:




विभिन्न प्रकार के एग्रीगेटर इस तरह के संगठन के उदाहरण हो सकते हैं: समाचार, विनिमय दर, स्टॉक उद्धरण, आदि।

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

अमेज़ॅन सबसे आम एप्लिकेशन घटकों की पहचान करने की कोशिश करता है, फिर स्वचालित करता है और सेवा घटक प्रदान करता है। अब ऐसी दो दर्जन से अधिक सेवाएं हैं और AWS वेबसाइट: http://aws.amazon.com/products/ पर पूरी सूची देखी जा सकती है। हब पर पहले से ही कई लोकप्रिय सेवाओं का वर्णन करने वाला एक लेख था: अमेज़ॅन वेब सेवाओं के बारे में लोकप्रिय । यह मुख्य रूप से आकर्षक है क्योंकि स्वयं-स्थापना और कॉन्फ़िगरेशन, साथ ही उच्च विश्वसनीयता और टुकड़ा-भुगतान भुगतान की कोई आवश्यकता नहीं है

और यदि आप AWS का उपयोग करते हैं, तो परियोजना योजना इस तरह दिखाई देगी:


निस्संदेह, यह दृष्टिकोण मांग में है और इसका अपना बाजार है। लेकिन अक्सर वित्तीय घटक के बारे में सवाल उठते हैं:

1. AWS का उपयोग करके आप कितना बचा सकते हैं?
2. क्या समान गुणों के साथ एक सेवा को स्वतंत्र रूप से लागू करना संभव है, लेकिन कम पैसे के लिए?
3. वह रेखा कहां है जो AWS को उसके समकक्ष से अलग करती है?

आगे हम इन सवालों के जवाब देने की कोशिश करेंगे।

1. एनालॉग्स का अवलोकन

तुलना के लिए, हम निम्नलिखित घटकों पर विचार करेंगे:

• संदेश-उन्मुख मिडलवेयर - RabbitMQ
• AWS की उपरोक्त सेवा का एक एनालॉग, जिसे SQS कहा जाता है

SQS सेवा का भुगतान API अनुरोधों + ट्रैफ़िक की संख्या के आधार पर किया जाता है
प्रत्येक सेवा पर अधिक विस्तार से विचार करें।

1.1। SQS

Amazon SQS एक सेवा है जो आपको संदेश कतारों के साथ बनाने और काम करने की अनुमति देती है। समाप्त SQS कतार के साथ काम करने के लिए मानक चक्र इस प्रकार है:

1. कतार में एक संदेश भेजने के लिए, निर्माता को इसका URL पता होना चाहिए। फिर, SendMessage कमांड का उपयोग करके, संदेश जोड़ता है।
2. उपभोक्ता को ReceiveMessag कमांड का उपयोग करके संदेश प्राप्त होता है।
3. जैसे ही कोई संदेश प्राप्त होता है, इसे थोड़ी देर के लिए फिर से प्राप्त करने के लिए अवरुद्ध कर दिया जाएगा।
4. संदेश को सफलतापूर्वक संसाधित करने के बाद, उपभोक्ता कतार से संदेश को हटाने के लिए DeleteMessage कमांड का उपयोग करता है। यदि प्रसंस्करण के दौरान कोई त्रुटि हुई या डिलीटमैसेज कमांड को कॉल नहीं किया गया, तो समय समाप्त होने के बाद संदेश वापस कतार में वापस आ जाएगा।

इस प्रकार, एक संदेश भेजने और संसाधित करने के लिए औसतन 3 एपीआई कॉल की आवश्यकता होती है।

SQS का उपयोग करते हुए, आप क्षेत्रों के बीच API कॉल + ट्रैफ़िक की संख्या के लिए भुगतान करते हैं। 10k कॉल की लागत $ 0.01 है, अर्थात्। 10k संदेशों (x3 एपीआई कॉल) के औसत के लिए आप $ 0.03 का भुगतान करते हैं। आप यहां अन्य क्षेत्रों में दरों को देख सकते हैं ।

संदेश भेजने की सेवा के आयोजन के लिए बड़ी संख्या में विकल्प हैं:

• RabbitMQ
• ActiveMQ
• ZMQ
• OpenMQ
• ईज़बर्ड (xmpp)

प्रत्येक विकल्प के पेशेवरों और विपक्ष हैं। हम RabbitMQ को AMQP प्रोटोकॉल के सबसे लोकप्रिय कार्यान्वयन में से एक के रूप में चुनेंगे।

1.2। RabbitMQ

1.2.1। परिनियोजन योजना

RabbitMQ स्थापित और डिफ़ॉल्ट सेटिंग्स वाला एक सर्वर बहुत अच्छा प्रदर्शन करता है। लेकिन तैनाती का यह संस्करण हमें शोभा नहीं देता, क्योंकि इस नोड के गिरने की स्थिति में, हम तुरंत कई समस्याएं प्राप्त कर सकते हैं:

1. संदेशों में महत्वपूर्ण डेटा का नुकसान;
2. निर्माता पर जानकारी का "संचय", जो कतार की बहाली के बाद उपभोक्ताओं के अधिभार को जन्म दे सकता है;
3. किसी समस्या का समाधान करते समय संपूर्ण एप्लिकेशन को रोकना।

परीक्षण में, हम नोड्स के बीच कतारों की प्रतिकृति के साथ सक्रिय-सक्रिय मोड में 2 नोड्स का उपयोग करेंगे। RabbitMQ के लिए, इसे प्रतिबिंबित कतार कहा जाता है।


ऐसी प्रत्येक कतार के लिए, एक मास्टर और दासों के एक सेट को परिभाषित किया जाता है, जहां कतार की एक प्रति संग्रहीत की जाती है। मास्टर नोड दुर्घटना की स्थिति में, गुलामों में से एक को मास्टर द्वारा चुना जाता है।

इस तरह की कतार बनाने के लिए, "एक्स-हा-पॉलिसी" पैरामीटर को घोषणा के दौरान सेट किया जाता है, जो इंगित करता है कि कतार की प्रतियां कहाँ संग्रहीत की जानी चाहिए। संभव 2 पैरामीटर मान

• सभी: कतार की प्रतियां क्लस्टर के सभी नोड्स पर संग्रहीत की जाएंगी। क्लस्टर में एक नया नोड जोड़ते समय, इस पर एक कॉपी बनाई जाएगी;
• नोड्स: प्रतियां केवल "x-ha-policy-params" पैरामीटर द्वारा निर्दिष्ट नोड्स पर बनाई जाएंगी।

आप यहाँ स्पष्ट रूप से कतारों के बारे में अधिक पढ़ सकते हैं: http://www.rabbitmq.com/ha.html

1.2.2। प्रदर्शन मापन तकनीक

इससे पहले, हमने जांच की कि परीक्षण पर्यावरण का आयोजन कैसे किया जाएगा। अब देखते हैं कि हम क्या और कैसे मापेंगे।
सभी मापों के लिए, m1.small इंस्टेंस (AWS) का उपयोग किया गया था।

हम कई माप निकालेंगे:
एक निश्चित मूल्य पर संदेश भेजने की गति, फिर प्राप्त करने की गति - जिससे हम बढ़ती हुई कतार के साथ प्रदर्शन की गिरावट की जांच करेंगे।

1. संदेशों को एक निश्चित मूल्य पर भेजने की गति, फिर प्राप्त करने की गति - जिससे हम बढ़ती कतार के साथ प्रदर्शन की गिरावट की जांच करेंगे।
2. एक कतार से संदेश भेजना और प्राप्त करना।
3. विभिन्न कतारों से संदेश भेजना और प्राप्त करना।
4. कतार पर असममित भार:

• एक। प्राप्त करने की तुलना में 10 गुना अधिक धागे तक कतार;
• ख। भेजे जाने की तुलना में कतार से 10 गुना अधिक धाराएँ प्राप्त होती हैं।

5. विभिन्न आकारों के संदेश भेजना और प्राप्त करना:

• एक। 16 बाइट्स;
• ख। 1 किलोबाइट;
• सी। 64 किलोबाइट (SQS के लिए अधिकतम)।

पहले को छोड़कर सभी परीक्षण 3 चरणों में किए जाएंगे:

1. वार्मिंग 2 सेकंड;
2. टेस्ट रन 15 सेकंड;
3. कतार की सफाई।

संदेश पावती

इस संपत्ति का उपयोग वितरण और संदेश प्रसंस्करण की पुष्टि करने के लिए किया जाता है। ऑपरेशन के दो तरीके हैं:

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

परीक्षण में, दूसरा मोड चुना जाता है, क्योंकि यह SQS के कार्य से मेल खाता है, जहां संदेश प्रसंस्करण दो कमांड द्वारा किया जाता है: ReceiveMessage और DeleteMessage।

बैच प्रसंस्करण

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

1.2.3। परीक्षण के परिणाम

लोड अनलोड परीक्षण

सारांश परिणाम:

लोड अनलोड परीक्षण		संदेश / एस	अनुरोध समय
			एवीजी एमएस	मिनट, एमएस	अधिकतम एमएस	90%, एमएस
SQS	उपभोग	198	25	17	721	28
	उपज	317	16	10	769	20
RabbitMQ	उपभोग	1293	3	0	3716	3
	उपज	1875	2	0	14,785	0

तालिका से पता चलता है कि SQS RabbitMQ की तुलना में अधिक स्थिर काम करता है, जिसमें 15 सेकंड के लिए संदेश भेजते समय विफलताएं हो सकती हैं! दुर्भाग्य से, हम तुरंत इस व्यवहार का कारण नहीं खोज सके, और परीक्षण में हम मानक सेटिंग्स का पालन करने की कोशिश करते हैं। इसी समय, RabbitMQ की औसत गति SQS की तुलना में लगभग 6 गुना अधिक है, और क्वेरी निष्पादन समय कई गुना कम है।

निम्न गति बनाम समय के वितरण के साथ ग्राफ हैं।




सामान्य तौर पर, कतार में संदेशों की संख्या में वृद्धि के साथ प्रदर्शन में कोई गिरावट नहीं देखी गई है, जिसका अर्थ है कि आप डर नहीं सकते कि जब प्राप्त नोड गिर जाते हैं, तो कतार एक अड़चन बन जाएगी।

समानांतर

कोई कम दिलचस्प एक साथ काम करने वाले थ्रेड्स की संख्या पर काम की गति की निर्भरता का परीक्षण नहीं है। SQS परीक्षा परिणाम की आसानी से भविष्यवाणी की जा सकती है: चूंकि HTTP प्रोटोकॉल पर काम किया जाता है और ज्यादातर समय कनेक्शन स्थापित करने में लगता है, तो, संभवतः, परिणाम थ्रेड्स की संख्या के साथ बढ़ना चाहिए, जो निम्न तालिका द्वारा अच्छी तरह से चित्रित किया गया है:

SQS संदेश / एस	धागे
	1	5	10	40
उपज	65	324	641	969
उपभोग	33	186	333	435

एक संदेश भेजने के लिए एक अनुरोध का औसत समय 16 एमएस है, और 29 एमएस प्राप्त करने के लिए।
यह भी देखा जा सकता है कि 1, 5, और 10 प्रवाह के लिए, निर्भरता रैखिक है, लेकिन 40 प्रवाह तक की वृद्धि के साथ, भेजने के लिए औसत गति 50% बढ़ जाती है और प्राप्त करने के लिए 30%, लेकिन औसत अनुरोध समय में काफी वृद्धि होती है: क्रमशः 43ms और 98ms।

RabbitMQ के लिए, गति संतृप्ति बहुत तेज़ है, पहले से ही 5 थ्रेड्स के साथ अधिकतम तक पहुँच गया है:

RabbitMQ थ्रेड्स		धागे
		1	5	10	40
उपज	गति, संदेश / एस	3086	3157	3083	3200
	विलंबता, एमएस	0	1	3	11
उपभोग	गति, संदेश / एस	272	811	820	798
	विलंबता, एमएस	3	6	12	51

परीक्षण के दौरान, एक विशेषता सामने आई थी: यदि भेजने के लिए 1 धागा और उसी समय में काम करने के लिए 1 धागा, तो संदेश प्राप्त करने की गति लगभग 0 हो जाती है, जबकि भेजने वाला धागा अधिकतम प्रदर्शन दिखाता है। समस्या को हल किया जाता है यदि संदर्भ को परीक्षण के प्रत्येक पुनरावृत्ति के बाद स्विच करने के लिए मजबूर किया जाता है, जबकि भेजने के थ्रूपुट कम हो जाते हैं, लेकिन क्वेरी निष्पादन समय की ऊपरी सीमा काफी कम हो जाती है। 1 धागे के साथ स्थानीय परीक्षणों से (भेजें / पढ़ें): 11000/25 बनाम 5000/1000।

इसके अतिरिक्त, हमने 5 थ्रेड्स के लिए कई कतारों के साथ RabbitMQ के लिए एक परीक्षण किया:

RabbitMQ	कतार
	1	5
उपज	3157	3489
उपभोग	811	880

यह देखा जा सकता है कि कई कतारों की गति थोड़ी अधिक है। 10 सूत्र के लिए सारांश परिणाम निम्नलिखित चित्र में प्रस्तुत किए गए हैं:


आकार

इस परीक्षण में, हम प्रेषित डेटा के आकार पर गति की निर्भरता पर विचार करते हैं।

RabbitMQ और SQS दोनों ने संदेश का आकार बढ़ाने के साथ भेजने और प्राप्त करने की गति में अपेक्षित गिरावट दिखाई। इसके अलावा, संदेश के आकार के साथ RabbitMQ में कतार अक्सर "जमा देता है" और अनुरोधों का जवाब नहीं देता है। यह अप्रत्यक्ष रूप से अनुमान की पुष्टि करता है कि यह हार्ड डिस्क के साथ काम करने से संबंधित है।

तुलनात्मक गति के परिणाम:


तुलनात्मक क्वेरी समय परिणाम:

2. लागत और सिफारिशों की गणना

यूरोपीय क्षेत्र में एक छोटे से उदाहरण के लिए $ 0.08 की अनुमानित लागत से, हमें दो-नोड कॉन्फ़िगरेशन + ट्रैफ़िक लागत में RabbitMQ के लिए $ 0.16 की कीमत मिलती है। SQS में, 10,000 संदेश भेजने और प्राप्त करने की लागत $ 0.03 है। हमें निम्नलिखित निर्भरता मिलती है:


प्रति घंटे 60 हजार संदेश लगभग 17 संदेश प्रति सेकंड है, जो कि SQS और RabbitMQ प्रदान करने की गति से बहुत कम है।

इस प्रकार, यदि आपके आवेदन में प्रति सेकंड 17 से कम संदेशों की औसत गति की आवश्यकता है, तो एसक्यूएस बेहतर है। यदि एप्लिकेशन की आवश्यकताएं अधिक हो रही हैं, तो यह समर्पित मैसेजिंग सर्वरों के लिए माइग्रेशन पथों पर विचार करने योग्य है।

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

RabMMQ का उपयोग करने का एक और कारण अनुरोध की विलंबता के लिए आवश्यकता हो सकती है, जो SQS की तुलना में कम परिमाण का एक आदेश है।

2.1। क्या RabbitMQ समाधान की लागत को कम करना संभव है?

लागत कम करने के दो तरीके हैं:

• क्लस्टर का उपयोग न करें।
• माइक्रो उदाहरण का उपयोग करें।

पहले मामले में, नोड के गिरने या पूरे सक्रिय क्षेत्र की स्थिति में क्लस्टर का एचए खो जाता है, लेकिन यह डरावना नहीं है यदि पूरे आवेदन को केवल एक ही क्षेत्र में होस्ट किया गया है।
दूसरे मामले में, सूक्ष्म उदाहरण संसाधनों में कटौती कर सकते हैं, अगर कुछ समय के लिए संसाधनों का उपयोग 100% के करीब है। यह दृढ़ता के उपयोग किए जाने पर कतार के संचालन को प्रभावित कर सकता है।

3. निष्कर्ष

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

धन्यवाद!

EPAM क्लाउड कंप्यूटिंग प्रतियोगिता केंद्र के लिए मैक्सिम ब्रूनर ( न्यूनतम ) के शोध के आधार पर लेख लिखा और अनुकूलित किया गया था