ഇന്റർനെറ്റ് അഭ്യർത്ഥനകൾ വേഗത്തിലാക്കുകയും സമാധാനത്തോടെ ഉറങ്ങുകയും ചെയ്യുക

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

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

കോൺഫറൻസിൽ പങ്കെടുത്തവരിൽ നിന്ന് റിപ്പോർട്ടിന് മികച്ച അവലോകനങ്ങൾ ലഭിച്ചു, ഞങ്ങൾ നിങ്ങൾക്കായി ഒരു ടെക്സ്റ്റ് പതിപ്പ് തയ്യാറാക്കിയിട്ടുണ്ട്.

തന്റെ റിപ്പോർട്ടിൽ സെർജി വിശദമായി സംസാരിച്ചു

• ക്ലയന്റും സെർവറും തമ്മിലുള്ള ഇന്റർനെറ്റ് അഭ്യർത്ഥനകളുടെ കാലതാമസത്തെ ബാധിക്കുന്നതിനെക്കുറിച്ച്;
• ഈ കാലതാമസം എങ്ങനെ കുറയ്ക്കാം;
• പിശക്-സഹിഷ്ണുതയുള്ള സംവിധാനങ്ങൾ എങ്ങനെ രൂപകൽപ്പന ചെയ്യാം, പരിപാലിക്കാം, നിരീക്ഷിക്കാം;
• ചുരുങ്ങിയ സമയത്തിനുള്ളിൽ ഫലങ്ങൾ എങ്ങനെ നേടാം, കൂടാതെ ബിസിനസ്സിന് കുറഞ്ഞ അപകടസാധ്യത;
• ഫലങ്ങൾ എങ്ങനെ വിശകലനം ചെയ്യാം, തെറ്റുകളിൽ നിന്ന് പഠിക്കാം.

ഈ ചോദ്യങ്ങൾക്കുള്ള ഉത്തരം വലിയ കോർപ്പറേഷനുകളിൽ ജോലി ചെയ്യുന്നവർക്ക് മാത്രമല്ല ആവശ്യമാണ്.

അവതരിപ്പിച്ച തത്വങ്ങളും സാങ്കേതികതകളും ഇന്റർനെറ്റ് ഉൽപ്പന്നങ്ങൾ വികസിപ്പിക്കുകയും പിന്തുണയ്ക്കുകയും ചെയ്യുന്ന എല്ലാവരും അറിഞ്ഞിരിക്കണം.

സ്പീക്കറുടെ വീക്ഷണകോണിൽ നിന്നുള്ള വിവരണമാണ് അടുത്തത്.

ഇന്റർനെറ്റ് വേഗതയുടെ പ്രാധാന്യം

ഇന്റർനെറ്റ് അഭ്യർത്ഥനകളുടെ വേഗത ബിസിനസ്സുമായി നേരിട്ട് ബന്ധപ്പെട്ടിരിക്കുന്നു. ഷോപ്പിംഗ് വ്യവസായം പരിഗണിക്കുക: 2009-ൽ ആമസോൺ സംസാരിച്ചു100ms കാലതാമസം വിൽപ്പനയുടെ 1% നഷ്‌ടത്തിന് കാരണമാകുന്നു.

കൂടുതൽ കൂടുതൽ മൊബൈൽ ഉപകരണങ്ങൾ ഉണ്ട്, തുടർന്ന് മൊബൈൽ സൈറ്റുകളും ആപ്ലിക്കേഷനുകളും. നിങ്ങളുടെ പേജ് ലോഡുചെയ്യാൻ 3 സെക്കൻഡിൽ കൂടുതൽ സമയമെടുക്കുകയാണെങ്കിൽ, നിങ്ങളുടെ ഉപയോക്താക്കളിൽ പകുതിയോളം പേരെ നിങ്ങൾക്ക് നഷ്ടപ്പെടും. കൂടെ ജൂലൈ 2018 തിരയൽ ഫലങ്ങളിൽ നിങ്ങളുടെ പേജിന്റെ ലോഡിംഗ് വേഗത Google കണക്കിലെടുക്കുന്നു: പേജിന്റെ വേഗത, Google-ൽ അതിന്റെ സ്ഥാനം ഉയർന്നതാണ്.

ലേറ്റൻസി നിർണായകമായ ധനകാര്യ സ്ഥാപനങ്ങളിൽ കണക്ഷൻ വേഗതയും പ്രധാനമാണ്. 2015-ൽ, ഹൈബർനിയ നെറ്റ്‌വർക്കുകൾ തീർന്നു ന്യൂയോർക്കിനും ലണ്ടനും ഇടയിൽ 400 മില്യൺ ഡോളറിന്റെ കേബിൾ നഗരങ്ങൾക്കിടയിലുള്ള ലേറ്റൻസി 6 മി. 66 മി.എസ് ലേറ്റൻസി കുറയ്ക്കുന്നതിന് $1 ദശലക്ഷം സങ്കൽപ്പിക്കുക!

പറയുന്നു ഗവേഷണം, 5 Mbit/s-ന് മുകളിലുള്ള കണക്ഷൻ വേഗത ഒരു സാധാരണ വെബ്‌സൈറ്റിന്റെ ലോഡിംഗ് വേഗതയെ നേരിട്ട് ബാധിക്കില്ല. എന്നിരുന്നാലും, കണക്ഷൻ ലേറ്റൻസിയും പേജ് ലോഡിംഗ് വേഗതയും തമ്മിൽ ഒരു രേഖീയ ബന്ധമുണ്ട്:

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

റിപ്പോർട്ടിൽ ഞങ്ങൾ നെറ്റ്ഫ്ലിക്സ് ഇൻഫ്രാസ്ട്രക്ചറിന്റെ ഉദാഹരണം ഉപയോഗിച്ച് ലേറ്റൻസി കുറയ്ക്കുന്നതിൽ പ്രത്യേകം ശ്രദ്ധ കേന്ദ്രീകരിക്കും. പ്രവർത്തനപരമായ പ്രശ്നങ്ങളും തകർച്ചകളും കണ്ടുപിടിക്കുന്നതിനുപകരം സങ്കീർണ്ണമായ വിതരണ സംവിധാനങ്ങളുടെ രൂപകൽപ്പന, വികസനം, പ്രവർത്തനം എന്നിവയെ എങ്ങനെ സമീപിക്കാമെന്നും നവീകരണത്തിലും ഫലങ്ങളിലും സമയം ചെലവഴിക്കാമെന്നും പ്രായോഗിക വീക്ഷണകോണിൽ നിന്ന് നോക്കാം.

നെറ്റ്ഫ്ലിക്സിനുള്ളിൽ

ആയിരക്കണക്കിന് വ്യത്യസ്ത ഉപകരണങ്ങൾ Netflix ആപ്പുകളെ പിന്തുണയ്ക്കുന്നു. Android, iOS, TV, വെബ് ബ്രൗസറുകൾ എന്നിവയ്‌ക്കായി ക്ലയന്റിന്റെ പ്രത്യേക പതിപ്പുകൾ നിർമ്മിക്കുന്ന നാല് വ്യത്യസ്ത ടീമുകളാണ് അവ വികസിപ്പിച്ചെടുത്തത്. ഉപയോക്തൃ അനുഭവം മെച്ചപ്പെടുത്തുന്നതിനും വ്യക്തിഗതമാക്കുന്നതിനും ഞങ്ങൾ വളരെയധികം പരിശ്രമിക്കുന്നു. ഇത് ചെയ്യുന്നതിന്, ഞങ്ങൾ നൂറുകണക്കിന് എ/ബി ടെസ്റ്റുകൾ സമാന്തരമായി നടത്തുന്നു.

വ്യക്തിഗതമാക്കിയ ഉപയോക്തൃ ഡാറ്റ, ക്വറി ഡിസ്പാച്ച്, ടെലിമെട്രി, ബിഗ് ഡാറ്റ, എൻകോഡിംഗ് എന്നിവ നൽകിക്കൊണ്ട് AWS ക്ലൗഡിലെ നൂറുകണക്കിന് മൈക്രോസർവീസുകൾ വ്യക്തിഗതമാക്കലിനെ പിന്തുണയ്ക്കുന്നു. ട്രാഫിക് ദൃശ്യവൽക്കരണം ഇതുപോലെ കാണപ്പെടുന്നു:

പ്രദർശനത്തോടുകൂടിയ വീഡിയോയിലേക്കുള്ള ലിങ്ക് (6:04-6:23)

ഇടതുവശത്താണ് എൻട്രി പോയിന്റ്, തുടർന്ന് വിവിധ ബാക്കെൻഡ് ടീമുകൾ പിന്തുണയ്ക്കുന്ന നൂറുകണക്കിന് മൈക്രോ സർവീസുകൾക്കിടയിൽ ട്രാഫിക് വിതരണം ചെയ്യുന്നു.

