🧑🏽‍🤝‍🧑🏻 🈂️ 🚺 हमारे एसआरई सप्ताह के दिनों से 6 व्यावहारिक कहानियां 👩🏿‍🤝‍👨🏼 🥄 🧚🏾

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

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

इतिहास नंबर 1। गोलंग और एचटीटीपी / 2

एक बेंचमार्क चलाना जो एक वेब एप्लिकेशन के लिए कई HTTP अनुरोध करता है, अप्रत्याशित परिणाम का कारण बना है। बेंचमार्क प्रक्रिया में एक सरल गो एप्लिकेशन इंन्ग्रेस / ओपनएस्टी के पीछे स्थित एक अन्य गो एप्लिकेशन को जाता है। जब HTTP / 2 सक्षम किया जाता है, तो हमें कुछ अनुरोधों के लिए कोड 400 के साथ त्रुटियां मिलती हैं। इस व्यवहार के कारण को समझने के लिए, हमने श्रृंखला से दूर के अंत में गो एप्लिकेशन को हटा दिया और इनग्रेड में एक साधारण स्थान बनाया, जो हमेशा 200 रिटर्न करता है। व्यवहार नहीं बदला है!

फिर कुबेरनेट्स पर्यावरण के बाहर स्क्रिप्ट को फिर से तैयार करने का निर्णय लिया गया - हार्डवेयर के एक अलग टुकड़े पर। परिणाम एक मेकफाइल था, जिसकी मदद से दो कंटेनरों को लॉन्च किया गया है: एक में - बेंचमार्क जो कि नेग्नेक्स में जाते हैं, दूसरे में - अपाचे में। दोनों HTTP / 2 को एक स्व-हस्ताक्षरित प्रमाण पत्र के साथ सुनते हैं। अंतिम संचालन समय इस भंडार में देखें।

concurrency=200 साथ मानदंड चलाएँ:

1.1। nginx:

 Completed 0 requests Completed 1000 requests Completed 2000 requests Completed 3000 requests Completed 4000 requests Completed 5000 requests Completed 6000 requests Completed 7000 requests Completed 8000 requests Completed 9000 requests ----- Bench results begin ----- Requests per second: 10336.09 Failed requests: 1623 ----- Bench results end -----

1.2। अपाचे:

 … ----- Bench results begin ----- Requests per second: 11427.60 Failed requests: 0 ----- Bench results end -----

हम मानते हैं कि यहाँ बिंदु Apache में HTTP / 2 का कम सख्त कार्यान्वयन है।

आइए संगोष्ठी के साथ प्रयास करें concurrency=1000 :

2.1। nginx:

 … ----- Bench results begin ----- Requests per second: 11274.92 Failed requests: 4205 ----- Bench results end -----

2.2। अपाचे:

 … ----- Bench results begin ----- Requests per second: 11211.48 Failed requests: 5 ----- Bench results end -----

उसी समय, हम ध्यान देते हैं कि परिणाम हर बार पुन : प्रस्तुत नहीं किए जाते हैं: कुछ लॉन्च बिना समस्याओं के गुजरते हैं।

गोलंग परियोजना के गितुब पर मुद्दों की तलाश में # 25009 और # 32441 का नेतृत्व किया गया। उनके माध्यम से हम पीआर 903 पर गए : HTTP / 2 को डिफ़ॉल्ट रूप से निष्क्रिय करना!

उपरोक्त वेब सर्वरों की वास्तुकला में गहराई से गोताखोरी किए बिना बेंचमार्क परिणामों की व्याख्या करना काफी कठिन है। एक विशिष्ट मामले में, निर्दिष्ट सेवा के लिए HTTP / 2 को अक्षम करना पर्याप्त था।

इतिहास नंबर २ पुरानी सहानुभूति और संतरी

एक परियोजना में, सिम्फनी PHP फ्रेमवर्क (v2.3) का एक बहुत पुराना संस्करण अभी भी काम कर रहा है। PHP में एक पुराना रेवेन क्लाइंट और एक स्व-लिखित वर्ग "किट में" से जुड़ा हुआ है, जो डीबगिंग को थोड़ा जटिल करता है।

