Bitrix24: "വേഗത്തിൽ ഉയർത്തുന്നത് വീണതായി കണക്കാക്കില്ല"

ഇന്ന്, ബിട്രിക്സ് 24 സേവനത്തിന് നൂറുകണക്കിന് ഗിഗാബൈറ്റ് ട്രാഫിക് ഇല്ല, അല്ലെങ്കിൽ അതിന് ഒരു വലിയ സെർവറുകൾ ഇല്ല (തീർച്ചയായും, നിലവിലുള്ള കുറച്ച് എണ്ണം ഉണ്ടെങ്കിലും). എന്നാൽ പല ക്ലയന്റുകൾക്കും ഇത് കമ്പനിയിൽ ജോലി ചെയ്യുന്നതിനുള്ള പ്രധാന ഉപകരണമാണ്; ഇത് ഒരു യഥാർത്ഥ ബിസിനസ്സ് നിർണായക ആപ്ലിക്കേഷനാണ്. അതുകൊണ്ട് വീഴാൻ വഴിയില്ല. ക്രാഷ് സംഭവിച്ചാൽ എന്തുചെയ്യും, പക്ഷേ ആരും ഒന്നും ശ്രദ്ധിച്ചില്ലെങ്കിലും സേവനം വളരെ വേഗം "വീണ്ടെടുത്തു"? ജോലിയുടെ ഗുണനിലവാരവും ക്ലയന്റുകളുടെ എണ്ണവും നഷ്ടപ്പെടാതെ എങ്ങനെ പരാജയം നടപ്പിലാക്കാൻ കഴിയും? ബിട്രിക്സ് 24 ലെ ക്ലൗഡ് സേവനങ്ങളുടെ ഡയറക്ടർ അലക്സാണ്ടർ ഡെമിഡോവ്, ഉൽപ്പന്നത്തിന്റെ നിലനിൽപ്പിന്റെ 7 വർഷത്തിനിടയിൽ റിസർവേഷൻ സംവിധാനം എങ്ങനെ വികസിച്ചു എന്നതിനെക്കുറിച്ച് ഞങ്ങളുടെ ബ്ലോഗിനായി സംസാരിച്ചു.

“24 വർഷം മുമ്പ് ഞങ്ങൾ Bitrix7 ഒരു SaaS ആയി പുറത്തിറക്കി. പ്രധാന ബുദ്ധിമുട്ട് ഒരുപക്ഷേ ഇനിപ്പറയുന്നതായിരിക്കാം: ഇത് SaaS ആയി പരസ്യമായി സമാരംഭിക്കുന്നതിനുമുമ്പ്, ഈ ഉൽപ്പന്നം ഒരു പെട്ടി പരിഹാരത്തിന്റെ ഫോർമാറ്റിൽ നിലവിലുണ്ടായിരുന്നു. ക്ലയന്റുകൾ ഞങ്ങളിൽ നിന്ന് ഇത് വാങ്ങി, അവരുടെ സെർവറുകളിൽ ഹോസ്റ്റ് ചെയ്തു, ഒരു കോർപ്പറേറ്റ് പോർട്ടൽ സജ്ജീകരിച്ചു - ജീവനക്കാരുടെ ആശയവിനിമയം, ഫയൽ സംഭരണം, ടാസ്‌ക് മാനേജുമെന്റ്, CRM എന്നിവയ്ക്കുള്ള ഒരു പൊതു പരിഹാരം. 2012-ഓടെ, ഞങ്ങൾ ഇത് SaaS ആയി സമാരംഭിക്കണമെന്ന് ഞങ്ങൾ തീരുമാനിച്ചു, അത് സ്വയം കൈകാര്യം ചെയ്തു, തെറ്റ് സഹിഷ്ണുതയും വിശ്വാസ്യതയും ഉറപ്പാക്കുന്നു. വഴിയിൽ ഞങ്ങൾക്ക് അനുഭവം ലഭിച്ചു, കാരണം അതുവരെ ഞങ്ങൾക്ക് അത് ഇല്ലായിരുന്നു - ഞങ്ങൾ സോഫ്റ്റ്വെയർ നിർമ്മാതാക്കൾ മാത്രമായിരുന്നു, സേവന ദാതാക്കളല്ല.

സേവനം സമാരംഭിക്കുമ്പോൾ, ഏറ്റവും പ്രധാനപ്പെട്ട കാര്യം തെറ്റ് സഹിഷ്ണുത, വിശ്വാസ്യത, സേവനത്തിന്റെ നിരന്തരമായ ലഭ്യത എന്നിവ ഉറപ്പാക്കുകയാണെന്ന് ഞങ്ങൾ മനസ്സിലാക്കി, കാരണം നിങ്ങൾക്ക് ലളിതമായ ഒരു സാധാരണ വെബ്‌സൈറ്റ് ഉണ്ടെങ്കിൽ, ഒരു സ്റ്റോർ, ഉദാഹരണത്തിന്, അത് നിങ്ങളുടെ മേൽ പതിക്കുകയും അവിടെ ഇരിക്കുകയും ചെയ്യുന്നു. ഒരു മണിക്കൂർ, നിങ്ങൾ മാത്രം കഷ്ടപ്പെടുന്നു, നിങ്ങൾക്ക് ഓർഡറുകൾ നഷ്‌ടപ്പെടുന്നു, നിങ്ങൾക്ക് ക്ലയന്റുകളെ നഷ്‌ടപ്പെടുത്തുന്നു, പക്ഷേ നിങ്ങളുടെ ക്ലയന്റിനെ സംബന്ധിച്ചിടത്തോളം ഇത് അദ്ദേഹത്തിന് വളരെ നിർണായകമല്ല. അവൻ അസ്വസ്ഥനായിരുന്നു, തീർച്ചയായും, അവൻ പോയി മറ്റൊരു സൈറ്റിൽ അത് വാങ്ങി. കമ്പനിക്കുള്ളിലെ എല്ലാ ജോലികളും ആശയവിനിമയങ്ങളും തീരുമാനങ്ങളും ബന്ധിപ്പിക്കുന്ന ഒരു ആപ്ലിക്കേഷനാണ് ഇത് എങ്കിൽ, ഏറ്റവും പ്രധാനപ്പെട്ട കാര്യം ഉപയോക്താക്കളുടെ വിശ്വാസം നേടുക എന്നതാണ്, അതായത്, അവരെ നിരാശപ്പെടുത്തരുത്, വീഴരുത്. കാരണം ഉള്ളിലുള്ള എന്തെങ്കിലും പ്രവർത്തിക്കുന്നില്ലെങ്കിൽ എല്ലാ ജോലികളും നിർത്താം.

SaaS ആയി Bitrix.24

പൊതു സമാരംഭത്തിന് ഒരു വർഷം മുമ്പ്, 2011 ൽ ഞങ്ങൾ ആദ്യത്തെ പ്രോട്ടോടൈപ്പ് സമാഹരിച്ചു. ഞങ്ങൾ ഇത് ഏകദേശം ഒരാഴ്ചയ്ക്കുള്ളിൽ കൂട്ടിയോജിപ്പിച്ചു, അത് നോക്കി, വളച്ചൊടിച്ചു - അത് പ്രവർത്തിക്കുന്നു പോലും. അതായത്, നിങ്ങൾക്ക് ഫോമിലേക്ക് പോകാം, അവിടെ പോർട്ടലിന്റെ പേര് നൽകുക, ഒരു പുതിയ പോർട്ടൽ തുറക്കുകയും ഒരു ഉപയോക്തൃ അടിത്തറ സൃഷ്ടിക്കുകയും ചെയ്യും. ഞങ്ങൾ അത് നോക്കി, ഉൽപ്പന്നത്തെ തത്വത്തിൽ വിലയിരുത്തി, അത് സ്ക്രാപ്പ് ചെയ്തു, ഒരു വർഷം മുഴുവൻ അത് പരിഷ്ക്കരിക്കുന്നത് തുടർന്നു. ഞങ്ങൾക്ക് ഒരു വലിയ ചുമതലയുള്ളതിനാൽ: ഞങ്ങൾക്ക് രണ്ട് വ്യത്യസ്ത കോഡ് ബേസുകൾ നിർമ്മിക്കാൻ താൽപ്പര്യമില്ല, പ്രത്യേക പാക്കേജുചെയ്ത ഉൽപ്പന്നത്തെ പിന്തുണയ്ക്കാൻ ഞങ്ങൾ ആഗ്രഹിച്ചില്ല, പ്രത്യേക ക്ലൗഡ് സൊല്യൂഷനുകൾ - എല്ലാം ഒരു കോഡിനുള്ളിൽ ചെയ്യാൻ ഞങ്ങൾ ആഗ്രഹിക്കുന്നു.

