ብዙ ጀማሪዎች በዚህ ውስጥ አልፈዋል፡ ብዙ አዳዲስ ተጠቃሚዎች በየቀኑ ይመዘገባሉ፣ እና የልማቱ ቡድን አገልግሎቱን ለማስቀጠል ይታገላል።

መኖሩ ጥሩ ችግር ነው፣ ነገር ግን የድር መተግበሪያን ከምንም ወደ በመቶ ሺዎች የሚቆጠሩ ተጠቃሚዎች እንዴት በጥንቃቄ እንደሚመዘን በድር ላይ ትንሽ ግልፅ መረጃ የለም። በተለምዶ የእሳት መፍትሄዎች ወይም የጠርሙስ መፍትሄዎች (እና ብዙውን ጊዜ ሁለቱም) አሉ. ስለዚህ፣ ሰዎች አማተር ፕሮጄክታቸውን ወደ ከባድ ነገር ለማመጣጠን የተዝረከረኩ ቴክኒኮችን ይጠቀማሉ።

መረጃውን ለማጣራት እና መሰረታዊውን ቀመር ለመጻፍ እንሞክር. አዲሱን የፎቶ ማጋሪያ ጣቢያችንን Graminsta ደረጃ በደረጃ ከ1 ወደ 100 ተጠቃሚዎች እናሳድጋለን።

ታዳሚው ወደ 10, 100, 1000, 10 እና 000 ሰዎች ሲጨምር ምን ልዩ እርምጃዎች መወሰድ እንዳለባቸው እንጻፍ.

1 ተጠቃሚ: 1 ማሽን

እያንዳንዱ መተግበሪያ ማለት ይቻላል, ድር ጣቢያ ወይም የሞባይል መተግበሪያ, ሦስት ቁልፍ ክፍሎች አሉት.

• ኤ ፒ አይ
• የውሂብ ጎታ
• ደንበኛ (የሞባይል መተግበሪያ ራሱ ወይም ድር ጣቢያ)

የመረጃ ቋቱ የማያቋርጥ ውሂብ ያከማቻል። ኤፒአይ በዚህ ውሂብ ዙሪያ ጥያቄዎችን ያቀርባል። ደንበኛው መረጃን ለተጠቃሚው ያስተላልፋል.

ከሥነ ሕንፃ እይታ አንጻር ደንበኛው እና የኤፒአይ አካላት ሙሉ በሙሉ ከተለያዩ ማመልከቻን ስለማስኬድ ማውራት በጣም ቀላል ነው ወደሚል መደምደሚያ ደርሻለሁ።

አፕሊኬሽን መገንባት ስንጀምር ሦስቱም አካላት በአንድ አገልጋይ ላይ ሊሠሩ ይችላሉ። በአንዳንድ መንገዶች ይህ ከዕድገት አካባቢያችን ጋር ተመሳሳይ ነው፡ አንድ መሐንዲስ የውሂብ ጎታውን፣ ኤፒአይን እና ደንበኛን በአንድ ማሽን ላይ ያንቀሳቅሳል።

በንድፈ ሀሳብ፣ ከታች እንደሚታየው በአንድ ዲጂታል ውቅያኖስ Droplet ወይም AWS EC2 ምሳሌ ላይ በደመና ውስጥ ማሰማራት እንችላለን፡-

ይህን ስል፣ በአንድ ጣቢያ ላይ ከአንድ በላይ ተጠቃሚዎች ካሉ፣ ሁልጊዜ ማለት ይቻላል የውሂብ ጎታ ንብርብር መወሰን ምክንያታዊ ነው።

10 ተጠቃሚዎች: የውሂብ ጎታውን ወደ የተለየ ደረጃ ማንቀሳቀስ

ዳታቤዙን ወደ ሚተዳደሩ አገልግሎቶች እንደ Amazon RDS ወይም Digital Ocean Managed Database መከፋፈል ለረጅም ጊዜ ጥሩ አገልግሎት ይሰጠናል። በአንድ ማሽን ወይም በ EC2 ምሳሌ እራስን ከማስተናገድ ትንሽ የበለጠ ውድ ነው፣ ነገር ግን በእነዚህ አገልግሎቶች ብዙ ጠቃሚ ማራዘሚያዎችን ከሳጥኑ ውስጥ ታገኛላችሁ ይህም ወደፊት ጠቃሚ ይሆናል፡ ባለብዙ ክልል ምትኬ፣ ቅጂዎችን ያንብቡ፣ አውቶማቲክ ምትኬዎች እና ሌሎችም።

