බොහෝ ආරම්භකයින් මෙය හරහා ගොස් ඇත: සෑම දිනකම නව පරිශීලකයින් පිරිසක් ලියාපදිංචි වන අතර, සංවර්ධන කණ්ඩායම සේවාව පවත්වාගෙන යාමට අරගල කරයි.

එය තිබීම ප්‍රසන්න ගැටලුවකි, නමුත් වෙබ් යෙදුමක් පරිස්සමෙන් සිය දහස් ගණනක් පරිශීලකයින් දක්වා පරිමාණය කරන්නේ කෙසේද යන්න පිළිබඳ පැහැදිලි තොරතුරු වෙබයේ නොමැත. සාමාන්‍යයෙන් ගිනි විසඳුම් හෝ බාධක විසඳුම් (සහ බොහෝ විට දෙකම) ඇත. එමනිසා, මිනිසුන් ඔවුන්ගේ ආධුනික ව්‍යාපෘතිය සැබවින්ම බැරෑරුම් දෙයකට පරිමාණය කිරීමට තරමක් ක්ලිච් ශිල්පීය ක්‍රම භාවිතා කරයි.

තොරතුරු පෙරීමට සහ මූලික සූත්‍රය ලිවීමට උත්සාහ කරමු. අපි අපගේ නව ඡායාරූප බෙදාගැනීමේ අඩවිය වන Graminsta පියවරෙන් පියවර පරිශීලකයින් 1 සිට 100 දක්වා පරිමාණය කරන්නෙමු.

ප්‍රේක්ෂකයින් 10, 100, 1000, 10 සහ 000 දක්වා වැඩි වන විට ගත යුතු නිශ්චිත ක්‍රියාමාර්ග මොනවාදැයි අපි ලියා තබමු.

1 පරිශීලක: 1 යන්ත්රය

සෑම යෙදුමකම පාහේ, එය වෙබ් අඩවියක් හෝ ජංගම යෙදුමක් වේවා, ප්‍රධාන සංරචක තුනක් ඇත:

• API
• දත්ත සමුදාය
• සේවාදායකයා (ජංගම යෙදුම හෝ වෙබ් අඩවිය)

දත්ත සමුදාය ස්ථිර දත්ත ගබඩා කරයි. API මෙම දත්ත වෙත සහ ඒ අවට ඉල්ලීම් සපයයි. සේවාදායකයා පරිශීලකයාට දත්ත සම්ප්‍රේෂණය කරයි.

වාස්තු විද්‍යාත්මක දෘෂ්ටි කෝණයකින්, සේවාදායකයා සහ API ආයතන සම්පූර්ණයෙන්ම වෙන් කර ඇත්නම් යෙදුමක් පරිමාණය කිරීම ගැන කතා කිරීම වඩාත් පහසු බව මම නිගමනය කළෙමි.

අපි මුලින්ම යෙදුමක් තැනීම ආරම්භ කරන විට, සංරචක තුනම එකම සේවාදායකයක ධාවනය කළ හැකිය. සමහර ආකාරවලින්, මෙය අපගේ සංවර්ධන පරිසරයට සමාන වේ: එක් ඉංජිනේරුවෙක් දත්ත සමුදාය, API සහ සේවාදායකයා එකම යන්ත්‍රයක ධාවනය කරයි.

න්‍යායාත්මකව, පහත දැක්වෙන පරිදි, අපට එය තනි DigitalOcean Droplet හෝ AWS EC2 අවස්ථාවක් මත වලාකුළෙහි යෙදවිය හැක:

ඒ සමඟම, වෙබ් අඩවියක පරිශීලකයින් එකකට වඩා සිටී නම්, දත්ත සමුදා ස්ථරයක් කැප කිරීම සැමවිටම පාහේ අර්ථවත් කරයි.

පරිශීලකයින් 10: දත්ත සමුදාය වෙනම මට්ටමකට ගෙන යාම

