ස්නායුක ජාල මත පදනම්ව පෙනුම තක්සේරු කිරීම සඳහා සේවා ගෘහ නිර්මාණ ශිල්පය පිළිබඳ පොදු දළ විශ්ලේෂණය

පිවිසුම්

හෙලෝ!

මෙම ලිපියෙන් මම ස්නායුක ජාල භාවිතා කරමින් ව්‍යාපෘතියක් සඳහා ක්ෂුද්‍ර සේවා ගෘහ නිර්මාණ ශිල්පයක් ගොඩනැගීමේ මගේ අත්දැකීම් බෙදා ගන්නෙමි.

ගෘහ නිර්මාණ ශිල්පීය අවශ්‍යතා ගැන කතා කරමු, විවිධ ව්‍යුහාත්මක රූප සටහන් දෙස බලමු, නිමි ගෘහ නිර්මාණ ශිල්පයේ එක් එක් අංග විශ්ලේෂණය කරමු, විසඳුමේ තාක්ෂණික ප්‍රමිතික ද ඇගයීමට ලක් කරමු.

කියවන්න කියවන්න!

ගැටලුව සහ එහි විසඳුම ගැන වචන කිහිපයක්

ප්රධාන අදහස වන්නේ ඡායාරූපයක් මත පදනම්ව දස ලක්ෂයක පරිමාණයෙන් පුද්ගලයෙකුගේ ආකර්ශනීය බව ඇගයීමයි.

මෙම ලිපියෙන් අපි භාවිතා කරන ස්නායුක ජාල සහ දත්ත සැකසීමේ හා පුහුණු කිරීමේ ක්‍රියාවලිය යන දෙකම විස්තර කිරීමෙන් ඉවත් වෙමු. කෙසේ වෙතත්, පහත සඳහන් එක් ප්‍රකාශනයක, අපි අනිවාර්යයෙන්ම ගැඹුරු මට්ටමින් තක්සේරු නල මාර්ගය විශ්ලේෂණය කිරීමට නැවත පැමිණෙමු.

දැන් අපි ඉහළ මට්ටමේ ඇගයුම් නල මාර්ගය හරහා යන්නෙමු, සහ සමස්ත ව්‍යාපෘති ගෘහ නිර්මාණ ශිල්පයේ සන්දර්භය තුළ ක්ෂුද්‍ර සේවාවල අන්තර් ක්‍රියාකාරිත්වය කෙරෙහි අවධානය යොමු කරනු ඇත. 

ආකර්ශනීය තක්සේරු නල මාර්ගයේ වැඩ කරන විට, කාර්යය පහත සඳහන් සංරචක වලට දිරාපත් විය:

1. ඡායාරූපවල මුහුණු තෝරා ගැනීම
2. එක් එක් පුද්ගලයාගේ ශ්රේණිගත කිරීම
3. ප්රතිඵලය ලබා දෙන්න

පළමුවැන්න පෙර පුහුණු වූ බලවේග විසින් විසඳනු ලැබේ MTCNN. දෙවැන්න සඳහා, පරිවර්තනීය ස්නායු ජාලයක් PyTorch භාවිතා කරමින් පුහුණු කරන ලදී ResNet34 - ශේෂයේ සිට "CPU මත අනුමාන කිරීමේ ගුණාත්මකභාවය / වේගය"

ඇගයුම් නල මාර්ගයේ ක්රියාකාරී රූප සටහන

ව්යාපෘති ගෘහ නිර්මාණ අවශ්යතා විශ්ලේෂණය

ජීවන චක්රය තුළ ML ආකෘති යෙදවීමේ ගෘහ නිර්මාණ ශිල්පය සහ ස්වයංක්‍රීයකරණය පිළිබඳ වැඩ කිරීමේ ව්‍යාපෘති අදියර බොහෝ විට වඩාත්ම කාලය ගතවන සහ සම්පත් වැය වන ඒවා වේ.

ML ව්‍යාපෘතියක ජීවන චක්‍රය

මෙම ව්‍යාපෘතිය ව්‍යතිරේකයක් නොවේ - තක්සේරු නල මාර්ගය මාර්ගගත සේවාවක් බවට පත් කිරීමට තීරණය කරන ලද අතර, ඒ සඳහා ගෘහ නිර්මාණ ශිල්පයේ ගිලී යාමට අවශ්‍ය විය. පහත මූලික අවශ්‍යතා හඳුනාගෙන ඇත:

