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

நுழைவு

வாழ்த்துக்கள்!

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

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

வாசிப்பு அனுபவியுங்கள்!

பிரச்சனை மற்றும் அதன் தீர்வு பற்றி சில வார்த்தைகள்

ஒரு புகைப்படத்தின் அடிப்படையில் ஒரு நபரின் கவர்ச்சியை பத்து-புள்ளி அளவில் மதிப்பிடுவதே முக்கிய யோசனை.

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

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

கவர்ச்சி மதிப்பீடு பைப்லைனில் பணிபுரியும் போது, ​​பணி பின்வரும் கூறுகளாக சிதைந்தது:

1. புகைப்படங்களில் முகங்களைத் தேர்ந்தெடுப்பது
2. ஒவ்வொரு நபரின் மதிப்பீடு
3. முடிவை வழங்கவும்

முதலாவது முன் பயிற்சி பெற்றவர்களின் சக்திகளால் தீர்க்கப்படுகிறது MTCNN. இரண்டாவதாக, பைடார்ச்சில் ஒரு சுறுசுறுப்பான நரம்பியல் வலையமைப்பு பயிற்சியளிக்கப்பட்டது ரெஸ்நெட்34 - சமநிலையில் இருந்து "CPU இல் அனுமானத்தின் தரம் / வேகம்"

மதிப்பீட்டு குழாயின் செயல்பாட்டு வரைபடம்

திட்ட கட்டமைப்பு தேவைகளின் பகுப்பாய்வு

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

ML திட்டத்தின் வாழ்க்கைச் சுழற்சி

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

1. ஒருங்கிணைந்த பதிவு சேமிப்பு - அனைத்து சேவைகளும் ஒரே இடத்தில் பதிவுகளை எழுத வேண்டும், அவை பகுப்பாய்வு செய்ய வசதியாக இருக்க வேண்டும்
2. மதிப்பீட்டு சேவையின் கிடைமட்ட அளவிடுதலின் சாத்தியம் - பெரும்பாலும் தடையாக இருக்கும்
3. அனுமானத்திற்கான நேரத்தை விநியோகிப்பதில் வெளிப்புறங்களைத் தவிர்ப்பதற்காக, ஒவ்வொரு படத்தையும் மதிப்பிடுவதற்கு அதே அளவு செயலி வளங்கள் ஒதுக்கப்பட வேண்டும்.
4. குறிப்பிட்ட சேவைகள் மற்றும் ஸ்டாக் இரண்டையும் வேகமாக (மீண்டும்) பயன்படுத்துதல்
5. தேவைப்பட்டால், வெவ்வேறு சேவைகளில் பொதுவான பொருட்களைப் பயன்படுத்துவதற்கான திறன்

கட்டிடக்கலை

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

தேவையற்ற தலைவலியிலிருந்து விடுபட, டெலிகிராம் ஏபிஐ முன்னோடியாகத் தேர்ந்தெடுக்கப்பட்டது.

முதலில், முடிக்கப்பட்ட கட்டிடக்கலையின் கட்டமைப்பு வரைபடத்தைப் பார்ப்போம், பின்னர் ஒவ்வொரு கூறுகளின் விளக்கத்திற்கும் செல்லவும், மேலும் வெற்றிகரமான பட செயலாக்கத்தின் செயல்முறையை முறைப்படுத்தவும்.

முடிக்கப்பட்ட கட்டிடக்கலையின் கட்டமைப்பு வரைபடம்

வரைபடத்தின் ஒவ்வொரு கூறுகளையும் பற்றி மேலும் விரிவாகப் பேசுவோம், பட மதிப்பீட்டின் செயல்பாட்டில் ஒற்றைப் பொறுப்பைக் குறிக்கிறது.

மைக்ரோ சர்வீஸ் "attrai-telegram-bot"

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

படத்துடன் தனிப்பயன் செய்தியைப் பெறும்போது:

1. வடிகட்டுதல் செய்யப்படுகிறது, இதில் பின்வரும் காசோலைகள் உள்ளன:
   • உகந்த பட அளவு கிடைக்கும்
   • ஏற்கனவே வரிசையில் உள்ள பயனர் படங்களின் எண்ணிக்கை
2. ஆரம்ப வடிகட்டலைக் கடக்கும்போது, ​​படம் டோக்கர் தொகுதியில் சேமிக்கப்படும்
3. "to_estimate" வரிசையில் ஒரு பணி தயாரிக்கப்படுகிறது, இதில் மற்றவற்றுடன், எங்கள் தொகுதியில் உள்ள படத்திற்கான பாதையும் அடங்கும்.
4. மேலே உள்ள படிகள் வெற்றிகரமாக முடிந்தால், பயனர் தோராயமான பட செயலாக்க நேரத்துடன் ஒரு செய்தியைப் பெறுவார், இது வரிசையில் உள்ள பணிகளின் எண்ணிக்கையின் அடிப்படையில் கணக்கிடப்படுகிறது. ஒரு பிழை ஏற்பட்டால், என்ன தவறு நடந்திருக்கும் என்பது பற்றிய தகவல்களுடன் ஒரு செய்தியை அனுப்புவதன் மூலம் பயனருக்கு வெளிப்படையாகத் தெரிவிக்கப்படும்.