දත්ත සමුදාය Amazon RDS හෝ Digital Ocean Managed Database වැනි කළමනාකරණ සේවා වලට බෙදීම දිගු කාලයක් සඳහා අපට හොඳින් සේවය කරනු ඇත. එය තනි යන්ත්‍රයක් හෝ EC2 අවස්ථාවක් මත ස්වයං-සත්කාරක කිරීමට වඩා ටිකක් මිල අධිකයි, නමුත් මෙම සේවාවන් සමඟින් ඔබට අනාගතයේදී ප්‍රයෝජනවත් වන කොටුවෙන් බොහෝ ප්‍රයෝජනවත් දිගු ලැබේ: බහු-කලාපීය උපස්ථය, අනුරූ කියවීම, ස්වයංක්‍රීය උපස්ථ, සහ තවත්.

පද්ධතිය දැන් පෙනෙන්නේ මෙයයි:

පරිශීලකයින් 100: සේවාලාභියා වෙනම මට්ටමකට ගෙන යාම

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

සේවාදායකයා API වලින් වෙන්ව සිතන්නට මා කැමති වන්නේ එබැවිනි. මෙය බහු වේදිකා සඳහා සංවර්ධනය කිරීම ගැන සිතීම ඉතා පහසු කරයි: වෙබ්, ජංගම වෙබ්, iOS, Android, ඩෙස්ක්ටොප් යෙදුම්, තෙවන පාර්ශ්ව සේවා, ආදිය. ඔවුන් සියල්ලෝම එකම API භාවිතා කරන සේවාදායකයන් පමණි.

උදාහරණයක් ලෙස, දැන් අපගේ පරිශීලකයින් බොහෝ විට ජංගම යෙදුමක් නිකුත් කිරීමට ඉල්ලා සිටියි. ඔබ සේවාලාභියා සහ API ආයතන වෙන් කරන්නේ නම්, මෙය පහසු වේ.

එවැනි පද්ධතියක් පෙනෙන්නේ මෙයයි:

පරිශීලකයින් 1000ක්: load balancer එක් කරන්න

දේවල් බලනවා. Graminsta භාවිතා කරන්නන් වැඩි වැඩියෙන් ඡායාරූප උඩුගත කරයි. ලියාපදිංචි කිරීම් සංඛ්‍යාව ද වර්ධනය වේ. අපගේ හුදකලා API සේවාදායකයට සියලු මාර්ග තදබදය සමඟ සිටීමට අපහසු වේ. තවත් යකඩ අවශ්යයි!

Load balancer යනු ඉතා බලවත් සංකල්පයකි. ප්‍රධාන අදහස නම්, අපි API ඉදිරියෙන් load balancer එකක් තබන අතර, එය තනි පුද්ගල සේවා අවස්ථා වෙත ගමනාගමනය බෙදා හැරීමයි. අපි තිරස් අතට පරිමාණය කරන ආකාරය මෙයයි, එනම් අපි එකම කේතය සමඟ තවත් සේවාදායකයන් එකතු කරමු, අපට ක්‍රියා කළ හැකි ඉල්ලීම් ගණන වැඩි කරයි.

අපි web client එක ඉස්සරහා API එක ඉස්සරහා වෙනම load balancers දාන්නයි යන්නේ. මෙයින් අදහස් කරන්නේ ඔබට API කේතය සහ වෙබ් සේවාදායක කේතය ධාවනය වන අවස්ථා කිහිපයක් ධාවනය කළ හැකි බවයි. ලෝඩ් බැලන්සර් අඩුවෙන් පටවා ඇති සේවාදායකය වෙත ඉල්ලීම් යොමු කරයි.

මෙහිදී අපට තවත් වැදගත් වාසියක් ලැබේ - අතිරික්තය. එක් අවස්ථාවක් අසාර්ථක වූ විට (සමහර විට අධික ලෙස පටවා ඇති හෝ බිඳ වැටුණු විට), එන ඉල්ලීම්වලට දිගටම ප්‍රතිචාර දක්වන අනෙක් අය සමඟ අපට ඉතිරි වේ. එක් අවස්ථාවක් පමණක් ක්‍රියාත්මක වූයේ නම්, අසාර්ථක වුවහොත් සම්පූර්ණ පද්ධතියම බිඳ වැටේ.