ስርዓቱ አሁን ይህን ይመስላል፡-

100 ተጠቃሚዎች: ደንበኛው ወደ የተለየ ደረጃ ማንቀሳቀስ

እንደ እድል ሆኖ፣ የመጀመሪያዎቹ ተጠቃሚዎቻችን መተግበሪያችንን በእውነት ወደውታል። ትራፊክ ይበልጥ የተረጋጋ እየሆነ መጥቷል፣ ስለዚህ ደንበኛውን ወደ የተለየ ደረጃ ለማንቀሳቀስ ጊዜው አሁን ነው። መሆኑን ልብ ሊባል ይገባል። መለያየት አካላት ሊሰፋ የሚችል መተግበሪያ የመገንባት ቁልፍ ገጽታ ነው። የስርዓቱ አንዱ አካል ተጨማሪ ትራፊክ እንደሚቀበል፣ በተወሰኑ የትራፊክ ቅጦች ላይ በመመስረት የአገልግሎት ሚዛኖችን ለመቆጣጠር ልንከፋፍለው እንችላለን።

ለዚህም ነው ደንበኛው ከኤፒአይ የተለየ አድርጎ ማሰብ የፈለኩት። ይህ ለብዙ መድረኮች ስለመገንባት ለማሰብ በጣም ቀላል ያደርገዋል፡ ድር፣ የሞባይል ድር፣ አይኦኤስ፣ አንድሮይድ፣ ዴስክቶፕ አፕሊኬሽኖች፣ የሶስተኛ ወገን አገልግሎቶች፣ ወዘተ. ሁሉም ተመሳሳይ API የሚጠቀሙ ደንበኞች ናቸው።

ለምሳሌ፣ አሁን ተጠቃሚዎቻችን ብዙ ጊዜ የሞባይል መተግበሪያን ለመልቀቅ ይጠይቃሉ። ደንበኛውን እና የኤፒአይ አካላትን ከለዩ ይህ ቀላል ይሆናል።

እንዲህ ዓይነቱ ሥርዓት ይህን ይመስላል:

1000 ተጠቃሚዎች: የጭነት ሚዛን አክል

ነገሮች ወደላይ እየታዩ ነው። የ Graminsta ተጠቃሚዎች ብዙ እና ተጨማሪ ፎቶዎችን እየሰቀሉ ነው። የምዝገባ ቁጥርም እያደገ ነው። የእኛ ብቸኛ የኤፒአይ አገልጋይ ሁሉንም ትራፊክ ለመከታተል ተቸግሯል። ተጨማሪ ብረት ይፈልጋሉ!

የጭነት ሚዛን በጣም ኃይለኛ ጽንሰ-ሐሳብ ነው. ዋናው ሃሳብ የጭነት ሚዛንን ከኤፒአይ ፊት ለፊት እናስቀምጣለን, እና ትራፊክን ለግል አገልግሎት ሁኔታዎች ያሰራጫል. በአግድም የምንለካው በዚህ መንገድ ነው፣ ይህም ማለት ተመሳሳይ ኮድ ያላቸው ብዙ አገልጋዮችን እንጨምራለን፣ ይህም የምንሰራቸውን የጥያቄዎች ብዛት ይጨምራል።

ከድር ደንበኛው ፊት ለፊት እና ከኤፒአይ ፊት ለፊት የተለየ የጭነት ማመሳከሪያዎችን እናስቀምጣለን። ይህ ማለት የኤፒአይ ኮድ እና የድር ደንበኛ ኮድን የሚያሄዱ በርካታ አጋጣሚዎችን ማሄድ ይችላሉ። የመጫኛ ሚዛን ሰጪው ብዙም ወደተጫነው አገልጋይ ጥያቄዎችን ይመራል።

እዚህ ሌላ ጠቃሚ ጥቅም እናገኛለን - ድግግሞሽ. አንድ ምሳሌ ሳይሳካ ሲቀር (ምናልባትም ከመጠን በላይ የተጫነ ወይም የተበላሸ)፣ ለሚመጡ ጥያቄዎች ምላሽ መስጠቱን የሚቀጥሉ ከሌሎች ጋር እንቀራለን። አንድ ምሳሌ ብቻ እየሰራ ከሆነ ፣ ከዚያ ውድቀት በሚከሰትበት ጊዜ አጠቃላይ ስርዓቱ ይወድቃል።