1. ඒකාබද්ධ ලොග් ආචයනය - සියලුම සේවාවන් එක් ස්ථානයක ලොග් ලිවිය යුතුය, ඒවා විශ්ලේෂණය කිරීමට පහසු විය යුතුය
2. තක්සේරු සේවාවේ තිරස් පරිමාණය කිරීමේ හැකියාව - බොහෝ දුරට ඉඩ ඇති බාධාව ලෙස
3. අනුමානය සඳහා කාලය බෙදා හැරීමේදී පිටස්තරයන් වළක්වා ගැනීම සඳහා එක් එක් රූපය ඇගයීමට සමාන ප්‍රොසෙසර සම්පත් ප්‍රමාණයක් වෙන් කළ යුතුය.
4. නිශ්චිත සේවාවන් සහ සමස්තයක් ලෙස තොගය යන දෙකම වේගවත් (නැවත) යෙදවීම
5. අවශ්ය නම්, විවිධ සේවාවන්හි පොදු වස්තූන් භාවිතා කිරීමට ඇති හැකියාව

ගෘහ නිර්මාණ ශිල්පය

අවශ්‍යතා විශ්ලේෂණය කිරීමෙන් පසුව, ක්ෂුද්‍ර සේවා ගෘහ නිර්මාණ ශිල්පය සම්පූර්ණයෙන්ම පාහේ ගැලපෙන බව පැහැදිලි විය.

අනවශ්‍ය හිසරදයෙන් මිදීම සඳහා, Telegram API ඉදිරිපස ලෙස තෝරා ගන්නා ලදී.

පළමුව, නිමි ගෘහ නිර්මාණ ශිල්පයේ ව්‍යුහාත්මක රූප සටහන දෙස බලමු, ඉන්පසු එක් එක් සංරචක පිළිබඳ විස්තරයක් වෙත යන්න, සාර්ථක රූප සැකසීමේ ක්‍රියාවලිය විධිමත් කරන්න.

නිමි ගෘහ නිර්මාණ ශිල්පයේ ව්‍යුහාත්මක රූප සටහන

රූප සටහනේ එක් එක් අංගයන් ගැන වඩාත් විස්තරාත්මකව කතා කරමු, ඒවා රූප ඇගයීමේ ක්‍රියාවලියේදී තනි වගකීමක් ලෙස දක්වයි.

Microservice "attrai-telegram-bot"

මෙම ක්ෂුද්‍ර සේවාව Telegram API සමඟ ඇති සියලුම අන්තර්ක්‍රියා ආවරණය කරයි. ප්‍රධාන අවස්ථා 2 ක් ඇත: අභිරුචි රූපයක් සමඟ වැඩ කිරීම සහ තක්සේරු නල මාර්ගයක ප්‍රතිඵලය සමඟ වැඩ කිරීම. අපි සාමාන්‍යයෙන් අවස්ථා දෙකම බලමු.

රූපයක් සහිත අභිරුචි පණිවිඩයක් ලැබෙන විට:

1. පහත දැක්වෙන චෙක්පත් වලින් සමන්විත පෙරහන සිදු කරනු ලැබේ:
   • ප්රශස්ත රූප ප්රමාණය ලබා ගැනීම
   • දැනටමත් පෝලිමේ ඇති පරිශීලක පින්තූර ගණන
2. ආරම්භක පෙරහන පසු කරන විට, රූපය ඩොකර් පරිමාවේ සුරැකේ
3. "to_estimate" පෝලිමේ කාර්යයක් නිපදවනු ලැබේ, වෙනත් දේ අතර, අපගේ පරිමාවේ පිහිටා ඇති රූපයට යන මාර්ගයද ඇතුළත් වේ.
4. ඉහත පියවර සාර්ථකව සම්පූර්ණ කර ඇත්නම්, පරිශීලකයා පෝලිමේ ඇති කාර්යයන් ගණන මත පදනම්ව ගණනය කරනු ලබන ආසන්න රූප සැකසුම් කාලය සමඟ පණිවිඩයක් ලැබෙනු ඇත. දෝෂයක් සිදුවුවහොත්, වැරදී ඇති දේ පිළිබඳ තොරතුරු සහිත පණිවිඩයක් යැවීමෙන් පරිශීලකයාට පැහැදිලිවම දැනුම් දෙනු ලැබේ.

