பல ஸ்டார்ட்அப்கள் இதை கடந்து சென்றுள்ளன: ஒவ்வொரு நாளும் புதிய பயனர்களின் கூட்டம் பதிவு செய்யப்படுகிறது, மேலும் மேம்பாட்டுக் குழு சேவையை இயங்க வைக்க போராடுகிறது.

இது ஒரு நல்ல பிரச்சனை, ஆனால் நூறாயிரக்கணக்கான பயனர்களுக்கு இணைய பயன்பாட்டை எப்படி கவனமாக அளவிடுவது என்பது பற்றிய தெளிவான தகவல்கள் இணையத்தில் இல்லை. பொதுவாக தீ தீர்வுகள் அல்லது இடையூறு தீர்வுகள் (மற்றும் பெரும்பாலும் இரண்டும்) உள்ளன. எனவே, மக்கள் தங்கள் அமெச்சூர் திட்டத்தை மிகவும் தீவிரமான ஒன்றாக அளவிடுவதற்கு மாறாக கிளிச் நுட்பங்களைப் பயன்படுத்துகின்றனர்.

தகவலை வடிகட்டி அடிப்படை சூத்திரத்தை எழுத முயற்சிப்போம். எங்கள் புதிய புகைப்பட பகிர்வு தளமான கிராமின்ஸ்டாவை 1 முதல் 100 பயனர்களாக படிப்படியாக அளவிடப் போகிறோம்.

பார்வையாளர்கள் 10, 100, 1000, 10 மற்றும் 000 பேராக அதிகரிக்கும் போது என்ன குறிப்பிட்ட நடவடிக்கைகள் எடுக்கப்பட வேண்டும் என்பதை எழுதுவோம்.

1 பயனர்: 1 இயந்திரம்

கிட்டத்தட்ட ஒவ்வொரு பயன்பாடும், அது ஒரு இணையதளம் அல்லது மொபைல் பயன்பாடு, மூன்று முக்கிய கூறுகளைக் கொண்டுள்ளது:

• ஏபிஐ
• தகவல்
• கிளையன்ட் (மொபைல் பயன்பாடு அல்லது இணையதளம்)

தரவுத்தளமானது நிலையான தரவுகளை சேமிக்கிறது. இந்தத் தரவைச் சுற்றியுள்ள கோரிக்கைகளை API வழங்குகிறது. கிளையன்ட் பயனருக்கு தரவை அனுப்புகிறது.

ஒரு கட்டடக்கலை பார்வையில், கிளையன்ட் மற்றும் API நிறுவனங்கள் முற்றிலும் பிரிக்கப்பட்டிருந்தால், பயன்பாட்டை அளவிடுவது பற்றி பேசுவது மிகவும் எளிதானது என்ற முடிவுக்கு வந்தேன்.

நாம் முதலில் ஒரு பயன்பாட்டை உருவாக்கத் தொடங்கும் போது, ​​மூன்று கூறுகளையும் ஒரே சர்வரில் இயக்க முடியும். சில வழிகளில், இது எங்கள் மேம்பாட்டு சூழலைப் போன்றது: ஒரு பொறியாளர் ஒரே கணினியில் தரவுத்தளம், API மற்றும் கிளையண்டை இயக்குகிறார்.

கோட்பாட்டில், கீழே காட்டப்பட்டுள்ளபடி, ஒரு டிஜிட்டல் ஓஷன் டிராப்லெட் அல்லது AWS EC2 நிகழ்வில் நாம் அதை மேகக்கணியில் பயன்படுத்த முடியும்:

ஒரு தளத்தில் ஒன்றுக்கும் மேற்பட்ட பயனர்கள் இருந்தால், தரவுத்தள அடுக்கை அர்ப்பணிப்பது எப்போதும் அர்த்தமுள்ளதாக இருக்கும்.

10 பயனர்கள்: தரவுத்தளத்தை ஒரு தனி நிலைக்கு நகர்த்துதல்

அமேசான் ஆர்டிஎஸ் அல்லது டிஜிட்டல் ஓஷன் மேனேஜ்ட் டேட்டாபேஸ் போன்ற நிர்வகிக்கப்பட்ட சேவைகளாக தரவுத்தளத்தைப் பிரிப்பது நீண்ட காலத்திற்கு நமக்குச் சேவை செய்யும். ஒரு கணினி அல்லது EC2 நிகழ்வில் சுய-ஹோஸ்டிங் செய்வதை விட இது சற்று விலை அதிகம், ஆனால் இந்த சேவைகளின் மூலம் நீங்கள் பல பயனுள்ள நீட்டிப்புகளைப் பெறுவீர்கள். காப்புப்பிரதிகள் மற்றும் பல.