የጭነት ማመሳከሪያው አውቶማቲክ ማመጣጠን ያቀርባል. ከከፍተኛ ጭነት በፊት የአብነቶችን ብዛት እንዲጨምር እና ሁሉም ተጠቃሚዎች ሲተኙ እንዲቀንስ ልናዋቅረው እንችላለን።

በሎድ ሚዛን፣ የኤፒአይ ደረጃ ላልተወሰነ ጊዜ ሊመዘን ይችላል፣ የጥያቄዎች ብዛት ሲጨምር በቀላሉ አዳዲስ አጋጣሚዎችን ይጨምራል።

ማስታወሻ. አሁን የእኛ ስርዓት እንደ Heroku ወይም Elastic Beanstalk በ AWS ላይ ያሉ የPaaS ኩባንያዎች ከሳጥኑ ውጭ ከሚያቀርቡት ጋር በጣም ተመሳሳይ ነው (ለዚህም ነው በጣም ተወዳጅ የሆኑት)። Heroku የውሂብ ጎታውን በተለየ አስተናጋጅ ላይ ያስቀምጣል, በራስ-ሰር የሚለካ ጭነት ሚዛን ያስተዳድራል እና የድር ደንበኛውን ከኤፒአይ ለይተው እንዲያስተናግዱ ይፈቅድልዎታል. ይህ ሄሮኩን ለመጠቀም ጥሩ ምክንያት ነው የመጀመሪያ ደረጃ ፕሮጀክቶች ወይም ጅምር - ሁሉንም መሰረታዊ አገልግሎቶች ከሳጥኑ ውስጥ ያገኛሉ።

10 ተጠቃሚዎች: CDN

ምናልባት ገና ከመጀመሪያው ይህን ማድረግ ነበረብን። ጥያቄዎችን ማስተናገድ እና አዳዲስ ፎቶዎችን መቀበል በአገልጋዮቻችን ላይ ብዙ ጫና መፍጠር እየጀመረ ነው።

በዚህ ደረጃ፣ የማይንቀሳቀስ ይዘትን - ምስሎችን፣ ቪዲዮዎችን እና ሌሎችንም (AWS S3 ወይም Digital Ocean Spaces) ለማከማቸት የደመና አገልግሎትን መጠቀም ያስፈልግዎታል። በአጠቃላይ የእኛ ኤፒአይ እንደ ምስሎችን ከማገልገል እና ምስሎችን ወደ አገልጋዩ ከመስቀል መቆጠብ አለበት።

የደመና ማስተናገጃ ሌላው ጥቅም ሲዲኤን ነው (AWS ይህንን ተጨማሪ Cloudfront ብለው ይጠሩታል ፣ ግን ብዙ የደመና ማከማቻ አቅራቢዎች ከሳጥኑ ውጭ ያቀርቡታል)። ሲዲኤን ምስሎቻችንን በአለም ዙሪያ ባሉ የተለያዩ የመረጃ ቋቶች ውስጥ በራስ ሰር ይሸፍናል።

ዋናው የዳታ ማዕከላችን በኦሃዮ ውስጥ የሚገኝ ቢሆንም፣ አንድ ሰው ከጃፓን ምስል ከጠየቀ፣ የደመና አቅራቢው ቅጂ ሰርተው በጃፓን የመረጃ ማዕከላቸው ውስጥ ያከማቻሉ። በጃፓን ይህን ምስል የሚጠይቅ ቀጣዩ ሰው በፍጥነት ይቀበላል። በፕላኔታችን ላይ ለማውረድ እና ለማስተላለፍ ረጅም ጊዜ የሚወስዱ እንደ ፎቶዎች ወይም ቪዲዮዎች ካሉ ትላልቅ ፋይሎች ጋር ስንሰራ ይህ አስፈላጊ ነው።

100 ተጠቃሚዎች፡ የውሂብ ንብርብሩን ማመጣጠን