कुबेरनेट्स में से एक को सेंट्री में सेवाओं के हस्तांतरण के बाद, इस परियोजना के आवेदन में त्रुटियों को ट्रैक करने के लिए उपयोग किया जाता था, घटनाओं का आना शुरू हो गया था। इस व्यवहार को पुन: पेश करने के लिए, हमने संतरी वेबसाइट से उदाहरणों का उपयोग किया, दो विकल्प लेकर और सेंट्री सेटिंग्स से डीएसएन की प्रतिलिपि बनाई। नेत्रहीन, सब कुछ काम किया: त्रुटि संदेश (कथित रूप से) एक के बाद एक भेजे गए थे।

जावास्क्रिप्ट चेक विकल्प:

 <!DOCTYPE html> <html> <body> <script src="https://browser.sentry-cdn.com/5.6.3/bundle.min.js" integrity="sha384-/Cqa/8kaWn7emdqIBLk3AkFMAHBk0LObErtMhO+hr52CntkaurEnihPmqYj3uJho" crossorigin="anonymous"> </script> <h2>JavaScript in Body</h2> <p id="demo">A Paragraph.</p> <button type="button" onclick="myFunction()">Try it</button> <script> Sentry.init({ dsn: 'http://33dddd76e9f0c4ddcdb51@sentry.kube-dev.test//12' }); try { throw new Error('Caught'); } catch (err) { Sentry.captureException(err); } </script> </body> </html>

इसी तरह पायथन में:

  from sentry_sdk import init, capture_message init("http://33dddd76e9f0c4ddcdb51@sentry.kube-dev.test//12") capture_message("Hello World") # Will create an event. raise ValueError()

हालांकि, वे संतरी में नहीं आए। संदेश भेजते समय, भ्रम पैदा किया जाता है कि संदेश भेजा गया था, क्योंकि ग्राहक तुरंत इस मुद्दे के लिए एक हैश उत्पन्न करते हैं।

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

इतिहास नंबर 3। RabbitMQ और तृतीय-पक्ष प्रॉक्सी

एक परियोजना में, ईवाटर क्लाउड का उपयोग नकद रजिस्टरों को जोड़ने के लिए किया जाता है। वास्तव में, यह एक प्रॉक्सी के रूप में काम करता है: ईवॉटर से POST अनुरोध सीधे RabbitMQ पर जाते हैं - WebSocket कनेक्शन पर कार्यान्वित STOMP प्लगइन के माध्यम से।

डेवलपर्स में से एक ने पोस्टमैन का उपयोग करके परीक्षण अनुरोध किए और 200 OK की अपेक्षित प्रतिक्रियाएं प्राप्त कीं, हालांकि, क्लाउड के माध्यम से अनुरोधों ने अप्रत्याशित 405 Method Not Allowed ।

200 ठीक है

 source: kubernetes namespace: kube-nginx-ingress host: kube-node-2 pod_name: nginx-2bpt7 container_name: nginx stream: stdout app: nginx controller-revision-hash: 5bdbfd564 pod-template-generation: 25 time: 2019-09-10T09:42:50+00:00 request_id: 1271dba228f0943ab2df0196ff0d7f67 user: client address: 100.200.300.400 protocol: HTTP/1.1 scheme: http method: POST host: rmq-review.kube-dev.client.domain path: /api/queues/vhost/queue.gen.eeeeffff111:1.onlinecassa:55556666/get request_query: referrer: user_agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/65.0.3325.181 Safari/537.36 content_kind: cacheable namespace: review ingress: stomp-ws service: rabbitmq service_port: stats vhost: rmq-review.kube-dev.client.domain location: / nginx_upstream_addr: 10.127.1.1:15672 nginx_upstream_bytes_received: 2538 nginx_upstream_response_time: 0.008 nginx_upstream_status: 200 bytes_received: 757 bytes_sent: 1254 request_time: 0 status: 200 upstream_response_time: 0 upstream_retries: 0