இந்த அமைப்பு இப்போது எப்படி இருக்கிறது:

100 பயனர்கள்: கிளையண்டை ஒரு தனி நிலைக்கு நகர்த்துதல்

அதிர்ஷ்டவசமாக, எங்கள் முதல் பயனர்கள் எங்கள் பயன்பாட்டை மிகவும் விரும்பினர். போக்குவரத்து மிகவும் நிலையானதாகி வருகிறது, எனவே வாடிக்கையாளரை தனி நிலைக்கு நகர்த்துவதற்கான நேரம் இது. என்பதை கவனத்தில் கொள்ள வேண்டும் பிரித்தல் நிறுவனங்கள் அளவிடக்கூடிய பயன்பாட்டை உருவாக்குவதற்கான முக்கிய அம்சமாகும். கணினியின் ஒரு பகுதி அதிக ட்ராஃபிக்கைப் பெறுவதால், குறிப்பிட்ட ட்ராஃபிக் முறைகளின் அடிப்படையில் சேவை அளவைக் கட்டுப்படுத்த நாம் அதைப் பிரிக்கலாம்.

இதனால்தான் கிளையண்டை API இலிருந்து தனித்தனியாக நினைக்க விரும்புகிறேன். இணையம், மொபைல் வலை, iOS, ஆண்ட்ராய்டு, டெஸ்க்டாப் பயன்பாடுகள், மூன்றாம் தரப்பு சேவைகள் போன்ற பல இயங்குதளங்களை உருவாக்குவது பற்றி யோசிப்பதை இது மிகவும் எளிதாக்குகிறது. அவை அனைத்தும் ஒரே API ஐப் பயன்படுத்தும் வாடிக்கையாளர்களாகும்.

எடுத்துக்காட்டாக, இப்போது எங்கள் பயனர்கள் பெரும்பாலும் மொபைல் பயன்பாட்டை வெளியிடும்படி கேட்கிறார்கள். நீங்கள் கிளையன்ட் மற்றும் API நிறுவனங்களை பிரித்தால், இது எளிதாகிவிடும்.

அத்தகைய அமைப்பு இது போல் தெரிகிறது:

1000 பயனர்கள்: சுமை சமநிலையைச் சேர்க்கவும்

விஷயங்கள் மேலே பார்க்கின்றன. கிராமின்ஸ்டா பயனர்கள் அதிகமான புகைப்படங்களைப் பதிவேற்றுகின்றனர். பதிவுகளின் எண்ணிக்கையும் அதிகரித்து வருகிறது. எங்களின் தனி ஏபிஐ சேவையகம் அனைத்து டிராஃபிக்கையும் சமாளிப்பது கடினம். இன்னும் இரும்பு வேண்டும்!

சுமை சமநிலை என்பது மிகவும் சக்திவாய்ந்த கருத்து. முக்கிய யோசனை என்னவென்றால், நாங்கள் API க்கு முன்னால் ஒரு சுமை சமநிலையை வைக்கிறோம், மேலும் இது தனிப்பட்ட சேவை நிகழ்வுகளுக்கு போக்குவரத்தை விநியோகிக்கிறது. இப்படித்தான் நாம் கிடைமட்டமாக அளவிடுகிறோம், அதாவது ஒரே குறியீட்டைக் கொண்டு அதிக சேவையகங்களைச் சேர்ப்போம், நாங்கள் செயல்படுத்தக்கூடிய கோரிக்கைகளின் எண்ணிக்கையை அதிகரிக்கிறோம்.

வலை கிளையண்ட் முன் மற்றும் API முன் தனித்தனியாக சுமை பேலன்சர்களை வைக்க உள்ளோம். இதன் பொருள் நீங்கள் API குறியீடு மற்றும் இணைய கிளையன்ட் குறியீட்டை இயக்கும் பல நிகழ்வுகளை இயக்கலாம். லோட் பேலன்சர் குறைவான ஏற்றப்பட்ட சேவையகத்திற்கு கோரிக்கைகளை அனுப்பும்.