അക്കാലത്ത് ഒരു സാധാരണ വെബ് ആപ്ലിക്കേഷൻ ഒരു സെർവറായിരുന്നു, അതിൽ ചില PHP കോഡ് പ്രവർത്തിക്കുന്നു, ഒരു mysql ഡാറ്റാബേസ്, ഫയലുകൾ അപ്‌ലോഡ് ചെയ്യുന്നു, പ്രമാണങ്ങൾ, ചിത്രങ്ങൾ അപ്‌ലോഡ് ഫോൾഡറിൽ ഇടുന്നു - ശരി, എല്ലാം പ്രവർത്തിക്കുന്നു. അയ്യോ, ഇത് ഉപയോഗിച്ച് ഗുരുതരമായ സ്ഥിരതയുള്ള ഒരു വെബ് സേവനം സമാരംഭിക്കുക അസാധ്യമാണ്. അവിടെ, വിതരണം ചെയ്ത കാഷെ പിന്തുണയ്ക്കുന്നില്ല, ഡാറ്റാബേസ് റെപ്ലിക്കേഷൻ പിന്തുണയ്ക്കുന്നില്ല.

ഞങ്ങൾ ആവശ്യകതകൾ രൂപീകരിച്ചു: ഇത് വ്യത്യസ്ത സ്ഥലങ്ങളിൽ സ്ഥിതിചെയ്യാനുള്ള കഴിവാണ്, പുനർനിർമ്മാണത്തെ പിന്തുണയ്‌ക്കുക, കൂടാതെ ഭൂമിശാസ്ത്രപരമായി വിതരണം ചെയ്‌തിരിക്കുന്ന വ്യത്യസ്‌ത ഡാറ്റാ സെന്ററുകളിൽ മികച്ച രീതിയിൽ സ്ഥിതിചെയ്യുക. ഉൽപ്പന്ന ലോജിക്കും വാസ്തവത്തിൽ ഡാറ്റ സംഭരണവും വേർതിരിക്കുക. ലോഡ് അനുസരിച്ച് ചലനാത്മകമായി സ്കെയിൽ ചെയ്യാനും സ്റ്റാറ്റിക്സ് മൊത്തത്തിൽ സഹിക്കാനും കഴിയും. ഈ പരിഗണനകളിൽ നിന്ന്, വാസ്തവത്തിൽ, ഉൽപ്പന്നത്തിന്റെ ആവശ്യകതകൾ ഉയർന്നുവന്നു, അത് വർഷത്തിൽ ഞങ്ങൾ പരിഷ്കരിച്ചു. ഈ സമയത്ത്, ഏകീകൃതമായി മാറിയ പ്ലാറ്റ്‌ഫോമിൽ - ബോക്‌സ്ഡ് സൊല്യൂഷനുകൾക്കായി, ഞങ്ങളുടെ സ്വന്തം സേവനത്തിനായി - ഞങ്ങൾക്ക് ആവശ്യമായ കാര്യങ്ങൾക്ക് ഞങ്ങൾ പിന്തുണ നൽകി. ഉൽപ്പന്നത്തിന്റെ തലത്തിൽ തന്നെ mysql റെപ്ലിക്കേഷനുള്ള പിന്തുണ: അതായത്, കോഡ് എഴുതുന്ന ഡവലപ്പർ തന്റെ അഭ്യർത്ഥനകൾ എങ്ങനെ വിതരണം ചെയ്യുമെന്ന് ചിന്തിക്കുന്നില്ല, അവൻ ഞങ്ങളുടെ api ഉപയോഗിക്കുന്നു, കൂടാതെ മാസ്റ്റർമാർക്കിടയിൽ എഴുതാനും വായിക്കാനും അഭ്യർത്ഥനകൾ എങ്ങനെ ശരിയായി വിതരണം ചെയ്യാമെന്ന് ഞങ്ങൾക്കറിയാം. അടിമകളും.

വിവിധ ക്ലൗഡ് ഒബ്‌ജക്റ്റ് സ്റ്റോറേജുകൾക്കായി ഞങ്ങൾ ഉൽപ്പന്ന തലത്തിൽ പിന്തുണ നൽകിയിട്ടുണ്ട്: ഗൂഗിൾ സ്റ്റോറേജ്, ആമസോൺ എസ് 3, കൂടാതെ ഓപ്പൺ സ്റ്റാക്ക് സ്വിഫ്റ്റിനുള്ള പിന്തുണ. അതിനാൽ, ഒരു സേവനം എന്ന നിലയിലും ഒരു പാക്കേജ് ചെയ്ത സൊല്യൂഷനുമായി പ്രവർത്തിക്കുന്ന ഡവലപ്പർമാർക്കും ഇത് സൗകര്യപ്രദമായിരുന്നു: അവർ ഞങ്ങളുടെ API ജോലിക്ക് ഉപയോഗിക്കുകയാണെങ്കിൽ, ഫയൽ ആത്യന്തികമായി ഫയൽ എവിടെയാണ് സംരക്ഷിക്കപ്പെടുകയെന്ന് അവർ ചിന്തിക്കുന്നില്ല, പ്രാദേശികമായി ഫയൽ സിസ്റ്റത്തിൽ അല്ലെങ്കിൽ ഒബ്ജക്റ്റ് ഫയൽ സ്റ്റോറേജിൽ.

തൽഫലമായി, മുഴുവൻ ഡാറ്റാ സെന്ററിന്റെയും തലത്തിൽ ഞങ്ങൾ റിസർവ് ചെയ്യുമെന്ന് ഞങ്ങൾ ഉടൻ തീരുമാനിച്ചു. 2012-ൽ, ഞങ്ങൾ പൂർണ്ണമായും ആമസോൺ AWS-ൽ സമാരംഭിച്ചു, കാരണം ഈ പ്ലാറ്റ്‌ഫോമിൽ ഞങ്ങൾക്ക് ഇതിനകം അനുഭവമുണ്ടായിരുന്നു - ഞങ്ങളുടെ സ്വന്തം വെബ്‌സൈറ്റ് അവിടെ ഹോസ്റ്റ് ചെയ്‌തിരുന്നു. ഓരോ പ്രദേശത്തും ആമസോണിന് നിരവധി ലഭ്യത സോണുകൾ ഉണ്ട് എന്ന വസ്തുത ഞങ്ങളെ ആകർഷിച്ചു - വാസ്തവത്തിൽ, (അവരുടെ പദാവലിയിൽ) പരസ്പരം കൂടുതലോ കുറവോ സ്വതന്ത്രമായതും ഒരു മുഴുവൻ ഡാറ്റാ സെന്ററിന്റെ തലത്തിൽ റിസർവ് ചെയ്യാൻ ഞങ്ങളെ അനുവദിക്കുന്നതുമായ നിരവധി ഡാറ്റാ സെന്ററുകൾ: ഇത് പെട്ടെന്ന് പരാജയപ്പെടുകയാണെങ്കിൽ, ഡാറ്റാബേസുകൾ മാസ്റ്റർ-മാസ്റ്റർ പകർത്തുകയും വെബ് ആപ്ലിക്കേഷൻ സെർവറുകൾ ബാക്കപ്പ് ചെയ്യുകയും സ്റ്റാറ്റിക് ഡാറ്റ s3 ഒബ്ജക്റ്റ് സ്റ്റോറേജിലേക്ക് മാറ്റുകയും ചെയ്യും. ലോഡ് സമതുലിതമാണ് - ആ സമയത്ത് ആമസോൺ എൽബ് വഴി, എന്നാൽ കുറച്ച് കഴിഞ്ഞ് ഞങ്ങൾ ഞങ്ങളുടെ സ്വന്തം ലോഡ് ബാലൻസറുകളിലേക്ക് എത്തി, കാരണം ഞങ്ങൾക്ക് കൂടുതൽ സങ്കീർണ്ണമായ യുക്തി ആവശ്യമാണ്.

അവർ ആഗ്രഹിച്ചത് അവർക്ക് കിട്ടിയതാണ്...

ഞങ്ങൾ ഉറപ്പാക്കാൻ ആഗ്രഹിക്കുന്ന എല്ലാ അടിസ്ഥാന കാര്യങ്ങളും - സെർവറുകളുടെ തെറ്റ് സഹിഷ്ണുത, വെബ് ആപ്ലിക്കേഷനുകൾ, ഡാറ്റാബേസുകൾ - എല്ലാം നന്നായി പ്രവർത്തിച്ചു. ഏറ്റവും ലളിതമായ സാഹചര്യം: ഞങ്ങളുടെ വെബ് ആപ്ലിക്കേഷനുകളിലൊന്ന് പരാജയപ്പെടുകയാണെങ്കിൽ, എല്ലാം ലളിതമാണ് - അവ ബാലൻസിൽ നിന്ന് സ്വിച്ച് ഓഫ് ചെയ്തിരിക്കുന്നു.