ഞങ്ങളുടെ ഇൻഫ്രാസ്ട്രക്ചറിന്റെ മറ്റൊരു പ്രധാന ഘടകം ഓപ്പൺ കണക്റ്റ് CDN ആണ്, അത് അന്തിമ ഉപയോക്താവിന് സ്റ്റാറ്റിക് ഉള്ളടക്കം നൽകുന്നു - വീഡിയോകൾ, ഇമേജുകൾ, ക്ലയന്റ് കോഡ് മുതലായവ. ഇഷ്‌ടാനുസൃത സെർവറുകളിൽ (OCA - ഓപ്പൺ കണക്റ്റ് അപ്ലയൻസ്) CDN സ്ഥിതിചെയ്യുന്നു. ഉള്ളിൽ NGINX ഉം ഒരു കൂട്ടം സേവനങ്ങളും ഉള്ള ഒപ്റ്റിമൈസ് ചെയ്ത FreeBSD പ്രവർത്തിക്കുന്ന SSD, HDD ഡ്രൈവുകളുടെ നിരകൾ ഉണ്ട്. ഞങ്ങൾ ഹാർഡ്‌വെയർ, സോഫ്‌റ്റ്‌വെയർ ഘടകങ്ങൾ രൂപകൽപ്പന ചെയ്യുകയും ഒപ്റ്റിമൈസ് ചെയ്യുകയും ചെയ്യുന്നതിനാൽ അത്തരം CDN സെർവറിന് ഉപയോക്താക്കൾക്ക് കഴിയുന്നത്ര ഡാറ്റ അയയ്‌ക്കാൻ കഴിയും.

ഇന്റർനെറ്റ് ട്രാഫിക് എക്സ്ചേഞ്ച് പോയിന്റിലെ (ഇന്റർനെറ്റ് എക്സ്ചേഞ്ച് - IX) ഈ സെർവറുകളുടെ "മതിൽ" ഇതുപോലെ കാണപ്പെടുന്നു:

ഇന്റർനെറ്റിൽ കൂടുതൽ നേരിട്ട് ഡാറ്റ കൈമാറ്റം ചെയ്യുന്നതിനായി ഇന്റർനെറ്റ് സേവന ദാതാക്കൾക്കും ഉള്ളടക്ക ദാതാക്കൾക്കും പരസ്പരം "കണക്റ്റ്" ചെയ്യാനുള്ള കഴിവ് ഇന്റർനെറ്റ് എക്സ്ചേഞ്ച് നൽകുന്നു. ഞങ്ങളുടെ സെർവറുകൾ ഇൻസ്റ്റാൾ ചെയ്തിട്ടുള്ള ഏകദേശം 70-80 ഇന്റർനെറ്റ് എക്സ്ചേഞ്ച് പോയിന്റുകൾ ലോകമെമ്പാടും ഉണ്ട്, ഞങ്ങൾ അവ സ്വതന്ത്രമായി ഇൻസ്റ്റാൾ ചെയ്യുകയും പരിപാലിക്കുകയും ചെയ്യുന്നു:

കൂടാതെ, നെറ്റ്ഫ്ലിക്സ് ട്രാഫിക്കിന്റെ പ്രാദേശികവൽക്കരണവും ഉപയോക്താക്കൾക്കുള്ള സ്ട്രീമിംഗിന്റെ ഗുണനിലവാരവും മെച്ചപ്പെടുത്തുന്ന ഇന്റർനെറ്റ് ദാതാക്കൾക്ക് ഞങ്ങൾ സെർവറുകൾ നേരിട്ട് നൽകുന്നു.

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

വഴി സാൻഡ്‌വൈൻ കണക്കാക്കുന്നു, ഞങ്ങളുടെ CDN ഇൻഫ്രാസ്ട്രക്ചർ പീക്ക് സമയങ്ങളിൽ ലോകത്തെ ഇന്റർനെറ്റ് ട്രാഫിക്കിന്റെ ഏകദേശം ⅛ നൽകുന്നു, നെറ്റ്ഫ്ലിക്സ് ഏറ്റവും ദൈർഘ്യമേറിയ വടക്കേ അമേരിക്കയിലെ ട്രാഫിക്കിന്റെ ⅓. ശ്രദ്ധേയമായ സംഖ്യകൾ, എന്നാൽ എന്നെ സംബന്ധിച്ചിടത്തോളം ഏറ്റവും അത്ഭുതകരമായ നേട്ടങ്ങളിലൊന്ന്, മുഴുവൻ സിഡിഎൻ സംവിധാനവും 150-ൽ താഴെ ആളുകളുടെ ഒരു ടീമാണ് വികസിപ്പിക്കുകയും പരിപാലിക്കുകയും ചെയ്യുന്നത്.

തുടക്കത്തിൽ, സിഡിഎൻ ഇൻഫ്രാസ്ട്രക്ചർ വീഡിയോ ഡാറ്റ ഡെലിവർ ചെയ്യുന്നതിനാണ് രൂപകൽപ്പന ചെയ്തിരിക്കുന്നത്. എന്നിരുന്നാലും, കാലക്രമേണ, AWS ക്ലൗഡിലെ ക്ലയന്റുകളിൽ നിന്നുള്ള ചലനാത്മക അഭ്യർത്ഥനകൾ ഒപ്റ്റിമൈസ് ചെയ്യുന്നതിനും ഇത് ഉപയോഗിക്കാമെന്ന് ഞങ്ങൾ മനസ്സിലാക്കി.

ഇന്റർനെറ്റ് ത്വരിതപ്പെടുത്തലിനെക്കുറിച്ച്

ഇന്ന്, Netflix-ന് 3 AWS മേഖലകളുണ്ട്, ക്ലൗഡിലേക്കുള്ള അഭ്യർത്ഥനകളുടെ കാലതാമസം ഉപഭോക്താവ് അടുത്തുള്ള പ്രദേശത്ത് നിന്ന് എത്ര ദൂരെയാണ് എന്നതിനെ ആശ്രയിച്ചിരിക്കും. അതേ സമയം, സ്റ്റാറ്റിക് ഉള്ളടക്കം നൽകുന്നതിന് ഉപയോഗിക്കുന്ന നിരവധി CDN സെർവറുകൾ ഞങ്ങളുടെ പക്കലുണ്ട്. ഡൈനാമിക് അന്വേഷണങ്ങൾ വേഗത്തിലാക്കാൻ ഈ ചട്ടക്കൂട് ഉപയോഗിക്കുന്നതിന് എന്തെങ്കിലും മാർഗമുണ്ടോ? എന്നിരുന്നാലും, നിർഭാഗ്യവശാൽ, ഈ അഭ്യർത്ഥനകൾ കാഷെ ചെയ്യുന്നത് അസാധ്യമാണ് - API-കൾ വ്യക്തിഗതമാക്കിയതും ഓരോ ഫലവും അദ്വിതീയവുമാണ്.

നമുക്ക് CDN സെർവറിൽ ഒരു പ്രോക്സി ഉണ്ടാക്കി അതിലൂടെ ട്രാഫിക് അയക്കാൻ തുടങ്ങാം. ഇത് വേഗത്തിലാകുമോ?

മെറ്റീരിയൽ

നെറ്റ്‌വർക്ക് പ്രോട്ടോക്കോളുകൾ എങ്ങനെ പ്രവർത്തിക്കുന്നുവെന്ന് നമുക്ക് ഓർക്കാം. ഇന്ന്, ഇന്റർനെറ്റിലെ മിക്ക ട്രാഫിക്കും HTTP-കൾ ഉപയോഗിക്കുന്നു, ഇത് TCP, TLS എന്നീ ലോവർ ലെയർ പ്രോട്ടോക്കോളുകളെ ആശ്രയിച്ചിരിക്കുന്നു. ഒരു ക്ലയന്റ് സെർവറിലേക്ക് കണക്റ്റുചെയ്യുന്നതിന്, അത് ഒരു ഹാൻ‌ഡ്‌ഷേക്ക് ചെയ്യുന്നു, കൂടാതെ ഒരു സുരക്ഷിത കണക്ഷൻ സ്ഥാപിക്കുന്നതിന്, ക്ലയന്റ് സെർവറുമായി മൂന്ന് തവണ സന്ദേശങ്ങൾ കൈമാറുകയും ഡാറ്റ കൈമാറാൻ കുറഞ്ഞത് ഒരു തവണയെങ്കിലും നൽകുകയും വേണം. ഓരോ റൗണ്ട് ട്രിപ്പിനും (ആർടിടി) 100 എംഎസ് ലേറ്റൻസി ഉള്ളതിനാൽ, ഡാറ്റയുടെ ആദ്യ ബിറ്റ് ലഭിക്കാൻ ഞങ്ങൾക്ക് 400 എംഎസ് എടുക്കും:

ഞങ്ങൾ സിഡിഎൻ സെർവറിൽ സർട്ടിഫിക്കറ്റുകൾ സ്ഥാപിക്കുകയാണെങ്കിൽ, സിഡിഎൻ അടുത്താണെങ്കിൽ ക്ലയന്റും സെർവറും തമ്മിലുള്ള ഹാൻഡ്‌ഷേക്ക് സമയം ഗണ്യമായി കുറയ്ക്കാൻ കഴിയും. CDN സെർവറിലേക്കുള്ള ലേറ്റൻസി 30ms ആണെന്ന് നമുക്ക് അനുമാനിക്കാം. അപ്പോൾ ആദ്യത്തെ ബിറ്റ് ലഭിക്കാൻ 220 ms എടുക്കും:

എന്നാൽ നേട്ടങ്ങൾ അവിടെ അവസാനിക്കുന്നില്ല. ഒരു കണക്ഷൻ സ്ഥാപിച്ചുകഴിഞ്ഞാൽ, ടിസിപി കൺജഷൻ വിൻഡോ വർദ്ധിപ്പിക്കുന്നു (ആ കണക്ഷനിലൂടെ സമാന്തരമായി കൈമാറാൻ കഴിയുന്ന വിവരങ്ങളുടെ അളവ്). ഒരു ഡാറ്റ പാക്കറ്റ് നഷ്‌ടപ്പെട്ടാൽ, TCP പ്രോട്ടോക്കോളിന്റെ (ടിസിപി ന്യൂ റെനോ പോലെയുള്ള) ക്ലാസിക് നടപ്പിലാക്കലുകൾ തുറന്ന "വിൻഡോ" പകുതിയായി കുറയ്ക്കുന്നു. കൺജഷൻ വിൻഡോയുടെ വളർച്ചയും നഷ്ടത്തിൽ നിന്ന് വീണ്ടെടുക്കുന്നതിന്റെ വേഗതയും സെർവറിലേക്കുള്ള കാലതാമസത്തെ (ആർടിടി) ആശ്രയിച്ചിരിക്കുന്നു. ഈ കണക്ഷൻ CDN സെർവർ വരെ മാത്രമേ പോകുന്നുള്ളൂ എങ്കിൽ, ഈ വീണ്ടെടുക്കൽ വേഗത്തിലാകും. അതേ സമയം, പാക്കറ്റ് നഷ്ടം ഒരു സാധാരണ പ്രതിഭാസമാണ്, പ്രത്യേകിച്ച് വയർലെസ് നെറ്റ്വർക്കുകൾക്ക്.

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

ആപ്ലിക്കേഷൻ ലെവൽ പ്രോട്ടോക്കോളുകളും (OSI ലെവൽ 7) ലേറ്റൻസിയിൽ സ്വാധീനം ചെലുത്തുന്നു. HTTP/2 പോലുള്ള പുതിയ പ്രോട്ടോക്കോളുകൾ സമാന്തര അഭ്യർത്ഥനകളുടെ പ്രകടനം ഒപ്റ്റിമൈസ് ചെയ്യുന്നു. എന്നിരുന്നാലും, പുതിയ പ്രോട്ടോക്കോളുകളെ പിന്തുണയ്ക്കാത്ത പഴയ ഉപകരണങ്ങളുള്ള Netflix ക്ലയന്റുകൾ ഞങ്ങൾക്കുണ്ട്. എല്ലാ ക്ലയന്റുകളും അപ്ഡേറ്റ് ചെയ്യാനോ ഒപ്റ്റിമൽ കോൺഫിഗർ ചെയ്യാനോ കഴിയില്ല. അതേ സമയം, CDN പ്രോക്സിക്കും ക്ലൗഡിനും ഇടയിൽ പൂർണ്ണ നിയന്ത്രണവും പുതിയ, ഒപ്റ്റിമൽ പ്രോട്ടോക്കോളുകളും ക്രമീകരണങ്ങളും ഉപയോഗിക്കാനുള്ള കഴിവും ഉണ്ട്. പഴയ പ്രോട്ടോക്കോളുകളുള്ള ഫലപ്രദമല്ലാത്ത ഭാഗം ക്ലയന്റിനും CDN സെർവറിനുമിടയിൽ മാത്രമേ പ്രവർത്തിക്കൂ. കൂടാതെ, ടിസിപി ലെവലിൽ കണക്ഷൻ വിനിയോഗം മെച്ചപ്പെടുത്തിക്കൊണ്ട്, CDN-നും ക്ലൗഡിനും ഇടയിൽ ഇതിനകം സ്ഥാപിച്ച കണക്ഷനിൽ മൾട്ടിപ്ലക്സ് അഭ്യർത്ഥനകൾ നടത്താം:

ഞങ്ങൾ അളക്കുന്നു

സിദ്ധാന്തം മെച്ചപ്പെടുത്തലുകൾ വാഗ്ദാനം ചെയ്യുന്നുണ്ടെങ്കിലും, ഉൽ‌പാദനത്തിൽ സിസ്റ്റം സമാരംഭിക്കാൻ ഞങ്ങൾ ഉടൻ തിരക്കുകൂട്ടുന്നില്ല. പകരം, ആശയം പ്രായോഗികമായി പ്രവർത്തിക്കുമെന്ന് ആദ്യം തെളിയിക്കണം. ഇത് ചെയ്യുന്നതിന്, നിങ്ങൾ നിരവധി ചോദ്യങ്ങൾക്ക് ഉത്തരം നൽകേണ്ടതുണ്ട്:

• വേഗത: ഒരു പ്രോക്സി വേഗതയേറിയതായിരിക്കുമോ?
• വിശ്വാസ്യത: ഇത് കൂടുതൽ തവണ തകരുമോ?
• സങ്കീർണത: ആപ്ലിക്കേഷനുകളുമായി എങ്ങനെ സംയോജിപ്പിക്കാം?
• ചെലവ്: അധിക അടിസ്ഥാന സൗകര്യങ്ങൾ വിന്യസിക്കാൻ എത്ര ചിലവാകും?

ആദ്യ പോയിന്റ് വിലയിരുത്തുന്നതിനുള്ള ഞങ്ങളുടെ സമീപനം വിശദമായി പരിഗണിക്കാം. ബാക്കിയുള്ളവയും സമാനമായ രീതിയിൽ കൈകാര്യം ചെയ്യുന്നു.

അഭ്യർത്ഥനകളുടെ വേഗത വിശകലനം ചെയ്യുന്നതിനായി, എല്ലാ ഉപയോക്താക്കൾക്കും വേണ്ടി ഡാറ്റ ലഭിക്കാൻ ഞങ്ങൾ ആഗ്രഹിക്കുന്നു, വികസനത്തിനായി ധാരാളം സമയം ചെലവഴിക്കാതെയും ഉൽപ്പാദനം തകർക്കാതെയും. ഇതിനായി നിരവധി സമീപനങ്ങളുണ്ട്:

1. RUM, അല്ലെങ്കിൽ നിഷ്ക്രിയ അഭ്യർത്ഥന അളക്കൽ. ഉപയോക്താക്കളിൽ നിന്നുള്ള നിലവിലെ അഭ്യർത്ഥനകളുടെ നിർവ്വഹണ സമയം ഞങ്ങൾ അളക്കുകയും പൂർണ്ണ ഉപയോക്തൃ കവറേജ് ഉറപ്പാക്കുകയും ചെയ്യുന്നു. നിരവധി ഘടകങ്ങൾ കാരണം സിഗ്നൽ വളരെ സ്ഥിരതയുള്ളതല്ല എന്നതാണ് പോരായ്മ, ഉദാഹരണത്തിന്, വ്യത്യസ്ത അഭ്യർത്ഥന വലുപ്പങ്ങൾ, സെർവറിലും ക്ലയന്റിലുമുള്ള പ്രോസസ്സിംഗ് സമയം എന്നിവ കാരണം. കൂടാതെ, ഉൽപ്പാദനത്തിൽ ഫലമില്ലാതെ നിങ്ങൾക്ക് ഒരു പുതിയ കോൺഫിഗറേഷൻ പരീക്ഷിക്കാൻ കഴിയില്ല.
2. ലബോറട്ടറി പരിശോധനകൾ. ക്ലയന്റുകളെ അനുകരിക്കുന്ന പ്രത്യേക സെർവറുകളും അടിസ്ഥാന സൗകര്യങ്ങളും. അവരുടെ സഹായത്തോടെ ഞങ്ങൾ ആവശ്യമായ പരിശോധനകൾ നടത്തുന്നു. ഈ രീതിയിൽ നമുക്ക് അളക്കൽ ഫലങ്ങളിൽ പൂർണ്ണമായ നിയന്ത്രണവും വ്യക്തമായ സിഗ്നലും ലഭിക്കും. എന്നാൽ ഉപകരണങ്ങളുടെയും ഉപയോക്തൃ ലൊക്കേഷനുകളുടെയും പൂർണ്ണമായ കവറേജ് ഇല്ല (പ്രത്യേകിച്ച് ലോകമെമ്പാടുമുള്ള സേവനവും ആയിരക്കണക്കിന് ഉപകരണ മോഡലുകൾക്കുള്ള പിന്തുണയും).

രണ്ട് രീതികളുടെയും ഗുണങ്ങൾ നിങ്ങൾക്ക് എങ്ങനെ സംയോജിപ്പിക്കാം?

ഞങ്ങളുടെ ടീം ഒരു പരിഹാരം കണ്ടെത്തി. ഞങ്ങൾ ഒരു ചെറിയ കോഡ് എഴുതി - ഒരു സാമ്പിൾ - അത് ഞങ്ങൾ ഞങ്ങളുടെ ആപ്ലിക്കേഷനിൽ നിർമ്മിച്ചു. ഞങ്ങളുടെ ഉപകരണങ്ങളിൽ നിന്ന് പൂർണ്ണമായും നിയന്ത്രിത നെറ്റ്‌വർക്ക് ടെസ്റ്റുകൾ നടത്താൻ പ്രോബുകൾ ഞങ്ങളെ അനുവദിക്കുന്നു. ഇത് ഇതുപോലെ പ്രവർത്തിക്കുന്നു:

1. ആപ്ലിക്കേഷൻ ലോഡുചെയ്‌ത് പ്രാരംഭ പ്രവർത്തനം പൂർത്തിയാക്കിയ ഉടൻ, ഞങ്ങൾ ഞങ്ങളുടെ പ്രോബുകൾ പ്രവർത്തിപ്പിക്കുന്നു.
2. ക്ലയന്റ് സെർവറിലേക്ക് ഒരു അഭ്യർത്ഥന നടത്തുകയും ടെസ്റ്റിനായി ഒരു "പാചകക്കുറിപ്പ്" സ്വീകരിക്കുകയും ചെയ്യുന്നു. ഒരു HTTP(കൾ) അഭ്യർത്ഥന നടത്തേണ്ട URL-കളുടെ ഒരു ലിസ്റ്റാണ് പാചകക്കുറിപ്പ്. കൂടാതെ, പാചകക്കുറിപ്പ് അഭ്യർത്ഥന പാരാമീറ്ററുകൾ കോൺഫിഗർ ചെയ്യുന്നു: അഭ്യർത്ഥനകൾക്കിടയിലുള്ള കാലതാമസം, അഭ്യർത്ഥിച്ച ഡാറ്റയുടെ അളവ്, HTTP(കൾ) തലക്കെട്ടുകൾ മുതലായവ. അതേ സമയം, നമുക്ക് സമാന്തരമായി നിരവധി വ്യത്യസ്ത പാചകക്കുറിപ്പുകൾ പരീക്ഷിക്കാൻ കഴിയും - ഒരു കോൺഫിഗറേഷൻ അഭ്യർത്ഥിക്കുമ്പോൾ, ഏത് പാചകക്കുറിപ്പ് നൽകണമെന്ന് ഞങ്ങൾ ക്രമരഹിതമായി നിർണ്ണയിക്കുന്നു.
3. ക്ലയന്റിലുള്ള നെറ്റ്‌വർക്ക് ഉറവിടങ്ങളുടെ സജീവ ഉപയോഗവുമായി വൈരുദ്ധ്യമുണ്ടാകാതിരിക്കാൻ പ്രോബ് ലോഞ്ച് സമയം തിരഞ്ഞെടുത്തു. അടിസ്ഥാനപരമായി, ക്ലയന്റ് സജീവമല്ലാത്ത സമയത്താണ് സമയം തിരഞ്ഞെടുക്കുന്നത്.
4. പാചകക്കുറിപ്പ് ലഭിച്ച ശേഷം, ക്ലയന്റ് സമാന്തരമായി ഓരോ URL-കളിലേക്കും അഭ്യർത്ഥനകൾ നടത്തുന്നു. ഓരോ വിലാസങ്ങളിലേക്കും അഭ്യർത്ഥന ആവർത്തിക്കാം - വിളിക്കപ്പെടുന്നവ. "പൾസ്". ആദ്യ പൾസിൽ, ഒരു കണക്ഷൻ സ്ഥാപിക്കാനും ഡാറ്റ ഡൗൺലോഡ് ചെയ്യാനും എത്ര സമയമെടുത്തുവെന്ന് ഞങ്ങൾ അളക്കുന്നു. രണ്ടാമത്തെ പൾസിൽ, ഇതിനകം സ്ഥാപിതമായ കണക്ഷനിലൂടെ ഡാറ്റ ലോഡ് ചെയ്യാൻ എടുക്കുന്ന സമയം ഞങ്ങൾ അളക്കുന്നു. മൂന്നാമത്തേതിന് മുമ്പ്, നമുക്ക് കാലതാമസം സജ്ജമാക്കാനും വീണ്ടും കണക്ഷൻ സ്ഥാപിക്കുന്നതിന്റെ വേഗത അളക്കാനും കഴിയും.

   പരിശോധനയ്ക്കിടെ, ഉപകരണത്തിന് ലഭ്യമാകുന്ന എല്ലാ പാരാമീറ്ററുകളും ഞങ്ങൾ അളക്കുന്നു:

   • DNS അഭ്യർത്ഥന സമയം;
   • TCP കണക്ഷൻ സജ്ജീകരണ സമയം;
   • TLS കണക്ഷൻ സജ്ജീകരണ സമയം;
   • ഡാറ്റയുടെ ആദ്യ ബൈറ്റ് സ്വീകരിക്കുന്ന സമയം;
   • മൊത്തം ലോഡിംഗ് സമയം;
   • സ്റ്റാറ്റസ് ഫല കോഡ്.
5. എല്ലാ പൾസുകളും പൂർത്തിയായ ശേഷം, വിശകലനത്തിനായി സാമ്പിൾ എല്ലാ അളവുകളും ലോഡ് ചെയ്യുന്നു.

ക്ലയന്റിലുള്ള ലോജിക്, സെർവറിലെ ഡാറ്റ പ്രോസസ്സിംഗ്, സമാന്തര അഭ്യർത്ഥനകളുടെ അളവെടുപ്പ് എന്നിവയാണ് പ്രധാന പോയിന്റുകൾ. അതിനാൽ, അന്വേഷണ പ്രകടനത്തെ ബാധിക്കുന്ന വിവിധ ഘടകങ്ങളുടെ സ്വാധീനം വേർതിരിച്ച് പരിശോധിക്കാനും ഒരൊറ്റ പാചകക്കുറിപ്പിൽ അവ വ്യത്യാസപ്പെടുത്താനും യഥാർത്ഥ ക്ലയന്റുകളിൽ നിന്ന് ഫലങ്ങൾ നേടാനും ഞങ്ങൾക്ക് കഴിയും.

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

പരീക്ഷണ സിദ്ധാന്തം പ്രായോഗികമായി: പ്രോട്ടോടൈപ്പ്

അത്തരമൊരു സംവിധാനം ഉപയോഗിച്ച്, അഭ്യർത്ഥന ലേറ്റൻസിയിൽ CDN പ്രോക്സികളുടെ ഫലപ്രാപ്തി വിലയിരുത്താൻ ഞങ്ങൾക്ക് കഴിഞ്ഞു. ഇപ്പോൾ നിങ്ങൾക്ക് വേണ്ടത്:

• ഒരു പ്രോക്സി പ്രോട്ടോടൈപ്പ് സൃഷ്ടിക്കുക;
• ഒരു CDN-ൽ പ്രോട്ടോടൈപ്പ് സ്ഥാപിക്കുക;
• ഒരു നിർദ്ദിഷ്‌ട CDN സെർവറിലെ ഒരു പ്രോക്‌സിയിലേക്ക് ക്ലയന്റുകളെ എങ്ങനെ നയിക്കണമെന്ന് നിർണ്ണയിക്കുക;
• പ്രോക്സി ഇല്ലാതെ AWS-ലെ അഭ്യർത്ഥനകളുമായി പ്രകടനം താരതമ്യം ചെയ്യുക.

നിർദ്ദിഷ്ട പരിഹാരത്തിന്റെ ഫലപ്രാപ്തി എത്രയും വേഗം വിലയിരുത്തുക എന്നതാണ് ചുമതല. നല്ല നെറ്റ്‌വർക്കിംഗ് ലൈബ്രറികളുടെ ലഭ്യത കാരണം പ്രോട്ടോടൈപ്പ് നടപ്പിലാക്കാൻ ഞങ്ങൾ Go തിരഞ്ഞെടുത്തു. ഓരോ CDN സെർവറിലും, ഡിപൻഡൻസികൾ കുറയ്ക്കുന്നതിനും ഏകീകരണം ലളിതമാക്കുന്നതിനുമായി ഞങ്ങൾ പ്രോട്ടോടൈപ്പ് പ്രോക്സി ഒരു സ്റ്റാറ്റിക് ബൈനറിയായി ഇൻസ്റ്റാൾ ചെയ്തു. പ്രാരംഭ നിർവ്വഹണത്തിൽ, HTTP/2 കണക്ഷൻ പൂളിംഗിനും മൾട്ടിപ്ലക്‌സിംഗ് അഭ്യർത്ഥനയ്ക്കും ഞങ്ങൾ പരമാവധി സ്റ്റാൻഡേർഡ് ഘടകങ്ങളും ചെറിയ പരിഷ്‌ക്കരണങ്ങളും ഉപയോഗിച്ചു.