இங்கே நாம் மற்றொரு முக்கியமான நன்மையைப் பெறுகிறோம் - பணிநீக்கம். ஒரு நிகழ்வு தோல்வியுற்றால் (ஒருவேளை ஓவர்லோட் அல்லது செயலிழந்தால்), உள்வரும் கோரிக்கைகளுக்கு தொடர்ந்து பதிலளிக்கும் மற்றவர்களுடன் நாங்கள் இருக்கிறோம். ஒரே ஒரு நிகழ்வு மட்டுமே வேலை செய்திருந்தால், தோல்வி ஏற்பட்டால் முழு கணினியும் செயலிழந்துவிடும்.

லோட் பேலன்சர் தானியங்கி அளவீட்டையும் வழங்குகிறது. பீக் லோடுக்கு முன் நிகழ்வுகளின் எண்ணிக்கையை அதிகரிக்கவும், எல்லாப் பயனர்கள் தூங்கும்போதும் குறைக்கவும் அதை உள்ளமைக்கலாம்.

ஒரு சுமை சமநிலையுடன், ஏபிஐ அளவை கிட்டத்தட்ட காலவரையின்றி அளவிட முடியும், கோரிக்கைகளின் எண்ணிக்கை அதிகரிக்கும் போது புதிய நிகழ்வுகளைச் சேர்க்கலாம்.

குறிப்பு. AWS இல் Heroku அல்லது Elastic Beanstalk போன்ற 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 Cloud இல் Memorystore.

ஒரு சேவையானது அதே தகவலை மீட்டெடுக்க தரவுத்தளத்திற்கு மீண்டும் மீண்டும் அழைப்புகளை மேற்கொள்ளும்போது ஒரு தற்காலிக சேமிப்பு பயனுள்ளதாக இருக்கும். அடிப்படையில், நாங்கள் தரவுத்தளத்தை ஒரு முறை மட்டுமே அணுகுவோம், தகவலை தற்காலிக சேமிப்பில் சேமித்து, அதை மீண்டும் தொட வேண்டாம்.

எடுத்துக்காட்டாக, எங்கள் கிராமின்ஸ்டா சேவையில், ஒவ்வொரு முறையும் ஒருவர் நட்சத்திர மொப்ரிக்கின் சுயவிவரப் பக்கத்திற்குச் செல்லும் போது, ​​API சேவையகம் அவரது சுயவிவரத்திலிருந்து தகவல்களுக்கு தரவுத்தளத்தை வினவுகிறது. இது மீண்டும் மீண்டும் நடக்கிறது. Mobrik இன் சுயவிவரத் தகவல் ஒவ்வொரு கோரிக்கையிலும் மாறாது என்பதால், இது தேக்ககத்திற்கு சிறந்தது.

ரெடிஸில் உள்ள தரவுத்தளத்திலிருந்து முடிவுகளை விசை மூலம் தேக்ககப்படுத்துவோம் user:id 30 வினாடிகளின் செல்லுபடியாகும் காலத்துடன். இப்போது, ​​யாராவது Mobrik இன் சுயவிவரத்திற்குச் சென்றால், முதலில் Redis ஐ சரிபார்க்கிறோம், மேலும் தரவு இருந்தால், அதை நேரடியாக Redis இலிருந்து மாற்றுவோம். இப்போது தளத்தில் மிகவும் பிரபலமான சுயவிவரத்திற்கான கோரிக்கைகள் நடைமுறையில் எங்கள் தரவுத்தளத்தை ஏற்றாது.

பெரும்பாலான கேச்சிங் சேவைகளின் மற்றொரு நன்மை என்னவென்றால், அவை தரவுத்தள சேவையகங்களை விட அளவிட எளிதானது. ரெடிஸ் ஒரு உள்ளமைக்கப்பட்ட ரெடிஸ் கிளஸ்டர் பயன்முறையைக் கொண்டுள்ளது. லோட் பேலன்சரைப் போன்றது1, இது உங்கள் Redis தற்காலிக சேமிப்பை பல இயந்திரங்களில் (தேவைப்பட்டால் ஆயிரக்கணக்கான சேவையகங்களில்) விநியோகிக்க அனுமதிக்கிறது.

ஏறக்குறைய அனைத்து பெரிய அளவிலான பயன்பாடுகளும் தேக்ககத்தைப் பயன்படுத்துகின்றன; இது வேகமான API இன் முற்றிலும் ஒருங்கிணைந்த பகுதியாகும். வேகமான வினவல் செயலாக்கம் மற்றும் அதிக உற்பத்தி குறியீடு ஆகியவை முக்கியமானவை, ஆனால் தற்காலிக சேமிப்பு இல்லாமல் மில்லியன் கணக்கான பயனர்களுக்கு ஒரு சேவையை அளவிடுவது கிட்டத்தட்ட சாத்தியமற்றது.