ബാലൻസർ (അക്കാലത്ത് അത് ആമസോണിന്റെ എൽബ് ആയിരുന്നു) ക്രമരഹിതമായ മെഷീനുകളെ അനാരോഗ്യകരമെന്ന് അടയാളപ്പെടുത്തുകയും അവയിലെ ലോഡ് ഡിസ്ട്രിബ്യൂഷൻ ഓഫ് ചെയ്യുകയും ചെയ്തു. ആമസോൺ ഓട്ടോസ്‌കേലിംഗ് പ്രവർത്തിച്ചു: ലോഡ് വർദ്ധിച്ചപ്പോൾ, ഓട്ടോസ്‌കേലിംഗ് ഗ്രൂപ്പിലേക്ക് പുതിയ മെഷീനുകൾ ചേർത്തു, ലോഡ് പുതിയ മെഷീനുകളിലേക്ക് വിതരണം ചെയ്തു - എല്ലാം മികച്ചതായിരുന്നു. ഞങ്ങളുടെ ബാലൻസറുകളുടെ കാര്യത്തിൽ, യുക്തി ഏതാണ്ട് സമാനമാണ്: ആപ്ലിക്കേഷൻ സെർവറിന് എന്തെങ്കിലും സംഭവിച്ചാൽ, ഞങ്ങൾ അതിൽ നിന്ന് അഭ്യർത്ഥനകൾ നീക്കം ചെയ്യുകയും ഈ മെഷീനുകൾ വലിച്ചെറിയുകയും പുതിയവ ആരംഭിക്കുകയും പ്രവർത്തിക്കുകയും ചെയ്യും. വർഷങ്ങളായി ഈ സ്കീം അല്പം മാറി, പക്ഷേ പ്രവർത്തിക്കുന്നത് തുടരുന്നു: ഇത് ലളിതവും മനസ്സിലാക്കാവുന്നതുമാണ്, മാത്രമല്ല അതിൽ ബുദ്ധിമുട്ടുകളൊന്നുമില്ല.

ഞങ്ങൾ ലോകമെമ്പാടും പ്രവർത്തിക്കുന്നു, ഉപഭോക്തൃ ലോഡ് കൊടുമുടികൾ തികച്ചും വ്യത്യസ്തമാണ്, കൂടാതെ, സൗഹാർദ്ദപരമായ രീതിയിൽ, ഞങ്ങളുടെ സിസ്റ്റത്തിലെ ഏതെങ്കിലും ഘടകങ്ങളിൽ എപ്പോൾ വേണമെങ്കിലും ചില സേവന പ്രവർത്തനങ്ങൾ നടത്താൻ ഞങ്ങൾക്ക് കഴിയണം - ഉപഭോക്താക്കളുടെ ശ്രദ്ധയിൽപ്പെടാതെ. അതിനാൽ, പ്രവർത്തനത്തിൽ നിന്ന് ഡാറ്റാബേസ് ഓഫ് ചെയ്യാനുള്ള അവസരമുണ്ട്, രണ്ടാമത്തെ ഡാറ്റാ സെന്ററിലേക്ക് ലോഡ് പുനർവിതരണം ചെയ്യുന്നു.

എല്ലാം എങ്ങനെ പ്രവർത്തിക്കുന്നു? — പ്രവർത്തിക്കുന്ന ഒരു ഡാറ്റാ സെന്ററിലേക്ക് ഞങ്ങൾ ട്രാഫിക് മാറ്റുന്നു - ഡാറ്റാ സെന്ററിൽ ഒരു അപകടമുണ്ടായാൽ, പൂർണ്ണമായും, ഇത് ഒരു ഡാറ്റാബേസ് ഉപയോഗിച്ചുള്ള ഞങ്ങളുടെ ആസൂത്രിത ജോലിയാണെങ്കിൽ, ഈ ക്ലയന്റുകൾക്ക് നൽകുന്ന ട്രാഫിക്കിന്റെ ഒരു ഭാഗം ഞങ്ങൾ താൽക്കാലികമായി നിർത്തി രണ്ടാമത്തെ ഡാറ്റാ സെന്ററിലേക്ക് മാറ്റുന്നു. അതിന്റെ പകർപ്പ്. രണ്ടാമത്തെ ഡാറ്റാ സെന്ററിലെ ലോഡ് വർധിച്ചതിനാൽ വെബ് ആപ്ലിക്കേഷനുകൾക്ക് പുതിയ മെഷീനുകൾ ആവശ്യമാണെങ്കിൽ, അവ സ്വയമേവ ആരംഭിക്കും. ഞങ്ങൾ ജോലി പൂർത്തിയാക്കി, ആവർത്തനം പുനഃസ്ഥാപിച്ചു, ഞങ്ങൾ മുഴുവൻ ലോഡും തിരികെ നൽകുന്നു. നമുക്ക് രണ്ടാമത്തെ ഡിസിയിൽ ചില ജോലികൾ മിറർ ചെയ്യേണ്ടതുണ്ടെങ്കിൽ, ഉദാഹരണത്തിന്, സിസ്റ്റം അപ്ഡേറ്റുകൾ ഇൻസ്റ്റാൾ ചെയ്യുക അല്ലെങ്കിൽ രണ്ടാമത്തെ ഡാറ്റാബേസിൽ ക്രമീകരണങ്ങൾ മാറ്റുക, പിന്നെ, പൊതുവേ, ഞങ്ങൾ അതേ കാര്യം തന്നെ മറ്റൊരു ദിശയിൽ ആവർത്തിക്കുന്നു. ഇതൊരു അപകടമാണെങ്കിൽ, ഞങ്ങൾ എല്ലാം നിസ്സാരമായി ചെയ്യുന്നു: മോണിറ്ററിംഗ് സിസ്റ്റത്തിൽ ഞങ്ങൾ ഇവന്റ്-ഹാൻഡ്‌ലർ സംവിധാനം ഉപയോഗിക്കുന്നു. നിരവധി പരിശോധനകൾ ട്രിഗർ ചെയ്യുകയും സ്റ്റാറ്റസ് നിർണായകമാകുകയും ചെയ്താൽ, ഞങ്ങൾ ഈ ഹാൻഡ്‌ലർ പ്രവർത്തിപ്പിക്കുന്നു, ഇത് അല്ലെങ്കിൽ ആ ലോജിക്ക് നിർവഹിക്കാൻ കഴിയുന്ന ഒരു ഹാൻഡ്‌ലർ. ഓരോ ഡാറ്റാബേസിനും, ഏത് സെർവറാണ് പരാജയപ്പെടുന്നതെന്നും ട്രാഫിക് ലഭ്യമല്ലെങ്കിൽ എവിടെയാണ് മാറേണ്ടതെന്നും ഞങ്ങൾ വ്യക്തമാക്കുന്നു. ചരിത്രപരമായി, നമ്മൾ നാഗിയോസ് അല്ലെങ്കിൽ അതിന്റെ ചില ഫോർക്കുകൾ ഒരു രൂപത്തിൽ അല്ലെങ്കിൽ മറ്റൊന്നിൽ ഉപയോഗിക്കുന്നു. തത്വത്തിൽ, മിക്കവാറും എല്ലാ മോണിറ്ററിംഗ് സിസ്റ്റത്തിലും സമാനമായ സംവിധാനങ്ങൾ നിലവിലുണ്ട്; ഞങ്ങൾ ഇതുവരെ കൂടുതൽ സങ്കീർണ്ണമായ ഒന്നും ഉപയോഗിക്കുന്നില്ല, പക്ഷേ ഒരുപക്ഷേ എന്നെങ്കിലും ഞങ്ങൾ ഉപയോഗിക്കും. ഇപ്പോൾ മോണിറ്ററിംഗ് ലഭ്യതയില്ലായ്കയാൽ ട്രിഗർ ചെയ്യപ്പെടുകയും എന്തെങ്കിലും സ്വിച്ചുചെയ്യാനുള്ള കഴിവുണ്ട്.

നമ്മൾ എല്ലാം റിസർവ് ചെയ്തിട്ടുണ്ടോ?

