హలో, నా పేరు Evgeniy. నేను Yandex.Market శోధన ఇన్‌ఫ్రాస్ట్రక్చర్‌లో పని చేస్తున్నాను. నేను మార్కెట్ లోపలి వంటగది గురించి హబ్ర్ కమ్యూనిటీకి చెప్పాలనుకుంటున్నాను - మరియు నేను చెప్పడానికి చాలా ఉన్నాయి. అన్నింటిలో మొదటిది, మార్కెట్ శోధన ఎలా పనిచేస్తుంది, ప్రక్రియలు మరియు నిర్మాణం. మేము అత్యవసర పరిస్థితులతో ఎలా వ్యవహరిస్తాము: ఒక సర్వర్ డౌన్ అయితే ఏమి జరుగుతుంది? అలాంటి సర్వర్లు 100 ఉంటే?
మేము ఒకేసారి అనేక సర్వర్‌లలో కొత్త కార్యాచరణను ఎలా అమలు చేస్తాము అని కూడా మీరు నేర్చుకుంటారు. మరియు వినియోగదారులకు ఎలాంటి అసౌకర్యం కలగకుండా మేము సంక్లిష్ట సేవలను ఉత్పత్తిలో నేరుగా ఎలా పరీక్షిస్తాము. సాధారణంగా, మార్కెట్ శోధన ఎలా పని చేస్తుంది, తద్వారా అందరికీ మంచి సమయం ఉంటుంది.
మా గురించి కొంచెం: మేము ఏ సమస్యను పరిష్కరిస్తాము
మీరు వచనాన్ని నమోదు చేసినప్పుడు, పారామితుల ద్వారా ఉత్పత్తి కోసం శోధించినప్పుడు లేదా వివిధ స్టోర్‌లలో ధరలను సరిపోల్చినప్పుడు, అన్ని అభ్యర్థనలు శోధన సేవకు పంపబడతాయి. శోధన అనేది మార్కెట్‌లో అతిపెద్ద సేవ.
మేము అన్ని శోధన అభ్యర్థనలను ప్రాసెస్ చేస్తాము: sites market.yandex.ru, beru.ru, Supercheck సేవ, Yandex.Advisor, మొబైల్ అప్లికేషన్‌ల నుండి. మేము yandex.ruలోని శోధన ఫలితాల్లో ఉత్పత్తి ఆఫర్‌లను కూడా చేర్చుతాము.
శోధన సేవ ద్వారా నా ఉద్దేశ్యం శోధన మాత్రమే కాదు, మార్కెట్‌లోని అన్ని ఆఫర్‌లతో కూడిన డేటాబేస్ కూడా. స్కేల్ ఇది: రోజుకు ఒక బిలియన్ కంటే ఎక్కువ శోధన అభ్యర్థనలు ప్రాసెస్ చేయబడతాయి. మరియు ప్రతిదీ త్వరగా పని చేయాలి, అంతరాయాలు లేకుండా మరియు ఎల్లప్పుడూ ఆశించిన ఫలితాన్ని ఉత్పత్తి చేయాలి.
ఏమిటి: మార్కెట్ ఆర్కిటెక్చర్
మార్కెట్ యొక్క ప్రస్తుత నిర్మాణాన్ని నేను క్లుప్తంగా వివరిస్తాను. దిగువ రేఖాచిత్రం ద్వారా దీనిని స్థూలంగా వివరించవచ్చు:
భాగస్వామి దుకాణం మా వద్దకు వస్తుందని అనుకుందాం. అతను నేను ఒక బొమ్మను విక్రయించాలనుకుంటున్నాను: ఈ దుష్ట పిల్లి స్కీకర్‌తో ఉంది. మరియు squeaker లేకుండా మరొక కోపంతో పిల్లి. మరియు కేవలం ఒక పిల్లి. అప్పుడు స్టోర్ మార్కెట్ శోధించే ఆఫర్‌లను సిద్ధం చేయాలి. స్టోర్ ఆఫర్‌లతో ప్రత్యేక xmlని రూపొందిస్తుంది మరియు అనుబంధ ఇంటర్‌ఫేస్ ద్వారా ఈ xmlకి మార్గాన్ని తెలియజేస్తుంది. ఇండెక్సర్ క్రమానుగతంగా ఈ xmlని డౌన్‌లోడ్ చేస్తుంది, లోపాల కోసం తనిఖీ చేస్తుంది మరియు మొత్తం సమాచారాన్ని భారీ డేటాబేస్లో సేవ్ చేస్తుంది.
అటువంటి సేవ్ చేయబడిన xmls చాలా ఉన్నాయి. ఈ డేటాబేస్ నుండి శోధన సూచిక సృష్టించబడింది. ఇండెక్స్ అంతర్గత ఆకృతిలో నిల్వ చేయబడుతుంది. సూచికను సృష్టించిన తర్వాత, లేఅవుట్ సేవ దానిని శోధన సర్వర్‌లకు అప్‌లోడ్ చేస్తుంది.
ఫలితంగా, స్క్వీకర్‌తో కోపంతో ఉన్న పిల్లి డేటాబేస్లో కనిపిస్తుంది మరియు పిల్లి సూచిక సర్వర్‌లో కనిపిస్తుంది.
సెర్చ్ ఆర్కిటెక్చర్ అనే భాగంలో పిల్లి కోసం మనం ఎలా శోధిస్తామో నేను మీకు చెప్తాను.
మార్కెట్ శోధన నిర్మాణం
మేము మైక్రోసర్వీస్‌ల ప్రపంచంలో జీవిస్తున్నాము: ప్రతి ఇన్‌కమింగ్ అభ్యర్థన చాలా సబ్‌క్వెరీలను కలిగిస్తుంది మరియు వాటి ప్రాసెసింగ్‌లో డజన్ల కొద్దీ సేవలు పాల్గొంటాయి. రేఖాచిత్రం కొన్ని మాత్రమే చూపిస్తుంది:
సరళీకృత అభ్యర్థన ప్రాసెసింగ్ పథకం
ప్రతి సేవకు అద్భుతమైన విషయం ఉంది - ప్రత్యేకమైన పేరుతో దాని స్వంత బ్యాలెన్సర్:
సేవను నిర్వహించడంలో బాలన్సర్ మాకు ఎక్కువ సౌలభ్యాన్ని అందిస్తుంది: ఉదాహరణకు, మీరు సర్వర్‌లను ఆఫ్ చేయవచ్చు, ఇది తరచుగా నవీకరణల కోసం అవసరం. బ్యాలెన్సర్ సర్వర్ అందుబాటులో లేదని చూస్తాడు మరియు అభ్యర్థనలను ఇతర సర్వర్లు లేదా డేటా సెంటర్‌లకు స్వయంచాలకంగా దారి మళ్లిస్తుంది. సర్వర్‌ని జోడించేటప్పుడు లేదా తీసివేసేటప్పుడు, సర్వర్ల మధ్య లోడ్ స్వయంచాలకంగా పునఃపంపిణీ చేయబడుతుంది.
బ్యాలెన్సర్ యొక్క ప్రత్యేక పేరు డేటా సెంటర్‌పై ఆధారపడి ఉండదు. సేవ A Bకి అభ్యర్థన చేసినప్పుడు, డిఫాల్ట్ బ్యాలెన్సర్ B అభ్యర్థనను ప్రస్తుత డేటా కేంద్రానికి దారి మళ్లిస్తుంది. సేవ అందుబాటులో లేకుంటే లేదా ప్రస్తుత డేటా సెంటర్‌లో ఉనికిలో లేకుంటే, అభ్యర్థన ఇతర డేటా కేంద్రాలకు దారి మళ్లించబడుతుంది.
అన్ని డేటా కేంద్రాల కోసం ఒకే FQDN సేవ Aని స్థానాల నుండి పూర్తిగా సంగ్రహించడానికి అనుమతిస్తుంది. సేవ B కోసం అతని అభ్యర్థన ఎల్లప్పుడూ ప్రాసెస్ చేయబడుతుంది. సేవ అన్ని డేటా సెంటర్లలో ఉన్నప్పుడు మినహాయింపు.
కానీ ఈ బాలన్సర్‌తో ప్రతిదీ అంత రోజీగా ఉండదు: మాకు అదనపు ఇంటర్మీడియట్ భాగం ఉంది. బ్యాలెన్సర్ అస్థిరంగా ఉండవచ్చు మరియు ఈ సమస్య పునరావృత సర్వర్ల ద్వారా పరిష్కరించబడుతుంది. A మరియు B సేవల మధ్య అదనపు ఆలస్యం కూడా ఉంది. కానీ ఆచరణలో ఇది 1 ms కంటే తక్కువ మరియు చాలా సేవలకు ఇది క్లిష్టమైనది కాదు.
ఊహించని వాటితో వ్యవహరించడం: సెర్చ్ సర్వీస్ బ్యాలెన్సింగ్ మరియు రెసిలెన్స్
కూలిపోయిందని ఊహించుకోండి: మీరు స్క్వీకర్‌తో పిల్లిని కనుగొనవలసి ఉంటుంది, కానీ సర్వర్ క్రాష్ అవుతుంది. లేదా 100 సర్వర్లు. ఎలా బయటపడాలి? మనం నిజంగా వినియోగదారుని పిల్లి లేకుండా వదిలేస్తామా?
పరిస్థితి భయానకంగా ఉంది, కానీ మేము దానికి సిద్ధంగా ఉన్నాము. నేను మీకు క్రమంలో చెబుతాను.
శోధన అవస్థాపన అనేక డేటా కేంద్రాలలో ఉంది:
రూపకల్పన చేస్తున్నప్పుడు, మేము ఒక డేటా సెంటర్‌ను మూసివేసే అవకాశాన్ని చేర్చుతాము. జీవితం ఆశ్చర్యాలతో నిండి ఉంది - ఉదాహరణకు, ఎక్స్‌కవేటర్ భూగర్భ కేబుల్‌ను కత్తిరించగలదు (అవును, అది జరిగింది). పీక్ లోడ్‌ను తట్టుకోవడానికి మిగిలిన డేటా సెంటర్‌లలోని సామర్థ్యం సరిపోతుంది.
ఒకే డేటా సెంటర్‌ని పరిశీలిద్దాం. ప్రతి డేటా సెంటర్‌లో ఒకే బ్యాలెన్సర్ ఆపరేషన్ స్కీమ్ ఉంటుంది:
ఒక బాలన్సర్ కనీసం మూడు భౌతిక సర్వర్లు. ఈ రిడెండెన్సీ విశ్వసనీయత కోసం చేయబడింది. బ్యాలెన్సర్లు HAProxలో అమలవుతాయి.
అధిక పనితీరు, తక్కువ వనరుల అవసరాలు మరియు విస్తృత కార్యాచరణ కారణంగా మేము HAProxని ఎంచుకున్నాము. మా శోధన సాఫ్ట్‌వేర్ ప్రతి సర్వర్‌లో నడుస్తుంది.
ఒక సర్వర్ విఫలమయ్యే అవకాశం తక్కువ. కానీ మీకు చాలా సర్వర్లు ఉంటే, కనీసం ఒకటి డౌన్ అయ్యే అవకాశం పెరుగుతుంది.
వాస్తవానికి ఇది జరుగుతుంది: సర్వర్లు క్రాష్. అందువల్ల, అన్ని సర్వర్ల స్థితిని నిరంతరం పర్యవేక్షించడం అవసరం. సర్వర్ ప్రతిస్పందించడం ఆపివేస్తే, అది ఆటోమేటిక్‌గా ట్రాఫిక్ నుండి డిస్‌కనెక్ట్ చేయబడుతుంది. ఈ ప్రయోజనం కోసం, HAProxy అంతర్నిర్మిత ఆరోగ్య తనిఖీని కలిగి ఉంది. ఇది HTTP అభ్యర్థన “/పింగ్”తో సెకనుకు ఒకసారి అన్ని సర్వర్‌లకు వెళుతుంది.
HAProxy యొక్క మరొక లక్షణం: ఏజెంట్-చెక్ అన్ని సర్వర్‌లను సమానంగా లోడ్ చేయడానికి మిమ్మల్ని అనుమతిస్తుంది. దీన్ని చేయడానికి, HAProxy అన్ని సర్వర్‌లకు కనెక్ట్ చేస్తుంది మరియు అవి 1 నుండి 100 వరకు ఉన్న ప్రస్తుత లోడ్‌పై ఆధారపడి వాటి బరువును తిరిగి ఇస్తాయి. ప్రాసెసింగ్ కోసం క్యూలో ఉన్న అభ్యర్థనల సంఖ్య మరియు ప్రాసెసర్‌పై లోడ్ ఆధారంగా బరువు లెక్కించబడుతుంది.
ఇప్పుడు పిల్లిని కనుగొనడం గురించి. ఇలాంటి అభ్యర్థనలలో శోధన ఫలితాలు: /శోధించాలా?టెక్స్ట్=కోపం+పిల్లి. శోధన వేగంగా ఉండాలంటే, మొత్తం క్యాట్ ఇండెక్స్ తప్పనిసరిగా RAMకి సరిపోవాలి. SSD నుండి చదవడం కూడా తగినంత వేగంగా లేదు.
ఒకప్పుడు, ఆఫర్ డేటాబేస్ చిన్నది మరియు ఒక సర్వర్ యొక్క RAM దానికి సరిపోతుంది. ఆఫర్ బేస్ పెరిగినందున, ప్రతిదీ ఈ RAMకి సరిపోదు మరియు డేటా రెండు భాగాలుగా విభజించబడింది: షార్డ్ 1 మరియు షార్డ్ 2.
కానీ ఇది ఎల్లప్పుడూ జరుగుతుంది: ఏదైనా పరిష్కారం, మంచిదే అయినా, ఇతర సమస్యలకు దారితీస్తుంది.
బాలన్సర్ ఇప్పటికీ ఏదైనా సర్వర్‌కి వెళ్లింది. కానీ రిక్వెస్ట్ వచ్చిన మెషీన్‌లో ఇండెక్స్‌లో సగం మాత్రమే ఉంది. మిగిలినవి ఇతర సర్వర్‌లలో ఉన్నాయి. అందువల్ల, సర్వర్ కొన్ని పొరుగు యంత్రానికి వెళ్లవలసి వచ్చింది. రెండు సర్వర్ల నుండి డేటాను స్వీకరించిన తర్వాత, ఫలితాలు మిళితం చేయబడ్డాయి మరియు మళ్లీ ర్యాంక్ చేయబడ్డాయి.
బ్యాలెన్సర్ అభ్యర్థనలను సమానంగా పంపిణీ చేస్తుంది కాబట్టి, అన్ని సర్వర్లు డేటాను పంపడమే కాకుండా రీ-ర్యాంకింగ్‌లో నిమగ్నమై ఉన్నాయి.
పొరుగు సర్వర్ అందుబాటులో లేకుంటే సమస్య ఏర్పడింది. "పొరుగు" సర్వర్‌గా విభిన్న ప్రాధాన్యతలతో అనేక సర్వర్‌లను పేర్కొనడం పరిష్కారం. ముందుగా, అభ్యర్థన ప్రస్తుత ర్యాక్‌లోని సర్వర్‌లకు పంపబడింది. ప్రతిస్పందన లేకుంటే, ఈ డేటా సెంటర్‌లోని అన్ని సర్వర్‌లకు అభ్యర్థన పంపబడుతుంది. చివరగా, అభ్యర్థన ఇతర డేటా కేంద్రాలకు వెళ్లింది.
ప్రతిపాదనల సంఖ్య పెరగడంతో, డేటాను నాలుగు భాగాలుగా విభజించారు. కానీ ఇది పరిమితి కాదు.
ప్రస్తుతం, ఎనిమిది ముక్కల కాన్ఫిగరేషన్ ఉపయోగించబడింది. అదనంగా, మరింత మెమరీని సేవ్ చేయడానికి, సూచిక శోధన భాగం (శోధన కోసం ఉపయోగించబడుతుంది) మరియు స్నిప్పెట్ భాగం (ఇది శోధనలో పాల్గొనదు)గా విభజించబడింది.
ఒక సర్వర్ ఒక షార్డ్ కోసం మాత్రమే సమాచారాన్ని కలిగి ఉంటుంది. అందువల్ల, పూర్తి సూచికను శోధించడానికి, మీరు వేర్వేరు షార్డ్‌లను కలిగి ఉన్న ఎనిమిది సర్వర్‌లలో వెతకాలి.
సర్వర్లు క్లస్టర్‌లుగా వర్గీకరించబడ్డాయి. ప్రతి క్లస్టర్‌లో ఎనిమిది శోధన ఇంజిన్‌లు మరియు ఒక స్నిప్పెట్ సర్వర్ ఉంటాయి.
స్నిప్పెట్ సర్వర్ స్టాటిక్ డేటాతో కీ-విలువ డేటాబేస్ను అమలు చేస్తుంది. పత్రాలను జారీ చేయడానికి అవి అవసరం, ఉదాహరణకు, స్క్వీకర్‌తో పిల్లి యొక్క వివరణ. శోధన సర్వర్ల మెమరీని లోడ్ చేయకుండా డేటా ప్రత్యేకంగా ప్రత్యేక సర్వర్‌కు బదిలీ చేయబడుతుంది.
డాక్యుమెంట్ IDలు ఒక ఇండెక్స్‌లో మాత్రమే ప్రత్యేకమైనవి కాబట్టి, స్నిప్పెట్‌లలో పత్రాలు లేని పరిస్థితి ఏర్పడవచ్చు. సరే, లేదా ఒక IDకి వేరే కంటెంట్ ఉంటుంది. అందువల్ల, శోధన పని చేయడానికి మరియు ఫలితాలు తిరిగి రావడానికి, మొత్తం క్లస్టర్‌లో స్థిరత్వం అవసరం. మేము స్థిరత్వాన్ని ఎలా పర్యవేక్షిస్తామో క్రింద నేను మీకు చెప్తాను.
శోధన ఈ క్రింది విధంగా రూపొందించబడింది: శోధన అభ్యర్థన ఎనిమిది సర్వర్‌లలో దేనికైనా రావచ్చు. అతను సర్వర్ 1కి వచ్చాడనుకుందాం. ఈ సర్వర్ అన్ని వాదనలను ప్రాసెస్ చేస్తుంది మరియు ఏమి మరియు ఎలా వెతకాలో అర్థం చేసుకుంటుంది. ఇన్‌కమింగ్ అభ్యర్థనపై ఆధారపడి, అవసరమైన సమాచారం కోసం సర్వర్ బాహ్య సేవలకు అదనపు అభ్యర్థనలను చేయవచ్చు. ఒక అభ్యర్థన తర్వాత బాహ్య సేవలకు గరిష్టంగా పది అభ్యర్థనలను పొందవచ్చు.
అవసరమైన సమాచారాన్ని సేకరించిన తర్వాత, ఆఫర్ డేటాబేస్లో శోధన ప్రారంభమవుతుంది. దీన్ని చేయడానికి, క్లస్టర్‌లోని మొత్తం ఎనిమిది సర్వర్‌లకు సబ్‌క్వెరీలు చేయబడతాయి.
ప్రతిస్పందనలను స్వీకరించిన తర్వాత, ఫలితాలు మిళితం చేయబడతాయి. చివరికి, ఫలితాలను రూపొందించడానికి స్నిప్పెట్ సర్వర్‌కు మరిన్ని సబ్‌క్వెరీలు అవసరం కావచ్చు.
క్లస్టర్‌లోని శోధన ప్రశ్నలు ఇలా కనిపిస్తాయి: /shard1?text=angry+cat. అదనంగా, ఫారమ్ యొక్క సబ్‌క్వెరీలు క్లస్టర్‌లోని అన్ని సర్వర్ల మధ్య సెకనుకు ఒకసారి నిరంతరం చేయబడతాయి: / స్థితి.
విచారణ / స్థితి సర్వర్ అందుబాటులో లేని పరిస్థితిని గుర్తిస్తుంది.
ఇది శోధన ఇంజిన్ వెర్షన్ మరియు ఇండెక్స్ వెర్షన్ అన్ని సర్వర్‌లలో ఒకేలా ఉండాలని కూడా నియంత్రిస్తుంది, లేకపోతే క్లస్టర్‌లో అస్థిరమైన డేటా ఉంటుంది.
ఒక స్నిప్పెట్ సర్వర్ ఎనిమిది శోధన ఇంజిన్‌ల నుండి అభ్యర్థనలను ప్రాసెస్ చేస్తున్నప్పటికీ, దాని ప్రాసెసర్ చాలా తేలికగా లోడ్ చేయబడింది. కాబట్టి, మేము ఇప్పుడు స్నిప్పెట్ డేటాను ప్రత్యేక సేవకు బదిలీ చేస్తున్నాము.
డేటాను బదిలీ చేయడానికి, మేము పత్రాల కోసం యూనివర్సల్ కీలను పరిచయం చేసాము. ఇప్పుడు ఒక కీని ఉపయోగించి మరొక పత్రం నుండి కంటెంట్ తిరిగి వచ్చే పరిస్థితికి ఇది అసాధ్యం.
కానీ మరొక నిర్మాణానికి మారడం ఇంకా పూర్తి కాలేదు. ఇప్పుడు మేము అంకితమైన స్నిప్పెట్ సర్వర్‌ను వదిలించుకోవాలనుకుంటున్నాము. ఆపై క్లస్టర్ నిర్మాణం నుండి పూర్తిగా దూరంగా ఉండండి. ఇది సులువుగా స్కేల్‌ను కొనసాగించడానికి మమ్మల్ని అనుమతిస్తుంది. అదనపు బోనస్ గణనీయమైన ఇనుము పొదుపు.
ఇప్పుడు సంతోషకరమైన ముగింపులతో భయానక కథలకు. సర్వర్ అందుబాటులో లేని అనేక సందర్భాలను పరిశీలిద్దాం.
భయంకరమైన ఏదో జరిగింది: ఒక సర్వర్ అందుబాటులో లేదు
ఒక సర్వర్ అందుబాటులో లేదని అనుకుందాం. అప్పుడు క్లస్టర్‌లోని మిగిలిన సర్వర్లు ప్రతిస్పందించడం కొనసాగించవచ్చు, కానీ శోధన ఫలితాలు అసంపూర్ణంగా ఉంటాయి.
స్థితి తనిఖీ ద్వారా / స్థితి ఒకటి అందుబాటులో లేదని పొరుగు సర్వర్లు అర్థం చేసుకున్నాయి. అందువల్ల, సంపూర్ణతను కొనసాగించడానికి, ప్రతి అభ్యర్థనకు క్లస్టర్‌లోని అన్ని సర్వర్లు /పింగ్ వారు కూడా అందుబాటులో లేరని బాలన్సర్‌కి ప్రతిస్పందించడం ప్రారంభిస్తారు. క్లస్టర్‌లోని అన్ని సర్వర్లు చనిపోయాయని తేలింది (ఇది నిజం కాదు). ఇది మా క్లస్టర్ స్కీమ్‌లోని ప్రధాన లోపం - అందుకే మేము దాని నుండి బయటపడాలనుకుంటున్నాము.
లోపంతో విఫలమైన అభ్యర్థనలు ఇతర సర్వర్‌లలోని బ్యాలెన్సర్ ద్వారా మళ్లీ పంపబడతాయి.
బ్యాలెన్సర్ వినియోగదారు ట్రాఫిక్‌ని డెడ్ సర్వర్‌లకు పంపడాన్ని కూడా ఆపివేస్తుంది, కానీ వారి స్థితిని తనిఖీ చేయడం కొనసాగిస్తుంది.
సర్వర్ అందుబాటులోకి వచ్చినప్పుడు, అది ప్రతిస్పందించడం ప్రారంభిస్తుంది /పింగ్. డెడ్ సర్వర్ల నుండి పింగ్‌లకు సాధారణ ప్రతిస్పందనలు రావడం ప్రారంభించిన వెంటనే, బ్యాలెన్సర్లు వినియోగదారు ట్రాఫిక్‌ను అక్కడికి పంపడం ప్రారంభిస్తారు. క్లస్టర్ ఆపరేషన్ పునరుద్ధరించబడింది, హుర్రే.
అధ్వాన్నంగా: చాలా సర్వర్లు అందుబాటులో లేవు
డేటా సెంటర్‌లోని సర్వర్‌లలో గణనీయమైన భాగం కత్తిరించబడింది. ఏమి చేయాలి, ఎక్కడ పరుగెత్తాలి? బాలన్సర్ మళ్ళీ రక్షించటానికి వస్తాడు. ప్రతి బాలన్సర్ ప్రస్తుత లైవ్ సర్వర్ల సంఖ్యను మెమరీలో నిరంతరం నిల్వ చేస్తుంది. ఇది ప్రస్తుత డేటా సెంటర్ ప్రాసెస్ చేయగల గరిష్ట ట్రాఫిక్ మొత్తాన్ని నిరంతరం గణిస్తుంది.
డేటా సెంటర్‌లోని అనేక సర్వర్లు డౌన్ అయినప్పుడు, ఈ డేటా సెంటర్ మొత్తం ట్రాఫిక్‌ను ప్రాసెస్ చేయలేదని బ్యాలెన్సర్ గుర్తిస్తాడు.
అప్పుడు అదనపు ట్రాఫిక్ యాదృచ్ఛికంగా ఇతర డేటా కేంద్రాలకు పంపిణీ చేయడం ప్రారంభమవుతుంది. ప్రతిదీ పనిచేస్తుంది, అందరూ సంతోషంగా ఉన్నారు.
మేము దీన్ని ఎలా చేస్తాము: విడుదలలను ప్రచురించడం
సేవలో చేసిన మార్పులను మేము ఎలా ప్రచురిస్తాము అనే దాని గురించి ఇప్పుడు మాట్లాడుదాం. ఇక్కడ మేము ప్రక్రియలను సరళీకృతం చేసే మార్గాన్ని తీసుకున్నాము: కొత్త విడుదలను విడుదల చేయడం దాదాపు పూర్తిగా ఆటోమేటెడ్.
ప్రాజెక్ట్‌లో నిర్దిష్ట సంఖ్యలో మార్పులు సేకరించబడినప్పుడు, కొత్త విడుదల స్వయంచాలకంగా సృష్టించబడుతుంది మరియు దాని నిర్మాణం ప్రారంభమవుతుంది.
అప్పుడు సేవ పరీక్షకు పంపబడుతుంది, ఇక్కడ ఆపరేషన్ యొక్క స్థిరత్వం తనిఖీ చేయబడుతుంది.
అదే సమయంలో, ఆటోమేటిక్ పనితీరు పరీక్ష ప్రారంభించబడింది. ఇది ప్రత్యేక సేవ ద్వారా నిర్వహించబడుతుంది. నేను ఇప్పుడు దాని గురించి మాట్లాడను - దాని వివరణ ప్రత్యేక కథనానికి అర్హమైనది.
పరీక్షలో ప్రచురణ విజయవంతమైతే, ప్రీస్టేబుల్‌లో విడుదల యొక్క ప్రచురణ స్వయంచాలకంగా ప్రారంభించబడుతుంది. ప్రెస్టేబుల్ అనేది సాధారణ వినియోగదారు ట్రాఫిక్‌ని నిర్దేశించే ప్రత్యేక క్లస్టర్. ఇది ఎర్రర్‌ను తిరిగి ఇస్తే, బ్యాలెన్సర్ ఉత్పత్తికి మళ్లీ అభ్యర్థన చేస్తుంది.
ప్రీస్టేబుల్‌లో, ప్రతిస్పందన సమయాలు కొలుస్తారు మరియు ఉత్పత్తిలో మునుపటి విడుదలతో పోల్చబడతాయి. ప్రతిదీ సరిగ్గా ఉంటే, అప్పుడు ఒక వ్యక్తి కనెక్ట్ చేస్తాడు: లోడ్ పరీక్ష యొక్క గ్రాఫ్‌లు మరియు ఫలితాలను తనిఖీ చేసి, ఆపై ఉత్పత్తికి వెళ్లడం ప్రారంభిస్తాడు.
వినియోగదారుకు ఆల్ ది బెస్ట్ వెళ్తుంది: A/B పరీక్ష
సేవకు మార్పులు నిజమైన ప్రయోజనాలను అందిస్తాయా అనేది ఎల్లప్పుడూ స్పష్టంగా ఉండదు. మార్పుల ఉపయోగాన్ని కొలవడానికి, వ్యక్తులు A/B పరీక్షతో ముందుకు వచ్చారు. Yandex.Market శోధనలో ఇది ఎలా పని చేస్తుందో నేను మీకు కొంచెం చెబుతాను.
కొత్త ఫంక్షనాలిటీని ఎనేబుల్ చేసే కొత్త CGI పారామీటర్‌ని జోడించడంతో ఇదంతా ప్రారంభమవుతుంది. మన పరామితి ఇలా ఉండనివ్వండి: market_new_functionality=1. ఫ్లాగ్ ఉన్నట్లయితే కోడ్‌లో మేము ఈ కార్యాచరణను ప్రారంభిస్తాము:
If (cgi.experiments.market_new_functionality) {
// enable new functionality
}కొత్త కార్యాచరణ ఉత్పత్తికి అందుబాటులోకి వచ్చింది.
A/B పరీక్షను ఆటోమేట్ చేయడానికి, వివరణాత్మక సమాచారాన్ని అందించే ప్రత్యేక సేవ ఉంది . సేవలో ఒక ప్రయోగం సృష్టించబడింది. ట్రాఫిక్ వాటా సెట్ చేయబడింది, ఉదాహరణకు, 15%. శాతాలు ప్రశ్నల కోసం కాదు, వినియోగదారుల కోసం సెట్ చేయబడ్డాయి. ప్రయోగం యొక్క వ్యవధి కూడా సూచించబడుతుంది, ఉదాహరణకు, ఒక వారం.
అనేక ప్రయోగాలను ఏకకాలంలో అమలు చేయవచ్చు. సెట్టింగ్‌లలో మీరు ఇతర ప్రయోగాలతో ఖండన సాధ్యమేనా అని పేర్కొనవచ్చు.
ఫలితంగా, సేవ స్వయంచాలకంగా వాదనను జోడిస్తుంది market_new_functionality=1 15% వినియోగదారులకు. ఇది ఎంచుకున్న కొలమానాలను కూడా స్వయంచాలకంగా గణిస్తుంది. ప్రయోగం పూర్తయిన తర్వాత, విశ్లేషకులు ఫలితాలను చూసి తీర్మానాలు చేస్తారు. కనుగొన్న వాటి ఆధారంగా, ఉత్పత్తి లేదా శుద్ధీకరణకు వెళ్లాలని నిర్ణయం తీసుకోబడుతుంది.
మార్కెట్ యొక్క తెలివిగల చేతి: ఉత్పత్తిలో పరీక్ష
మీరు ఉత్పత్తిలో కొత్త కార్యాచరణ యొక్క ఆపరేషన్‌ను పరీక్షించాల్సిన అవసరం ఉందని తరచుగా జరుగుతుంది, కానీ అధిక భారంలో ఉన్న "పోరాట" పరిస్థితులలో ఇది ఎలా ప్రవర్తిస్తుందో మీకు ఖచ్చితంగా తెలియదు.
ఒక పరిష్కారం ఉంది: CGI పారామితులలోని ఫ్లాగ్‌లు A/B పరీక్ష కోసం మాత్రమే కాకుండా, కొత్త కార్యాచరణను పరీక్షించడానికి కూడా ఉపయోగించవచ్చు.
సేవను ప్రమాదాలకు గురిచేయకుండా వేలాది సర్వర్‌లలో కాన్ఫిగరేషన్‌ను తక్షణమే మార్చడానికి మిమ్మల్ని అనుమతించే సాధనాన్ని మేము తయారు చేసాము. దాన్ని స్టాప్ ట్యాప్ అంటారు. లేఅవుట్ లేకుండా కొన్ని కార్యాచరణలను త్వరగా నిలిపివేయగలగడం అసలు ఆలోచన. అప్పుడు సాధనం విస్తరించింది మరియు మరింత క్లిష్టంగా మారింది.
సేవా ప్రవాహ రేఖాచిత్రం క్రింద ప్రదర్శించబడింది:
ఫ్లాగ్ విలువలు API ద్వారా సెట్ చేయబడ్డాయి. నిర్వహణ సేవ ఈ విలువలను డేటాబేస్లో నిల్వ చేస్తుంది. అన్ని సర్వర్లు ప్రతి పది సెకన్లకు ఒకసారి డేటాబేస్‌కి వెళ్లి, ఫ్లాగ్ విలువలను పంప్ చేయండి మరియు ప్రతి అభ్యర్థనకు ఈ విలువలను వర్తింపజేస్తాయి.
స్టాప్ ట్యాప్‌లో మీరు రెండు రకాల విలువలను సెట్ చేయవచ్చు:
1) షరతులతో కూడిన వ్యక్తీకరణలు. విలువల్లో ఒకటి నిజం అయినప్పుడు వర్తించండి. ఉదాహరణకి:
{
"condition":"IS_DC1",
"value":"3",
},
{
"condition": "CLUSTER==2 and IS_BERU",
"value": "4!"
}DC3 స్థానంలో అభ్యర్థన ప్రాసెస్ చేయబడినప్పుడు "1" విలువ వర్తించబడుతుంది. మరియు beru.ru సైట్ కోసం రెండవ క్లస్టర్‌లో అభ్యర్థనను ప్రాసెస్ చేసినప్పుడు విలువ "4".
2) షరతులు లేని విలువలు. షరతులు ఏవీ పాటించకపోతే డిఫాల్ట్‌గా వర్తించండి. ఉదాహరణకి:
విలువ, విలువ!
ఒక విలువ ఆశ్చర్యార్థక బిందువుతో ముగిస్తే, దానికి అధిక ప్రాధాన్యత ఇవ్వబడుతుంది.
CGI పరామితి పార్సర్ URLని అన్వయిస్తుంది. ఆపై స్టాప్ ట్యాప్ నుండి విలువలను వర్తింపజేస్తుంది.
కింది ప్రాధాన్యతలతో విలువలు వర్తించబడతాయి:
- స్టాప్ ట్యాప్ (ఆశ్చర్యార్థకం) నుండి పెరిగిన ప్రాధాన్యతతో.
- అభ్యర్థన నుండి విలువ.
- స్టాప్ ట్యాప్ నుండి డిఫాల్ట్ విలువ.
- కోడ్‌లో డిఫాల్ట్ విలువ.
షరతులతో కూడిన విలువలలో సూచించబడిన అనేక జెండాలు ఉన్నాయి - అవి మనకు తెలిసిన అన్ని దృశ్యాలకు సరిపోతాయి:
- డేటా సెంటర్.
- పర్యావరణం: ఉత్పత్తి, పరీక్ష, నీడ.
- స్థలం: మార్కెట్, బేరు.
- క్లస్టర్ సంఖ్య.
ఈ సాధనంతో, మీరు నిర్దిష్ట సర్వర్ల సమూహంలో (ఉదాహరణకు, ఒకే ఒక డేటా సెంటర్‌లో) కొత్త కార్యాచరణను ప్రారంభించవచ్చు మరియు మొత్తం సేవకు ఎటువంటి ప్రత్యేక ప్రమాదం లేకుండా ఈ కార్యాచరణ యొక్క ఆపరేషన్‌ను పరీక్షించవచ్చు. మీరు ఎక్కడో తీవ్రమైన తప్పు చేసినప్పటికీ, ప్రతిదీ పడిపోయింది మరియు మొత్తం డేటా సెంటర్ డౌన్ అయింది, బ్యాలెన్సర్లు ఇతర డేటా కేంద్రాలకు అభ్యర్థనలను దారి మళ్లిస్తారు. తుది వినియోగదారులు దేనినీ గమనించలేరు.
మీరు సమస్యను గమనించినట్లయితే, మీరు వెంటనే ఫ్లాగ్‌ను దాని మునుపటి విలువకు తిరిగి ఇవ్వవచ్చు మరియు మార్పులు వెనక్కి తీసుకోబడతాయి.
ఈ సేవ దాని ప్రతికూలతలను కూడా కలిగి ఉంది: డెవలపర్‌లు దీన్ని చాలా ఇష్టపడతారు మరియు తరచుగా అన్ని మార్పులను స్టాప్ ట్యాప్‌లోకి నెట్టడానికి ప్రయత్నిస్తారు. దుర్వినియోగాన్ని అరికట్టేందుకు ప్రయత్నిస్తున్నాం.
మీరు ఇప్పటికే ఉత్పత్తికి అందుబాటులోకి రావడానికి సిద్ధంగా ఉన్న స్థిరమైన కోడ్‌ని కలిగి ఉన్నప్పుడు స్టాప్ ట్యాప్ విధానం బాగా పని చేస్తుంది. అదే సమయంలో, మీకు ఇంకా సందేహాలు ఉన్నాయి మరియు మీరు "పోరాట" పరిస్థితుల్లో కోడ్‌ని తనిఖీ చేయాలనుకుంటున్నారు.
అయితే, అభివృద్ధి సమయంలో పరీక్షించడానికి స్టాప్ ట్యాప్ తగినది కాదు. డెవలపర్‌ల కోసం "షాడో క్లస్టర్" అని పిలవబడే ప్రత్యేక క్లస్టర్ ఉంది.
రహస్య పరీక్ష: షాడో క్లస్టర్
క్లస్టర్‌లలో ఒకదాని నుండి వచ్చిన అభ్యర్థనలు షాడో క్లస్టర్‌కు నకిలీ చేయబడతాయి. కానీ బ్యాలెన్సర్ ఈ క్లస్టర్ నుండి వచ్చే ప్రతిస్పందనలను పూర్తిగా విస్మరిస్తుంది. దాని ఆపరేషన్ యొక్క రేఖాచిత్రం క్రింద ప్రదర్శించబడింది.
మేము నిజమైన "పోరాట" పరిస్థితుల్లో ఉన్న టెస్ట్ క్లస్టర్‌ను పొందుతాము. సాధారణ వినియోగదారు ట్రాఫిక్ అక్కడికి వెళుతుంది. రెండు క్లస్టర్‌లలోని హార్డ్‌వేర్ ఒకేలా ఉంటుంది, కాబట్టి పనితీరు మరియు లోపాలను పోల్చవచ్చు.
మరియు బ్యాలెన్సర్ ప్రతిస్పందనలను పూర్తిగా విస్మరిస్తుంది కాబట్టి, తుది వినియోగదారులు షాడో క్లస్టర్ నుండి ప్రతిస్పందనలను చూడలేరు. అందువల్ల, తప్పు చేయడం భయానకం కాదు.
కనుగొన్న
కాబట్టి, మేము మార్కెట్ శోధనను ఎలా నిర్మించాము?
ప్రతిదీ సజావుగా జరిగేలా చేయడానికి, మేము కార్యాచరణను ప్రత్యేక సేవలుగా విభజిస్తాము. ఈ విధంగా మనం మనకు అవసరమైన భాగాలను మాత్రమే స్కేల్ చేయగలము మరియు భాగాలను సులభతరం చేయవచ్చు. మరొక బృందానికి ప్రత్యేక భాగాన్ని కేటాయించడం మరియు దానిపై పని చేయడానికి బాధ్యతలను పంచుకోవడం సులభం. మరియు ఈ విధానంతో ఇనుములో ముఖ్యమైన పొదుపులు ఒక స్పష్టమైన ప్లస్.
షాడో క్లస్టర్ కూడా మాకు సహాయపడుతుంది: మేము సేవలను అభివృద్ధి చేయవచ్చు, ప్రాసెస్‌లో వాటిని పరీక్షించవచ్చు మరియు వినియోగదారుకు భంగం కలిగించకూడదు.
బాగా, ఉత్పత్తిలో పరీక్ష, కోర్సు. వేలకొద్దీ సర్వర్‌లలో కాన్ఫిగరేషన్‌ని మార్చాలా? సులభం, స్టాప్ ట్యాప్‌ని ఉపయోగించండి. ఈ విధంగా మీరు వెంటనే రెడీమేడ్ కాంప్లెక్స్ సొల్యూషన్‌ను రూపొందించవచ్చు మరియు సమస్యలు తలెత్తితే స్థిరమైన సంస్కరణకు తిరిగి వెళ్లవచ్చు.
ఎప్పటికప్పుడు పెరుగుతున్న ఆఫర్‌లతో మనం మార్కెట్‌ను ఎలా వేగంగా మరియు స్థిరంగా మారుస్తామో నేను చూపించగలిగానని ఆశిస్తున్నాను. మేము సర్వర్ సమస్యలను ఎలా పరిష్కరిస్తాము, భారీ సంఖ్యలో అభ్యర్థనలతో వ్యవహరిస్తాము, సేవ యొక్క సౌలభ్యాన్ని మెరుగుపరుస్తాము మరియు పని ప్రక్రియలకు అంతరాయం కలిగించకుండా దీన్ని చేస్తాము.
మూలం: www.habr.com