405 विधि अनुमति नहीं है

 source: kubernetes namespace: kube-nginx-ingress host: kube-node-1 pod_name: nginx-4xx6h container_name: nginx stream: stdout app: nginx controller-revision-hash: 5bdbfd564 pod-template-generation: 25 time: 2019-09-10T09:46:26+00:00 request_id: b8dd789604864c95b4af499ed6805630 user: client address: 200.100.300.400 protocol: HTTP/1.1 scheme: http method: POST host: rmq-review.kube-dev.client.domain path: /api/queues/vhost/queue.gen.ef7fb93387ca9b544fc1ecd581cad4a9:1.onlinecassa:55556666/get request_query: referrer: user_agent: ru.evotor.proxy/37 content_kind: cache-headers-not-present namespace: review ingress: stomp-ws service: rabbitmq service_port: stats vhost: rmq-review.kube-dev.client.domain location: / nginx_upstream_addr: 10.127.1.1:15672 nginx_upstream_bytes_received: 134 nginx_upstream_response_time: 0.004 nginx_upstream_status: 405 bytes_received: 878 bytes_sent: 137 request_time: 0 status: 405 upstream_response_time: 0 upstream_retries: 0

एवॉटर से Tcpdump अनुरोध

 200.100.300.400.21519 > 100.200.400.300: Flags [P.], cksum 0x8e29 (correct), seq 1:879, ack 1, win 221, options [nop,nop,TS val 2313007107 ecr 79097074], length 878: HTTP, length: 878 POST /api/queues//vhost/queue.gen.ef7fb93387ca9b544fc1ecd581cad4a9:1.onlinecassa:55556666/get HTTP/1.1 device-model: ST-5 device-os: android Accept-Encoding: gzip content-type: application/json; charset=utf-8 connection: close accept: application/json x-original-forwarded-for: 10.11.12.13 originhost: rmq-review.kube-dev.client.domain x-original-uri: /api/v2/apps/e114-aaef-bbbb-beee-abadada44ae/requests x-scheme: https accept-encoding: gzip user-agent: ru.evotor.proxy/37 Authorization: Basic X-Evotor-Store-Uuid: 20180417-73DC-40C9-80B7-00E990B77D2D X-Evotor-Device-Uuid: 20190909-A47B-40EA-806A-F7BC33833270 X-Evotor-User-Id: 01-000000000147888 Content-Length: 58 Host: rmq-review.kube-dev.client.domain {"count":1,"encoding":"auto","ackmode":"ack_requeue_true"}[!http] 12:53:30.095385 IP (tos 0x0, ttl 64, id 5512, offset 0, flags [DF], proto TCP (6), length 52) 100.200.400.300:80 > 200.100.300.400.21519: Flags [.], cksum 0xfa81 (incorrect -> 0x3c87), seq 1, ack 879, win 60, options [nop,nop,TS val 79097122 ecr 2313007107], length 0 12:53:30.096876 IP (tos 0x0, ttl 64, id 5513, offset 0, flags [DF], proto TCP (6), length 189) 100.200.400.300:80 > 200.100.300.400.21519: Flags [P.], cksum 0xfb0a (incorrect -> 0x03b9), seq 1:138, ack 879, win 60, options [nop,nop,TS val 79097123 ecr 2313007107], length 137: HTTP, length: 137 HTTP/1.1 405 Method Not Allowed Date: Tue, 10 Sep 2019 10:53:30 GMT Content-Length: 0 Connection: close allow: HEAD, GET, OPTIONS