ഞങ്ങൾക്ക് യു‌എസ്‌എയിൽ നിന്ന് ധാരാളം ക്ലയന്റുകൾ ഉണ്ട്, യൂറോപ്പിൽ നിന്നുള്ള നിരവധി ക്ലയന്റുകൾ, കിഴക്ക് - ജപ്പാൻ, സിംഗപ്പൂർ എന്നിവയോട് അടുത്തിരിക്കുന്ന നിരവധി ക്ലയന്റുകൾ. തീർച്ചയായും, ക്ലയന്റുകളുടെ വലിയൊരു പങ്ക് റഷ്യയിലാണ്. അതായത്, ജോലി ഒരു മേഖലയിലല്ല. ഉപയോക്താക്കൾക്ക് പെട്ടെന്നുള്ള പ്രതികരണം ആവശ്യമാണ്, വിവിധ പ്രാദേശിക നിയമങ്ങൾ പാലിക്കുന്നതിന് ആവശ്യകതകളുണ്ട്, ഓരോ പ്രദേശത്തും ഞങ്ങൾ രണ്ട് ഡാറ്റാ സെന്ററുകൾ റിസർവ് ചെയ്യുന്നു, കൂടാതെ ചില അധിക സേവനങ്ങളും ഉണ്ട്, അവ വീണ്ടും ഒരു പ്രദേശത്ത് സ്ഥാപിക്കാൻ സൗകര്യപ്രദമാണ് - ക്ലയന്റുകൾക്ക് ഈ പ്രദേശം പ്രവർത്തിക്കുന്നു. REST ഹാൻഡ്‌ലറുകൾ, അംഗീകൃത സെർവറുകൾ, ക്ലയന്റിന്റെ മൊത്തത്തിലുള്ള പ്രവർത്തനത്തിന് അവ നിർണായകമല്ല, സ്വീകാര്യമായ ഒരു ചെറിയ കാലതാമസത്തോടെ നിങ്ങൾക്ക് അവയിലൂടെ മാറാം, എന്നാൽ അവയെ എങ്ങനെ നിരീക്ഷിക്കണം, എന്തുചെയ്യണം എന്നതിനെക്കുറിച്ചുള്ള ചക്രം പുനർനിർമ്മിക്കാൻ നിങ്ങൾ ആഗ്രഹിക്കുന്നില്ല. അവരോടൊപ്പം. അതിനാൽ, അധിക ഉൽപ്പന്നങ്ങളിൽ ഏതെങ്കിലും തരത്തിലുള്ള കഴിവ് വികസിപ്പിക്കുന്നതിനുപകരം നിലവിലുള്ള പരിഹാരങ്ങൾ പരമാവധി ഉപയോഗിക്കാൻ ഞങ്ങൾ ശ്രമിക്കുന്നു. എവിടെയോ ഞങ്ങൾ DNS തലത്തിൽ സ്വിച്ചിംഗ് നിസ്സാരമായി ഉപയോഗിക്കുന്നു, അതേ DNS മുഖേന ഞങ്ങൾ സേവനത്തിന്റെ സജീവത നിർണ്ണയിക്കുന്നു. ആമസോണിന് ഒരു റൂട്ട് 53 സേവനമുണ്ട്, എന്നാൽ ഇത് നിങ്ങൾക്ക് എൻട്രികൾ ചെയ്യാൻ കഴിയുന്ന ഒരു DNS മാത്രമല്ല, അത്രമാത്രം-ഇത് കൂടുതൽ വഴക്കമുള്ളതും സൗകര്യപ്രദവുമാണ്. ഇതിലൂടെ നിങ്ങൾക്ക് ജിയോലൊക്കേഷനുകൾ ഉപയോഗിച്ച് ജിയോ-ഡിസ്ട്രിബ്യൂട്ടഡ് സേവനങ്ങൾ നിർമ്മിക്കാൻ കഴിയും, ക്ലയന്റ് എവിടെ നിന്നാണ് വന്നതെന്ന് നിർണ്ണയിക്കാനും ചില രേഖകൾ നൽകാനും നിങ്ങൾ അത് ഉപയോഗിക്കുമ്പോൾ - അതിന്റെ സഹായത്തോടെ നിങ്ങൾക്ക് പരാജയ ആർക്കിടെക്ചറുകൾ നിർമ്മിക്കാൻ കഴിയും. അതേ ആരോഗ്യ പരിശോധനകൾ റൂട്ട് 53-ൽ തന്നെ ക്രമീകരിച്ചിരിക്കുന്നു, നിങ്ങൾ നിരീക്ഷിക്കുന്ന എൻഡ്‌പോയിന്റുകൾ സജ്ജമാക്കുക, മെട്രിക്‌സ് സജ്ജമാക്കുക, സേവനത്തിന്റെ "ജീവൻ" നിർണ്ണയിക്കുന്നതിനുള്ള പ്രോട്ടോക്കോളുകൾ സജ്ജമാക്കുക - tcp, http, https; സേവനം ജീവനുള്ളതാണോ അല്ലയോ എന്ന് നിർണ്ണയിക്കുന്ന പരിശോധനകളുടെ ആവൃത്തി സജ്ജമാക്കുക. റൂട്ട് 53-നുള്ളിൽ ഹെൽത്ത്-ചെക്ക് ട്രിഗർ ചെയ്‌താൽ എവിടെയാണ് മാറേണ്ടതെന്ന് ഡിഎൻഎസിൽ തന്നെ നിങ്ങൾ വ്യക്തമാക്കും. ഒരിക്കൽ എഴുന്നേറ്റു കഴിഞ്ഞാൽ പിന്നെ നമ്മൾ എങ്ങനെ ചെക്കുകൾ ചെയ്യുന്നു, എങ്ങനെ മാറുന്നു എന്നൊന്നും ചിന്തിക്കരുത്: എല്ലാം സ്വന്തമായി പ്രവർത്തിക്കുന്നു.

ആദ്യത്തെ "എന്നാൽ": റൂട്ട് 53 തന്നെ എങ്ങനെ, എന്തിനൊപ്പം റിസർവ് ചെയ്യാം? ആർക്കറിയാം, അയാൾക്ക് എന്തെങ്കിലും സംഭവിച്ചാലോ? ഭാഗ്യവശാൽ, ഞങ്ങൾ ഒരിക്കലും ഈ റാക്കിൽ കാലുകുത്തിയിട്ടില്ല, പക്ഷേ, ഞങ്ങൾ ഇപ്പോഴും ഒരു റിസർവേഷൻ നടത്തേണ്ടതുണ്ടെന്ന് ഞങ്ങൾ കരുതിയതിന്റെ ഒരു കഥ എനിക്ക് മുന്നിലുണ്ടാകും. ഇവിടെ ഞങ്ങൾ മുൻകൂട്ടിത്തന്നെ സ്‌ട്രോകൾ നിരത്തി. റൂട്ട് 53-ൽ ഉള്ള എല്ലാ സോണുകളും ഞങ്ങൾ ദിവസത്തിൽ പല തവണ പൂർണ്ണമായി അൺലോഡ് ചെയ്യുന്നു. ആമസോണിന്റെ API നിങ്ങളെ JSON-ൽ എളുപ്പത്തിൽ അയയ്‌ക്കാൻ അനുവദിക്കുന്നു, ഞങ്ങൾ അത് പരിവർത്തനം ചെയ്യുകയും കോൺഫിഗറുകളുടെ രൂപത്തിൽ അപ്‌ലോഡ് ചെയ്യുകയും ഏകദേശം പറഞ്ഞാൽ, ഒരു ബാക്കപ്പ് കോൺഫിഗറേഷൻ ഉള്ള നിരവധി ബാക്കപ്പ് സെർവറുകൾ ഞങ്ങൾക്കുണ്ട്. എന്തെങ്കിലും സംഭവിക്കുകയാണെങ്കിൽ, DNS ക്രമീകരണ ഡാറ്റ നഷ്‌ടപ്പെടാതെ തന്നെ നമുക്ക് അത് സ്വമേധയാ വിന്യസിക്കാനാകും.