ሲዲኤን ብዙ ረድቷል፡ ትራፊክ በከፍተኛ ፍጥነት እያደገ ነው። ታዋቂው የቪዲዮ ጦማሪ ማቪድ ሞብሪክ ልክ ከእኛ ጋር ተመዝግቦ "ታሪኩን" አውጥቷል ይላሉ። ለጭነት ሚዛን ምስጋና ይግባውና በኤፒአይ አገልጋዮች ላይ ያለው ሲፒዩ እና የማህደረ ትውስታ አጠቃቀም ዝቅተኛ ነው (አስር የኤፒአይ አጋጣሚዎች እየሰሩ ነው)፣ ነገር ግን በጥያቄዎች ላይ ብዙ ጊዜ ማለፊያዎችን ማግኘት ጀምረናል... እነዚህ መዘግየቶች ከየት እየመጡ ነው?

በመለኪያዎች ውስጥ ትንሽ በመቆፈር, በመረጃ ቋቱ አገልጋይ ላይ ያለው ሲፒዩ ከ80-90% እንደተጫነ እናያለን. ገደቡ ላይ ነን።

የውሂብ ንብርብርን ማመጣጠን ምናልባት በጣም አስቸጋሪው የእኩልታው ክፍል ነው። የኤፒአይ አገልጋዮች አገር አልባ ጥያቄዎችን ያገለግላሉ፣ ስለዚህ በቀላሉ ተጨማሪ የኤፒአይ ምሳሌዎችን እንጨምራለን። አፍንጫ አብዛኞቹ የውሂብ ጎታዎች ይህንን ማድረግ አይችሉም. ስለ ታዋቂ የግንኙነት የውሂብ ጎታ አስተዳደር ስርዓቶች (PostgreSQL, MySQL, ወዘተ) እንነጋገራለን.

መሸጎጫ

የመረጃ ቋታችንን አፈፃፀም ለመጨመር ቀላሉ መንገዶች አንዱ አዲስ አካል ማስተዋወቅ ነው-የመሸጎጫ ንብርብር። በጣም የተለመደው የመሸጎጫ ዘዴ እንደ Redis ወይም Memcached ያለ የማህደረ ትውስታ ቁልፍ-እሴት ማከማቻ ነው። አብዛኛዎቹ ደመናዎች የሚተዳደረው የእነዚህ አገልግሎቶች ስሪት አላቸው፡ Elasticache on AWS እና Memorystore በGoogle ክላውድ ላይ።

አንድ አገልግሎት ተመሳሳይ መረጃ ለማግኘት ብዙ ተደጋጋሚ ጥሪዎችን ወደ ዳታቤዝ ሲያደርግ መሸጎጫ ጠቃሚ ነው። በመሠረቱ, የውሂብ ጎታውን አንድ ጊዜ ብቻ ነው የምንደርሰው, መረጃውን በመሸጎጫው ውስጥ እናከማቻለን እና እንደገና አይንኩት.

ለምሳሌ በ Graminsta አገልግሎታችን አንድ ሰው ወደ ኮከቡ ሞብሪክ ፕሮፋይል በሄደ ቁጥር የኤፒአይ አገልጋይ የመረጃ ቋቱን ከመገለጫው ይጠይቃል። ይህ በተደጋጋሚ ይከሰታል. የሞብሪክ ፕሮፋይል መረጃ በእያንዳንዱ ጥያቄ ስለማይቀየር ለመሸጎጥ በጣም ጥሩ ነው።

ውጤቶቹን በሬዲስ ውስጥ ካለው የውሂብ ጎታ በቁልፍ እናስቀምጣለን። user:id በ 30 ሰከንድ ተቀባይነት ያለው ጊዜ. አሁን፣ አንድ ሰው ወደ ሞብሪክ ፕሮፋይል ሲሄድ፣ መጀመሪያ Redisን እንፈትሻለን፣ እና ውሂቡ ካለ፣ በቀላሉ ከሬዲስ በቀጥታ እናስተላልፋለን። አሁን በጣቢያው ላይ በጣም ታዋቂ ለሆኑ መገለጫዎች የሚቀርቡ ጥያቄዎች የእኛን የውሂብ ጎታ አይጫኑም።

ሌላው የአብዛኛዎቹ መሸጎጫ አገልግሎቶች ከዳታቤዝ አገልጋዮች ይልቅ ለመለካት ቀላል መሆናቸው ነው። Redis አብሮ የተሰራ የRedis ክላስተር ሁነታ አለው። ከጭነት ሚዛን ጋር ተመሳሳይ1, የእርስዎን Redis መሸጎጫ በበርካታ ማሽኖች ላይ እንዲያሰራጩ ይፈቅድልዎታል (አስፈላጊ ከሆነ በሺዎች በሚቆጠሩ አገልጋዮች).