AWS മേഖലകൾക്കിടയിൽ സന്തുലിതമാക്കാൻ, ഞങ്ങൾ ഒരു ഭൂമിശാസ്ത്രപരമായ DNS ഡാറ്റാബേസ് ഉപയോഗിച്ചു, ക്ലയന്റുകളെ സന്തുലിതമാക്കാൻ ഉപയോഗിച്ച അതേ ഡാറ്റാബേസ്. ക്ലയന്റിനായി ഒരു CDN സെർവർ തിരഞ്ഞെടുക്കുന്നതിന്, ഇന്റർനെറ്റ് എക്സ്ചേഞ്ചിലെ (IX) സെർവറുകൾക്കായി ഞങ്ങൾ TCP Anycast ഉപയോഗിക്കുന്നു. ഈ ഓപ്‌ഷനിൽ, എല്ലാ CDN സെർവറുകൾക്കും ഞങ്ങൾ ഒരു IP വിലാസം ഉപയോഗിക്കുന്നു, കൂടാതെ ഏറ്റവും കുറഞ്ഞ IP ഹോപ്പുകളുള്ള CDN സെർവറിലേക്ക് ക്ലയന്റ് നയിക്കപ്പെടും. ഇന്റർനെറ്റ് ദാതാക്കൾ (ISP-കൾ) ഇൻസ്റ്റാൾ ചെയ്ത CDN സെർവറുകളിൽ, TCP Anycast കോൺഫിഗർ ചെയ്യുന്നതിനുള്ള റൂട്ടറിന്റെ നിയന്ത്രണം ഞങ്ങൾക്ക് ഇല്ല, അതിനാൽ ഞങ്ങൾ ഉപയോഗിക്കുന്നു ഒരേ യുക്തി, വീഡിയോ സ്ട്രീമിംഗിനായി ഉപഭോക്താക്കളെ ഇന്റർനെറ്റ് ദാതാക്കളിലേക്ക് നയിക്കുന്നു.

അതിനാൽ, ഞങ്ങൾക്ക് മൂന്ന് തരം അഭ്യർത്ഥന പാതകളുണ്ട്: ഓപ്പൺ ഇന്റർനെറ്റ് വഴി ക്ലൗഡിലേക്ക്, IX-ലെ ഒരു CDN സെർവർ വഴി അല്ലെങ്കിൽ ഒരു ഇന്റർനെറ്റ് ദാതാവിൽ സ്ഥിതി ചെയ്യുന്ന ഒരു CDN സെർവർ വഴി. പ്രൊഡക്ഷനിലേക്ക് അഭ്യർത്ഥനകൾ എങ്ങനെ അയയ്‌ക്കുന്നു എന്നതുമായി താരതമ്യപ്പെടുത്തുമ്പോൾ ഏത് വഴിയാണ് മികച്ചതെന്നും പ്രോക്‌സിയുടെ പ്രയോജനം എന്താണെന്നും മനസ്സിലാക്കുക എന്നതാണ് ഞങ്ങളുടെ ലക്ഷ്യം. ഇത് ചെയ്യുന്നതിന്, ഞങ്ങൾ ഇനിപ്പറയുന്ന രീതിയിൽ ഒരു സാമ്പിൾ സിസ്റ്റം ഉപയോഗിക്കുന്നു:

ഓരോ പാതകളും ഒരു പ്രത്യേക ലക്ഷ്യമായി മാറുന്നു, ഞങ്ങൾക്ക് ലഭിച്ച സമയം ഞങ്ങൾ നോക്കുന്നു. വിശകലനത്തിനായി, ഞങ്ങൾ പ്രോക്സി ഫലങ്ങൾ ഒരു ഗ്രൂപ്പായി സംയോജിപ്പിക്കുന്നു (IX, ISP പ്രോക്സികൾക്കിടയിലുള്ള മികച്ച സമയം തിരഞ്ഞെടുക്കുക), കൂടാതെ ഒരു പ്രോക്സി ഇല്ലാതെ ക്ലൗഡിലേക്കുള്ള അഭ്യർത്ഥനകളുടെ സമയവുമായി താരതമ്യം ചെയ്യുക:

നിങ്ങൾക്ക് കാണാനാകുന്നതുപോലെ, ഫലങ്ങൾ സമ്മിശ്രമായിരുന്നു - മിക്ക കേസുകളിലും പ്രോക്സി നല്ല വേഗത നൽകുന്നു, എന്നാൽ സാഹചര്യം ഗണ്യമായി വഷളാക്കുന്ന ആവശ്യത്തിന് ക്ലയന്റുകളുമുണ്ട്.

തൽഫലമായി, ഞങ്ങൾ നിരവധി പ്രധാന കാര്യങ്ങൾ ചെയ്തു:

1. ഒരു CDN പ്രോക്സി വഴി ക്ലയന്റുകളിൽ നിന്ന് ക്ലൗഡിലേക്കുള്ള അഭ്യർത്ഥനകളുടെ പ്രതീക്ഷിച്ച പ്രകടനം ഞങ്ങൾ വിലയിരുത്തി.
2. എല്ലാത്തരം ഉപകരണങ്ങളിൽ നിന്നും യഥാർത്ഥ ക്ലയന്റുകളിൽ നിന്ന് ഞങ്ങൾക്ക് ഡാറ്റ ലഭിച്ചു.
3. സിദ്ധാന്തം 100% സ്ഥിരീകരിച്ചിട്ടില്ലെന്നും ഒരു CDN പ്രോക്‌സിയുമായുള്ള പ്രാരംഭ ഓഫർ ഞങ്ങൾക്ക് പ്രവർത്തിക്കില്ലെന്നും ഞങ്ങൾ മനസ്സിലാക്കി.
4. ഞങ്ങൾ അപകടസാധ്യതകൾ എടുത്തില്ല - ക്ലയന്റുകളുടെ ഉൽപ്പാദന കോൺഫിഗറേഷനുകൾ ഞങ്ങൾ മാറ്റിയില്ല.
5. ഒന്നും തകർന്നില്ല.

പ്രോട്ടോടൈപ്പ് 2.0

അതിനാൽ, ഡ്രോയിംഗ് ബോർഡിലേക്ക് മടങ്ങുക, പ്രക്രിയ വീണ്ടും ആവർത്തിക്കുക.

100% പ്രോക്സി ഉപയോഗിക്കുന്നതിനുപകരം, ഓരോ ക്ലയന്റിനുമുള്ള ഏറ്റവും വേഗതയേറിയ പാത ഞങ്ങൾ നിർണ്ണയിക്കും, ഞങ്ങൾ അവിടെ അഭ്യർത്ഥനകൾ അയയ്ക്കും - അതായത്, ക്ലയന്റ് സ്റ്റിയറിംഗ് എന്ന് വിളിക്കുന്നത് ഞങ്ങൾ ചെയ്യും എന്നതാണ് ആശയം.

ഇത് എങ്ങനെ നടപ്പിലാക്കും? സെർവർ ഭാഗത്ത് നമുക്ക് ലോജിക് ഉപയോഗിക്കാൻ കഴിയില്ല, കാരണം... ഈ സെർവറുമായി ബന്ധിപ്പിക്കുക എന്നതാണ് ലക്ഷ്യം. ക്ലയന്റിൽ ഇത് ചെയ്യുന്നതിന് എന്തെങ്കിലും മാർഗം ഉണ്ടായിരിക്കണം. കൂടാതെ, ഒരു വലിയ എണ്ണം ക്ലയന്റ് പ്ലാറ്റ്‌ഫോമുകളുമായുള്ള സംയോജനത്തിന്റെ പ്രശ്നം പരിഹരിക്കാതിരിക്കാൻ, ഏറ്റവും കുറഞ്ഞ സങ്കീർണ്ണമായ യുക്തി ഉപയോഗിച്ച് ഇത് ചെയ്യുക.

ഉത്തരം ഡിഎൻഎസ് ഉപയോഗിക്കുക എന്നതാണ്. ഞങ്ങളുടെ കാര്യത്തിൽ, ഞങ്ങൾക്ക് ഞങ്ങളുടെ സ്വന്തം ഡിഎൻഎസ് ഇൻഫ്രാസ്ട്രക്ചർ ഉണ്ട്, ഞങ്ങളുടെ സെർവറുകൾ സ്വേച്ഛാധിപത്യമുള്ള ഒരു ഡൊമെയ്ൻ സോൺ സജ്ജീകരിക്കാം. ഇത് ഇതുപോലെ പ്രവർത്തിക്കുന്നു:

1. ഒരു ഹോസ്റ്റ് ഉപയോഗിച്ച് ക്ലയന്റ് DNS സെർവറിലേക്ക് ഒരു അഭ്യർത്ഥന നടത്തുന്നു, ഉദാഹരണത്തിന് api.netflix.xom.
2. അഭ്യർത്ഥന ഞങ്ങളുടെ DNS സെർവറിൽ എത്തുന്നു
3. ഈ ക്ലയന്റിനുള്ള ഏറ്റവും വേഗതയേറിയ പാത ഏതെന്ന് DNS സെർവറിന് അറിയുകയും അനുബന്ധ IP വിലാസം നൽകുകയും ചെയ്യുന്നു.

പരിഹാരത്തിന് ഒരു അധിക സങ്കീർണ്ണതയുണ്ട്: സ്വേച്ഛാധിപത്യ ഡിഎൻഎസ് ദാതാക്കൾ ക്ലയന്റിൻറെ IP വിലാസം കാണുന്നില്ല കൂടാതെ ക്ലയന്റ് ഉപയോഗിക്കുന്ന ആവർത്തന പരിഹാരത്തിന്റെ IP വിലാസം മാത്രമേ വായിക്കാൻ കഴിയൂ.