രണ്ടാമത്തേത് "എന്നാൽ": ഈ ചിത്രത്തിൽ എന്താണ് ഇതുവരെ റിസർവ് ചെയ്യാത്തത്? ബാലൻസർ തന്നെ! പ്രദേശം അനുസരിച്ച് ഞങ്ങളുടെ ക്ലയന്റുകളുടെ വിതരണം വളരെ ലളിതമാക്കിയിരിക്കുന്നു. ഞങ്ങൾക്ക് bitrix24.ru, bitrix24.com, .de - ഇപ്പോൾ 13 വ്യത്യസ്ത ഡൊമെയ്‌നുകൾ ഉണ്ട്, അവ വിവിധ സോണുകളിൽ പ്രവർത്തിക്കുന്നു. ഞങ്ങൾ ഇനിപ്പറയുന്നതിലേക്ക് എത്തി: ഓരോ പ്രദേശത്തിനും അതിന്റേതായ ബാലൻസറുകൾ ഉണ്ട്. നെറ്റ്‌വർക്കിലെ പീക്ക് ലോഡ് എവിടെയാണെന്നതിനെ ആശ്രയിച്ച് ഇത് പ്രദേശങ്ങളിൽ വിതരണം ചെയ്യുന്നത് കൂടുതൽ സൗകര്യപ്രദമാക്കുന്നു. ഒരൊറ്റ ബാലൻസറിന്റെ തലത്തിൽ ഇത് പരാജയമാണെങ്കിൽ, അത് സേവനത്തിൽ നിന്ന് പുറത്തെടുക്കുകയും dns-ൽ നിന്ന് നീക്കം ചെയ്യുകയും ചെയ്യും. ഒരു കൂട്ടം ബാലൻസറുകളിൽ എന്തെങ്കിലും പ്രശ്‌നമുണ്ടെങ്കിൽ, അവ മറ്റ് സൈറ്റുകളിൽ ബാക്കപ്പ് ചെയ്യുന്നു, അവയ്‌ക്കിടയിൽ മാറുന്നത് അതേ റൂട്ട് 53 ഉപയോഗിച്ചാണ് ചെയ്യുന്നത്, കാരണം ഹ്രസ്വ ടിടിഎൽ കാരണം, പരമാവധി 2, 3, 5 മിനിറ്റിനുള്ളിൽ സ്വിച്ചിംഗ് സംഭവിക്കുന്നു. .

മൂന്നാമത്തേത് "എന്നാൽ": എന്താണ് ഇതുവരെ റിസർവ് ചെയ്യാത്തത്? S3, ശരിയാണ്. ഉപയോക്താക്കൾക്കായി ഞങ്ങൾ സംഭരിക്കുന്ന ഫയലുകൾ s3-ൽ സ്ഥാപിച്ചപ്പോൾ, അത് കവചം തുളയ്ക്കലാണെന്നും അവിടെ ഒന്നും കരുതിവെക്കേണ്ട ആവശ്യമില്ലെന്നും ഞങ്ങൾ ആത്മാർത്ഥമായി വിശ്വസിച്ചു. എന്നാൽ കാര്യങ്ങൾ മറിച്ചാണ് സംഭവിക്കുന്നതെന്ന് ചരിത്രം തെളിയിക്കുന്നു. പൊതുവേ, ആമസോൺ S3-യെ ഒരു അടിസ്ഥാന സേവനമായി വിശേഷിപ്പിക്കുന്നു, കാരണം ആമസോൺ തന്നെ S3 ഉപയോഗിച്ച് മെഷീൻ ഇമേജുകൾ, കോൺഫിഗറുകൾ, AMI ഇമേജുകൾ, സ്നാപ്പ്ഷോട്ടുകൾ എന്നിവ സംഭരിക്കുന്നതിന് ഉപയോഗിക്കുന്നു... കൂടാതെ s3 ക്രാഷായാൽ, ഈ 7 വർഷത്തിനിടയിൽ ഒരിക്കൽ സംഭവിച്ചതുപോലെ, നമ്മൾ ഉപയോഗിക്കുന്നിടത്തോളം. bitrix24, അത് ഒരു ഫാൻ പോലെ പിന്തുടരുന്നു - വെർച്വൽ മെഷീനുകൾ ആരംഭിക്കാനുള്ള കഴിവില്ലായ്മ, api പരാജയം തുടങ്ങിയവ.

എസ് 3 വീഴാം - അത് ഒരിക്കൽ സംഭവിച്ചു. അതിനാൽ, ഞങ്ങൾ ഇനിപ്പറയുന്ന സ്കീമിലേക്ക് എത്തി: കുറച്ച് വർഷങ്ങൾക്ക് മുമ്പ് റഷ്യയിൽ ഗുരുതരമായ പൊതു ഒബ്ജക്റ്റ് സ്റ്റോറേജ് സൗകര്യങ്ങളൊന്നും ഉണ്ടായിരുന്നില്ല, സ്വന്തമായി എന്തെങ്കിലും ചെയ്യാനുള്ള ഓപ്ഷൻ ഞങ്ങൾ പരിഗണിച്ചു ... ഭാഗ്യവശാൽ, ഞങ്ങൾ ഇത് ചെയ്യാൻ തുടങ്ങിയില്ല, കാരണം ഞങ്ങൾ ഞങ്ങൾക്കില്ലാത്ത വൈദഗ്ധ്യം കുഴിച്ചെടുത്തു, ഒരുപക്ഷേ കുഴപ്പത്തിലാക്കും. ഇപ്പോൾ Mail.ru-ന് s3-അനുയോജ്യമായ സംഭരണമുണ്ട്, Yandex-ലുണ്ട്, കൂടാതെ മറ്റ് നിരവധി ദാതാക്കൾക്കും ഇത് ഉണ്ട്. ആദ്യം, ബാക്കപ്പ്, രണ്ടാമതായി, പ്രാദേശിക പകർപ്പുകൾക്കൊപ്പം പ്രവർത്തിക്കാനുള്ള കഴിവ് എന്നിവ വേണമെന്ന ആശയത്തിലേക്ക് ഞങ്ങൾ ഒടുവിൽ എത്തി. റഷ്യൻ പ്രദേശത്തിന് പ്രത്യേകമായി, ഞങ്ങൾ Mail.ru ഹോട്ട്ബോക്സ് സേവനം ഉപയോഗിക്കുന്നു, അത് s3 ന് അനുയോജ്യമായ API ആണ്. ആപ്ലിക്കേഷനിലെ കോഡിൽ ഞങ്ങൾക്ക് വലിയ മാറ്റങ്ങളൊന്നും ആവശ്യമില്ല, ഞങ്ങൾ ഇനിപ്പറയുന്ന സംവിധാനം ഉണ്ടാക്കി: s3-ൽ ഒബ്‌ജക്‌റ്റുകൾ സൃഷ്‌ടിക്കുന്നതിനും ഇല്ലാതാക്കുന്നതിനും ട്രിഗറുകൾ ഉണ്ട്, ആമസോണിന് ലാംഡ എന്നൊരു സേവനമുണ്ട് - ഇത് കോഡിന്റെ സെർവർലെസ് ലോഞ്ചാണ് ചില ട്രിഗറുകൾ ട്രിഗർ ചെയ്യുമ്പോൾ അത് എക്സിക്യൂട്ട് ചെയ്യപ്പെടും.

ഞങ്ങൾ ഇത് വളരെ ലളിതമായി ചെയ്തു: ഞങ്ങളുടെ ട്രിഗർ ഫയർ ആണെങ്കിൽ, Mail.ru സ്റ്റോറേജിലേക്ക് ഒബ്ജക്റ്റ് പകർത്തുന്ന കോഡ് ഞങ്ങൾ എക്സിക്യൂട്ട് ചെയ്യുന്നു. ഡാറ്റയുടെ പ്രാദേശിക പകർപ്പുകൾ ഉപയോഗിച്ച് വർക്ക് പൂർണ്ണമായി സമാരംഭിക്കുന്നതിന്, ഞങ്ങൾക്ക് റിവേഴ്സ് സിൻക്രൊണൈസേഷനും ആവശ്യമാണ്, അതുവഴി റഷ്യൻ സെഗ്‌മെന്റിലുള്ള ക്ലയന്റുകൾക്ക് അവരോട് അടുത്തുള്ള സ്റ്റോറേജിൽ പ്രവർത്തിക്കാൻ കഴിയും. മെയിൽ അതിന്റെ സംഭരണത്തിൽ ട്രിഗറുകൾ പൂർത്തിയാക്കാൻ പോകുന്നു - ഇൻഫ്രാസ്ട്രക്ചർ തലത്തിൽ റിവേഴ്സ് സിൻക്രൊണൈസേഷൻ നടത്താൻ സാധിക്കും, എന്നാൽ ഇപ്പോൾ ഞങ്ങൾ ഇത് ഞങ്ങളുടെ സ്വന്തം കോഡിന്റെ തലത്തിലാണ് ചെയ്യുന്നത്. ഒരു ക്ലയന്റ് ഒരു ഫയൽ പോസ്റ്റ് ചെയ്തതായി ഞങ്ങൾ കാണുകയാണെങ്കിൽ, കോഡ് തലത്തിൽ ഞങ്ങൾ ഇവന്റ് ഒരു ക്യൂവിൽ സ്ഥാപിക്കുകയും പ്രോസസ്സ് ചെയ്യുകയും റിവേഴ്സ് റെപ്ലിക്കേഷൻ നടത്തുകയും ചെയ്യുന്നു. എന്തുകൊണ്ടാണ് ഇത് മോശമായത്: ഞങ്ങളുടെ ഉൽപ്പന്നത്തിന് പുറത്ത് ഞങ്ങളുടെ വസ്തുക്കളുമായി എന്തെങ്കിലും തരത്തിലുള്ള ജോലികൾ ചെയ്യുകയാണെങ്കിൽ, അതായത്, ചില ബാഹ്യ മാർഗങ്ങളിലൂടെ, ഞങ്ങൾ അത് കണക്കിലെടുക്കില്ല. അതിനാൽ, സ്റ്റോറേജ് ലെവലിൽ ട്രിഗറുകൾ ദൃശ്യമാകുമ്പോൾ അവസാനം വരെ ഞങ്ങൾ കാത്തിരിക്കുന്നു, അങ്ങനെ ഞങ്ങൾ കോഡ് എവിടെ നിന്ന് എക്സിക്യൂട്ട് ചെയ്താലും, ഞങ്ങൾക്ക് വന്ന ഒബ്ജക്റ്റ് മറ്റൊരു ദിശയിലേക്ക് പകർത്തപ്പെടും.