பிரதிகளைப் படிக்கவும்

தரவுத்தளத்திற்கான வினவல்களின் எண்ணிக்கை பெரிதும் அதிகரித்திருக்கும் போது, ​​நாம் செய்யக்கூடிய ஒரு விஷயம், தரவுத்தள மேலாண்மை அமைப்பில் வாசிப்புப் பிரதிகளைச் சேர்ப்பதாகும். மேலே விவரிக்கப்பட்ட நிர்வகிக்கப்பட்ட சேவைகள் மூலம், இதை ஒரே கிளிக்கில் செய்யலாம். படிக்கப்பட்ட பிரதி முதன்மை தரவுத்தளத்தில் தற்போதைய நிலையில் இருக்கும் மற்றும் SELECT அறிக்கைகளுக்குக் கிடைக்கும்.

இப்போது எங்கள் அமைப்பு இங்கே:

அடுத்த படிகள்

பயன்பாடு தொடர்ந்து அளவிடப்படுவதால், சேவைகளை தனித்தனியாக அளவிட, நாங்கள் தொடர்ந்து பிரிப்போம். எடுத்துக்காட்டாக, நாம் Websockets ஐப் பயன்படுத்தத் தொடங்கினால், Websockets செயலாக்கக் குறியீட்டை ஒரு தனி சேவையாக இழுப்பது அர்த்தமுள்ளதாக இருக்கும். திறந்த வெப்சாக்கெட் இணைப்புகள் மற்றும் HTTP கோரிக்கைகளின் எண்ணிக்கையைப் பொருட்படுத்தாமல், எங்கள் சொந்த லோட் பேலன்சருக்குப் பின்னால் புதிய நிகழ்வுகளில் அதை வைக்கலாம்.

தரவுத்தள மட்டத்தில் கட்டுப்பாடுகளை எதிர்த்து தொடர்ந்து போராடுவோம். இந்த கட்டத்தில்தான் தரவுத்தள பகிர்வு மற்றும் பகிர்வு ஆகியவற்றைப் படிக்க வேண்டிய நேரம் இது. இரண்டு அணுகுமுறைகளுக்கும் கூடுதல் மேல்நிலை தேவைப்படுகிறது, ஆனால் தரவுத்தளத்தை கிட்டத்தட்ட காலவரையின்றி அளவிட உங்களை அனுமதிக்கிறது.

New Relic அல்லது Datadog போன்ற கண்காணிப்பு மற்றும் பகுப்பாய்வு சேவையையும் நிறுவ விரும்புகிறோம். இது மெதுவான வினவல்களைக் கண்டறியவும், எங்கு முன்னேற்றம் தேவை என்பதைப் புரிந்துகொள்ளவும் உதவும். நாம் அளவிடும்போது, ​​இடையூறுகளைக் கண்டறிந்து அவற்றை நீக்குவதில் கவனம் செலுத்த விரும்புகிறோம்—பெரும்பாலும் முந்தைய பிரிவுகளின் சில யோசனைகளைப் பயன்படுத்துகிறோம்.

ஆதாரங்கள்

இந்த இடுகை ஒருவரால் ஈர்க்கப்பட்டது உயர் அளவிடுதல் பற்றி எனக்கு பிடித்த பதிவுகள். திட்டங்களின் ஆரம்ப கட்டங்களுக்கு கட்டுரையை இன்னும் கொஞ்சம் குறிப்பிட்டதாக உருவாக்கி அதை ஒரு விற்பனையாளரிடமிருந்து அவிழ்க்க விரும்பினேன். இந்த தலைப்பில் நீங்கள் ஆர்வமாக இருந்தால் படிக்கவும்.

அடிக்குறிப்புகள்

1. பல நிகழ்வுகளில் சுமை விநியோகத்தின் அடிப்படையில் ஒத்ததாக இருந்தாலும், ரெடிஸ் கிளஸ்டரின் அடிப்படைச் செயலாக்கம் ஒரு சுமை சமநிலையிலிருந்து மிகவும் வேறுபட்டது. [திரும்ப]

ஆதாரம்: www.habr.com