එසේම, මෙම ක්ෂුද්‍ර සේවාව, සැල්දිරි සේවකයෙකු මෙන්, ඇගයුම් නල මාර්ගය හරහා ගමන් කර ඇති කාර්යයන් සඳහා අදහස් කරන "after_estimate" පෝලිමට සවන් දෙයි.

"after_estimate" වෙතින් නව කාර්යයක් ලැබෙන විට:

1. රූපය සාර්ථකව සකසන්නේ නම්, අපි ප්රතිඵලය පරිශීලකයාට යවන්නෙමු; එසේ නොවේ නම්, අපි දෝෂයක් ගැන දැනුම් දෙන්නෙමු.
2. ඇගයුම් නල මාර්ගයේ ප්රතිඵලය වන රූපය ඉවත් කිරීම

ක්ෂුද්‍ර සේවා "ඇට්‍රයි-ඇස්තමේටර්" ඇගයීම

මෙම ක්ෂුද්‍ර සේවාව සැල්දිරි සේවකයෙකු වන අතර රූප ඇගයුම් නල මාර්ගයට අදාළ සෑම දෙයක්ම ආවරණය කරයි. මෙහි ඇත්තේ එක් ක්‍රියාකාරී ඇල්ගොරිතමයක් පමණි - අපි එය විශ්ලේෂණය කරමු.

"to_estimate" වෙතින් නව කාර්යයක් ලැබෙන විට:

1. අපි ඇගයුම් නල මාර්ගය හරහා රූපය ධාවනය කරමු:
   1. රූපය මතකයට පැටවීම
   2. අපි රූපය අවශ්ය ප්රමාණයට ගෙන එයි
   3. සියලුම මුහුණු සොයා ගැනීම (MTCNN)
   4. අපි සියලු මුහුණු ඇගයීමට ලක් කරන්නෙමු (අවසන් පියවරේදී සොයාගත් මුහුණු අපි කණ්ඩායමකට ඔතා ResNet34 අනුමාන කරන්නෙමු)
   5. අවසාන රූපය නිරූපණය කරන්න
      1. අපි මායිම් පෙට්ටි අඳින්නෙමු
      2. ශ්රේණිගත කිරීම් ඇඳීම
2. අභිරුචි (මුල්) රූපයක් මකා දැමීම
3. ඇගයුම් නල මාර්ගයෙන් ප්රතිදානය සුරැකීම
4. ඉහත සාකච්ඡා කර ඇති "attrai-telegram-bot" microservice මගින් සවන් දෙන "after_estimate" පෝලිමේ අපි කාර්යය තැබුවෙමු.

ග්‍රේලොග් (+ mongoDB + Elasticsearch)

ග්‍රේලොග් මධ්යගත ලොග් කළමනාකරණය සඳහා විසඳුමක් වේ. මෙම ව්යාපෘතියේ දී, එය එහි අපේක්ෂිත අරමුණු සඳහා භාවිතා කරන ලදී.

තේරීම ඔහු මත පතිත වූ අතර සුපුරුදු එකක් මත නොවේ ELK stack, එය Python වෙතින් වැඩ කිරීමේ පහසුව නිසා. ග්‍රේලොග් වෙත ලොග් වීමට ඔබ කළ යුත්තේ පැකේජයෙන් GELFTCPHandler එක් කිරීමයි අළු පැහැති අපගේ python microservice හි ඉතිරි root logger හසුරුවන්නන් වෙත.

මීට පෙර ELK තොගය සමඟ පමණක් වැඩ කර ඇති අයෙක් ලෙස, මම සාමාන්‍යයෙන් ග්‍රේලොග් සමඟ වැඩ කිරීමේදී ධනාත්මක අත්දැකීමක් ලබා ඇත්තෙමි. මානසික අවපීඩනය ඇති කරන එකම දෙය නම් ග්‍රේලොග් වෙබ් අතුරු මුහුණතට වඩා කිබානා විශේෂාංගවල ඇති විශිෂ්ටත්වයයි.