ሁሉም ማለት ይቻላል መጠነ ሰፊ አፕሊኬሽኖች መሸጎጫ ይጠቀማሉ፤ የፈጣን ኤፒአይ ፍፁም አካል ነው። ፈጣን የመጠይቅ ሂደት እና የበለጠ ፍሬያማ ኮድ ሁሉም አስፈላጊ ናቸው፣ ነገር ግን ያለ መሸጎጫ አገልግሎቱን በሚሊዮኖች ለሚቆጠሩ ተጠቃሚዎች ማሳደግ ፈጽሞ የማይቻል ነው።

ቅጂዎችን ያንብቡ

በመረጃ ቋቱ ውስጥ የሚደረጉ መጠይቆች ብዛት በከፍተኛ ደረጃ ሲጨምር፣ አንድ ተጨማሪ ነገር ማድረግ የምንችለው በመረጃ ቋቱ አስተዳደር ስርዓት ውስጥ የተነበቡ ቅጂዎችን ማከል ነው። ከላይ በተገለጹት የሚተዳደሩ አገልግሎቶች, ይህ በአንድ ጠቅታ ሊከናወን ይችላል. የተነበበው ቅጂ በዋናው ዳታቤዝ ውስጥ እንዳለ ይቆያል እና ለ SELECT መግለጫዎች ይገኛል።

አሁን የእኛ ስርዓት ይኸውና:

ቀጣይ እርምጃዎች

አፕሊኬሽኑ መጠኑን እየቀጠለ ሲሄድ፣ አገልግሎቶቹን በተናጥል ለመለካት መለያየታችንን እንቀጥላለን። ለምሳሌ ዌብሶኬቶችን መጠቀም ከጀመርን የዌብሶኬቶችን ሂደት ኮድ ወደ ተለየ አገልግሎት መጎተት ተገቢ ነው። በክፍት የዌብሶኬት ግንኙነቶች ላይ በመመስረት እና የኤችቲቲፒ ጥያቄዎች ብዛት ምንም ይሁን ምን ከፍ እና ዝቅ ሊል ከሚችለው የራሳችን ጭነት ሚዛን ጀርባ በአዲስ አጋጣሚዎች ላይ ልናስቀምጠው እንችላለን።

እንዲሁም በመረጃ ቋት ደረጃ ገደቦችን መዋጋት እንቀጥላለን። የውሂብ ጎታ ክፍፍልን እና ማጋራትን ለማጥናት ጊዜው አሁን በዚህ ደረጃ ላይ ነው. ሁለቱም አካሄዶች ተጨማሪ ወጪን ይፈልጋሉ ነገር ግን የውሂብ ጎታውን ላልተወሰነ ጊዜ እንዲያሳድጉ ያስችሉዎታል።

እንደ New Relic ወይም Datadog ያሉ የክትትልና የትንታኔ አገልግሎት መጫን እንፈልጋለን። ይህ ቀርፋፋ መጠይቆችን ለመለየት እና የት መሻሻል እንደሚያስፈልግ ለመረዳት ይረዳዎታል። ስናመዛዝን፣ ማነቆዎችን በማፈላለግ እና እነሱን በማጥፋት ላይ ማተኮር እንፈልጋለን—ብዙውን ጊዜ ከቀደምት ክፍሎች የተወሰኑ ሃሳቦችን እንጠቀማለን።

ምንጮች

ይህ ልጥፍ በአንዱ አነሳሽነት ነው። ስለ ከፍተኛ ልኬት በጣም የምወዳቸው ልጥፎች. ጽሑፉን ለመጀመሪያዎቹ የፕሮጀክቶች የመጀመሪያ ደረጃዎች ትንሽ ልዩ ለማድረግ እና ከአንድ ሻጭ መፍታት ፈልጌ ነበር። በዚህ ርዕስ ላይ ፍላጎት ካሎት ማንበብዎን እርግጠኛ ይሁኑ.

የግርጌ ማስታወሻዎች

1. ምንም እንኳን በብዙ ሁኔታዎች ላይ ካለው ጭነት ስርጭት አንፃር ተመሳሳይ ቢሆንም የሬዲስ ክላስተር መሰረታዊ አተገባበር ከጭነት ሚዛን በጣም የተለየ ነው። [መመለስ]

ምንጭ: hab.com