കോഡ് തലത്തിൽ, ഓരോ ക്ലയന്റിനുമായി ഞങ്ങൾ രണ്ട് സ്റ്റോറേജുകളും രജിസ്റ്റർ ചെയ്യുന്നു: ഒന്ന് പ്രധാനമായി കണക്കാക്കപ്പെടുന്നു, മറ്റൊന്ന് ബാക്കപ്പായി കണക്കാക്കുന്നു. എല്ലാം ശരിയാണെങ്കിൽ, ഞങ്ങൾക്ക് അടുത്തുള്ള സ്റ്റോറേജിൽ ഞങ്ങൾ പ്രവർത്തിക്കുന്നു: അതായത്, ആമസോണിലുള്ള ഞങ്ങളുടെ ക്ലയന്റുകൾ, അവർ S3-ൽ പ്രവർത്തിക്കുന്നു, റഷ്യയിൽ ജോലി ചെയ്യുന്നവർ, അവർ Hotbox-ൽ പ്രവർത്തിക്കുന്നു. ഫ്ലാഗ് പ്രവർത്തനക്ഷമമാക്കിയാൽ, പരാജയം കണക്ട് ചെയ്യണം, ഞങ്ങൾ ക്ലയന്റുകളെ മറ്റൊരു സ്റ്റോറേജിലേക്ക് മാറ്റും. പ്രദേശം അനുസരിച്ച് നമുക്ക് ഈ ബോക്‌സ് സ്വതന്ത്രമായി പരിശോധിക്കാനും അവയെ അങ്ങോട്ടും ഇങ്ങോട്ടും മാറ്റാനും കഴിയും. ഞങ്ങൾ ഇത് ഇതുവരെ പ്രായോഗികമായി ഉപയോഗിച്ചിട്ടില്ല, പക്ഷേ ഞങ്ങൾ ഈ സംവിധാനം നൽകിയിട്ടുണ്ട്, എന്നെങ്കിലും ഞങ്ങൾക്ക് ഈ സ്വിച്ച് ആവശ്യമായി വരുമെന്നും ഉപയോഗപ്രദമാകുമെന്നും ഞങ്ങൾ കരുതുന്നു. ഇത് ഇതിനകം ഒരിക്കൽ സംഭവിച്ചു.

ഓ, ആമസോൺ ഓടിപ്പോയി ...

റഷ്യയിൽ ടെലിഗ്രാം തടയൽ ആരംഭിച്ചതിന്റെ വാർഷികമാണ് ഈ ഏപ്രിലിൽ. ഇതിൽ ഏറ്റവും കൂടുതൽ ബാധിച്ച ദാതാവ് ആമസോൺ ആണ്. നിർഭാഗ്യവശാൽ, ലോകമെമ്പാടും പ്രവർത്തിച്ച റഷ്യൻ കമ്പനികൾ കൂടുതൽ കഷ്ടപ്പെട്ടു.

കമ്പനി ആഗോളമാണെങ്കിൽ റഷ്യ അതിന് വളരെ ചെറിയ ഒരു വിഭാഗമാണെങ്കിൽ, 3-5% - നന്നായി, ഒരു വഴി അല്ലെങ്കിൽ മറ്റൊന്ന്, നിങ്ങൾക്ക് അവരെ ബലിയർപ്പിക്കാൻ കഴിയും.

ഇതൊരു പൂർണ്ണമായും റഷ്യൻ കമ്പനിയാണെങ്കിൽ - ഇത് പ്രാദേശികമായി സ്ഥാപിക്കേണ്ടതുണ്ടെന്ന് എനിക്ക് ഉറപ്പുണ്ട് - ശരി, ഇത് ഉപയോക്താക്കൾക്ക് തന്നെ സൗകര്യപ്രദവും സൗകര്യപ്രദവുമാണ്, കൂടാതെ അപകടസാധ്യതകൾ കുറവായിരിക്കും.

ഇത് ആഗോളതലത്തിൽ പ്രവർത്തിക്കുന്ന ഒരു കമ്പനിയാണെങ്കിൽ റഷ്യയിൽ നിന്നും ലോകമെമ്പാടുമുള്ള എവിടെയെങ്കിലും ഏകദേശം തുല്യമായ ക്ലയന്റുകളുള്ള കമ്പനിയാണെങ്കിലോ? സെഗ്‌മെന്റുകളുടെ കണക്റ്റിവിറ്റി പ്രധാനമാണ്, അവ ഒരു തരത്തിൽ അല്ലെങ്കിൽ മറ്റൊന്നുമായി പ്രവർത്തിക്കണം.

2018 മാർച്ച് അവസാനം, Roskomnadzor ഏറ്റവും വലിയ ഓപ്പറേറ്റർമാർക്ക് ഒരു കത്ത് അയച്ചു, സെല്ലോ മെസഞ്ചറിനെ തടയുന്നതിനായി നിരവധി ദശലക്ഷം ആമസോൺ ഐപികൾ തടയാൻ അവർ പദ്ധതിയിട്ടിരുന്നു. ഇതേ ദാതാക്കൾക്ക് നന്ദി - അവർ എല്ലാവർക്കുമായി കത്ത് വിജയകരമായി ചോർത്തി, ആമസോണുമായുള്ള ബന്ധം വിച്ഛേദിക്കപ്പെടുമെന്ന് ഒരു ധാരണയുണ്ടായിരുന്നു. വെള്ളിയാഴ്ചയായിരുന്നു, ഞങ്ങൾ servers.ru-ൽ നിന്ന് ഞങ്ങളുടെ സഹപ്രവർത്തകരോട് പരിഭ്രാന്തരായി പറഞ്ഞു: “സുഹൃത്തുക്കളേ, ഞങ്ങൾക്ക് റഷ്യയിലല്ല, ആമസോണിലല്ല, ഉദാഹരണത്തിന്, ആംസ്റ്റർഡാമിൽ എവിടെയെങ്കിലും സ്ഥിതി ചെയ്യുന്ന നിരവധി സെർവറുകൾ ആവശ്യമാണ്,” ക്രമത്തിൽ. നമുക്ക് ഒരു തരത്തിലും സ്വാധീനിക്കാൻ കഴിയാത്ത ചില എൻഡ് പോയിന്റുകൾക്കായി നമ്മുടെ സ്വന്തം VPN-ഉം പ്രോക്‌സിയും എങ്ങനെയെങ്കിലും ഇൻസ്റ്റാൾ ചെയ്യാൻ കഴിയും, ഉദാഹരണത്തിന് അതേ s3-ന്റെ എൻഡ്‌പോണ്ടുകൾ - ഒരു പുതിയ സേവനം ഉയർത്താനും മറ്റൊരു ഐപി നേടാനും ഞങ്ങൾക്ക് ശ്രമിക്കാനാവില്ല, ഞങ്ങൾക്ക് നിങ്ങൾ ഇനിയും അവിടെ എത്തേണ്ടതുണ്ട്. ഏതാനും ദിവസങ്ങൾക്കുള്ളിൽ, ഞങ്ങൾ ഈ സെർവറുകൾ സജ്ജീകരിച്ചു, അവ പ്രവർത്തനക്ഷമമാക്കി, പൊതുവേ, തടയൽ ആരംഭിച്ച നിമിഷത്തിനായി ഞങ്ങൾ തയ്യാറെടുത്തു. ബഹളവും പരിഭ്രാന്തിയും നോക്കി ആർകെഎൻ പറഞ്ഞത് കൗതുകകരമാണ്: "ഇല്ല, ഞങ്ങൾ ഇപ്പോൾ ഒന്നും തടയില്ല." (എന്നാൽ ഇത് കൃത്യമായി ടെലിഗ്രാം ബ്ലോക്ക് ചെയ്യാൻ തുടങ്ങുന്ന നിമിഷം വരെയാണ്.) ബൈപാസ് കഴിവുകൾ സജ്ജീകരിക്കുകയും തടയൽ അവതരിപ്പിച്ചിട്ടില്ലെന്ന് മനസ്സിലാക്കുകയും ചെയ്തതിനാൽ, ഞങ്ങൾ മുഴുവൻ കാര്യവും അടുക്കാൻ തുടങ്ങിയില്ല. അതെ, കേസിൽ.