തൽഫലമായി, ഞങ്ങളുടെ സ്വേച്ഛാധിപത്യ റിസോൾവർ ഒരു തീരുമാനം എടുക്കേണ്ടത് ഒരു വ്യക്തിഗത ക്ലയന്റിനല്ല, മറിച്ച് ആവർത്തന പരിഹാരത്തെ അടിസ്ഥാനമാക്കിയുള്ള ഒരു കൂട്ടം ക്ലയന്റുകൾക്ക് വേണ്ടിയാണ്.

പരിഹരിക്കാൻ, ഞങ്ങൾ ഒരേ സാമ്പിളുകൾ ഉപയോഗിക്കുന്നു, ഓരോ ആവർത്തന പരിഹാരങ്ങൾക്കുമായി ക്ലയന്റുകളിൽ നിന്നുള്ള അളക്കൽ ഫലങ്ങൾ സമാഹരിച്ച് ഈ ഗ്രൂപ്പിനെ എവിടേക്കാണ് അയയ്‌ക്കേണ്ടതെന്ന് തീരുമാനിക്കുക - TCP Anycast ഉപയോഗിച്ച് IX-ലൂടെ ഒരു പ്രോക്‌സി, ഒരു ISP പ്രോക്‌സി വഴി അല്ലെങ്കിൽ നേരിട്ട് ക്ലൗഡിലേക്ക്.

ഞങ്ങൾക്ക് ഇനിപ്പറയുന്ന സിസ്റ്റം ലഭിക്കും:

തത്ഫലമായുണ്ടാകുന്ന ഡിഎൻഎസ് സ്റ്റിയറിംഗ് മോഡൽ, ക്ലയന്റുകളിൽ നിന്ന് ക്ലൗഡിലേക്കുള്ള കണക്ഷനുകളുടെ വേഗതയെക്കുറിച്ചുള്ള ചരിത്രപരമായ നിരീക്ഷണങ്ങളെ അടിസ്ഥാനമാക്കി ക്ലയന്റുകളെ നയിക്കാൻ നിങ്ങളെ അനുവദിക്കുന്നു.

ഈ സമീപനം എത്രത്തോളം ഫലപ്രദമായി പ്രവർത്തിക്കും എന്നതാണ് വീണ്ടും ചോദ്യം. ഉത്തരം നൽകാൻ, ഞങ്ങൾ വീണ്ടും ഞങ്ങളുടെ അന്വേഷണ സംവിധാനം ഉപയോഗിക്കുന്നു. അതിനാൽ, ഞങ്ങൾ അവതാരക കോൺഫിഗറേഷൻ ക്രമീകരിക്കുന്നു, അവിടെ ലക്ഷ്യങ്ങളിലൊന്ന് DNS സ്റ്റിയറിംഗിൽ നിന്നുള്ള ദിശ പിന്തുടരുന്നു, മറ്റൊന്ന് നേരിട്ട് ക്ലൗഡിലേക്ക് പോകുന്നു (നിലവിലെ ഉത്പാദനം).

ഫലമായി, ഞങ്ങൾ ഫലങ്ങൾ താരതമ്യം ചെയ്യുകയും ഫലപ്രാപ്തിയുടെ ഒരു വിലയിരുത്തൽ നേടുകയും ചെയ്യുന്നു:

തൽഫലമായി, ഞങ്ങൾ നിരവധി പ്രധാന കാര്യങ്ങൾ പഠിച്ചു:

1. ക്ലയന്റുകളിൽ നിന്ന് ക്ലൗഡിലേക്കുള്ള അഭ്യർത്ഥനകളുടെ പ്രതീക്ഷിച്ച പ്രകടനം ഞങ്ങൾ DNS സ്റ്റിയറിംഗ് ഉപയോഗിച്ച് വിലയിരുത്തി.
2. എല്ലാത്തരം ഉപകരണങ്ങളിൽ നിന്നും യഥാർത്ഥ ക്ലയന്റുകളിൽ നിന്ന് ഞങ്ങൾക്ക് ഡാറ്റ ലഭിച്ചു.
3. നിർദ്ദിഷ്ട ആശയത്തിന്റെ ഫലപ്രാപ്തി തെളിയിക്കപ്പെട്ടിട്ടുണ്ട്.
4. ഞങ്ങൾ അപകടസാധ്യതകൾ എടുത്തില്ല - ക്ലയന്റുകളുടെ ഉൽപ്പാദന കോൺഫിഗറേഷനുകൾ ഞങ്ങൾ മാറ്റിയില്ല.
5. ഒന്നും തകർന്നില്ല.

ഇപ്പോൾ ബുദ്ധിമുട്ടുള്ള ഭാഗത്തെക്കുറിച്ച് - ഞങ്ങൾ അത് ഉൽപ്പാദനത്തിൽ സമാരംഭിക്കുന്നു

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

ഇതിനെല്ലാം പുറമേ, സിസ്റ്റത്തിന്റെ വികസനത്തിനും വിന്യാസത്തിനും പൂർണ്ണ പിന്തുണയ്ക്കും ഉത്തരവാദികളായ 3 എഞ്ചിനീയർമാർ ടീമിന് ഉണ്ട്.

അതിനാൽ, വിശ്രമവും ആരോഗ്യകരവുമായ ഉറക്കത്തെക്കുറിച്ച് നമ്മൾ സംസാരിക്കുന്നത് തുടരും.

വികസനം എങ്ങനെ തുടരാം, നിങ്ങളുടെ മുഴുവൻ സമയവും പിന്തുണയ്‌ക്കായി ചെലവഴിക്കരുത്? ഞങ്ങളുടെ സമീപനം 3 തത്വങ്ങളെ അടിസ്ഥാനമാക്കിയുള്ളതാണ്:

1. തകർച്ചയുടെ സാധ്യതയുള്ള സ്കെയിൽ ഞങ്ങൾ കുറയ്ക്കുന്നു (ബ്ലാസ്റ്റ് റേഡിയസ്).
2. ഞങ്ങൾ ആശ്ചര്യങ്ങൾക്കായി തയ്യാറെടുക്കുകയാണ് - പരിശോധനയും വ്യക്തിപരമായ അനുഭവവും ഉണ്ടായിരുന്നിട്ടും എന്തെങ്കിലും തകരുമെന്ന് ഞങ്ങൾ പ്രതീക്ഷിക്കുന്നു.
3. ഗംഭീരമായ ഡീഗ്രേഡേഷൻ - എന്തെങ്കിലും ശരിയായി പ്രവർത്തിക്കുന്നില്ലെങ്കിൽ, അത് ഏറ്റവും കാര്യക്ഷമമായ രീതിയിൽ അല്ലെങ്കിലും യാന്ത്രികമായി പരിഹരിക്കപ്പെടണം.

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

തീർച്ചയായും, വീഴ്ചയുണ്ടായിട്ടും, വികസന സമയത്ത് ഞങ്ങൾ വ്യക്തമായ അച്ചടക്കം പാലിക്കുന്നു:

1. സാമ്പിൾ ടെസ്റ്റ്.
2. എ/ബി ടെസ്റ്റിംഗ് അല്ലെങ്കിൽ കാനറികൾ.
3. പുരോഗമനപരമായ റോൾഔട്ട്.

സാമ്പിളുകൾ ഉപയോഗിച്ച്, സമീപനം വിവരിച്ചിട്ടുണ്ട് - ഒരു ഇഷ്‌ടാനുസൃത പാചകക്കുറിപ്പ് ഉപയോഗിച്ച് മാറ്റങ്ങൾ ആദ്യം പരീക്ഷിക്കുന്നു.

കാനറി പരിശോധനയ്‌ക്കായി, മാറ്റങ്ങൾക്ക് മുമ്പും ശേഷവും സിസ്റ്റം എങ്ങനെ പ്രവർത്തിക്കുന്നുവെന്ന് താരതമ്യം ചെയ്യാൻ കഴിയുന്ന താരതമ്യപ്പെടുത്താവുന്ന ജോഡി സെർവറുകൾ ഞങ്ങൾക്ക് ലഭിക്കേണ്ടതുണ്ട്. ഇത് ചെയ്യുന്നതിന്, ഞങ്ങളുടെ നിരവധി CDN സൈറ്റുകളിൽ നിന്ന്, താരതമ്യപ്പെടുത്താവുന്ന ട്രാഫിക് ലഭിക്കുന്ന ജോഡി സെർവറുകൾ ഞങ്ങൾ തിരഞ്ഞെടുക്കുന്നു:

തുടർന്ന് കാനറി സെർവറിലെ മാറ്റങ്ങളോടെ ഞങ്ങൾ ബിൽഡ് ഇൻസ്റ്റാൾ ചെയ്യുന്നു. ഫലങ്ങൾ വിലയിരുത്തുന്നതിന്, കൺട്രോൾ സെർവറുകളുടെ സാമ്പിളുമായി ഏകദേശം 100-150 മെട്രിക്കുകൾ താരതമ്യം ചെയ്യുന്ന ഒരു സിസ്റ്റം ഞങ്ങൾ പ്രവർത്തിപ്പിക്കുന്നു:

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

