నేడు, Bitrix24 సేవలో వందల కొద్దీ గిగాబిట్‌ల ట్రాఫిక్ లేదు, లేదా దీనికి భారీ సర్వర్లు లేవు (అయినప్పటికీ, ఇప్పటికే ఉన్నవి చాలా తక్కువ). కానీ చాలా మంది ఖాతాదారులకు ఇది కంపెనీలో పని చేయడానికి ప్రధాన సాధనం; ఇది నిజమైన వ్యాపార-క్లిష్టమైన అప్లికేషన్. అందువల్ల, పడిపోవడానికి మార్గం లేదు. ఒకవేళ క్రాష్ జరిగితే, కానీ ఎవరూ ఏమీ గమనించనంత త్వరగా సేవ "కోలుకుంది"? మరియు పని నాణ్యత మరియు ఖాతాదారుల సంఖ్యను కోల్పోకుండా వైఫల్యాన్ని అమలు చేయడం ఎలా సాధ్యమవుతుంది? Bitrix24 వద్ద క్లౌడ్ సేవల డైరెక్టర్ అలెగ్జాండర్ డెమిడోవ్, ఉత్పత్తి యొక్క 7 సంవత్సరాలలో రిజర్వేషన్ వ్యవస్థ ఎలా అభివృద్ధి చెందింది అనే దాని గురించి మా బ్లాగ్ కోసం మాట్లాడారు.
“మేము 24 సంవత్సరాల క్రితం SaaS గా Bitrix7ని ప్రారంభించాము. ప్రధాన ఇబ్బంది బహుశా కిందిది కావచ్చు: ఇది SaaSగా పబ్లిక్‌గా ప్రారంభించబడటానికి ముందు, ఈ ఉత్పత్తి కేవలం బాక్స్డ్ సొల్యూషన్ ఆకృతిలో ఉంది. క్లయింట్లు దీన్ని మా నుండి కొనుగోలు చేసారు, వారి సర్వర్‌లలో హోస్ట్ చేసారు, కార్పొరేట్ పోర్టల్‌ని సెటప్ చేసారు - ఉద్యోగుల కమ్యూనికేషన్, ఫైల్ నిల్వ, టాస్క్ మేనేజ్‌మెంట్, CRM, అంతే. మరియు 2012 నాటికి, మేము దానిని SaaSగా ప్రారంభించాలని నిర్ణయించుకున్నాము, దానిని స్వయంగా నిర్వహించడం, తప్పు సహనం మరియు విశ్వసనీయతను నిర్ధారించడం. మేము మార్గంలో అనుభవాన్ని పొందాము, ఎందుకంటే అప్పటి వరకు మా వద్ద అది లేదు - మేము సాఫ్ట్‌వేర్ తయారీదారులు మాత్రమే, సర్వీస్ ప్రొవైడర్లు కాదు.
సేవను ప్రారంభించేటప్పుడు, తప్పు సహనం, విశ్వసనీయత మరియు సేవ యొక్క స్థిరమైన లభ్యతను నిర్ధారించడం చాలా ముఖ్యమైన విషయం అని మేము అర్థం చేసుకున్నాము, ఎందుకంటే మీకు సాధారణ సాధారణ వెబ్‌సైట్, స్టోర్ ఉంటే, ఉదాహరణకు, అది మీపై పడి అక్కడ కూర్చుని ఉంటుంది. ఒక గంట, మీరు మాత్రమే బాధపడతారు, మీరు ఆర్డర్‌లను కోల్పోతారు, మీరు క్లయింట్‌లను కోల్పోతారు, కానీ మీ క్లయింట్ కోసం, ఇది అతనికి చాలా క్లిష్టమైనది కాదు. అతను కలత చెందాడు, అయితే అతను వెళ్లి మరొక సైట్‌లో కొనుగోలు చేశాడు. మరియు ఇది సంస్థలోని అన్ని పనులు, కమ్యూనికేషన్లు, నిర్ణయాలు ముడిపడి ఉన్న అప్లికేషన్ అయితే, అతి ముఖ్యమైన విషయం ఏమిటంటే వినియోగదారుల నమ్మకాన్ని పొందడం, అంటే వారిని నిరాశపరచకూడదు మరియు పడకుండా ఉండకూడదు. ఎందుకంటే లోపల ఏదైనా పని చేయకపోతే అన్ని పనులు ఆగిపోతాయి.
Bitrix.24 SaaSగా
మేము 2011లో పబ్లిక్ లాంచ్‌కు ఒక సంవత్సరం ముందు మొదటి ప్రోటోటైప్‌ను రూపొందించాము. మేము దానిని ఒక వారంలో సమీకరించాము, దానిని చూశాము, తిప్పాము - అది కూడా పని చేస్తోంది. అంటే, మీరు ఫారమ్‌లోకి వెళ్లి, అక్కడ పోర్టల్ పేరును నమోదు చేయవచ్చు, కొత్త పోర్టల్ తెరవబడుతుంది మరియు వినియోగదారు బేస్ సృష్టించబడుతుంది. మేము దానిని చూశాము, ఉత్పత్తిని సూత్రప్రాయంగా అంచనా వేసాము, దానిని స్క్రాప్ చేసాము మరియు ఒక సంవత్సరం పాటు దానిని మెరుగుపరచడం కొనసాగించాము. మాకు పెద్ద పని ఉన్నందున: మేము రెండు వేర్వేరు కోడ్ బేస్‌లను తయారు చేయాలనుకోలేదు, మేము ప్రత్యేక ప్యాక్ చేయబడిన ఉత్పత్తికి, ప్రత్యేక క్లౌడ్ సొల్యూషన్‌లకు మద్దతు ఇవ్వకూడదనుకున్నాము - మేము అన్నింటినీ ఒకే కోడ్‌లో చేయాలనుకుంటున్నాము.
ఆ సమయంలో ఒక సాధారణ వెబ్ అప్లికేషన్ ఒక సర్వర్, దీనిలో కొన్ని PHP కోడ్ రన్ అవుతుంది, ఒక mysql డేటాబేస్, ఫైల్‌లు అప్‌లోడ్ చేయబడతాయి, పత్రాలు, చిత్రాలు అప్‌లోడ్ ఫోల్డర్‌లో ఉంచబడతాయి - బాగా, ఇవన్నీ పని చేస్తాయి. అయ్యో, దీన్ని ఉపయోగించి క్లిష్టమైన స్థిరమైన వెబ్ సేవను ప్రారంభించడం అసాధ్యం. అక్కడ, పంపిణీ చేయబడిన కాష్‌కి మద్దతు లేదు, డేటాబేస్ రెప్లికేషన్‌కు మద్దతు లేదు.
మేము అవసరాలను రూపొందించాము: ఇది విభిన్న స్థానాల్లో ఉండే సామర్థ్యం, ప్రతిరూపణకు మద్దతు ఇస్తుంది మరియు విభిన్న భౌగోళికంగా పంపిణీ చేయబడిన డేటా కేంద్రాలలో ఆదర్శంగా ఉంటుంది. ఉత్పత్తి లాజిక్ మరియు నిజానికి డేటా నిల్వను వేరు చేయండి. లోడ్‌కు అనుగుణంగా డైనమిక్‌గా స్కేల్ చేయగలగాలి మరియు స్టాటిక్స్‌ను పూర్తిగా తట్టుకోగలగాలి. ఈ పరిశీలనల నుండి, వాస్తవానికి, ఉత్పత్తికి సంబంధించిన అవసరాలు ఉద్భవించాయి, ఇది మేము సంవత్సరంలో శుద్ధి చేసాము. ఈ సమయంలో, ప్లాట్‌ఫారమ్‌లో, ఏకీకృతంగా మారినది - బాక్స్డ్ సొల్యూషన్‌ల కోసం, మా స్వంత సేవ కోసం - మేము మాకు అవసరమైన వాటికి మద్దతునిచ్చాము. ఉత్పత్తి స్థాయిలోనే mysql రెప్లికేషన్‌కు మద్దతు: అంటే, కోడ్‌ను వ్రాసే డెవలపర్ తన అభ్యర్థనలు ఎలా పంపిణీ చేయబడతాయో ఆలోచించడు, అతను మా apiని ఉపయోగిస్తాడు మరియు మాస్టర్‌ల మధ్య అభ్యర్థనలను వ్రాయడం మరియు చదవడం ఎలా సరిగ్గా పంపిణీ చేయాలో మాకు తెలుసు. మరియు బానిసలు.
మేము వివిధ క్లౌడ్ ఆబ్జెక్ట్ స్టోరేజ్‌ల కోసం ఉత్పత్తి స్థాయిలో మద్దతునిచ్చాము: గూగుల్ స్టోరేజ్, అమెజాన్ s3, ప్లస్ ఓపెన్ స్టాక్ స్విఫ్ట్‌కు మద్దతు. కాబట్టి, ఇది సేవగా మాకు మరియు ప్యాక్ చేయబడిన సొల్యూషన్‌తో పనిచేసే డెవలపర్‌లకు అనుకూలమైనది: వారు కేవలం పని కోసం మా APIని ఉపయోగిస్తే, ఫైల్ సిస్టమ్‌లో స్థానికంగా లేదా ఫైల్ ఎక్కడ సేవ్ చేయబడుతుందో వారు ఆలోచించరు. ఆబ్జెక్ట్ ఫైల్ నిల్వలో.
ఫలితంగా, మేము మొత్తం డేటా సెంటర్ స్థాయిలో రిజర్వ్ చేయాలని వెంటనే నిర్ణయించుకున్నాము. 2012లో, మేము పూర్తిగా Amazon AWSలో ప్రారంభించాము ఎందుకంటే ఈ ప్లాట్‌ఫారమ్‌తో మాకు ఇప్పటికే అనుభవం ఉంది - మా స్వంత వెబ్‌సైట్ అక్కడ హోస్ట్ చేయబడింది. ప్రతి ప్రాంతంలో Amazon అనేక లభ్యత జోన్‌లను కలిగి ఉంది - వాస్తవానికి, (వాటి పరిభాషలో) అనేక డేటా సెంటర్‌లు ఒకదానికొకటి ఎక్కువ లేదా తక్కువ స్వతంత్రంగా ఉంటాయి మరియు మొత్తం డేటా సెంటర్ స్థాయిలో రిజర్వ్ చేయడానికి మాకు అనుమతిస్తాయి: అది అకస్మాత్తుగా విఫలమైతే, డేటాబేస్‌లు మాస్టర్-మాస్టర్‌గా పునరావృతమవుతాయి, వెబ్ అప్లికేషన్ సర్వర్లు బ్యాకప్ చేయబడతాయి మరియు స్టాటిక్ డేటా s3 ఆబ్జెక్ట్ స్టోరేజ్‌కి తరలించబడుతుంది. లోడ్ సమతుల్యంగా ఉంది - ఆ సమయంలో అమెజాన్ ఎల్బ్ ద్వారా, కానీ కొంచెం తరువాత మేము మా స్వంత లోడ్ బ్యాలెన్సర్‌ల వద్దకు వచ్చాము, ఎందుకంటే మాకు మరింత క్లిష్టమైన తర్కం అవసరం.
వారు కోరుకున్నది వారికి లభించింది...
మేము నిర్ధారించాలనుకుంటున్న అన్ని ప్రాథమిక అంశాలు - సర్వర్‌ల యొక్క తప్పు సహనం, వెబ్ అప్లికేషన్‌లు, డేటాబేస్‌లు - అన్నీ బాగా పనిచేశాయి. సరళమైన దృశ్యం: మా వెబ్ అప్లికేషన్‌లలో ఒకటి విఫలమైతే, ప్రతిదీ సులభం - అవి బ్యాలెన్సింగ్ నుండి స్విచ్ ఆఫ్ చేయబడతాయి.
బ్యాలెన్సర్ (ఆ సమయంలో ఇది అమెజాన్ యొక్క ఎల్బ్) పనికిరాని మెషీన్‌లను అనారోగ్యకరమైనదిగా గుర్తించి, వాటిపై లోడ్ పంపిణీని నిలిపివేసింది. అమెజాన్ ఆటోస్కేలింగ్ పని చేసింది: లోడ్ పెరిగినప్పుడు, ఆటోస్కేలింగ్ సమూహానికి కొత్త యంత్రాలు జోడించబడ్డాయి, లోడ్ కొత్త యంత్రాలకు పంపిణీ చేయబడింది - అంతా బాగానే ఉంది. మా బ్యాలెన్సర్‌లతో, తర్కం దాదాపు ఒకే విధంగా ఉంటుంది: అప్లికేషన్ సర్వర్‌కు ఏదైనా జరిగితే, మేము దాని నుండి అభ్యర్థనలను తీసివేస్తాము, ఈ మెషీన్‌లను విసిరివేస్తాము, కొత్త వాటిని ప్రారంభించి పనిని కొనసాగిస్తాము. ఈ పథకం సంవత్సరాలుగా కొద్దిగా మారిపోయింది, కానీ పని చేస్తూనే ఉంది: ఇది సరళమైనది, అర్థమయ్యేలా ఉంది మరియు దానితో ఎటువంటి ఇబ్బందులు లేవు.
మేము ప్రపంచవ్యాప్తంగా పని చేస్తున్నాము, కస్టమర్ లోడ్ పీక్స్ పూర్తిగా భిన్నంగా ఉంటాయి మరియు స్నేహపూర్వక మార్గంలో, మేము మా సిస్టమ్‌లోని ఏదైనా భాగాలపై ఏ సమయంలోనైనా నిర్దిష్ట సేవా పనిని నిర్వహించగలగాలి - కస్టమర్‌లు గుర్తించలేరు. అందువల్ల, ఆపరేషన్ నుండి డేటాబేస్ను ఆపివేయడానికి మాకు అవకాశం ఉంది, రెండవ డేటా సెంటర్కు లోడ్ను పునఃపంపిణీ చేస్తుంది.
అవన్నీ ఎలా పని చేస్తాయి? — మేము ట్రాఫిక్‌ని పని చేసే డేటా సెంటర్‌కి మారుస్తాము - డేటా సెంటర్‌లో ఏదైనా ప్రమాదం జరిగితే, పూర్తిగా, ఇది ఒక డేటాబేస్‌తో మా ప్రణాళికాబద్ధమైన పని అయితే, మేము ఈ క్లయింట్‌లకు అందించే ట్రాఫిక్‌లో కొంత భాగాన్ని సస్పెండ్ చేస్తూ రెండవ డేటా సెంటర్‌కి మారుస్తాము. అది ప్రతిరూపం. రెండవ డేటా సెంటర్‌లో లోడ్ పెరిగినందున వెబ్ అప్లికేషన్‌ల కోసం కొత్త మెషీన్‌లు అవసరమైతే, అవి స్వయంచాలకంగా ప్రారంభమవుతాయి. మేము పనిని పూర్తి చేస్తాము, ప్రతిరూపణ పునరుద్ధరించబడుతుంది మరియు మేము మొత్తం లోడ్ని తిరిగి ఇస్తాము. మేము రెండవ DCలో కొంత పనిని ప్రతిబింబించాల్సిన అవసరం ఉంటే, ఉదాహరణకు, సిస్టమ్ అప్‌డేట్‌లను ఇన్‌స్టాల్ చేయండి లేదా రెండవ డేటాబేస్‌లో సెట్టింగ్‌లను మార్చండి, అప్పుడు, సాధారణంగా, మేము అదే విషయాన్ని మరొక దిశలో పునరావృతం చేస్తాము. మరియు ఇది ప్రమాదం అయితే, మేము ప్రతిదీ చిన్నవిషయంగా చేస్తాము: మేము మానిటరింగ్ సిస్టమ్‌లో ఈవెంట్-హ్యాండ్లర్స్ మెకానిజంను ఉపయోగిస్తాము. అనేక తనిఖీలు ట్రిగ్గర్ చేయబడి, స్థితి క్లిష్టంగా మారినట్లయితే, మేము ఈ హ్యాండ్లర్‌ను అమలు చేస్తాము, ఇది ఈ లేదా ఆ లాజిక్‌ని అమలు చేయగల హ్యాండ్లర్. ప్రతి డేటాబేస్ కోసం, ఏ సర్వర్ విఫలమైందో మరియు ట్రాఫిక్ అందుబాటులో లేకుంటే ఎక్కడికి మారాలి అని మేము పేర్కొంటాము. చారిత్రాత్మకంగా, మేము నాగియోస్ లేదా కొన్ని ఫోర్క్‌లను ఒక రూపంలో లేదా మరొక రూపంలో ఉపయోగిస్తాము. సూత్రప్రాయంగా, దాదాపు ఏ మానిటరింగ్ సిస్టమ్‌లోనైనా ఇలాంటి మెకానిజమ్స్ ఉన్నాయి; మేము ఇంకా సంక్లిష్టంగా దేనినీ ఉపయోగించము, కానీ బహుశా ఏదో ఒక రోజు మనం చేస్తాము. ఇప్పుడు పర్యవేక్షణ అందుబాటులో లేకపోవడంతో ప్రేరేపించబడింది మరియు ఏదైనా మారే సామర్థ్యాన్ని కలిగి ఉంది.
మనం అన్నీ రిజర్వ్ చేసుకున్నామా?
మాకు USA నుండి చాలా మంది క్లయింట్లు ఉన్నారు, ఐరోపా నుండి చాలా మంది క్లయింట్లు ఉన్నారు, తూర్పు - జపాన్, సింగపూర్ మరియు మొదలైన వాటికి దగ్గరగా ఉన్న చాలా మంది క్లయింట్లు ఉన్నారు. వాస్తవానికి, క్లయింట్ల యొక్క భారీ వాటా రష్యాలో ఉంది. అంటే, పని ఒక ప్రాంతంలో కాదు. వినియోగదారులు శీఘ్ర ప్రతిస్పందనను కోరుకుంటున్నారు, వివిధ స్థానిక చట్టాలను పాటించాల్సిన అవసరం ఉంది మరియు ప్రతి ప్రాంతంలో మేము రెండు డేటా సెంటర్‌లను రిజర్వ్ చేస్తాము, అలాగే కొన్ని అదనపు సేవలు ఉన్నాయి, ఇవి మళ్లీ ఒక ప్రాంతంలో ఉంచడానికి అనుకూలమైనవి - ఖాతాదారులకు ఈ ప్రాంతం పని చేస్తోంది. REST హ్యాండ్లర్లు, ఆథరైజేషన్ సర్వర్లు, మొత్తంగా క్లయింట్ యొక్క ఆపరేషన్ కోసం అవి తక్కువ క్లిష్టమైనవి, మీరు వాటిని చిన్న ఆమోదయోగ్యమైన ఆలస్యంతో మార్చవచ్చు, కానీ వాటిని ఎలా పర్యవేక్షించాలి మరియు ఏమి చేయాలి అనే దానిపై మీరు చక్రాన్ని తిరిగి ఆవిష్కరించడం ఇష్టం లేదు. వారితో. అందువల్ల, మేము అదనపు ఉత్పత్తులలో ఒకరకమైన సామర్థ్యాన్ని అభివృద్ధి చేయకుండా, ఇప్పటికే ఉన్న పరిష్కారాలను గరిష్టంగా ఉపయోగించడానికి ప్రయత్నిస్తున్నాము. మరియు ఎక్కడో మేము DNS స్థాయిలో స్విచ్చింగ్‌ని చిన్నగా ఉపయోగిస్తాము మరియు అదే DNS ద్వారా సేవ యొక్క జీవనోపాధిని మేము నిర్ణయిస్తాము. అమెజాన్ రూట్ 53 సేవను కలిగి ఉంది, కానీ ఇది మీరు ఎంట్రీలను చేయగల DNS మాత్రమే కాదు మరియు అంతే-ఇది మరింత సరళమైనది మరియు అనుకూలమైనది. దాని ద్వారా మీరు జియోలొకేషన్‌లతో జియో-డిస్ట్రిబ్యూటెడ్ సేవలను నిర్మించవచ్చు, క్లయింట్ ఎక్కడ నుండి వచ్చారో గుర్తించడానికి మరియు అతనికి నిర్దిష్ట రికార్డులను అందించడానికి మీరు దాన్ని ఉపయోగించినప్పుడు - దాని సహాయంతో మీరు ఫెయిల్‌ఓవర్ నిర్మాణాలను నిర్మించవచ్చు. అదే ఆరోగ్య-తనిఖీలు రూట్ 53లోనే కాన్ఫిగర్ చేయబడ్డాయి, మీరు పర్యవేక్షించబడే ముగింపు పాయింట్‌లను సెట్ చేయండి, కొలమానాలను సెట్ చేయండి, సేవ యొక్క “జీవనాన్ని” నిర్ణయించడానికి ఏ ప్రోటోకాల్‌లను సెట్ చేయండి - tcp, http, https; సేవ సజీవంగా ఉందో లేదో నిర్ణయించే తనిఖీల ఫ్రీక్వెన్సీని సెట్ చేయండి. మరియు DNS లోనే మీరు ఏది ప్రైమరీ, ఏది సెకండరీ, హెల్త్ చెక్ రూట్ 53 లోపల ట్రిగ్గర్ చేయబడితే ఎక్కడ మారాలి అని మీరు పేర్కొంటారు. ఇవన్నీ కొన్ని ఇతర సాధనాలతో చేయవచ్చు, అయితే ఇది ఎందుకు సౌకర్యవంతంగా ఉంటుంది - మేము దానిని సెట్ చేసాము ఒకసారి పైకి లేచి, ఆపై మనం ఎలా తనిఖీలు చేస్తాం, ఎలా మారతాము అనే దాని గురించి అస్సలు ఆలోచించకండి: ప్రతిదీ దాని స్వంతదానిపై పని చేస్తుంది.
మొదటి "కానీ": మార్గం 53ని ఎలా మరియు దేనితో రిజర్వ్ చేసుకోవాలి? ఎవరికి తెలుసు, అతనికి ఏదైనా జరిగితే? అదృష్టవశాత్తూ, మేము ఈ రేక్‌పై ఎప్పుడూ అడుగు పెట్టలేదు, కానీ మళ్లీ, మనం ఇంకా రిజర్వేషన్ చేయాల్సిన అవసరం ఉందని ఎందుకు అనుకున్నామో నా ముందు కథ ఉంటుంది. ఇక్కడ మేము ముందుగానే స్ట్రాస్ వేసుకున్నాము. రోజుకు చాలా సార్లు మేము రూట్ 53లో ఉన్న అన్ని జోన్‌లను పూర్తిగా అన్‌లోడ్ చేస్తాము. Amazon API వాటిని JSONలో సులభంగా పంపడానికి మిమ్మల్ని అనుమతిస్తుంది మరియు మేము దానిని మార్చే అనేక బ్యాకప్ సర్వర్‌లను కలిగి ఉన్నాము, కాన్ఫిగర్‌ల రూపంలో అప్‌లోడ్ చేస్తాము మరియు స్థూలంగా చెప్పాలంటే, బ్యాకప్ కాన్ఫిగరేషన్‌ను కలిగి ఉంటాము. ఏదైనా జరిగితే, DNS సెట్టింగ్‌ల డేటాను కోల్పోకుండానే మేము దానిని మాన్యువల్‌గా త్వరగా అమలు చేయవచ్చు.
రెండవ "కానీ": ఈ చిత్రంలో ఇంకా రిజర్వ్ చేయబడలేదు? బ్యాలెన్సర్ కూడా! ప్రాంతాల వారీగా మా ఖాతాదారుల పంపిణీ చాలా సులభం. మేము bitrix24.ru, bitrix24.com, .de డొమైన్‌లను కలిగి ఉన్నాము - ఇప్పుడు 13 విభిన్నమైనవి ఉన్నాయి, ఇవి వివిధ జోన్‌లలో పనిచేస్తాయి. మేము ఈ క్రింది వాటికి వచ్చాము: ప్రతి ప్రాంతానికి దాని స్వంత బ్యాలెన్సర్‌లు ఉన్నాయి. ఇది నెట్‌వర్క్‌లో పీక్ లోడ్ ఎక్కడ ఉందో దానిపై ఆధారపడి, ప్రాంతాల అంతటా పంపిణీ చేయడం మరింత సౌకర్యవంతంగా ఉంటుంది. ఇది ఒకే బ్యాలెన్సర్ స్థాయిలో వైఫల్యం అయితే, అది కేవలం సేవ నుండి తీసివేయబడుతుంది మరియు dns నుండి తీసివేయబడుతుంది. బ్యాలెన్సర్‌ల సమూహంతో ఏదైనా సమస్య ఉంటే, అవి ఇతర సైట్‌లలో బ్యాకప్ చేయబడతాయి మరియు వాటి మధ్య మారడం అదే రూట్53ని ఉపయోగించి జరుగుతుంది, ఎందుకంటే చిన్న TTL కారణంగా, మారడం గరిష్టంగా 2, 3, 5 నిమిషాల్లో జరుగుతుంది. .
మూడవ "కానీ": ఇంకా ఏమి రిజర్వ్ చేయబడలేదు? S3, సరైనది. మేము వినియోగదారుల కోసం నిల్వ చేసే ఫైల్‌లను s3లో ఉంచినప్పుడు, అది కవచం-కుట్లు అని మేము హృదయపూర్వకంగా విశ్వసించాము మరియు అక్కడ దేనినీ రిజర్వ్ చేయవలసిన అవసరం లేదు. కానీ పరిస్థితులు భిన్నంగా జరుగుతున్నాయని చరిత్ర చెబుతోంది. సాధారణంగా, Amazon S3ని ఒక ప్రాథమిక సేవగా అభివర్ణిస్తుంది, ఎందుకంటే మెషిన్ ఇమేజ్‌లు, configs, AMI ఇమేజ్‌లు, స్నాప్‌షాట్‌లను నిల్వ చేయడానికి Amazon S3ని ఉపయోగిస్తుంది... మరియు s3 క్రాష్ అయితే, ఈ 7 సంవత్సరాలలో ఒకసారి జరిగినట్లుగా, మనం ఉపయోగిస్తున్నంత కాలం. bitrix24, ఇది అభిమాని వలె అనుసరిస్తుంది - వర్చువల్ మెషీన్‌లను ప్రారంభించలేకపోవడం, api వైఫల్యం మరియు మొదలైనవి.
మరియు S3 పడిపోవచ్చు - ఇది ఒకసారి జరిగింది. అందువల్ల, మేము ఈ క్రింది పథకానికి వచ్చాము: కొన్ని సంవత్సరాల క్రితం రష్యాలో తీవ్రమైన పబ్లిక్ ఆబ్జెక్ట్ నిల్వ సౌకర్యాలు లేవు మరియు మా స్వంతంగా ఏదైనా చేసే ఎంపికను మేము పరిగణించాము ... అదృష్టవశాత్తూ, మేము దీన్ని చేయడం ప్రారంభించలేదు, ఎందుకంటే మేము మన దగ్గర లేని నైపుణ్యాన్ని త్రవ్వి, బహుశా గజిబిజి కావచ్చు. ఇప్పుడు Mail.ru s3-అనుకూల నిల్వను కలిగి ఉంది, Yandex దానిని కలిగి ఉంది మరియు అనేక ఇతర ప్రొవైడర్లు దానిని కలిగి ఉన్నారు. మొదట, బ్యాకప్ మరియు రెండవది, స్థానిక కాపీలతో పని చేసే సామర్థ్యాన్ని కలిగి ఉండాలనే ఆలోచనకు మేము చివరికి వచ్చాము. రష్యన్ ప్రాంతం కోసం ప్రత్యేకంగా, మేము Mail.ru హాట్‌బాక్స్ సేవను ఉపయోగిస్తాము, ఇది s3కి API అనుకూలంగా ఉంటుంది. అప్లికేషన్‌లోని కోడ్‌లో మాకు పెద్ద మార్పులు అవసరం లేదు మరియు మేము ఈ క్రింది మెకానిజం చేసాము: s3లో వస్తువుల సృష్టి/తొలగింపును ప్రేరేపించే ట్రిగ్గర్లు ఉన్నాయి, Amazon Lambda అనే సేవను కలిగి ఉంది - ఇది కోడ్ యొక్క సర్వర్‌లెస్ లాంచ్. నిర్దిష్ట ట్రిగ్గర్లు ప్రేరేపించబడినప్పుడు అది అమలు చేయబడుతుంది.
మేము దీన్ని చాలా సరళంగా చేసాము: మా ట్రిగ్గర్ మంటలు ఉంటే, మేము ఆబ్జెక్ట్‌ను Mail.ru నిల్వకు కాపీ చేసే కోడ్‌ను అమలు చేస్తాము. డేటా యొక్క స్థానిక కాపీలతో పనిని పూర్తిగా ప్రారంభించడానికి, మాకు రివర్స్ సింక్రొనైజేషన్ కూడా అవసరం, తద్వారా రష్యన్ సెగ్మెంట్‌లో ఉన్న క్లయింట్లు వారికి దగ్గరగా ఉండే నిల్వతో పని చేయవచ్చు. మెయిల్ దాని నిల్వలో ట్రిగ్గర్‌లను పూర్తి చేయబోతోంది - అవస్థాపన స్థాయిలో రివర్స్ సింక్రొనైజేషన్ చేయడం సాధ్యమవుతుంది, కానీ ప్రస్తుతానికి మేము దీన్ని మా స్వంత కోడ్ స్థాయిలో చేస్తున్నాము. క్లయింట్ ఫైల్‌ను పోస్ట్ చేసినట్లు మనం చూసినట్లయితే, కోడ్ స్థాయిలో మేము ఈవెంట్‌ను క్యూలో ఉంచుతాము, దాన్ని ప్రాసెస్ చేసి రివర్స్ రెప్లికేషన్ చేస్తాము. ఇది ఎందుకు చెడ్డది: మేము మా ఉత్పత్తి వెలుపల మా వస్తువులతో కొంత రకమైన పనిని చేస్తే, అంటే, కొన్ని బాహ్య మార్గాల ద్వారా, మేము దానిని పరిగణనలోకి తీసుకోము. అందువల్ల, నిల్వ స్థాయిలో ట్రిగ్గర్లు కనిపించే వరకు మేము చివరి వరకు వేచి ఉంటాము, తద్వారా మనం కోడ్‌ను ఎక్కడ నుండి అమలు చేసినా, మనకు వచ్చిన వస్తువు ఇతర దిశలో కాపీ చేయబడుతుంది.
కోడ్ స్థాయిలో, మేము ప్రతి క్లయింట్ కోసం రెండు నిల్వలను నమోదు చేస్తాము: ఒకటి ప్రధానమైనదిగా పరిగణించబడుతుంది, మరొకటి బ్యాకప్‌గా పరిగణించబడుతుంది. ప్రతిదీ సరిగ్గా ఉంటే, మేము మాకు దగ్గరగా ఉన్న నిల్వతో పని చేస్తాము: అంటే, అమెజాన్‌లో ఉన్న మా క్లయింట్లు, వారు S3తో పని చేస్తారు మరియు రష్యాలో పనిచేసే వారు హాట్‌బాక్స్‌తో పని చేస్తారు. ఫ్లాగ్ ట్రిగ్గర్ చేయబడితే, ఫెయిల్‌ఓవర్ కనెక్ట్ చేయబడాలి మరియు మేము క్లయింట్‌లను మరొక నిల్వకు మారుస్తాము. మేము ఈ పెట్టెను ప్రాంతాల వారీగా స్వతంత్రంగా తనిఖీ చేయవచ్చు మరియు వాటిని ముందుకు వెనుకకు మార్చవచ్చు. మేము దీన్ని ఇంకా ఆచరణలో ఉపయోగించలేదు, కానీ మేము ఈ మెకానిజం కోసం అందించాము మరియు ఏదో ఒక రోజు మనకు ఈ స్విచ్ అవసరం మరియు ఉపయోగకరంగా ఉంటుందని మేము భావిస్తున్నాము. ఇది ఇప్పటికే ఒకసారి జరిగింది.
ఓహ్, మరియు అమెజాన్ పారిపోయింది ...
ఈ ఏప్రిల్ రష్యాలో టెలిగ్రామ్ బ్లాకింగ్ ప్రారంభమైన వార్షికోత్సవాన్ని సూచిస్తుంది. దీని కింద అత్యంత ప్రభావితమైన ప్రొవైడర్ అమెజాన్. మరియు, దురదృష్టవశాత్తు, మొత్తం ప్రపంచం కోసం పనిచేసిన రష్యన్ కంపెనీలు మరింత బాధపడ్డాయి.
కంపెనీ గ్లోబల్ మరియు రష్యా దాని కోసం చాలా చిన్న సెగ్మెంట్ అయితే, 3-5% - బాగా, ఒక మార్గం లేదా మరొకటి, మీరు వాటిని త్యాగం చేయవచ్చు.
ఇది పూర్తిగా రష్యన్ కంపెనీ అయితే - ఇది స్థానికంగా ఉండాల్సిన అవసరం ఉందని నేను ఖచ్చితంగా అనుకుంటున్నాను - బాగా, ఇది వినియోగదారులకు సౌకర్యవంతంగా ఉంటుంది, సౌకర్యవంతంగా ఉంటుంది మరియు తక్కువ నష్టాలు ఉంటాయి.
ఇది ప్రపంచవ్యాప్తంగా పనిచేసే మరియు రష్యా నుండి మరియు ప్రపంచవ్యాప్తంగా ఎక్కడో ఒకచోట సమాన సంఖ్యలో క్లయింట్‌లను కలిగి ఉన్న కంపెనీ అయితే ఏమి చేయాలి? విభాగాల కనెక్టివిటీ ముఖ్యం, మరియు అవి ఒకదానికొకటి ఒక మార్గం లేదా మరొకదానితో పని చేయాలి.
మార్చి 2018 చివరిలో, Roskomnadzor అతిపెద్ద ఆపరేటర్‌లకు ఒక లేఖను పంపారు, వారు Zello మెసెంజర్‌ని బ్లాక్ చేయడానికి అనేక మిలియన్ల Amazon IPలను బ్లాక్ చేయాలని ప్లాన్ చేసారు. ఇదే ప్రొవైడర్‌లకు ధన్యవాదాలు - వారు ప్రతి ఒక్కరికీ లేఖను విజయవంతంగా లీక్ చేసారు మరియు అమెజాన్‌తో కనెక్షన్ విడిపోవచ్చని ఒక అవగాహన ఉంది. ఇది శుక్రవారం, మేము సర్వర్లు.రూ నుండి మా సహోద్యోగులకు భయాందోళనలతో ఈ పదాలతో పరిగెత్తాము: “మిత్రులారా, మాకు అనేక సర్వర్లు అవసరం, అవి రష్యాలో కాదు, అమెజాన్‌లో కాదు, ఉదాహరణకు, ఆమ్‌స్టర్‌డామ్‌లో ఎక్కడో ఉన్నాయి,” మనం ఏ విధంగానూ ప్రభావితం చేయలేని కొన్ని ఎండ్‌పాయింట్‌ల కోసం కనీసం ఏదో ఒకవిధంగా మన స్వంత VPN మరియు ప్రాక్సీని అక్కడ ఇన్‌స్టాల్ చేయగలిగేలా చేయడానికి, ఉదాహరణకు అదే s3 యొక్క ఎండ్‌పాంట్‌లు - మేము కొత్త సేవను పెంచడానికి మరియు వేరొకదాన్ని పొందడానికి ప్రయత్నించలేము. ip, మేము మీరు ఇంకా అక్కడికి చేరుకోవాలి. కేవలం కొద్ది రోజులలో, మేము ఈ సర్వర్‌లను సెటప్ చేసాము, వాటిని ప్రారంభించాము మరియు అమలు చేసాము మరియు సాధారణంగా, బ్లాకింగ్ ప్రారంభమైన క్షణం కోసం సిద్ధం చేసాము. రచ్చ మరియు భయాందోళనలను చూస్తూ RKN ఇలా అన్నాడు: "లేదు, మేము ఇప్పుడు దేనినీ నిరోధించము." (కానీ టెలిగ్రామ్ బ్లాక్ చేయబడటం ప్రారంభించిన క్షణం వరకు ఇది ఖచ్చితంగా ఉంది.) బైపాస్ సామర్థ్యాలను సెటప్ చేయడం మరియు నిరోధించడం ప్రవేశపెట్టబడలేదని తెలుసుకున్న తరువాత, మేము మొత్తం విషయాన్ని క్రమబద్ధీకరించడం ప్రారంభించలేదు. అవును, కేవలం సందర్భంలో.
మరియు 2019లో, మేము ఇప్పటికీ నిరోధించే పరిస్థితులలో జీవిస్తున్నాము. నేను నిన్న రాత్రి చూశాను: దాదాపు ఒక మిలియన్ IPలు బ్లాక్ చేయబడుతూనే ఉన్నాయి. నిజమే, అమెజాన్ దాదాపు పూర్తిగా అన్‌బ్లాక్ చేయబడింది, దాని గరిష్ట స్థాయికి ఇది 20 మిలియన్ల చిరునామాలకు చేరుకుంది... సాధారణంగా, వాస్తవం ఏమిటంటే పొందిక, మంచి పొందిక ఉండకపోవచ్చు. అకస్మాత్తుగా. సాంకేతిక కారణాల వల్ల ఇది ఉనికిలో ఉండకపోవచ్చు - మంటలు, ఎక్స్‌కవేటర్లు, అన్నీ. లేదా, మేము చూసినట్లుగా, పూర్తిగా సాంకేతికమైనది కాదు. అందువల్ల, పెద్ద మరియు పెద్ద ఎవరైనా, వారి స్వంత ASలతో, బహుశా దీన్ని ఇతర మార్గాల్లో నిర్వహించవచ్చు - డైరెక్ట్ కనెక్ట్ మరియు ఇతర విషయాలు ఇప్పటికే l2 స్థాయిలో ఉన్నాయి. కానీ మాది లేదా అంతకంటే చిన్నది వంటి సాధారణ సంస్కరణలో, మీరు ఎక్కడైనా పెంచిన సర్వర్‌ల స్థాయిలో రిడెండెన్సీని కలిగి ఉండవచ్చు, ముందుగానే vpn, ప్రాక్సీలో కాన్ఫిగర్ చేయబడి, ఆ విభాగాలలోని వాటికి కాన్ఫిగరేషన్‌ను త్వరగా మార్చగల సామర్థ్యం ఉంటుంది. అవి మీ కనెక్టివిటీకి కీలకమైనవి. అమెజాన్ నిరోధించడం ప్రారంభమైనప్పుడు ఇది ఒకటి కంటే ఎక్కువసార్లు మాకు ఉపయోగపడింది; చెత్త సందర్భంలో, మేము వాటి ద్వారా S3 ట్రాఫిక్‌ను మాత్రమే అనుమతించాము, కానీ క్రమంగా ఇవన్నీ పరిష్కరించబడ్డాయి.
ఎలా రిజర్వ్ చేయాలి... మొత్తం ప్రొవైడర్?
మొత్తం అమెజాన్ డౌన్ అయిపోతే ప్రస్తుతం మాకు ఎలాంటి దృశ్యం లేదు. రష్యాకు సంబంధించి మనకు ఇదే విధమైన దృశ్యం ఉంది. రష్యాలో, మేము ఒక ప్రొవైడర్ ద్వారా హోస్ట్ చేయబడ్డాము, వీరి నుండి మేము అనేక సైట్‌లను కలిగి ఉండాలని ఎంచుకున్నాము. మరియు ఒక సంవత్సరం క్రితం మేము ఒక సమస్యను ఎదుర్కొన్నాము: ఇవి రెండు డేటా కేంద్రాలు అయినప్పటికీ, ప్రొవైడర్ యొక్క నెట్‌వర్క్ కాన్ఫిగరేషన్ స్థాయిలో ఇప్పటికే సమస్యలు ఉండవచ్చు, అది ఇప్పటికీ రెండు డేటా సెంటర్‌లను ప్రభావితం చేస్తుంది. మరియు మేము రెండు సైట్‌లలో అందుబాటులో ఉండకపోవచ్చు. అఫ్ కోర్స్ అదే జరిగింది. మేము లోపల నిర్మాణాన్ని పునఃపరిశీలించడం ముగించాము. ఇది పెద్దగా మారలేదు, కానీ రష్యా కోసం ఇప్పుడు మనకు రెండు సైట్లు ఉన్నాయి, అవి ఒకే ప్రొవైడర్ నుండి కాదు, కానీ రెండు వేర్వేరు వాటి నుండి. ఒకటి విఫలమైతే, మనం మరొకదానికి మారవచ్చు.
ఊహాత్మకంగా, Amazon కోసం మేము మరొక ప్రొవైడర్ స్థాయిలో రిజర్వేషన్ యొక్క అవకాశాన్ని పరిశీలిస్తున్నాము; బహుశా Google, బహుశా మరెవరైనా కావచ్చు... కానీ ఇప్పటివరకు మేము ఆచరణలో గమనించాము, అమెజాన్‌లో ఒక లభ్యత జోన్ స్థాయిలో ప్రమాదాలు జరుగుతుండగా, మొత్తం ప్రాంతం స్థాయిలో ప్రమాదాలు చాలా అరుదు. అందువల్ల, మేము సిద్ధాంతపరంగా “అమెజాన్ ఈజ్ నాట్ అమెజాన్” రిజర్వేషన్ చేయవచ్చనే ఆలోచనను కలిగి ఉన్నాము, కానీ ఆచరణలో ఇది ఇంకా జరగలేదు.
ఆటోమేషన్ గురించి కొన్ని మాటలు
ఆటోమేషన్ ఎల్లప్పుడూ అవసరమా? ఇక్కడ డన్నింగ్-క్రుగర్ ప్రభావాన్ని గుర్తుకు తెచ్చుకోవడం సముచితం. “x” అక్షంలో మనం పొందే మన జ్ఞానం మరియు అనుభవం, మరియు “y” అక్షం మీద మన చర్యలపై విశ్వాసం ఉంటుంది. మొదట మనకు ఏమీ తెలియదు మరియు ఖచ్చితంగా తెలియదు. అప్పుడు మనకు కొంచెం తెలుసు మరియు మెగా-కాన్ఫిడెంట్ అవుతాము - ఇది "మూర్ఖత్వం యొక్క శిఖరం" అని పిలవబడేది, "చిత్తవైకల్యం మరియు ధైర్యం" చిత్రం ద్వారా బాగా వివరించబడింది. అప్పుడు మేము కొంచెం నేర్చుకున్నాము మరియు యుద్ధానికి సిద్ధంగా ఉన్నాము. అప్పుడు మనం కొన్ని మెగా-తీవ్రమైన తప్పులపైకి అడుగుపెట్టి, నిరాశ యొక్క లోయలో చిక్కుకుంటాము, మనకు ఏదైనా తెలిసినట్లు అనిపించినప్పుడు, కానీ వాస్తవానికి మనకు పెద్దగా తెలియదు. అప్పుడు, మేము అనుభవాన్ని పొందినప్పుడు, మనం మరింత నమ్మకంగా ఉంటాము.
కొన్ని ప్రమాదాలకు సంబంధించిన వివిధ ఆటోమేటిక్ స్విచ్‌ల గురించి మా లాజిక్ ఈ గ్రాఫ్ ద్వారా బాగా వివరించబడింది. మేము ప్రారంభించాము - ఏదైనా ఎలా చేయాలో మాకు తెలియదు, దాదాపు అన్ని పనులు చేతితో జరిగాయి. అప్పుడు మేము ప్రతిదానికీ ఆటోమేషన్‌ను జోడించగలమని మరియు ప్రశాంతంగా నిద్రపోవచ్చని మేము గ్రహించాము. మరియు అకస్మాత్తుగా మేము మెగా-రేక్‌పై అడుగు పెట్టాము: తప్పుడు పాజిటివ్ ప్రేరేపించబడుతుంది మరియు మంచి మార్గంలో, మేము దీన్ని చేయనప్పుడు ట్రాఫిక్‌ను ముందుకు వెనుకకు మారుస్తాము. పర్యవసానంగా, ప్రతిరూపం విచ్ఛిన్నమవుతుంది లేదా మరేదైనా ఉంది-ఇది నిరాశ యొక్క లోయ. ఆపై మనం ప్రతి విషయాన్ని తెలివిగా సంప్రదించాలి అనే అవగాహనకు వస్తాము. అంటే, ఆటోమేషన్‌పై ఆధారపడటం అర్ధమే, తప్పుడు అలారాల అవకాశాన్ని అందిస్తుంది. కానీ! పర్యవసానాలు వినాశకరమైనవి అయితే, దానిని డ్యూటీ షిఫ్ట్‌కి, డ్యూటీలో ఉన్న ఇంజనీర్లకు వదిలివేయడం మంచిది, వారు నిజంగా ప్రమాదం జరిగిందని నిర్ధారించుకుంటారు మరియు పర్యవేక్షిస్తారు మరియు అవసరమైన చర్యలను మానవీయంగా నిర్వహిస్తారు...
తీర్మానం
7 సంవత్సరాల కాలంలో, మేము ఏదో పడిపోయినప్పుడు, భయాందోళనలు మరియు భయాందోళనలు ఉన్నాయి అనే వాస్తవం నుండి, సమస్యలు లేవు, పనులు మాత్రమే ఉన్నాయి, అవి తప్పక - మరియు పరిష్కరించగలవు - అనే అవగాహనకు చేరుకున్నాము. మీరు సేవను నిర్మిస్తున్నప్పుడు, పై నుండి చూడండి, సంభవించే అన్ని నష్టాలను అంచనా వేయండి. మీరు వాటిని వెంటనే చూసినట్లయితే, ముందుగానే రిడెండెన్సీని అందించండి మరియు లోపాలను తట్టుకునే మౌలిక సదుపాయాలను నిర్మించే అవకాశాన్ని అందించండి, ఎందుకంటే ఏదైనా విఫలమయ్యే మరియు సేవ యొక్క అసమర్థతకు దారితీసే ఏదైనా పాయింట్ ఖచ్చితంగా అలా చేస్తుంది. మరియు ఇన్‌ఫ్రాస్ట్రక్చర్‌లోని కొన్ని అంశాలు ఖచ్చితంగా విఫలం కావు అని మీకు అనిపించినప్పటికీ - అదే s3 లాగా, అవి చేయగలవని గుర్తుంచుకోండి. మరియు కనీసం సిద్ధాంతపరంగా, ఏదైనా జరిగితే మీరు వారితో ఏమి చేస్తారనే ఆలోచనను కలిగి ఉండండి. రిస్క్ మేనేజ్‌మెంట్ ప్లాన్‌ని కలిగి ఉండండి. మీరు ప్రతిదీ స్వయంచాలకంగా లేదా మాన్యువల్‌గా చేయడం గురించి ఆలోచిస్తున్నప్పుడు, నష్టాలను అంచనా వేయండి: ఆటోమేషన్ ప్రతిదీ మార్చడం ప్రారంభిస్తే ఏమి జరుగుతుంది - ఇది ప్రమాదంతో పోలిస్తే మరింత అధ్వాన్నమైన పరిస్థితికి దారితీయదా? ఆటోమేషన్ వాడకం మరియు విధిలో ఉన్న ఇంజనీర్ యొక్క ప్రతిచర్య మధ్య సహేతుకమైన రాజీని ఎక్కడో ఉపయోగించడం అవసరం కావచ్చు, వారు నిజమైన చిత్రాన్ని అంచనా వేస్తారు మరియు ఏదైనా అక్కడికక్కడే మార్చాల్సిన అవసరం ఉందా లేదా "అవును, కానీ ఇప్పుడు కాదు" అని అర్థం చేసుకుంటారు.
పరిపూర్ణత మరియు నిజమైన ప్రయత్నం, సమయం, డబ్బు మధ్య సహేతుకమైన రాజీ మీరు చివరికి పొందే పథకం కోసం ఖర్చు చేయవచ్చు.
ఈ టెక్స్ట్ సమావేశంలో అలెగ్జాండర్ డెమిడోవ్ యొక్క నివేదిక యొక్క నవీకరించబడిన మరియు విస్తరించిన సంస్కరణ .
మూలం: www.habr.com