බර සමතුලිතකය ස්වයංක්‍රීය පරිමාණය ද සපයයි. උපරිම පැටවීමට පෙර අවස්ථා ගණන වැඩි කිරීමට සහ සියලු පරිශීලකයින් නිදා සිටින විට එය අඩු කිරීමට අපට එය වින්‍යාසගත කළ හැකිය.

පැටවුම් සමතුලිතයක් සමඟ, API මට්ටම දින නියමයක් නොමැතිව පරිමාණය කළ හැකිය, ඉල්ලීම් ගණන වැඩි වන විට නව අවස්ථා එකතු කරයි.

සටහන. දැනට අපගේ පද්ධතිය AWS හි Heroku හෝ Elastic Beanstalk වැනි PaaS සමාගම් පෙට්ටියෙන් පිටත පිරිනමන දේට බෙහෙවින් සමාන ය (ඒවා එතරම් ජනප්‍රිය වන්නේ එබැවිනි). Heroku දත්ත සමුදාය වෙනම ධාරකයක් මත තබයි, ස්වයංක්‍රීය පරිමාණ පැටවුම් සමතුලිතයක් කළමනාකරණය කරයි, සහ ඔබට API වෙතින් වෙබ් සේවාලාභියා වෙන වෙනම සත්කාරක කිරීමට ඉඩ සලසයි. මුල් කාලීන ව්‍යාපෘති හෝ ආරම්භක ව්‍යාපෘති සඳහා Heroku භාවිතා කිරීමට මෙය හොඳ හේතුවකි - ඔබට සියලු මූලික සේවාවන් කොටුවෙන් ඉවත් වේ.

පරිශීලකයින් 10: CDN

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

මෙම අවස්ථාවෙහිදී, ඔබ ස්ථිතික අන්තර්ගතය ගබඩා කිරීම සඳහා වලාකුළු සේවාවක් භාවිතා කළ යුතුය - පින්තූර, වීඩියෝ සහ තවත් බොහෝ දේ (AWS S3 හෝ ඩිජිටල් සාගර අවකාශයන්). සාමාන්‍යයෙන්, අපගේ API විසින් පින්තූර සේවය කිරීම සහ සේවාදායකයට පින්තූර උඩුගත කිරීම වැනි දේවල් හැසිරවීමෙන් වැළකී සිටිය යුතුය.

වලාකුළු සත්කාරකයේ තවත් වාසියක් වන්නේ CDN (AWS මෙම ඇඩෝන ක්ලවුඩ් ෆ්‍රන්ට් ලෙස හඳුන්වයි, නමුත් බොහෝ වලාකුළු ගබඩා සපයන්නන් එය කොටුවෙන් පිටත ලබා දෙයි). CDN ලොව පුරා විවිධ දත්ත මධ්‍යස්ථානවල අපගේ පින්තූර ස්වයංක්‍රීයව හැඹිලිගත කරයි.

අපගේ ප්‍රධාන දත්ත මධ්‍යස්ථානය Ohio හි පිහිටා තිබිය හැකි වුවද, යමෙකු ජපානයෙන් පින්තූරයක් ඉල්ලා සිටියහොත්, cloud provider විසින් එය පිටපතක් සාදා ඔවුන්ගේ ජපන් දත්ත මධ්‍යස්ථානයේ ගබඩා කරනු ඇත. ජපානයේදී මෙම පින්තූරය ඉල්ලන මීළඟ පුද්ගලයාට එය වඩා වේගයෙන් ලැබෙනු ඇත. අප ග්‍රහලෝකය හරහා බාගත කර සම්ප්‍රේෂණය කිරීමට දිගු කාලයක් ගත වන ඡායාරූප හෝ වීඩියෝ වැනි විශාල ගොනු සමඟ වැඩ කරන විට මෙය වැදගත් වේ.