2019 ൽ, ഞങ്ങൾ ഇപ്പോഴും തടയുന്ന അവസ്ഥയിലാണ് ജീവിക്കുന്നത്. ഞാൻ ഇന്നലെ രാത്രി നോക്കി: ഏകദേശം ഒരു ദശലക്ഷം ഐപികൾ ബ്ലോക്ക് ചെയ്യുന്നത് തുടരുന്നു. ശരിയാണ്, ആമസോൺ ഏതാണ്ട് പൂർണ്ണമായും അൺബ്ലോക്ക് ചെയ്യപ്പെട്ടു, അതിന്റെ ഏറ്റവും ഉയർന്ന സമയത്ത് അത് 20 ദശലക്ഷം വിലാസങ്ങളിൽ എത്തി... പൊതുവേ, യോജിപ്പും നല്ല യോജിപ്പും ഉണ്ടാകണമെന്നില്ല എന്നതാണ് യാഥാർത്ഥ്യം. പെട്ടെന്ന്. സാങ്കേതിക കാരണങ്ങളാൽ ഇത് നിലവിലില്ലായിരിക്കാം - തീപിടുത്തങ്ങൾ, എക്‌സ്‌കവേറ്ററുകൾ, എല്ലാം. അല്ലെങ്കിൽ, നമ്മൾ കണ്ടതുപോലെ, പൂർണ്ണമായും സാങ്കേതികമല്ല. അതിനാൽ, വലുതും വലുതുമായ ഒരാൾക്ക്, അവരുടേതായ AS-കളുള്ള, ഒരുപക്ഷേ ഇത് മറ്റ് വഴികളിൽ കൈകാര്യം ചെയ്യാൻ കഴിയും - നേരിട്ടുള്ള കണക്ഷനും മറ്റ് കാര്യങ്ങളും ഇതിനകം l2 ലെവലിലാണ്. എന്നാൽ ഞങ്ങളുടേത് പോലെയോ അതിലും ചെറുതോ ആയ ഒരു ലളിതമായ പതിപ്പിൽ, മറ്റെവിടെയെങ്കിലും ഉയർത്തിയ സെർവറുകളുടെ തലത്തിൽ നിങ്ങൾക്ക് ആവർത്തനം ഉണ്ടാകാം, മുൻകൂട്ടി ക്രമീകരിച്ചിരിക്കുന്ന vpn, പ്രോക്സി, ആ സെഗ്‌മെന്റുകളിലെ കോൺഫിഗറേഷൻ വേഗത്തിൽ മാറ്റാനുള്ള കഴിവ്. അത് നിങ്ങളുടെ കണക്റ്റിവിറ്റിക്ക് നിർണായകമാണ്. ആമസോണിന്റെ തടയൽ ആരംഭിച്ചപ്പോൾ ഒന്നിലധികം തവണ ഇത് ഞങ്ങൾക്ക് ഉപയോഗപ്രദമായി; ഏറ്റവും മോശം സാഹചര്യത്തിൽ, ഞങ്ങൾ അവയിലൂടെ S3 ട്രാഫിക്ക് മാത്രമേ അനുവദിച്ചിട്ടുള്ളൂ, പക്ഷേ ക്രമേണ ഇതെല്ലാം പരിഹരിച്ചു.

എങ്ങനെ റിസർവ് ചെയ്യാം... ഒരു മുഴുവൻ ദാതാവ്?

ആമസോൺ മുഴുവനായും തകരുന്ന സാഹചര്യത്തിൽ ഞങ്ങൾക്ക് ഇപ്പോൾ ഒരു സാഹചര്യവുമില്ല. റഷ്യയുടെ കാര്യത്തിൽ ഞങ്ങൾക്ക് സമാനമായ ഒരു സാഹചര്യമുണ്ട്. റഷ്യയിൽ, ഞങ്ങൾ ഒരു ദാതാവാണ് ഹോസ്റ്റ് ചെയ്തത്, അവരിൽ നിന്ന് ഞങ്ങൾ നിരവധി സൈറ്റുകൾ തിരഞ്ഞെടുത്തു. ഒരു വർഷം മുമ്പ് ഞങ്ങൾ ഒരു പ്രശ്നം നേരിട്ടു: ഇവ രണ്ട് ഡാറ്റാ സെന്ററുകളാണെങ്കിലും, ദാതാവിന്റെ നെറ്റ്‌വർക്ക് കോൺഫിഗറേഷന്റെ തലത്തിൽ ഇതിനകം തന്നെ പ്രശ്നങ്ങൾ ഉണ്ടായേക്കാം, അത് ഇപ്പോഴും രണ്ട് ഡാറ്റാ സെന്ററുകളെയും ബാധിക്കും. കൂടാതെ രണ്ട് സൈറ്റുകളിലും ഞങ്ങൾ ലഭ്യമല്ലാതായേക്കാം. തീർച്ചയായും അതാണ് സംഭവിച്ചത്. ഉള്ളിലെ വാസ്തുവിദ്യ ഞങ്ങൾ പുനർവിചിന്തനം ചെയ്തു. ഇത് വളരെയധികം മാറിയിട്ടില്ല, എന്നാൽ റഷ്യയിൽ ഞങ്ങൾക്ക് ഇപ്പോൾ രണ്ട് സൈറ്റുകളുണ്ട്, അവ ഒരേ ദാതാവിൽ നിന്നുള്ളതല്ല, രണ്ട് വ്യത്യസ്ത സൈറ്റുകളിൽ നിന്നാണ്. ഒന്ന് പരാജയപ്പെട്ടാൽ, നമുക്ക് മറ്റൊന്നിലേക്ക് മാറാം.

സാങ്കൽപ്പികമായി, ആമസോണിനായി ഞങ്ങൾ മറ്റൊരു ദാതാവിന്റെ തലത്തിൽ സംവരണത്തിനുള്ള സാധ്യത പരിഗണിക്കുന്നു; ഒരുപക്ഷേ ഗൂഗിൾ, ഒരുപക്ഷേ മറ്റാരെങ്കിലും... എന്നാൽ ഇതുവരെ നമ്മൾ പ്രായോഗികമായി നിരീക്ഷിച്ചത്, ആമസോണിന് ഒരു ലഭ്യത മേഖലയുടെ തലത്തിൽ അപകടങ്ങൾ ഉണ്ടാകുമ്പോൾ, ഒരു പ്രദേശത്തിന്റെ തലത്തിലുള്ള അപകടങ്ങൾ വളരെ വിരളമാണ്. അതിനാൽ, "Amazon is not Amazon" റിസർവേഷൻ നടത്താമെന്ന ആശയം സൈദ്ധാന്തികമായി ഞങ്ങൾക്കുണ്ട്, എന്നാൽ പ്രായോഗികമായി ഇത് ഇതുവരെ അങ്ങനെയല്ല.

ഓട്ടോമേഷനെക്കുറിച്ച് കുറച്ച് വാക്കുകൾ