പൊതുവേ, ഈ സമീപനത്തിന്റെ ഫലപ്രാപ്തിയും സുരക്ഷിതത്വവും ശേഖരിച്ച അളവുകളുടെ അളവും ഗുണനിലവാരവും ആശ്രയിച്ചിരിക്കുന്നു. ഞങ്ങളുടെ അന്വേഷണ ആക്സിലറേഷൻ സിസ്റ്റത്തിനായി, സാധ്യമായ എല്ലാ ഘടകങ്ങളിൽ നിന്നും ഞങ്ങൾ മെട്രിക്സ് ശേഖരിക്കുന്നു:

• ക്ലയന്റുകളിൽ നിന്ന് - സെഷനുകളുടെയും അഭ്യർത്ഥനകളുടെയും എണ്ണം, ഫാൾബാക്ക് നിരക്കുകൾ;
• പ്രോക്സി - അഭ്യർത്ഥനകളുടെ എണ്ണവും സമയവും സംബന്ധിച്ച സ്ഥിതിവിവരക്കണക്കുകൾ;
• DNS - അഭ്യർത്ഥനകളുടെ നമ്പറും ഫലങ്ങളും;
• ക്ലൗഡ് എഡ്ജ് - ക്ലൗഡിലെ അഭ്യർത്ഥനകൾ പ്രോസസ്സ് ചെയ്യുന്നതിനുള്ള നമ്പറും സമയവും.

ഇതെല്ലാം ഒരൊറ്റ പൈപ്പ്‌ലൈനിലേക്ക് ശേഖരിക്കുന്നു, ആവശ്യങ്ങൾക്കനുസരിച്ച്, തത്സമയ അനലിറ്റിക്‌സിലേക്ക് ഏതൊക്കെ മെട്രിക്‌സുകളാണ് അയയ്‌ക്കേണ്ടതെന്നും കൂടുതൽ വിശദമായ ഡയഗ്‌നോസ്റ്റിക്‌സിനായി ഏത് ഇലാസ്റ്റിക് സെർച്ചിലേക്കോ ബിഗ് ഡാറ്റയിലേക്കോ അയയ്‌ക്കണമെന്നും ഞങ്ങൾ തീരുമാനിക്കുന്നു.

ഞങ്ങൾ നിരീക്ഷിക്കുന്നു

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

തത്സമയം എല്ലാത്തരം മെട്രിക്‌സുകളിലേക്കും ഫിൽട്ടറുകളിലേക്കും പൂർണ്ണ ആക്‌സസ്സ്. എന്നാൽ ധാരാളം അളവുകൾ ഉണ്ട്, അതിനാൽ ചെലവിന്റെ ചോദ്യം ഉയർന്നുവരുന്നു. ഞങ്ങളുടെ കാര്യത്തിൽ, ഞങ്ങൾ മെട്രിക്സും വികസന ഉപകരണങ്ങളും ഇനിപ്പറയുന്ന രീതിയിൽ വേർതിരിക്കുന്നു:

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

ഈ സമീപനം പ്രവർത്തിക്കാൻ വളരെ ബുദ്ധിമുട്ടാണെന്ന് തോന്നുന്നു. എന്നിരുന്നാലും, അളവുകോലുകളും ഉപകരണങ്ങളും ശ്രേണീകൃതമായി ക്രമീകരിക്കുന്നതിലൂടെ, നമുക്ക് ഒരു പ്രശ്നം പെട്ടെന്ന് വിശകലനം ചെയ്യാനും പ്രശ്നത്തിന്റെ തരം നിർണ്ണയിക്കാനും തുടർന്ന് വിശദമായ അളവുകോലുകളിലേക്ക് തുളച്ചുകയറാനും കഴിയും. പൊതുവേ, തകർച്ചയുടെ ഉറവിടം തിരിച്ചറിയാൻ ഞങ്ങൾ ഏകദേശം 1-2 മിനിറ്റ് ചെലവഴിക്കുന്നു. ഇതിനുശേഷം, ഡയഗ്നോസ്റ്റിക്സിൽ ഞങ്ങൾ ഒരു പ്രത്യേക ടീമുമായി പ്രവർത്തിക്കുന്നു - പതിനായിരക്കണക്കിന് മിനിറ്റ് മുതൽ നിരവധി മണിക്കൂർ വരെ.

രോഗനിർണയം വേഗത്തിൽ നടന്നാലും, ഇത് പലപ്പോഴും സംഭവിക്കാൻ ഞങ്ങൾ ആഗ്രഹിക്കുന്നില്ല. സേവനത്തിൽ കാര്യമായ സ്വാധീനം ചെലുത്തുമ്പോൾ മാത്രമേ ഞങ്ങൾക്ക് ഒരു നിർണായക മുന്നറിയിപ്പ് ലഭിക്കൂ. ഞങ്ങളുടെ അന്വേഷണ ആക്സിലറേഷൻ സിസ്റ്റത്തിന്, ഞങ്ങൾക്ക് 2 അലേർട്ടുകൾ മാത്രമേ ഉള്ളൂ, അത് അറിയിക്കും:

• ക്ലയന്റ് ഫാൾബാക്ക് ശതമാനം - ഉപഭോക്തൃ പെരുമാറ്റത്തിന്റെ വിലയിരുത്തൽ;
• ശതമാനം പ്രോബ് പിശകുകൾ - നെറ്റ്‌വർക്ക് ഘടകങ്ങളുടെ സ്ഥിരത ഡാറ്റ.

സിസ്റ്റം ഭൂരിഭാഗം ഉപയോക്താക്കൾക്കും വേണ്ടി പ്രവർത്തിക്കുന്നുണ്ടോ എന്ന് ഈ നിർണായക അലേർട്ടുകൾ നിരീക്ഷിക്കുന്നു. അഭ്യർത്ഥന ത്വരിതപ്പെടുത്തൽ നേടാൻ കഴിയുന്നില്ലെങ്കിൽ എത്ര ക്ലയന്റുകൾ ഫാൾബാക്ക് ഉപയോഗിച്ചുവെന്ന് ഞങ്ങൾ നോക്കുന്നു. സിസ്റ്റത്തിൽ ഒരു ടൺ മാറ്റങ്ങൾ നടക്കുന്നുണ്ടെങ്കിലും, ഞങ്ങൾ ആഴ്‌ചയിൽ ശരാശരി 1 നിർണ്ണായക അലേർട്ടിൽ താഴെയാണ്. എന്തുകൊണ്ടാണ് ഞങ്ങൾക്ക് ഇത് മതിയാകുന്നത്?

1. ഞങ്ങളുടെ പ്രോക്സി പ്രവർത്തിക്കുന്നില്ലെങ്കിൽ ഒരു ക്ലയന്റ് ഫാൾബാക്ക് ഉണ്ട്.
2. പ്രശ്നങ്ങളോട് പ്രതികരിക്കുന്ന ഒരു ഓട്ടോമാറ്റിക് സ്റ്റിയറിംഗ് സംവിധാനമുണ്ട്.

രണ്ടാമത്തേതിനെക്കുറിച്ചുള്ള കൂടുതൽ വിശദാംശങ്ങൾ. ഞങ്ങളുടെ ട്രയൽ സിസ്റ്റവും ക്ലയന്റിൽനിന്നുള്ള ക്ലൗഡിലേക്കുള്ള അഭ്യർത്ഥനകൾക്കുള്ള ഒപ്റ്റിമൽ പാത്ത് സ്വയമേവ നിർണയിക്കുന്നതിനുള്ള സംവിധാനവും ചില പ്രശ്‌നങ്ങളെ സ്വയമേവ നേരിടാൻ ഞങ്ങളെ അനുവദിക്കുന്നു.

നമുക്ക് നമ്മുടെ സാമ്പിൾ കോൺഫിഗറേഷനിലേക്കും 3 പാത്ത് വിഭാഗങ്ങളിലേക്കും മടങ്ങാം. ലോഡിംഗ് സമയം കൂടാതെ, ഡെലിവറി എന്ന വസ്തുതയും നമുക്ക് നോക്കാം. ഡാറ്റ ലോഡുചെയ്യുന്നത് സാധ്യമല്ലെങ്കിൽ, വ്യത്യസ്ത പാതകളിലൂടെയുള്ള ഫലങ്ങൾ നോക്കുന്നതിലൂടെ, എവിടെ, എന്താണ് തകർന്നത്, അഭ്യർത്ഥന പാത്ത് മാറ്റുന്നതിലൂടെ അത് യാന്ത്രികമായി പരിഹരിക്കാനാകുമോ എന്ന് നമുക്ക് നിർണ്ണയിക്കാനാകും.

ഉദാഹരണങ്ങൾ:

ഈ പ്രക്രിയ ഓട്ടോമേറ്റ് ചെയ്യാം. സ്റ്റിയറിംഗ് സിസ്റ്റത്തിൽ ഇത് ഉൾപ്പെടുത്തുക. ഒപ്പം പ്രകടന, വിശ്വാസ്യത പ്രശ്‌നങ്ങളോട് പ്രതികരിക്കാൻ അതിനെ പഠിപ്പിക്കുക. എന്തെങ്കിലും തകരാൻ തുടങ്ങിയാൽ, മികച്ച ഓപ്ഷൻ ഉണ്ടെങ്കിൽ പ്രതികരിക്കുക. അതേ സമയം, ഉടനടിയുള്ള പ്രതികരണം നിർണായകമല്ല, ക്ലയന്റുകളുടെ വീഴ്ചയ്ക്ക് നന്ദി.