மேலும், இந்த மைக்ரோ சர்வீஸ், ஒரு செலரி தொழிலாளியைப் போல, "ஆஃப்டர்_எஸ்டிமேட்" வரிசையைக் கேட்கிறது, இது மதிப்பீட்டுக் குழாய் வழியாகச் சென்ற பணிகளுக்காக வடிவமைக்கப்பட்டுள்ளது.

“after_estimate” இலிருந்து புதிய பணியைப் பெறும்போது:

1. படம் வெற்றிகரமாக செயலாக்கப்பட்டால், பயனருக்கு முடிவை அனுப்புவோம்; இல்லையெனில், பிழையைப் பற்றி அறிவிப்போம்.
2. மதிப்பீட்டுக் குழாயின் விளைவாக உருவான படத்தை அகற்றுதல்

மைக்ரோ சர்வீஸ் "அட்ரை-மதிப்பீடு" மதிப்பீடு

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

“to_estimate” இலிருந்து புதிய பணியைப் பெறும்போது:

1. மதிப்பீட்டு பைப்லைன் மூலம் படத்தை இயக்குவோம்:
   1. நினைவகத்தில் படத்தை ஏற்றுகிறது
   2. படத்தை தேவையான அளவுக்கு கொண்டு வருகிறோம்
   3. அனைத்து முகங்களையும் கண்டறிதல் (MTCNN)
   4. நாங்கள் எல்லா முகங்களையும் மதிப்பீடு செய்கிறோம் (கடைசிப் படியில் காணப்படும் முகங்களை ஒரு தொகுதி மற்றும் அனுமானம் ResNet34)
   5. இறுதி படத்தை வழங்கவும்
      1. எல்லைப் பெட்டிகளை வரைவோம்
      2. மதிப்பீடுகளை வரைதல்
2. தனிப்பயன் (அசல்) படத்தை நீக்குகிறது
3. மதிப்பீட்டுக் குழாயிலிருந்து வெளியீட்டைச் சேமிக்கிறது
4. மேலே விவாதிக்கப்பட்ட "attrai-telegram-bot" மைக்ரோ சர்வீஸ் மூலம் கேட்கப்படும் "after_estimate" வரிசையில் நாங்கள் பணியை வைக்கிறோம்.

கிரேலாக் (+ மோங்கோடிபி + மீள் தேடல்)

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

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

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

முயல்MQ

முயல்MQ AMQP நெறிமுறையின் அடிப்படையில் ஒரு செய்தி தரகர்.

இந்த திட்டத்தில் இது பயன்படுத்தப்பட்டது மிகவும் நிலையான மற்றும் நேர சோதனை செலரிக்கான தரகர் மற்றும் நீடித்த பயன்முறையில் பணியாற்றினார்.

Redis

Redis முக்கிய மதிப்பு தரவு கட்டமைப்புகளுடன் வேலை செய்யும் NoSQL DBMS ஆகும்

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

எடுத்துக்காட்டாக, "telegram_user_id => வரிசையில் உள்ள செயலில் உள்ள பணிகளின் எண்ணிக்கை" என்ற படிவத்தின் ஹாஷ்மேப்பை ரெடிஸ் சேமிக்கிறது, இது ஒரு பயனரின் கோரிக்கைகளின் எண்ணிக்கையை ஒரு குறிப்பிட்ட மதிப்பிற்கு வரம்பிடவும், அதன் மூலம் DoS தாக்குதல்களைத் தடுக்கவும் உங்களை அனுமதிக்கிறது.

வெற்றிகரமான பட செயலாக்க செயல்முறையை முறைப்படுத்துவோம்

1. பயனர் டெலிகிராம் போட்டிற்கு ஒரு படத்தை அனுப்புகிறார்
2. "attrai-telegram-bot" Telegram API இலிருந்து ஒரு செய்தியைப் பெற்று அதை அலசுகிறது
3. படத்துடன் கூடிய பணி ஒத்திசைவற்ற வரிசையில் “to_estimate” இல் சேர்க்கப்பட்டது
4. திட்டமிடப்பட்ட மதிப்பீட்டு நேரத்துடன் பயனர் ஒரு செய்தியைப் பெறுகிறார்
5. "attrai-estimator" "to_estimate" வரிசையில் இருந்து ஒரு பணியை எடுத்து, பைப்லைன் மூலம் மதிப்பீடுகளை இயக்கி, "after_estimate" வரிசையில் பணியை உருவாக்குகிறது
6. "attrai-telegram-bot" "after_estimate" வரிசையைக் கேட்டு, பயனருக்கு முடிவை அனுப்புகிறது