හාවා එම්.කේ.

හාවා එම්.කේ. AMQP ප්‍රොටෝකෝලය මත පදනම් වූ පණිවිඩ තැරැව්කරුවෙකි.

මෙම ව්යාපෘතියේ දී එය භාවිතා කරන ලදී වඩාත්ම ස්ථායී සහ කාල පරික්ෂා කර ඇත සැල්දිරි සඳහා තැරැව්කරු සහ කල් පවතින මාදිලියේ වැඩ කළේය.

Redis

Redis ප්‍රධාන අගය දත්ත ව්‍යුහයන් සමඟ ක්‍රියා කරන NoSQL DBMS වේ

සමහර විට විවිධ පයිතන් ක්ෂුද්‍ර සේවාවල ඇතැම් දත්ත ව්‍යුහයන් ක්‍රියාත්මක කරන පොදු වස්තු භාවිතා කිරීමට අවශ්‍ය වේ.

උදාහරණයක් ලෙස, Redis විසින් “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

ඩෝකර් රංචුව

 

ඩෝකර් රංචුව  - පොකුරු පද්ධතියක්, එහි ක්‍රියාකාරිත්වය ඩොකර් එන්ජිම තුළ ක්‍රියාත්මක වන අතර කොටුවෙන් පිටත ලබා ගත හැකිය.

"රංචුවක්" භාවිතා කරමින්, අපගේ පොකුරේ ඇති සියලුම නෝඩ් වර්ග 2 කට බෙදිය හැකිය - සේවකයා සහ කළමනාකරු. පළමු වර්ගයේ යන්ත්‍රවල, බහාලුම් කණ්ඩායම් (අට්ටි) යොදවා ඇත, දෙවන වර්ගයේ යන්ත්‍ර පරිමාණය, තුලනය සහ වෙනත් සිසිල් විශේෂාංග. කළමනාකරුවන් ද පෙරනිමියෙන් කම්කරුවන් වේ.

එක් නායක කළමනාකරුවෙකු සහ කම්කරුවන් තිදෙනෙකු සමඟ පොකුර

හැකි අවම පොකුරු ප්‍රමාණය 1 නෝඩ් වේ; තනි යන්ත්‍රයක් එකවර නායක කළමනාකරුවෙකු සහ සේවකයෙකු ලෙස ක්‍රියා කරයි. ව්යාපෘතියේ විශාලත්වය සහ වැරදි ඉවසීම සඳහා අවම අවශ්යතා මත පදනම්ව, මෙම ප්රවේශය භාවිතා කිරීමට තීරණය විය.

ඉදිරිය දෙස බලන විට, ජූනි මැද පැවති පළමු නිෂ්පාදන බෙදා හැරීමේ සිට, මෙම පොකුරු සංවිධානය හා සම්බන්ධ කිසිදු ගැටළුවක් නොමැති බව මම කියමි (නමුත් මින් අදහස් කරන්නේ එවැනි සංවිධානයක් ඕනෑම මධ්‍යම-විශාල ආයතනයකට කිසිදු ආකාරයකින් පිළිගත හැකි බව නොවේ. වැරදි ඉවසීමේ අවශ්‍යතා වලට යටත් වන ව්‍යාපෘති).

ඩොකර් ස්ටැක්

රංචු ප්‍රකාරයේදී, තොග (ඩොකර් සේවා කට්ටල) යෙදවීමට ඔහු වගකිව යුතුය. docker stack

එය docker-compose configs සඳහා සහය දක්වයි, ඔබට අතිරේකව යෙදවීමේ විකල්ප භාවිතා කිරීමට ඉඩ සලසයි.  

උදාහරණයක් ලෙස, මෙම පරාමිති භාවිතා කරමින්, එක් එක් ඇගයීම් ක්ෂුද්‍ර සේවා අවස්ථා සඳහා සම්පත් සීමිත විය (අපි N අවස්ථා සඳහා N හරයන් වෙන් කරමු, microservice තුළම අපි PyTorch විසින් භාවිතා කරන මධ්‍ය ගණන එකකට සීමා කරමු)

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