അതിനാൽ, സിസ്റ്റം പിന്തുണയുടെ തത്വങ്ങൾ ഇനിപ്പറയുന്ന രീതിയിൽ രൂപപ്പെടുത്താം:

• തകരാറുകളുടെ തോത് കുറയ്ക്കൽ;
• അളവുകൾ ശേഖരിക്കുന്നു;
• ഞങ്ങൾക്ക് കഴിയുമെങ്കിൽ ഞങ്ങൾ തകരാറുകൾ സ്വയമേവ നന്നാക്കുന്നു;
• അതിന് കഴിയുന്നില്ലെങ്കിൽ, ഞങ്ങൾ നിങ്ങളെ അറിയിക്കും;
• പെട്ടെന്നുള്ള പ്രതികരണത്തിനായി ഞങ്ങൾ ഡാഷ്‌ബോർഡുകളിലും ട്രയേജ് ടൂൾസെറ്റിലും പ്രവർത്തിക്കുന്നു.

പഠിച്ച പാഠങ്ങൾ

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

ഞങ്ങളുടെ അനുഭവത്തെ അടിസ്ഥാനമാക്കി, ഞങ്ങൾക്ക് ഇനിപ്പറയുന്നവ ശുപാർശ ചെയ്യാൻ കഴിയും:

1. നിങ്ങളുടെ അവബോധത്തെ വിശ്വസിക്കരുത്.

   ഞങ്ങളുടെ ടീം അംഗങ്ങളുടെ വിപുലമായ അനുഭവം ഉണ്ടായിരുന്നിട്ടും ഞങ്ങളുടെ അവബോധം ഞങ്ങളെ നിരന്തരം പരാജയപ്പെടുത്തി. ഉദാഹരണത്തിന്, ഒരു CDN പ്രോക്സി ഉപയോഗിക്കുന്നതിൽ നിന്നും അല്ലെങ്കിൽ TCP Anycast-ന്റെ പെരുമാറ്റത്തിൽ നിന്നും പ്രതീക്ഷിക്കുന്ന വേഗത ഞങ്ങൾ തെറ്റായി പ്രവചിച്ചു.

2. ഉൽപ്പാദനത്തിൽ നിന്ന് ഡാറ്റ നേടുക.

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

3. മറ്റുള്ളവരുടെ ഉപദേശങ്ങളും ഫലങ്ങളും പിന്തുടരരുത് - നിങ്ങളുടെ സ്വന്തം ഡാറ്റ ശേഖരിക്കുക.

   ഡാറ്റ ശേഖരിക്കുന്നതിനും വിശകലനം ചെയ്യുന്നതിനുമുള്ള തത്വങ്ങൾ പിന്തുടരുക, എന്നാൽ മറ്റുള്ളവരുടെ ഫലങ്ങളും പ്രസ്താവനകളും അന്ധമായി അംഗീകരിക്കരുത്. നിങ്ങളുടെ ഉപയോക്താക്കൾക്കായി എന്താണ് പ്രവർത്തിക്കുന്നതെന്ന് നിങ്ങൾക്ക് മാത്രമേ കൃത്യമായി അറിയാൻ കഴിയൂ. നിങ്ങളുടെ സിസ്റ്റങ്ങളും നിങ്ങളുടെ ഉപഭോക്താക്കളും മറ്റ് കമ്പനികളിൽ നിന്ന് കാര്യമായി വ്യത്യസ്തമായിരിക്കാം. ഭാഗ്യവശാൽ, വിശകലന ഉപകരണങ്ങൾ ഇപ്പോൾ ലഭ്യമാണ്, ഉപയോഗിക്കാൻ എളുപ്പമാണ്. നിങ്ങൾക്ക് ലഭിക്കുന്ന ഫലങ്ങൾ Netflix, Facebook, Akamai എന്നിവയും മറ്റ് കമ്പനികളും അവകാശപ്പെടുന്നതല്ല. ഞങ്ങളുടെ കാര്യത്തിൽ, TLS, HTTP2 അല്ലെങ്കിൽ DNS അഭ്യർത്ഥനകളിലെ സ്ഥിതിവിവരക്കണക്കുകൾ Facebook, Uber, Akamai എന്നിവയുടെ ഫലങ്ങളിൽ നിന്ന് വ്യത്യസ്തമാണ് - കാരണം ഞങ്ങൾക്ക് വ്യത്യസ്ത ഉപകരണങ്ങളും ക്ലയന്റുകളും ഡാറ്റാ ഫ്ലോകളും ഉണ്ട്.

4. ഫാഷൻ ട്രെൻഡുകൾ അനാവശ്യമായി പിന്തുടരരുത്, ഫലപ്രാപ്തി വിലയിരുത്തുക.

   ലളിതമായി ആരംഭിക്കുക. നിങ്ങൾക്ക് ആവശ്യമില്ലാത്ത ഘടകങ്ങൾ വികസിപ്പിക്കുന്നതിന് ധാരാളം സമയം ചെലവഴിക്കുന്നതിനേക്കാൾ ചുരുങ്ങിയ സമയത്തിനുള്ളിൽ ലളിതമായ ഒരു പ്രവർത്തന സംവിധാനം ഉണ്ടാക്കുന്നതാണ് നല്ലത്. നിങ്ങളുടെ അളവുകളെയും ഫലങ്ങളെയും അടിസ്ഥാനമാക്കി പ്രാധാന്യമുള്ള ജോലികളും പ്രശ്നങ്ങളും പരിഹരിക്കുക.

5. പുതിയ ആപ്ലിക്കേഷനുകൾക്കായി തയ്യാറാകൂ.

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

   • AWS മേഖലകളിലുടനീളം ട്രാഫിക് സന്തുലിതമാക്കുന്നതിനും ചെലവ് കുറയ്ക്കുന്നതിനും;
   • CDN സ്ഥിരത മാതൃകയാക്കാൻ;
   • DNS ക്രമീകരിക്കുന്നതിന്;
   • TLS/TCP കോൺഫിഗർ ചെയ്യാൻ.

തീരുമാനം

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

എന്നിരുന്നാലും, നെറ്റ്ഫ്ലിക്സിൽ ഞങ്ങൾ അത്തരമൊരു സംവിധാനം എങ്ങനെ നടപ്പിലാക്കി എന്നതിന്റെ ഒരു ഉദാഹരണം മാത്രമാണ് ഞങ്ങളുടെ പരിഹാരം. എന്താണ് ഞങ്ങൾക്ക് വേണ്ടി പ്രവർത്തിച്ചത്. നിങ്ങൾക്കുള്ള എന്റെ റിപ്പോർട്ടിന്റെ പ്രയോഗിച്ച ഭാഗം ഞങ്ങൾ പിന്തുടരുകയും നല്ല ഫലങ്ങൾ നേടുകയും ചെയ്യുന്ന വികസനത്തിന്റെയും പിന്തുണയുടെയും തത്വങ്ങളാണ്.

പ്രശ്നത്തിനുള്ള ഞങ്ങളുടെ പരിഹാരം നിങ്ങൾക്ക് അനുയോജ്യമല്ലായിരിക്കാം. എന്നിരുന്നാലും, നിങ്ങൾക്ക് സ്വന്തമായി CDN ഇൻഫ്രാസ്ട്രക്ചർ ഇല്ലെങ്കിലും ഞങ്ങളുടേതിൽ നിന്ന് കാര്യമായ വ്യത്യാസമുണ്ടെങ്കിൽ പോലും, സിദ്ധാന്തവും ഡിസൈൻ തത്വങ്ങളും നിലനിൽക്കുന്നു.

ബിസിനസ്സ് അഭ്യർത്ഥനകളുടെ വേഗതയുടെ പ്രാധാന്യവും പ്രധാനമാണ്. ഒരു ലളിതമായ സേവനത്തിനായി പോലും നിങ്ങൾ ഒരു തിരഞ്ഞെടുപ്പ് നടത്തേണ്ടതുണ്ട്: ക്ലൗഡ് ദാതാക്കൾ, സെർവർ ലൊക്കേഷൻ, സിഡിഎൻ, ഡിഎൻഎസ് ദാതാക്കൾ എന്നിവയ്ക്കിടയിൽ. നിങ്ങളുടെ ഉപഭോക്താക്കൾക്കുള്ള ഇന്റർനെറ്റ് അന്വേഷണങ്ങളുടെ ഫലപ്രാപ്തിയെ നിങ്ങളുടെ തിരഞ്ഞെടുപ്പ് സ്വാധീനിക്കും. ഈ സ്വാധീനം അളക്കുകയും മനസ്സിലാക്കുകയും ചെയ്യേണ്ടത് പ്രധാനമാണ്.

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

ഈ വർഷം ജൂലൈ 6 മുതൽ 10 വരെയാണ് സമ്മേളനം ഓൺലൈൻ ഫോർമാറ്റിൽ. DevOps-ന്റെ പിതാക്കന്മാരിൽ ഒരാളായ ജോൺ വില്ലിസിനോട് തന്നെ നിങ്ങൾക്ക് ചോദ്യങ്ങൾ ചോദിക്കാം!

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