100 පරිශීලකයින්: දත්ත ස්ථරය පරිමාණය කිරීම

CDN බොහෝ උපකාර කර ඇත: ගමනාගමනය සම්පූර්ණ වේගයෙන් වර්ධනය වේ. සුප්‍රසිද්ධ වීඩියෝ බ්ලොග්කරුවෙකු වන මාවිඩ් මොබ්රික් අප සමඟ ලියාපදිංචි වී ඔවුන් පවසන පරිදි ඔහුගේ “කතාව” පළ කළේය. load balancer එකට පින්සිද්ධ වෙන්න, API servers වල CPU සහ memory usage එක අඩුවෙන් තියාගෙන (API instances දහයක් දුවනවා), නමුත් අපි ඉල්ලීම් වලට timeouts ගොඩක් ගන්න පටන් අරන්... කොහෙන්ද මේ delays එන්නෙ?

ප්‍රමිතික ටිකක් හාරා, දත්ත සමුදා සේවාදායකයේ CPU 80-90% පටවා ඇති බව අපට පෙනේ. අපි ඉන්නේ සීමාවේ.

දත්ත ස්තරය පරිමාණය කිරීම සමීකරණයේ වඩාත්ම දුෂ්කර කොටස විය හැකිය. API සේවාදායකයන් අස්ථායී ඉල්ලීම් සපයයි, එබැවින් අපි තවත් API අවස්ථා එකතු කරමු. නාසය බහුතරය දත්ත සමුදායන්ට මෙය කළ නොහැක. අපි ජනප්‍රිය සම්බන්ධතා දත්ත සමුදා කළමනාකරණ පද්ධති (PostgreSQL, MySQL, ආදිය) ගැන කතා කරමු.

හැඹිලිගත කිරීම

අපගේ දත්ත සමුදායේ කාර්ය සාධනය වැඩි කිරීමට පහසුම ක්‍රමයක් නම් නව අංගයක් හඳුන්වා දීමයි: හැඹිලි ස්ථරය. වඩාත් පොදු හැඹිලි ක්‍රමය වන්නේ Redis හෝ Memcached වැනි මතකයේ ඇති යතුරු අගය වාර්තා ගබඩාවකි. බොහෝ වලාකුළු වල මෙම සේවාවන්හි කළමනාකරණය කළ අනුවාදයක් ඇත: AWS මත Elasticache සහ Google Cloud මත Memorystore.

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

උදාහරණයක් ලෙස, අපගේ Graminsta සේවාව තුළ, යමෙකු තරු Mobrik හි පැතිකඩ පිටුවට යන සෑම අවස්ථාවකම, API සේවාදායකය ඔහුගේ පැතිකඩෙන් තොරතුරු සඳහා දත්ත සමුදාය විමසයි. මෙය නැවත නැවතත් සිදු වේ. Mobrik හි පැතිකඩ තොරතුරු එක් එක් ඉල්ලීම සමඟ වෙනස් නොවන බැවින්, එය හැඹිලිගත කිරීම සඳහා විශිෂ්ටයි.

අපි යතුර මගින් Redis හි දත්ත ගබඩාවෙන් ප්‍රතිඵල හැඹිලිගත කරන්නෙමු user:id තත්පර 30 ක වලංගු කාල සීමාවක් සමඟ. දැන් කවුරුහරි Mobrik ගේ ප්‍රොෆයිල් එකට ගියාම අපි ඉස්සෙල්ලම Redis එක චෙක් කරනවා, Data තියෙනවා නම් අපි සරලවම Redis එකෙන් කෙලින්ම මාරු කරනවා. දැන් වෙබ් අඩවියේ වඩාත්ම ජනප්‍රිය පැතිකඩ වෙත ඉල්ලීම් ප්‍රායෝගිකව අපගේ දත්ත ගබඩාව පූරණය නොකරයි.