Tcpdump कर्ल द्वारा किया गया अनुरोध

 777.10.74.11.61211 > 100.200.400.300:80: Flags [P.], cksum 0x32a8 (correct), seq 1:397, ack 1, win 2052, options [nop,nop,TS val 734012594 ecr 4012360530], length 396: HTTP, length: 396 POST /api/queues/%2Fvhost/queue.gen.ef7fb93387ca9b544fc1ecd581cad4a9:1.onlinecassa:55556666/get HTTP/1.1 Host: rmq-review.kube-dev.client.domain User-Agent: curl/7.54.0 Authorization: Basic = Content-Type: application/json Accept: application/json Content-Length: 58 {"count":1,"ackmode":"ack_requeue_true","encoding":"auto"}[!http] 12:40:11.001442 IP (tos 0x0, ttl 64, id 50844, offset 0, flags [DF], proto TCP (6), length 52) 100.200.400.300:80 > 777.10.74.11.61211: Flags [.], cksum 0x2d01 (incorrect -> 0xfa25), seq 1, ack 397, win 59, options [nop,nop,TS val 4012360590 ecr 734012594], length 0 12:40:11.017065 IP (tos 0x0, ttl 64, id 50845, offset 0, flags [DF], proto TCP (6), length 2621) 100.200.400.300:80 > 777.10.74.11.61211: Flags [P.], cksum 0x370a (incorrect -> 0x6872), seq 1:2570, ack 397, win 59, options [nop,nop,TS val 4012360605 ecr 734012594], length 2569: HTTP, length: 2569 HTTP/1.1 200 OK Date: Tue, 10 Sep 2019 10:40:11 GMT Content-Type: application/json Content-Length: 2348 Connection: keep-alive Vary: Accept-Encoding cache-control: no-cache vary: accept, accept-encoding, origin

एक इंजीनियर की प्रशिक्षित आंख तुरंत अंतर देखती है:

कर्ल: POST /api/queues/%2Fclient…
एवॉटर: POST /api/queues//client… क्वीन्स POST /api/queues//client…

बात यह थी कि एक मामले में एक %2Fvhost लिए) //vhost , और दूसरे में - %2Fvhost , जो अपेक्षित व्यवहार है:

 # rabbitmqctl list_vhosts Listing vhosts ... /vhost

इस विषय पर RabbitMQ परियोजना के मुद्दे में, डेवलपर बताते हैं:

हम%-प्रतिस्थापित नहीं करेंगे। यह URL पथ एन्कोडिंग का एक मानक तरीका है और उम्र के लिए रहा है। यह मानकर कि HTTP- आधारित टूल में%-कोडिंग चली जाएगी क्योंकि यहां तक कि ऐसे URL पथों को "सबसे दुर्भावनापूर्ण" माना जाने वाला सबसे लोकप्रिय ढाँचा शॉर्टसाइड और भोला है। डिफ़ॉल्ट वर्चुअल होस्ट नाम को किसी भी मान में बदला जा सकता है (जैसे कि वह जो स्लैश या किसी अन्य वर्ण का उपयोग नहीं करता है जिसे% -encoding की आवश्यकता होती है) और कम से कम RabbitMQ की Pivotal BOSH रिलीज़ के साथ, वैसे भी डिफ़ॉल्ट वर्चुअल होस्ट को अवसादग्रस्त समय में हटा दिया जाता है ।

समस्या को हमारे इंजीनियरों की आगे की भागीदारी के बिना हल किया गया था (ईवाटर की ओर से उनसे संपर्क करने के बाद)।

इतिहास नंबर ४। PostgreSQL में जीन

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

सुबह 10 बजे उस समय में वृद्धि होती है जब एप्लिकेशन डेटाबेस के साथ काम करने पर खर्च करता है। जैसा कि अपेक्षित था, कारण DBMS की धीमी प्रतिक्रियाओं में निहित है। हमारे लिए, प्रश्नों का विश्लेषण करना, समस्या क्षेत्रों की पहचान करना और "हैंगिंग" इंडेक्स एक समझने योग्य दिनचर्या है। हमारे द्वारा उपयोग किया जाने वाला ओकेमीटर इसमें बहुत मदद करता है: सर्वरों की स्थिति की निगरानी और जल्दी से अपना निर्माण करने की क्षमता के लिए दोनों मानक पैनल हैं - समस्याग्रस्त मीट्रिक के उत्पादन के साथ:

सीपीयू लोड ग्राफ यह दर्शाता है कि डेटाबेस में से एक 100% लोड है। क्यों? नया PostgreSQL पैनल संकेत देगा:

समस्याओं का कारण तुरंत स्पष्ट है - सीपीयू का मुख्य उपभोक्ता:

 SELECT u.* FROM users u WHERE u.id = ? & u.field_1 = ? AND u.field_2 LIKE '%somestring%' ORDER BY u.id DESC LIMIT ?

समस्याग्रस्त क्वेरी की कार्य योजना को ध्यान में रखते हुए, हमें पता चला कि तालिका के अनुक्रमित क्षेत्रों को फ़िल्टर करने से बहुत बड़ा चयन होता है: डेटाबेस को id और field_1 द्वारा 70 हजार से अधिक पंक्तियाँ प्राप्त field_1 , और फिर उनके बीच field_1 खोज करता है। यह पता चलता है कि LIKE एक सब्स्टीट्यूट टेक्स्ट डेटा की एक बड़ी मात्रा पर आधारित है, जो क्वेरी निष्पादन में एक गंभीर मंदी और CPU लोड में वृद्धि की ओर जाता है।

यहां आप सही रूप से देख सकते हैं कि एक वास्तुशिल्प समस्या से इंकार नहीं किया गया है (एक आवेदन तर्क सुधार या यहां तक कि एक पूर्ण-पाठ इंजन की आवश्यकता है ...), लेकिन पुन: कार्य के लिए समय नहीं है, और इसे 15 मिनट पहले जल्दी से काम करना चाहिए था। उसी समय, खोज शब्द वास्तव में एक पहचानकर्ता है (और एक अलग क्षेत्र में क्यों नहीं? ..), जो लाइनों की इकाइयों का उत्पादन करता है। वास्तव में, यदि हम इस पाठ क्षेत्र पर एक सूचकांक बना सकते हैं, तो अन्य सभी अनावश्यक हो जाएंगे।

अंतिम वर्तमान समाधान field_2 लिए GIN सूचकांक field_2 । उस दिन का नायक - वही "जिन्न"। संक्षेप में, GIN एक प्रकार का सूचकांक है जो पूर्ण-पाठ खोज में बहुत अच्छा प्रदर्शन करता है, इसे गुणात्मक रूप से तेज करता है। आप इसके बारे में अधिक पढ़ सकते हैं, उदाहरण के लिए, इस अद्भुत सामग्री में ।

जैसा कि आप देख सकते हैं, इस सरल ऑपरेशन ने अतिरिक्त भार को हटाने की अनुमति दी, और इसके साथ - और ग्राहक के लिए पैसे बचाए।

इतिहास नंबर ५। Nginx में कैशिंग s3

S3- संगत क्लाउड स्टोरेज लंबे समय से कई परियोजनाओं द्वारा उपयोग की जाने वाली प्रौद्योगिकियों की सूची पर दृढ़ता से आधारित है। यदि आपको अपनी साइट के लिए या तंत्रिका नेटवर्क डेटा के लिए विश्वसनीय छवि भंडारण की आवश्यकता है, तो अमेज़ॅन एस 3 एक बढ़िया विकल्प है। भंडारण की विश्वसनीयता और उच्च डेटा उपलब्धता (और "बाड़" की आवश्यकता की कमी) मनोरम है।

हालांकि, कभी-कभी पैसे बचाने के लिए - क्योंकि आमतौर पर एस 3 के लिए भुगतान अनुरोधों और यातायात के लिए जाता है - एक अच्छा समाधान भंडारण के सामने एक कैशिंग प्रॉक्सी सर्वर स्थापित करना है। यह विधि लागतों को कम कर देगी जब यह आता है, उदाहरण के लिए, उपयोगकर्ता अवतार को, जिनमें से प्रत्येक पृष्ठ पर कई हैं।