Redis, RabbitMQ සහ Graylog රාජ්‍ය සේවා වන අතර ඒවා “attrai-estimator” තරම් පහසුවෙන් පරිමාණය කළ නොහැකි බව සැලකිල්ලට ගැනීම වැදගත්ය.

ප්‍රශ්නය පුරෝකථනය කරමින් - කුබර්නෙටස් නොවන්නේ මන්ද?

කුඩා හා මධ්‍යම ප්‍රමාණයේ ව්‍යාපෘති සඳහා Kubernetes භාවිතා කිරීම උඩිස් කටයුත්තක් බව පෙනේ; අවශ්‍ය සියලුම ක්‍රියාකාරීත්වය Docker Swarm වෙතින් ලබා ගත හැක, එය බහාලුම් වාද්‍ය වෘන්දයකට තරමක් පරිශීලක-හිතකාමී වන අතර ඇතුළුවීමට අඩු බාධකයක් ද ඇත.

යටිතල පහසුකම්

මේ සියල්ල පහත ලක්ෂණ සහිතව VDS මත යොදවා ඇත:

• CPU: 4 core Intel® Xeon® Gold 5120 CPU @ 2.20GHz
• RAM: 8 GB
• SSD: 160GB

දේශීය බර පරීක්ෂා කිරීමෙන් පසුව, පරිශීලකයින්ගේ බරපතල ගලා ඒම සමඟ, මෙම යන්ත්රය ප්රමාණවත් වනු ඇති බව පෙනෙන්නට තිබුණි.

නමුත්, යෙදවීම අවසන් වූ වහාම, මම CIS හි වඩාත් ජනප්‍රිය රූප පුවරුවකට සබැඳියක් පළ කළෙමි (ඔව්, එයම), ඉන් පසුව මිනිසුන් උනන්දු වූ අතර පැය කිහිපයකින් සේවාව සාර්ථකව රූප දස දහස් ගණනක් සකසන ලදී. ඒ අතරම, උපරිම අවස්ථාවන්හිදී, CPU සහ RAM සම්පත් අඩක්වත් භාවිතා නොකළේය.

තවත් ග්‍රැෆික්ස් කිහිපයක්

දිනය අනුව, යෙදවීමේ සිට අද්විතීය පරිශීලකයින් සංඛ්‍යාව සහ ඇගයීම් ඉල්ලීම්

ඇගයුම් නල මාර්ග අනුමාන කාලය බෙදා හැරීම

සොයා ගැනීම්

සාරාංශගත කිරීම සඳහා, බහාලුම්වල වාස්තුවිද්‍යාව සහ ප්‍රවේශය මුළුමනින්ම යුක්ති සහගත බව මට පැවසිය හැකිය - උච්ච අවස්ථාවන්හිදී පවා සැකසුම් කාලය තුළ බිංදු හෝ අඩුවීමක් නොතිබුණි. 

ඔවුන්ගේ ක්‍රියාවලියේදී CPU මත ස්නායුක ජාල පිළිබඳ තත්‍ය කාලීන අනුමාන භාවිතා කරන කුඩා හා මධ්‍යම ප්‍රමාණයේ ව්‍යාපෘති මෙම ලිපියේ විස්තර කර ඇති පරිචයන් සාර්ථකව අනුගමනය කළ හැකි යැයි මම සිතමි.

මුලදී ලිපිය දිගු වූ බව මම එකතු කරමි, නමුත් දිගු කියවීමක් පළ නොකිරීමට, මෙම ලිපියේ සමහර කරුණු මඟ හැරීමට මම තීරණය කළෙමි - අපි අනාගත ප්‍රකාශන වලදී ඒවා වෙත ආපසු යමු.

ඔබට ටෙලිග්‍රාම් - @AttraiBot මත බොට් එක සිදුරු කළ හැක, එය අවම වශයෙන් 2020 සරත් සමය අවසන් වන තෙක් ක්‍රියා කරයි. පරිශීලක දත්ත කිසිවක් ගබඩා කර නොමැති බව මම ඔබට මතක් කරමි - මුල් පින්තූර හෝ ඇගයීම් නල මාර්ගයේ ප්‍රතිඵල - සැකසීමෙන් පසු සියල්ල කඩා දමනු ලැබේ.

මූලාශ්රය: www.habr.com