DevOps

இறுதியாக, கட்டிடக்கலையை மதிப்பாய்வு செய்த பிறகு, நீங்கள் சமமான சுவாரஸ்யமான பகுதிக்கு செல்லலாம் - DevOps

டோக்கர் திரள்

 

டோக்கர் திரள்  — ஒரு கிளஸ்டரிங் அமைப்பு, இதன் செயல்பாடு டோக்கர் எஞ்சினுக்குள் செயல்படுத்தப்பட்டு பெட்டிக்கு வெளியே கிடைக்கிறது.

ஒரு "திரள்" பயன்படுத்தி, எங்கள் கிளஸ்டரில் உள்ள அனைத்து முனைகளையும் 2 வகைகளாகப் பிரிக்கலாம் - தொழிலாளி மற்றும் மேலாளர். முதல் வகை இயந்திரங்களில், கொள்கலன்களின் குழுக்கள் (அடுக்குகள்) பயன்படுத்தப்படுகின்றன, இரண்டாவது வகை இயந்திரங்கள் அளவிடுதல், சமநிலைப்படுத்துதல் மற்றும் மற்ற குளிர் அம்சங்கள். மேலாளர்களும் இயல்பாகவே தொழிலாளர்கள்.

ஒரு தலைவர் மேலாளர் மற்றும் மூன்று தொழிலாளர்கள் கொண்ட கிளஸ்டர்

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

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

டோக்கர் ஸ்டேக்

ஸ்வார்ம் பயன்முறையில், அடுக்குகளை (டாக்கர் சேவைகளின் தொகுப்புகள்) வரிசைப்படுத்துவதற்கு அவர் பொறுப்பு. டாக்கர் அடுக்கு

இது docker-compose configs ஐ ஆதரிக்கிறது, மேலும் வரிசைப்படுத்தல் விருப்பங்களைப் பயன்படுத்த உங்களை அனுமதிக்கிறது.  

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

attrai_estimator:
  image: 'erqups/attrai_estimator:1.2'
  deploy:
    replicas: 4
    resources:
      limits:
        cpus: '4'
    restart_policy:
      condition: on-failure
      …

ரெடிஸ், ராபிட்எம்க்யூ மற்றும் கிரேலாக் ஆகியவை அரசுசார்ந்த சேவைகள் மற்றும் அவற்றை "அட்ரை-மதிப்பீட்டாளர்" போல எளிதாக அளவிட முடியாது என்பதைக் கவனத்தில் கொள்ள வேண்டும்.

கேள்வியை முன்னறிவித்து - ஏன் குபர்னெட்டஸ் இல்லை?

சிறிய மற்றும் நடுத்தர அளவிலான திட்டங்களில் Kubernetes ஐப் பயன்படுத்துவது ஒரு மேல்நிலை என்று தோன்றுகிறது; தேவையான அனைத்து செயல்பாடுகளையும் Docker Swarm இலிருந்து பெறலாம், இது ஒரு கொள்கலன் ஆர்கெஸ்ட்ரேட்டருக்கு மிகவும் பயனர் நட்பு மற்றும் நுழைவதற்கு குறைந்த தடையைக் கொண்டுள்ளது.

உள்கட்டமைப்பு

இவை அனைத்தும் பின்வரும் பண்புகளுடன் VDS இல் பயன்படுத்தப்பட்டன:

• CPU: 4 கோர் Intel® Xeon® Gold 5120 CPU @ 2.20GHz
• ரேம்: 8 GB
• SSD: 160 ஜிபி

உள்ளூர் சுமை சோதனைக்குப் பிறகு, பயனர்களின் தீவிர வருகையுடன், இந்த இயந்திரம் போதுமானதாக இருக்கும் என்று தோன்றியது.

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

இன்னும் சில கிராபிக்ஸ்

வரிசைப்படுத்தப்பட்டதிலிருந்து தனிப்பட்ட பயனர்களின் எண்ணிக்கை மற்றும் மதிப்பீட்டுக் கோரிக்கைகள், நாள் சார்ந்தது

மதிப்பீட்டு குழாய் அனுமான நேர விநியோகம்

கண்டுபிடிப்புகள்

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

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

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

டெலிகிராமில் நீங்கள் போட்டை குத்தலாம் - @AttraiBot, இது குறைந்தது 2020 இலையுதிர் காலம் முடியும் வரை வேலை செய்யும். பயனர் தரவு எதுவும் சேமிக்கப்படவில்லை என்பதை நினைவூட்டுகிறேன் - அசல் படங்களோ அல்லது மதிப்பீட்டுக் குழாய் முடிவுகளோ - செயலாக்கத்திற்குப் பிறகு அனைத்தும் இடிக்கப்படும்.

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