ऐसा लगता है कि यह nginx लेने से आसान है और कैशिंग, पुनर्मूल्यांकन, पृष्ठभूमि अद्यतन और अन्य लाठी के साथ परदे के पीछे सेट करना आसान है? हालांकि, कहीं और के रूप में, कुछ बारीकियां हैं ...

कैशिंग के साथ ऐसी समीपता का अनुमानित विन्यास इस तरह से देखा गया:

 proxy_cache_key $uri; proxy_cache_methods GET HEAD; proxy_cache_lock on; proxy_cache_revalidate on; proxy_cache_background_update on; proxy_cache_use_stale updating error timeout invalid_header http_500 http_502 http_503 http_504; proxy_cache_valid 200 1h; location ~ ^/(?<bucket>avatars|images)/(?<filename>.+)$ { set $upstream $bucket.s3.amazonaws.com; proxy_pass http://$upstream/$filename; proxy_set_header Host $upstream; proxy_cache aws; proxy_cache_valid 200 1h; proxy_cache_valid 404 60s; }

और सामान्य तौर पर, यह काम करता था: चित्रों को प्रदर्शित किया गया था, सब कुछ कैश के साथ ठीक था ... हालांकि, एडब्ल्यूएस एस 3 ग्राहकों के साथ समस्याएं सामने आईं। विशेष रूप से, aws-sdk-php से क्लाइंट ने काम करना बंद कर दिया। नेगनेक्स लॉग के विश्लेषण से पता चला कि अपस्ट्रीम ने HEAD अनुरोधों के लिए 403 कोड लौटाया, और प्रतिक्रिया में एक विशिष्ट त्रुटि थी: SignatureDoesNotMatch । जब हमने देखा कि नग्नेक्स ने ऊपर की तरफ एक GET अनुरोध किया है, तो सब कुछ जगह में गिर गया।

तथ्य यह है कि एस 3 क्लाइंट प्रत्येक अनुरोध पर हस्ताक्षर करता है, और सर्वर इस हस्ताक्षर की जांच करता है। सरल समीपता के मामले में, सब कुछ ठीक काम करता है: अनुरोध सर्वर पर अपरिवर्तित पहुंचता है। हालाँकि, जब कैशिंग सक्षम हो जाता है, तो nginx बैकएंड के साथ काम का अनुकूलन शुरू कर देता है और GET के साथ HEAD अनुरोधों को बदल देता है। तर्क सरल है: संपूर्ण ऑब्जेक्ट को पुनर्प्राप्त करना और सहेजना बेहतर है, और फिर कैश से सभी HEAD अनुरोध भी। हालाँकि, हमारे मामले में, अनुरोध को संशोधित नहीं किया जा सकता है, क्योंकि यह हस्ताक्षरित है।

अनिवार्य रूप से दो समाधान हैं:

प्रॉक्सी के माध्यम से S3 क्लाइंट को न चलाएं;
यदि यह "आवश्यक" है, तो proxy_cache_convert_head विकल्प बंद करें और कैश कुंजी में $request_method जोड़ें। इस मामले में, nginx HEAD अनुरोधों को "जैसा है" भेजता है और उन्हें अलग से प्रतिक्रिया देता है।

इतिहास नंबर ६। DDoS और Google उपयोगकर्ता सामग्री

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

इस तरह के तेज उछाल के कारण सीपीयू ओवररन हो गया:

एक त्वरित विश्लेषण से पता चला कि अनुरोध मुख्य डोमेन के लिए नहीं आए थे, लेकिन लॉग से यह स्पष्ट हो गया कि वे डिफ़ॉल्ट रूप में हो गए हैं। साथ ही, यह पता चला कि कई अमेरिकी उपयोगकर्ता रूसी संसाधन में आए थे। ऐसे हालात हमेशा तुरंत सवाल खड़े करते हैं।

नग्नेक्स लॉग से डेटा एकत्र करने के बाद, हमने बताया कि हम एक निश्चित बॉटनेट के साथ काम कर रहे हैं:

 35.222.30.127 US [15/Sep/2019:21:40:00 +0300] GET "http://example.ru/?ITPDH=XHJI" HTTP/1.1 301 178 "http://example.ru/ORQHYGJES" "Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9.1.3) Gecko/20090824 Firefox/3.5.3 (.NET CLR 3.5.30729)" "-" "upcache=-" "upaddr=-" "upstatus=-" "uplen=-" "uptime=-" spdy="" "loc=wide-closed.example.ru.undef" "rewrited=/?ITPDH=XHJI" "redirect=http://www.example.ru/?ITPDH=XHJI" ancient=1 cipher=- "LM=-;EXP=-;CC=-" 107.178.215.0 US [15/Sep/2019:21:40:00 +0300] GET "http://example.ru/?REVQSD=VQPYFLAJZ" HTTP/1.1 301 178 "http://www.usatoday.com/search/results?q=MLAJSBZAK" "Mozilla/5.0 (Windows; U; MSIE 7.0; Windows NT 6.0; en-US)" "-" "upcache=-" "upaddr=-" "upstatus=-" "uplen=-" "uptime=-" spdy="" "loc=wide-closed.example.ru.undef" "rewrited=/?REVQSD=VQPYFLAJZ" "redirect=http://www.example.ru/?REVQSD=VQPYFLAJZ" ancient=1 cipher=- "LM=-;EXP=-;CC=-" 107.178.215.0 US [15/Sep/2019:21:40:00 +0300] GET "http://example.ru/?MPYGEXB=OMJ" HTTP/1.1 301 178 "http://engadget.search.aol.com/search?q=MIWTYEDX" "Mozilla/5.0 (Windows; U; Windows NT 6.1; en; rv:1.9.1.3) Gecko/20090824 Firefox/3.5.3 (.NET CLR 3.5.30729)" "-" "upcache=-" "upaddr=-" "upstatus=-" "uplen=-" "uptime=-" spdy="" "loc=wide-closed.example.ru.undef" "rewrited=/?MPYGEXB=OMJ" "redirect=http://www.example.ru/?MPYGEXB=OMJ" ancient=1 cipher=- "LM=-;EXP=-;CC=-"

एक समझने योग्य पैटर्न लॉग में पता लगाया गया है:

सच्चा उपयोगकर्ता-एजेंट;
कैश में जाने से बचने के लिए एक यादृच्छिक GET तर्क के साथ रूट URL का अनुरोध;
संदर्भित इंगित करता है कि अनुरोध एक खोज इंजन से आया है।

हम पते एकत्र करते हैं और उनकी संबद्धता को सत्यापित करते हैं - वे सभी googleusercontent.com , दो सबनेट (107.178.192.0/18 और 34.64.0.0/10) के साथ। इन सबनेट में GCE वर्चुअल मशीन और विभिन्न सेवाएं शामिल हैं, जैसे पेज ट्रांसलेशन।

सौभाग्य से, हमला इतने लंबे समय (लगभग एक घंटे) तक नहीं चला और धीरे-धीरे कम हो गया। ऐसा लगता है कि Google के अंदर के सुरक्षात्मक एल्गोरिदम ने काम किया है, इसलिए समस्या को "स्वयं द्वारा" हल किया गया था।

यह हमला विनाशकारी नहीं था, लेकिन भविष्य के लिए उपयोगी प्रश्न उठाए गए:

एंटी-डीडोस काम क्यों नहीं किया? एक बाहरी सेवा का उपयोग किया जाता है, जिसके लिए हमने एक संबंधित अनुरोध भेजा है। हालाँकि, पते बहुत थे ...
भविष्य में खुद को इससे कैसे बचाएं? हमारे मामले में, भौगोलिक आधार पर पहुंच को बंद करने के विकल्प भी संभव हैं।

पुनश्च

हमारे ब्लॉग में भी पढ़ें:

हमारे एसआरई सप्ताह के दिनों से 6 व्यावहारिक कहानियां