බොහෝ හැඹිලි සේවා වල තවත් වාසියක් වන්නේ ඒවා දත්ත සමුදා සේවාදායකයන්ට වඩා පරිමාණය කිරීමට පහසු වීමයි. Redis සතුව ගොඩනඟන ලද Redis Cluster මාදිලියක් ඇත. load balancer එකකට සමානයි1, එය ඔබට බහු යන්ත්‍ර හරහා ඔබේ Redis හැඹිලිය බෙදා හැරීමට ඉඩ සලසයි (අවශ්‍ය නම් සේවාදායකයන් දහස් ගණනක් හරහා).

මහා පරිමාණ යෙදුම් සියල්ලම පාහේ හැඹිලිගත කිරීම භාවිතා කරයි; එය වේගවත් API එකක සම්පූර්ණයෙන්ම අත්‍යවශ්‍ය කොටසකි. වේගවත් විමසුම් සැකසීම සහ වඩා ඵලදායී කේතය වැදගත් වේ, නමුත් හැඹිලියක් නොමැතිව මිලියන ගණනක් පරිශීලකයින් වෙත සේවාවක් පරිමාණය කිරීම පාහේ කළ නොහැක්කකි.

අනුරූ කියවන්න

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

මෙන්න දැන් අපේ පද්ධතිය:

වැඩිදුර ක්‍රියාමාර්ග

යෙදුම දිගින් දිගටම පරිමාණය වන බැවින්, අපි ඒවා ස්වාධීනව පරිමාණය කිරීම සඳහා සේවා වෙන් කිරීම දිගටම කරගෙන යන්නෙමු. උදාහරණයක් ලෙස, අපි Websockets භාවිතා කිරීමට පටන් ගන්නේ නම්, Websockets සැකසුම් කේතය වෙනම සේවාවකට ඇද දැමීම අර්ථවත් කරයි. විවෘත Websockets සම්බන්ධතා මත පදනම්ව සහ HTTP ඉල්ලීම් ගණන නොතකා ඉහළට සහ පහළට පරිමාණය කළ හැකි අපගේම load balancer පිටුපසින් අපට එය නව අවස්ථා මත තැබිය හැකිය.

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

අපට New Relic හෝ Datadog වැනි අධීක්ෂණ සහ විශ්ලේෂණ සේවාවක් ස්ථාපනය කිරීමටද අවශ්‍යයි. මන්දගාමී විමසුම් හඳුනා ගැනීමට සහ වැඩිදියුණු කිරීම අවශ්‍ය තැන් තේරුම් ගැනීමට මෙය ඔබට උපකාර කරයි. අපි පරිමාණය කරන විට, බාධක සොයා ගැනීම සහ ඒවා ඉවත් කිරීම කෙරෙහි අවධානය යොමු කිරීමට අපට අවශ්‍යයි - බොහෝ විට පෙර කොටස්වල සමහර අදහස් භාවිතා කිරීම.

මුලාශ්‍ර

මෙම සටහන ඉන් එකකින් ආභාෂය ලබා ඇත ඉහළ පරිමාණය පිළිබඳ මගේ ප්‍රියතම ලිපි. මට අවශ්‍ය වූයේ ව්‍යාපෘතිවල ආරම්භක අදියර සඳහා ලිපිය තව ටිකක් නිශ්චිත කර එක් වෙළෙන්දෙකුගෙන් එය ලිහා දැමීමටයි. ඔබ මෙම මාතෘකාව ගැන උනන්දුවක් දක්වන්නේ නම් කියවීමට වග බලා ගන්න.

පාද සටහන්

1. බහුවිධ අවස්ථා හරහා බර බෙදා හැරීම සම්බන්ධයෙන් සමාන වුවද, රෙඩිස් පොකුරක යටින් ක්‍රියාත්මක කිරීම බර සමතුලිතතාවයට වඩා බෙහෙවින් වෙනස් ය. [ආපසු]

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