చాలా స్టార్టప్‌లు దీని ద్వారా వెళ్ళాయి: ప్రతిరోజూ కొత్త వినియోగదారుల సమూహాలు నమోదు చేయబడతాయి మరియు సేవను కొనసాగించడానికి డెవలప్‌మెంట్ బృందం కష్టపడుతోంది.
ఇది కలిగి ఉండటం చాలా మంచి సమస్య, కానీ వందల వేల మంది వినియోగదారుల కోసం వెబ్ అప్లికేషన్‌ను జాగ్రత్తగా స్కేల్ చేయడం గురించి వెబ్‌లో చాలా స్పష్టమైన సమాచారం లేదు. సాధారణంగా అగ్ని పరిష్కారాలు లేదా అడ్డంకి పరిష్కారాలు (మరియు తరచుగా రెండూ) ఉన్నాయి. అందువల్ల, ప్రజలు తమ ఔత్సాహిక ప్రాజెక్ట్‌ను నిజంగా తీవ్రమైనదిగా స్కేల్ చేయడానికి బదులుగా క్లిచ్ చేసిన పద్ధతులను ఉపయోగిస్తారు.
సమాచారాన్ని ఫిల్టర్ చేయడానికి మరియు ప్రాథమిక సూత్రాన్ని వ్రాయడానికి ప్రయత్నిద్దాం. మేము మా కొత్త ఫోటో షేరింగ్ సైట్ గ్రామిన్‌స్టాను 1 నుండి 100 మంది వినియోగదారులకు దశలవారీగా స్కేల్ చేయబోతున్నాము.
ప్రేక్షకులు 10, 100, 1000, 10 మరియు 000 మందికి పెరిగినప్పుడు నిర్దిష్ట చర్యలు తీసుకోవాలో వ్రాసుకుందాం.
1 వినియోగదారు: 1 యంత్రం
దాదాపు ప్రతి అప్లికేషన్, అది వెబ్‌సైట్ లేదా మొబైల్ అప్లికేషన్ అయినా, మూడు కీలక భాగాలను కలిగి ఉంటుంది:
- API
- డేటాబేస్
- క్లయింట్ (మొబైల్ అప్లికేషన్ లేదా వెబ్‌సైట్)
డేటాబేస్ నిరంతర డేటాను నిల్వ చేస్తుంది. API ఈ డేటాకు మరియు దాని చుట్టూ ఉన్న అభ్యర్థనలను అందిస్తుంది. క్లయింట్ వినియోగదారుకు డేటాను ప్రసారం చేస్తుంది.
ఆర్కిటెక్చరల్ దృక్కోణం నుండి, క్లయింట్ మరియు API ఎంటిటీలు పూర్తిగా వేరు చేయబడితే, అప్లికేషన్‌ను స్కేలింగ్ చేయడం గురించి మాట్లాడటం చాలా సులభం అని నేను నిర్ధారణకు వచ్చాను.
మేము మొదట అప్లికేషన్‌ను రూపొందించడం ప్రారంభించినప్పుడు, మూడు భాగాలు ఒకే సర్వర్‌లో అమలు చేయబడతాయి. కొన్ని మార్గాల్లో, ఇది మా అభివృద్ధి వాతావరణాన్ని పోలి ఉంటుంది: ఒక ఇంజనీర్ డేటాబేస్, API మరియు క్లయింట్‌ను ఒకే మెషీన్‌లో అమలు చేస్తారు.
సిద్ధాంతపరంగా, దిగువ చూపిన విధంగా మేము దానిని ఒకే డిజిటల్ ఓషన్ డ్రాప్లెట్ లేదా AWS EC2 ఉదాహరణలో క్లౌడ్‌లో అమర్చవచ్చు:
ఒక సైట్‌లో ఒకటి కంటే ఎక్కువ మంది వినియోగదారులు ఉంటే, డేటాబేస్ లేయర్‌ను అంకితం చేయడం దాదాపు ఎల్లప్పుడూ అర్ధమే.
10 వినియోగదారులు: డేటాబేస్‌ను ప్రత్యేక స్థాయికి తరలించడం
డేటాబేస్‌ను అమెజాన్ RDS లేదా డిజిటల్ ఓషన్ మేనేజ్డ్ డేటాబేస్ వంటి మేనేజ్డ్ సర్వీసెస్‌గా విభజించడం వల్ల చాలా కాలం పాటు మనకు బాగా ఉపయోగపడుతుంది. ఇది ఒకే మెషీన్ లేదా EC2 ఉదాహరణలో స్వీయ-హోస్టింగ్ కంటే కొంచెం ఖరీదైనది, కానీ ఈ సేవలతో మీరు భవిష్యత్తులో ఉపయోగపడే అనేక ఉపయోగకరమైన పొడిగింపులను పొందుతారు: బహుళ-ప్రాంత బ్యాకప్, రీడ్ రెప్లికాస్, ఆటోమేటిక్ బ్యాకప్‌లు మరియు మరిన్ని.
సిస్టమ్ ఇప్పుడు ఇలా కనిపిస్తుంది:
100 మంది వినియోగదారులు: క్లయింట్‌ను ప్రత్యేక స్థాయికి తరలించడం
అదృష్టవశాత్తూ, మా మొదటి వినియోగదారులు మా అప్లికేషన్‌ను నిజంగా ఇష్టపడ్డారు. ట్రాఫిక్ మరింత స్థిరంగా మారుతోంది, కాబట్టి క్లయింట్‌ను ప్రత్యేక స్థాయికి తరలించడానికి ఇది సమయం. అని గమనించాలి వేరు స్కేలబుల్ అప్లికేషన్‌ను రూపొందించడంలో ఎంటిటీలు కీలకమైన అంశం. సిస్టమ్‌లోని ఒక భాగం ఎక్కువ ట్రాఫిక్‌ను పొందుతున్నందున, నిర్దిష్ట ట్రాఫిక్ ప్యాట్రన్‌ల ఆధారంగా సర్వీస్ స్కేల్‌లను నియంత్రించడానికి మేము దానిని విభజించవచ్చు.
అందుకే నేను క్లయింట్‌ని API నుండి వేరుగా భావించాలనుకుంటున్నాను. ఇది బహుళ ప్లాట్‌ఫారమ్‌ల కోసం అభివృద్ధి చేయడం గురించి ఆలోచించడం చాలా సులభం చేస్తుంది: వెబ్, మొబైల్ వెబ్, iOS, Android, డెస్క్‌టాప్ అప్లికేషన్‌లు, థర్డ్-పార్టీ సేవలు మొదలైనవి. అవన్నీ ఒకే APIని ఉపయోగించే క్లయింట్‌లు మాత్రమే.
ఉదాహరణకు, ఇప్పుడు మా వినియోగదారులు చాలా తరచుగా మొబైల్ అప్లికేషన్‌ను విడుదల చేయమని అడుగుతారు. మీరు క్లయింట్ మరియు API ఎంటిటీలను వేరు చేస్తే, ఇది సులభం అవుతుంది.
అటువంటి వ్యవస్థ ఇలా కనిపిస్తుంది:
1000 మంది వినియోగదారులు: లోడ్ బ్యాలెన్సర్‌ను జోడించండి
పనులు చూస్తున్నారు. గ్రామిన్‌స్టా వినియోగదారులు మరిన్ని ఫోటోలను అప్‌లోడ్ చేస్తున్నారు. రిజిస్ట్రేషన్ల సంఖ్య కూడా పెరుగుతోంది. మా ఏకైక API సర్వర్‌కు అన్ని ట్రాఫిక్‌లను అందుకోవడం చాలా కష్టంగా ఉంది. మరింత ఇనుము కావాలి!
లోడ్ బాలన్సర్ చాలా శక్తివంతమైన భావన. ముఖ్య ఆలోచన ఏమిటంటే, మేము API ముందు లోడ్ బ్యాలెన్సర్‌ను ఉంచుతాము మరియు ఇది వ్యక్తిగత సేవా సందర్భాలకు ట్రాఫిక్‌ను పంపిణీ చేస్తుంది. ఈ విధంగా మేము క్షితిజ సమాంతరంగా స్కేల్ చేస్తాము, అంటే మేము ఒకే కోడ్‌తో మరిన్ని సర్వర్‌లను జోడిస్తాము, మేము ప్రాసెస్ చేయగల అభ్యర్థనల సంఖ్యను పెంచుతాము.
మేము వెబ్ క్లయింట్ ముందు మరియు API ముందు వేర్వేరు లోడ్ బ్యాలెన్సర్‌లను ఉంచబోతున్నాము. దీని అర్థం మీరు API కోడ్ మరియు వెబ్ క్లయింట్ కోడ్‌ని అమలు చేసే బహుళ సందర్భాలను అమలు చేయవచ్చు. లోడ్ బ్యాలెన్సర్ తక్కువ లోడ్ అయిన సర్వర్‌కు అభ్యర్థనలను పంపుతుంది.
ఇక్కడ మనకు మరొక ముఖ్యమైన ప్రయోజనం లభిస్తుంది - రిడెండెన్సీ. ఒక ఉదాహరణ విఫలమైనప్పుడు (బహుశా ఓవర్‌లోడ్ లేదా క్రాష్ అయినప్పుడు), ఇన్‌కమింగ్ అభ్యర్థనలకు ప్రతిస్పందించడం కొనసాగించే ఇతరులతో మనకు మిగిలి ఉంటుంది. ఒకే ఒక్క ఉదాహరణ పని చేస్తే, వైఫల్యం విషయంలో మొత్తం సిస్టమ్ క్రాష్ అవుతుంది.
లోడ్ బాలన్సర్ ఆటోమేటిక్ స్కేలింగ్‌ను కూడా అందిస్తుంది. పీక్ లోడ్‌కు ముందు సందర్భాల సంఖ్యను పెంచడానికి మరియు వినియోగదారులందరూ నిద్రిస్తున్నప్పుడు దాన్ని తగ్గించడానికి మేము దీన్ని కాన్ఫిగర్ చేయవచ్చు.
లోడ్ బ్యాలెన్సర్‌తో, అభ్యర్థనల సంఖ్య పెరిగేకొద్దీ కొత్త ఉదాహరణలను జోడించడం ద్వారా API స్థాయిని దాదాపు నిరవధికంగా స్కేల్ చేయవచ్చు.
గమనిక. ప్రస్తుతం మా సిస్టమ్ AWSలో Heroku లేదా ఎలాస్టిక్ బీన్‌స్టాక్ వంటి PaaS కంపెనీలు అందించే వాటితో సమానంగా ఉంది (అందుకే అవి బాగా ప్రాచుర్యం పొందాయి). Heroku డేటాబేస్‌ను ప్రత్యేక హోస్ట్‌లో ఉంచుతుంది, ఆటో-స్కేలింగ్ లోడ్ బ్యాలెన్సర్‌ను నిర్వహిస్తుంది మరియు API నుండి విడిగా వెబ్ క్లయింట్‌ను హోస్ట్ చేయడానికి మిమ్మల్ని అనుమతిస్తుంది. ప్రారంభ దశ ప్రాజెక్ట్‌లు లేదా స్టార్టప్‌ల కోసం Herokuని ఉపయోగించడానికి ఇది ఒక గొప్ప కారణం - మీరు అన్ని ప్రాథమిక సేవలను బాక్స్ నుండి పొందగలరు.
10 మంది వినియోగదారులు: CDN
బహుశా మనం దీన్ని మొదటి నుంచీ చేసి ఉండవచ్చు. అభ్యర్థనలను ప్రాసెస్ చేయడం మరియు కొత్త ఫోటోలను ఆమోదించడం మా సర్వర్‌లపై చాలా ఒత్తిడిని కలిగించడం ప్రారంభించింది.
ఈ దశలో, మీరు స్టాటిక్ కంటెంట్ - చిత్రాలు, వీడియోలు మరియు మరిన్ని (AWS S3 లేదా డిజిటల్ ఓషన్ స్పేస్‌లు) నిల్వ చేయడానికి క్లౌడ్ సేవను ఉపయోగించాలి. సాధారణంగా, మా API చిత్రాలను అందించడం మరియు సర్వర్‌కు చిత్రాలను అప్‌లోడ్ చేయడం వంటి వాటిని నిర్వహించకుండా ఉండాలి.
క్లౌడ్ హోస్టింగ్ యొక్క మరొక ప్రయోజనం CDN (AWS దీన్ని యాడ్-ఆన్ క్లౌడ్‌ఫ్రంట్ అని పిలుస్తుంది, కానీ చాలా మంది క్లౌడ్ స్టోరేజ్ ప్రొవైడర్లు దీన్ని బాక్స్ వెలుపల అందిస్తారు). CDN ప్రపంచంలోని వివిధ డేటా సెంటర్లలో మన చిత్రాలను స్వయంచాలకంగా క్యాష్ చేస్తుంది.
మా ప్రధాన డేటా సెంటర్ ఒహియోలో ఉన్నప్పటికీ, ఎవరైనా జపాన్ నుండి చిత్రాన్ని అభ్యర్థిస్తే, క్లౌడ్ ప్రొవైడర్ కాపీని తయారు చేసి, వారి జపనీస్ డేటా సెంటర్‌లో నిల్వ చేస్తుంది. జపాన్‌లో ఈ చిత్రాన్ని అభ్యర్థించిన తర్వాతి వ్యక్తి దీన్ని చాలా వేగంగా స్వీకరిస్తారు. మేము ఫోటోలు లేదా వీడియోల వంటి పెద్ద ఫైల్‌లతో పని చేస్తున్నప్పుడు ఇది చాలా ముఖ్యమైనది, వీటిని డౌన్‌లోడ్ చేయడానికి మరియు గ్రహం అంతటా ప్రసారం చేయడానికి చాలా సమయం పడుతుంది.
100 మంది వినియోగదారులు: డేటా లేయర్‌ను స్కేలింగ్ చేయడం
CDN చాలా సహాయపడింది: ట్రాఫిక్ పూర్తి వేగంతో పెరుగుతోంది. ప్రసిద్ధ వీడియో బ్లాగర్ మావిడ్ మోబ్రిక్ ఇప్పుడే మాతో రిజిస్టర్ అయ్యాడు మరియు వారు చెప్పినట్లు అతని "కథ"ని పోస్ట్ చేసారు. లోడ్ బ్యాలెన్సర్‌కు ధన్యవాదాలు, API సర్వర్‌లలో CPU మరియు మెమరీ వినియోగం తక్కువగా ఉంచబడింది (పది API ఉదాహరణలు నడుస్తున్నాయి), కానీ మేము అభ్యర్థనలపై చాలా సమయములను పొందడం ప్రారంభించాము... ఈ ఆలస్యం ఎక్కడ నుండి వస్తోంది?
కొలమానాలను కొద్దిగా త్రవ్వినప్పుడు, డేటాబేస్ సర్వర్‌లోని CPU 80-90% లోడ్ చేయబడిందని మేము చూస్తాము. మేము పరిమితిలో ఉన్నాము.
డేటా లేయర్‌ను స్కేలింగ్ చేయడం బహుశా సమీకరణంలో అత్యంత కష్టతరమైన భాగం. API సర్వర్‌లు స్థితిలేని అభ్యర్థనలను అందిస్తాయి, కాబట్టి మేము మరిన్ని API ఉదాహరణలను జోడిస్తాము. ముక్కు అత్యధికులు డేటాబేస్లు దీన్ని చేయలేవు. మేము ప్రముఖ రిలేషనల్ డేటాబేస్ మేనేజ్‌మెంట్ సిస్టమ్స్ (PostgreSQL, MySQL, మొదలైనవి) గురించి మాట్లాడుతాము.
కాషింగ్
మా డేటాబేస్ పనితీరును పెంచడానికి సులభమైన మార్గాలలో ఒకటి కొత్త భాగాన్ని పరిచయం చేయడం: కాష్ లేయర్. అత్యంత సాధారణ కాషింగ్ పద్ధతి Redis లేదా Memcached వంటి ఇన్-మెమరీ కీ-విలువ రికార్డ్ స్టోర్. చాలా క్లౌడ్‌లు ఈ సేవల నిర్వహణ వెర్షన్‌ను కలిగి ఉన్నాయి: AWSలో ఎలాస్టికేచ్ మరియు Google క్లౌడ్‌లో మెమరీస్టోర్.
ఒక సేవ అదే సమాచారాన్ని తిరిగి పొందడానికి డేటాబేస్కు అనేక పదేపదే కాల్స్ చేసినప్పుడు కాష్ ఉపయోగకరంగా ఉంటుంది. ముఖ్యంగా, మేము డేటాబేస్‌ను ఒకసారి మాత్రమే యాక్సెస్ చేస్తాము, సమాచారాన్ని కాష్‌లో నిల్వ చేస్తాము మరియు దాన్ని మళ్లీ తాకము.
ఉదాహరణకు, మా Graminsta సేవలో, ఎవరైనా స్టార్ Mobrik యొక్క ప్రొఫైల్ పేజీకి వెళ్లిన ప్రతిసారీ, API సర్వర్ అతని ప్రొఫైల్ నుండి సమాచారం కోసం డేటాబేస్‌ను ప్రశ్నిస్తుంది. ఇది మళ్లీ మళ్లీ జరుగుతుంది. Mobrik యొక్క ప్రొఫైల్ సమాచారం ప్రతి అభ్యర్థనతో మారదు కాబట్టి, ఇది కాషింగ్ కోసం అద్భుతమైనది.
మేము Redisలోని డేటాబేస్ నుండి కీ ద్వారా ఫలితాలను కాష్ చేస్తాము user:id 30 సెకన్ల చెల్లుబాటు వ్యవధితో. ఇప్పుడు, ఎవరైనా Mobrik ప్రొఫైల్‌కి వెళ్లినప్పుడు, మేము ముందుగా Redisని తనిఖీ చేస్తాము మరియు డేటా ఉంటే, మేము దానిని నేరుగా Redis నుండి బదిలీ చేస్తాము. ఇప్పుడు సైట్‌లోని అత్యంత జనాదరణ పొందిన ప్రొఫైల్‌కు అభ్యర్థనలు ఆచరణాత్మకంగా మా డేటాబేస్‌ను లోడ్ చేయవు.
చాలా కాషింగ్ సేవల యొక్క మరొక ప్రయోజనం ఏమిటంటే అవి డేటాబేస్ సర్వర్‌ల కంటే స్కేల్ చేయడం సులభం. Redis అంతర్నిర్మిత Redis క్లస్టర్ మోడ్‌ను కలిగి ఉంది. లోడ్ బ్యాలెన్సర్‌ను పోలి ఉంటుంది, ఇది మీ Redis కాష్‌ని బహుళ మెషీన్‌లలో పంపిణీ చేయడానికి మిమ్మల్ని అనుమతిస్తుంది (అవసరమైతే వేలాది సర్వర్‌లలో).
దాదాపు అన్ని పెద్ద-స్థాయి అప్లికేషన్‌లు కాషింగ్‌ను ఉపయోగిస్తాయి; ఇది వేగవంతమైన APIలో పూర్తిగా అంతర్భాగం. వేగవంతమైన ప్రశ్న ప్రాసెసింగ్ మరియు మరింత ఉత్పాదక కోడ్ అన్నీ ముఖ్యమైనవి, కానీ కాష్ లేకుండా మిలియన్ల మంది వినియోగదారులకు సేవను స్కేల్ చేయడం దాదాపు అసాధ్యం.
ప్రతిరూపాలను చదవండి
డేటాబేస్కు ప్రశ్నల సంఖ్య బాగా పెరిగినప్పుడు, డేటాబేస్ మేనేజ్‌మెంట్ సిస్టమ్‌లో రీడ్ రెప్లికాస్‌ని జోడించడం మనం చేయగలిగే మరో విషయం. పైన వివరించిన నిర్వహించబడే సేవలతో, ఇది ఒక క్లిక్‌తో చేయవచ్చు. రీడ్ రెప్లికా ప్రధాన డేటాబేస్‌లో అలాగే ఉంటుంది మరియు SELECT స్టేట్‌మెంట్‌ల కోసం అందుబాటులో ఉంటుంది.
ఇప్పుడు మా సిస్టమ్ ఇక్కడ ఉంది:
తదుపరి చర్యలు
అప్లికేషన్ స్కేల్‌ను కొనసాగిస్తున్నందున, మేము వాటిని స్వతంత్రంగా స్కేల్ చేయడానికి సేవలను వేరు చేయడం కొనసాగిస్తాము. ఉదాహరణకు, మేము వెబ్‌సాకెట్‌లను ఉపయోగించడం ప్రారంభించినట్లయితే, వెబ్‌సాకెట్‌ల ప్రాసెసింగ్ కోడ్‌ను ప్రత్యేక సేవలోకి లాగడం అర్ధమే. మేము దీన్ని మా స్వంత లోడ్ బ్యాలెన్సర్ వెనుక ఉన్న కొత్త సందర్భాల్లో ఉంచవచ్చు, ఇది ఓపెన్ వెబ్‌సాకెట్ కనెక్షన్‌ల ఆధారంగా మరియు HTTP అభ్యర్థనల సంఖ్యతో సంబంధం లేకుండా పైకి క్రిందికి స్కేల్ చేయగలదు.
మేము డేటాబేస్ స్థాయిలో కూడా పరిమితులపై పోరాడుతూనే ఉంటాము. ఈ దశలోనే డేటాబేస్ విభజన మరియు భాగస్వామ్యాన్ని అధ్యయనం చేయడానికి ఇది సమయం. రెండు విధానాలకు అదనపు ఓవర్‌హెడ్ అవసరం, కానీ డేటాబేస్‌ను దాదాపు నిరవధికంగా స్కేల్ చేయడానికి మిమ్మల్ని అనుమతిస్తుంది.
మేము న్యూ రెలిక్ లేదా డేటాడాగ్ వంటి మానిటరింగ్ మరియు అనలిటిక్స్ సర్వీస్‌ను కూడా ఇన్‌స్టాల్ చేయాలనుకుంటున్నాము. ఇది స్లో క్వెరీలను గుర్తించడంలో మరియు ఎక్కడ అభివృద్ధి అవసరమో అర్థం చేసుకోవడంలో మీకు సహాయం చేస్తుంది. మేము స్కేల్ చేస్తున్నప్పుడు, మేము అడ్డంకులను కనుగొనడం మరియు వాటిని తొలగించడం-తరచుగా మునుపటి విభాగాల నుండి కొన్ని ఆలోచనలను ఉపయోగించడంపై దృష్టి పెట్టాలనుకుంటున్నాము.
వర్గాలు
ఈ పోస్ట్ ఒకరి ద్వారా ప్రేరణ పొందింది . ప్రాజెక్ట్‌ల ప్రారంభ దశల కోసం కథనాన్ని కొంచెం నిర్దిష్టంగా రూపొందించాలని మరియు ఒక విక్రేత నుండి దాన్ని విప్పాలని నేను కోరుకున్నాను. మీకు ఈ అంశంపై ఆసక్తి ఉంటే తప్పకుండా చదవండి.
ఫుట్ నోట్స్
- అనేక సందర్భాల్లో లోడ్ పంపిణీ పరంగా సారూప్యంగా ఉన్నప్పటికీ, Redis క్లస్టర్ యొక్క అంతర్లీన అమలు లోడ్ బ్యాలెన్సర్ నుండి చాలా భిన్నంగా ఉంటుంది.
మూలం: www.habr.com