ഓട്ടോമേഷൻ എപ്പോഴും ആവശ്യമാണോ? ഇവിടെ ഡണിംഗ്-ക്രുഗർ പ്രഭാവം ഓർമ്മിക്കുന്നത് ഉചിതമാണ്. “x” അക്ഷത്തിൽ നാം നേടുന്ന നമ്മുടെ അറിവും അനുഭവവുമാണ്, കൂടാതെ “y” അക്ഷത്തിൽ നമ്മുടെ പ്രവർത്തനങ്ങളിലുള്ള ആത്മവിശ്വാസമാണ്. ആദ്യം നമുക്ക് ഒന്നും അറിയില്ല, തീർച്ചയില്ല. അപ്പോൾ നമ്മൾ അൽപ്പം അറിയുകയും മെഗാ ആത്മവിശ്വാസം നേടുകയും ചെയ്യുന്നു - ഇതാണ് "മണ്ടത്തരത്തിന്റെ കൊടുമുടി" എന്ന് വിളിക്കപ്പെടുന്നത്, "ഡിമെൻഷ്യയും ധൈര്യവും" എന്ന ചിത്രം നന്നായി ചിത്രീകരിച്ചിരിക്കുന്നു. പിന്നെ ഞങ്ങൾ കുറച്ച് പഠിച്ച് യുദ്ധത്തിന് തയ്യാറാണ്. അപ്പോൾ നമ്മൾ ചില ഗുരുതരമായ തെറ്റുകൾ ചവിട്ടുകയും നിരാശയുടെ താഴ്‌വരയിൽ സ്വയം കണ്ടെത്തുകയും ചെയ്യുന്നു, നമുക്ക് എന്തെങ്കിലും അറിയാമെന്ന് തോന്നുമ്പോൾ, പക്ഷേ വാസ്തവത്തിൽ നമുക്ക് കൂടുതൽ അറിയില്ല. പിന്നെ, അനുഭവം നേടുമ്പോൾ, നമുക്ക് കൂടുതൽ ആത്മവിശ്വാസം ലഭിക്കും.

ചില അപകടങ്ങളിലേക്കുള്ള വിവിധ ഓട്ടോമാറ്റിക് സ്വിച്ചുകളെക്കുറിച്ചുള്ള ഞങ്ങളുടെ യുക്തി ഈ ഗ്രാഫ് നന്നായി വിവരിച്ചിരിക്കുന്നു. ഞങ്ങൾ ആരംഭിച്ചു - ഒന്നും എങ്ങനെ ചെയ്യണമെന്ന് ഞങ്ങൾക്ക് അറിയില്ല, മിക്കവാറും എല്ലാ ജോലികളും കൈകൊണ്ട് ചെയ്തു. എല്ലാത്തിനും ഓട്ടോമേഷൻ ഘടിപ്പിക്കാമെന്നും സമാധാനത്തോടെ ഉറങ്ങാമെന്നും ഞങ്ങൾ മനസ്സിലാക്കി. പെട്ടെന്ന് ഞങ്ങൾ ഒരു മെഗാ-റേക്കിലേക്ക് ചുവടുവെക്കുന്നു: ഒരു തെറ്റായ പോസിറ്റീവ് പ്രവർത്തനക്ഷമമാകുന്നു, നല്ല രീതിയിൽ, ഞങ്ങൾ ഇത് ചെയ്യാൻ പാടില്ലാത്തപ്പോൾ ഞങ്ങൾ ട്രാഫിക് അങ്ങോട്ടും ഇങ്ങോട്ടും മാറ്റുന്നു. തൽഫലമായി, അനുകരണം തകരുന്നു അല്ലെങ്കിൽ മറ്റെന്തെങ്കിലും-ഇത് നിരാശയുടെ താഴ്വരയാണ്. എന്നിട്ട് എല്ലാ കാര്യങ്ങളെയും വിവേകത്തോടെ സമീപിക്കണം എന്ന ധാരണയിൽ എത്തുന്നു. അതായത്, തെറ്റായ അലാറങ്ങളുടെ സാധ്യത നൽകിക്കൊണ്ട് ഓട്ടോമേഷനെ ആശ്രയിക്കുന്നതിൽ അർത്ഥമുണ്ട്. പക്ഷേ! അനന്തരഫലങ്ങൾ വിനാശകരമാണെങ്കിൽ, അത് ഡ്യൂട്ടി ഷിഫ്റ്റിന്, ഡ്യൂട്ടിയിലുള്ള എഞ്ചിനീയർമാർക്ക് വിടുന്നതാണ് നല്ലത്, അവർ ശരിക്കും ഒരു അപകടമുണ്ടെന്ന് ഉറപ്പുവരുത്തുകയും നിരീക്ഷിക്കുകയും ആവശ്യമായ പ്രവർത്തനങ്ങൾ സ്വമേധയാ നടപ്പിലാക്കുകയും ചെയ്യും.

തീരുമാനം

7 വർഷത്തിനിടയിൽ, എന്തെങ്കിലും വീഴുമ്പോൾ, പരിഭ്രാന്തി ഉണ്ടായിരുന്നു എന്ന വസ്തുതയിൽ നിന്ന്, പ്രശ്നങ്ങൾ നിലവിലില്ല, ജോലികൾ മാത്രമേ ഉള്ളൂ, അവ പരിഹരിക്കപ്പെടേണ്ടതും പരിഹരിക്കാവുന്നതുമാണ് എന്ന ധാരണയിലേക്ക് ഞങ്ങൾ പോയി. നിങ്ങൾ ഒരു സേവനം നിർമ്മിക്കുമ്പോൾ, മുകളിൽ നിന്ന് നോക്കുക, സംഭവിക്കാനിടയുള്ള എല്ലാ അപകടസാധ്യതകളും വിലയിരുത്തുക. നിങ്ങൾ അവരെ ഉടനടി കാണുകയാണെങ്കിൽ, മുൻ‌കൂട്ടി ആവർത്തനവും ഒരു തെറ്റ്-സഹിഷ്ണുതയുള്ള ഇൻഫ്രാസ്ട്രക്ചർ നിർമ്മിക്കാനുള്ള സാധ്യതയും നൽകുക, കാരണം പരാജയപ്പെടാവുന്നതും സേവനത്തിന്റെ പ്രവർത്തനരഹിതതയിലേക്ക് നയിക്കുന്നതുമായ ഏത് പോയിന്റും തീർച്ചയായും അങ്ങനെ ചെയ്യും. ഇൻഫ്രാസ്ട്രക്ചറിന്റെ ചില ഘടകങ്ങൾ തീർച്ചയായും പരാജയപ്പെടില്ലെന്ന് നിങ്ങൾക്ക് തോന്നിയാലും - അതേ s3 പോലെ, അവയ്ക്ക് കഴിയുമെന്ന് ഇപ്പോഴും ഓർമ്മിക്കുക. കുറഞ്ഞത് സിദ്ധാന്തത്തിലെങ്കിലും, എന്തെങ്കിലും സംഭവിച്ചാൽ നിങ്ങൾ അവരുമായി എന്തുചെയ്യുമെന്ന് ഒരു ആശയം ഉണ്ടായിരിക്കുക. ഒരു റിസ്ക് മാനേജ്മെന്റ് പ്ലാൻ ഉണ്ടായിരിക്കുക. എല്ലാം യാന്ത്രികമായോ സ്വമേധയാ ചെയ്യുന്നതിനെക്കുറിച്ച് നിങ്ങൾ ചിന്തിക്കുമ്പോൾ, അപകടസാധ്യതകൾ വിലയിരുത്തുക: ഓട്ടോമേഷൻ എല്ലാം മാറാൻ തുടങ്ങിയാൽ എന്ത് സംഭവിക്കും - ഇത് ഒരു അപകടത്തെ അപേക്ഷിച്ച് കൂടുതൽ മോശമായ അവസ്ഥയിലേക്ക് നയിക്കില്ലേ? ഒരുപക്ഷേ എവിടെയെങ്കിലും ഓട്ടോമേഷന്റെ ഉപയോഗവും ഡ്യൂട്ടിയിലുള്ള എഞ്ചിനീയറുടെ പ്രതികരണവും തമ്മിൽ ന്യായമായ വിട്ടുവീഴ്ച ഉപയോഗിക്കേണ്ടത് ആവശ്യമാണ്, അവർ യഥാർത്ഥ ചിത്രം വിലയിരുത്തുകയും എന്തെങ്കിലും സ്ഥലത്തുതന്നെ മാറ്റേണ്ടതുണ്ടോ അതോ "അതെ, പക്ഷേ ഇപ്പോൾ അല്ല" എന്ന് മനസ്സിലാക്കുകയും ചെയ്യും.

പെർഫെക്ഷനിസവും യഥാർത്ഥ പരിശ്രമവും, സമയം, പണം എന്നിവയ്ക്കിടയിലുള്ള ന്യായമായ വിട്ടുവീഴ്ച, നിങ്ങൾക്ക് ആത്യന്തികമായി ലഭിക്കുന്ന സ്കീമിനായി ചെലവഴിക്കാം.

ഈ വാചകം കോൺഫറൻസിലെ അലക്സാണ്ടർ ഡെമിഡോവിന്റെ റിപ്പോർട്ടിന്റെ പുതുക്കിയതും വിപുലീകരിച്ചതുമായ പതിപ്പാണ് പ്രവർത്തനസമയം ദിവസം 4.

അവലംബം: www.habr.com