Олон стартапууд үүнийг даван туулсан: олон тооны шинэ хэрэглэгчид өдөр бүр бүртгүүлдэг бөгөөд хөгжүүлэлтийн баг энэ үйлчилгээг үргэлжлүүлэн ажиллуулахын тулд тэмцдэг.
Энэ нь маш сайхан асуудал боловч вэб программыг юу ч бишээс хэдэн зуун мянган хэрэглэгч хүртэл хэрхэн болгоомжтой масштаблах талаар тодорхой мэдээлэл вэб дээр бага байдаг. Ихэвчлэн гал түймрийн шийдэл эсвэл түгжрэлийн шийдэл (мөн ихэвчлэн хоёулаа) байдаг. Тиймээс хүмүүс сонирхогчийн төслөө үнэхээр ноцтой зүйл болгон өргөжүүлэхийн тулд нэлээд хуучирсан арга техникийг ашигладаг.
Мэдээллийг шүүж, үндсэн томъёог бичихийг хичээцгээе. Бид шинэ зураг хуваалцах 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 хэрэглэгч: үйлчлүүлэгчийг тусдаа түвшинд шилжүүлэх
Аз болоход бидний анхны хэрэглэгчдэд манай програм үнэхээр таалагдсан. Замын хөдөлгөөн илүү тогтвортой болж байгаа тул үйлчлүүлэгчийг тусдаа түвшинд шилжүүлэх цаг болжээ. Үүнийг тэмдэглэх нь зүйтэй тусгаарлах аж ахуйн нэгжүүд нь өргөтгөх боломжтой програмыг бүтээх гол тал юм. Системийн нэг хэсэг нь илүү их траффик хүлээн авдаг тул бид тодорхой замын хөдөлгөөний хэв маягт үндэслэн үйлчилгээний хэмжээг хэрхэн хуваахыг хянах боломжтой.
Тийм ч учраас би үйлчлүүлэгчийг API-аас тусдаа гэж үзэх дуртай. Энэ нь вэб, мобайл вэб, iOS, Android, ширээний программууд, гуравдагч талын үйлчилгээ гэх мэт олон платформыг хөгжүүлэх талаар бодоход маш хялбар болгодог. Тэд бүгд ижил API ашигладаг үйлчлүүлэгчид юм.
Жишээлбэл, одоо манай хэрэглэгчид гар утасны програм гаргахыг ихэвчлэн хүсдэг. Хэрэв та үйлчлүүлэгч болон API нэгжүүдийг салгавал энэ нь илүү хялбар болно.
Ийм систем нь дараах байдалтай байна.
1000 хэрэглэгч: ачаалал тэнцвэржүүлэгч нэмнэ
Бүх зүйл дээшээ харж байна. Graminsta хэрэглэгчид улам олон зураг байршуулж байна. Бүртгэлийн тоо ч нэмэгдэж байна. Манай цорын ганц API сервер нь бүх ачааллыг дагаж мөрдөхөд хэцүү байна. Илүү их төмөр хэрэгтэй!
Ачаалал тэнцвэржүүлэгч нь маш хүчирхэг ойлголт юм. Гол санаа нь бид API-ийн өмнө ачаалал тэнцвэржүүлэгчийг байрлуулах бөгөөд энэ нь хувь хүний үйлчилгээний инстанцуудад траффик хуваарилдаг явдал юм. Ингэж бид хэвтээ байдлаар өргөжүүлж, ижил кодтой серверүүдийг нэмж, боловсруулах боломжтой хүсэлтийн тоог нэмэгдүүлнэ гэсэн үг юм.
Бид вэб клиентийн өмнө болон API-ийн өмнө тусдаа ачаалал тэнцвэржүүлэгчийг байрлуулах гэж байна. Энэ нь та API код болон вэб клиент кодыг ажиллуулж байгаа олон тохиолдлыг ажиллуулах боломжтой гэсэн үг юм. Ачаалал тэнцвэржүүлэгч нь бага ачаалалтай сервер рүү хүсэлтийг чиглүүлнэ.
Энд бид өөр нэг чухал давуу талыг олж авдаг - илүүдэл. Нэг тохиолдол бүтэлгүйтсэн үед (хэт ачаалалтай эсвэл осолдсон байж магадгүй) бид ирж буй хүсэлтэд хариу өгөх бусад хүмүүстэй үлддэг. Хэрэв зөвхөн нэг инстанц ажиллаж байсан бол бүтэлгүйтсэн тохиолдолд систем бүхэлдээ гацах болно.
Ачаалал тэнцвэржүүлэгч нь автомат масштабыг өгдөг. Бид үүнийг оргил ачааллын өмнөх тохиолдлын тоог нэмэгдүүлэх, бүх хэрэглэгчид унтаж байх үед багасгахаар тохируулах боломжтой.
Ачаалал тэнцвэржүүлэгчийн тусламжтайгаар API түвшинг бараг хязгааргүй хэмжээгээр нэмэгдүүлэх боломжтой бөгөөд хүсэлтийн тоо нэмэгдэх тусам шинэ тохиолдлуудыг нэмж болно.
Анхаарна уу. Яг одоо манай систем нь AWS дээрх Heroku эсвэл Elastic Beanstalk зэрэг PaaS компаниудын санал болгож буй зүйлтэй маш төстэй байна (тийм ч учраас тэд маш алдартай). Heroku нь өгөгдлийн санг тусдаа хост дээр байрлуулж, автоматаар масштабтай ачааллын тэнцвэржүүлэгчийг удирдаж, вэб клиентийг API-аас тусад нь байрлуулах боломжийг танд олгоно. Энэ нь Heroku-г эхний шатны төсөл эсвэл гарааны бизнест ашиглах сайхан шалтгаан юм - та бүх үндсэн үйлчилгээг хайрцагнаас нь авах болно.
10 хэрэглэгч: CDN
Магадгүй бид үүнийг анхнаасаа хийх ёстой байсан байх. Хүсэлтийг боловсруулах, шинэ зураг хүлээн авах нь манай серверүүдэд хэт их ачаалал өгч эхэлж байна.
Энэ үе шатанд та статик контент - зураг, видео болон бусад зүйлсийг (AWS S3 эсвэл Digital Ocean Spaces) хадгалах үүл үйлчилгээг ашиглах хэрэгтэй. Ерөнхийдөө манай API нь серверт зураг оруулах, зураг байршуулах гэх мэт зүйлсийг зохицуулахаас зайлсхийх ёстой.
Клоуд байршуулах өөр нэг давуу тал бол CDN (AWS энэ нэмэлтийг Cloudfront гэж нэрлэдэг боловч олон үүл хадгалах үйлчилгээ үзүүлэгч үүнийг хайрцагнаас нь санал болгодог). CDN нь дэлхий даяарх янз бүрийн мэдээллийн төвд бидний зургийг автоматаар кэш болгодог.
Манай үндсэн дата төв нь Охайо мужид байрладаг байж болох ч хэрэв хэн нэгэн Японоос зураг авах хүсэлт гаргавал үүлэн үйлчилгээ үзүүлэгч үүнийг хуулбарлаж, Японы мэдээллийн төвд хадгалах болно. Японд энэ зургийг хүссэн дараагийн хүн илүү хурдан хүлээж авах болно. Энэ нь зураг, видео зэрэг том файлуудтай ажиллахад маш чухал бөгөөд үүнийг татаж аваад дэлхий даяар дамжуулахад удаан хугацаа шаардагдана.
100 хэрэглэгч: өгөгдлийн давхаргыг өргөжүүлэх
CDN маш их тусалсан: замын хөдөлгөөн бүрэн хурдацтай нэмэгдэж байна. Алдарт видео блогчин Мавид Мобрик саяхан манайд бүртгүүлж, тэдний хэлснээр "түүх"-ээ нийтэлжээ. Ачаалал тэнцвэржүүлэгчийн ачаар API серверүүдийн CPU болон санах ойн хэрэглээ бага хэвээр байгаа (API-ийн арван тохиолдол ажиллаж байгаа), гэхдээ бид хүсэлтийн дагуу маш их завсарлага авч эхэлж байна ... эдгээр саатал хаанаас гарч байна вэ?
Хэмжилтийг бага зэрэг ухаж үзвэл мэдээллийн сангийн сервер дээрх CPU 80-90% ачаалалтай байгааг бид харж байна. Бид хязгаарт байна.
Өгөгдлийн давхаргыг масштаблах нь магадгүй тэгшитгэлийн хамгийн хэцүү хэсэг юм. API серверүүд нь харьяалалгүй хүсэлтэд үйлчилдэг тул бид зүгээр л илүү олон API жишээг нэмнэ. Хамар ихэнх нь мэдээллийн сан үүнийг хийх боломжгүй. Бид алдартай харилцааны мэдээллийн сангийн удирдлагын системүүдийн талаар ярих болно (PostgreSQL, MySQL гэх мэт).
кэш хийх
Манай мэдээллийн сангийн гүйцэтгэлийг нэмэгдүүлэх хамгийн хялбар аргуудын нэг бол кэшийн давхарга гэсэн шинэ бүрэлдэхүүн хэсгийг нэвтрүүлэх явдал юм. Хамгийн түгээмэл кэш хийх арга бол Redis эсвэл Memcached гэх мэт санах ойн түлхүүр-утга бичлэгийн дэлгүүр юм. Ихэнх үүлэнд эдгээр үйлчилгээний удирддаг хувилбар байдаг: AWS дээрх Elasticache болон Google Cloud дээрх Memorystore.
Үйлчилгээ нь ижил мэдээллийг авахын тулд мэдээллийн сан руу олон удаа давтан дуудлага хийх үед кэш нь ашигтай байдаг. Үндсэндээ бид мэдээллийн санд нэг л удаа нэвтэрч, мэдээллийг кэшэд хадгалдаг бөгөөд түүнд дахин хүрч болохгүй.
Жишээлбэл, манай Graminsta үйлчилгээнд хэн нэгэн Mobrik одны профайл хуудас руу орох бүрт API сервер нь мэдээллийн сангаас түүний профайлаас мэдээлэл авахыг хүсдэг. Энэ нь дахин дахин тохиолддог. Мобрикийн профайлын мэдээлэл хүсэлт болгонд өөрчлөгддөггүй тул кэш хийхэд маш тохиромжтой.
Бид Редис дэх мэдээллийн баазын үр дүнг түлхүүрээр кэш хийх болно user:id 30 секундын хүчинтэй байх хугацаатай. Одоо хэн нэгэн Mobrik-ийн профайл руу ороход бид эхлээд Redis-ийг шалгадаг бөгөөд хэрэв өгөгдөл байгаа бол бид үүнийг Redis-ээс шууд дамжуулдаг. Одоо сайт дээрх хамгийн алдартай профайлд хандах хүсэлт манай мэдээллийн санг бараг ачаалахгүй байна.
Ихэнх кэшийн үйлчилгээний өөр нэг давуу тал нь мэдээллийн баазын серверүүдийг бодвол масштаблахад хялбар байдаг. Redis нь суурилуулсан Redis Cluster горимтой. Ачаалал тэнцвэржүүлэгчтэй төстэй, энэ нь танд Redis кэшээ олон машинд (шаардлагатай бол олон мянган серверүүдээр) түгээх боломжийг олгодог.
Бараг бүх том хэмжээний програмууд кэшийг ашигладаг бөгөөд энэ нь хурдан API-ийн салшгүй хэсэг юм. Асуултыг хурдан боловсруулах, илүү бүтээмжтэй код нь чухал боловч кэшгүй бол үйлчилгээг сая сая хэрэглэгчдэд хүргэх бараг боломжгүй юм.
Хуулбаруудыг уншина уу
Өгөгдлийн сангийн асуулгын тоо эрс нэмэгдсэн үед бидний хийж чадах өөр нэг зүйл бол мэдээллийн сангийн удирдлагын системд уншсан хуулбаруудыг нэмэх явдал юм. Дээр тайлбарласан удирддаг үйлчилгээнүүдийн тусламжтайгаар үүнийг нэг товшилтоор хийж болно. Уншсан хуулбар нь үндсэн мэдээллийн санд хэвээр байх бөгөөд SELECT мэдэгдлүүдэд ашиглах боломжтой.
Одоо манай систем энд байна:
Цаашдын арга хэмжээ
Аппликешн өргөжин тэлэхийн хэрээр бид үйлчилгээг бие даан өргөжүүлэхийн тулд үргэлжлүүлэн салгах болно. Жишээлбэл, хэрэв бид Websockets ашиглаж эхэлбэл Websockets боловсруулах кодыг тусдаа үйлчилгээ болгон татах нь зүйтэй юм. Бид үүнийг өөрийн ачааллын тэнцвэржүүлэгчийн ард шинэ тохиолдлуудад байрлуулж болох бөгөөд энэ нь нээлттэй Websockets холболтууд дээр тулгуурлан, HTTP хүсэлтийн тооноос үл хамааран томруулж, багасгаж болно.
Мөн бид мэдээллийн сангийн түвшинд хязгаарлалттай тэмцсээр байх болно. Яг энэ үе шатанд өгөгдлийн сангийн хуваалт, хуваалтыг судлах цаг болжээ. Энэ хоёр арга нь нэмэлт зардал шаарддаг боловч өгөгдлийн санг бараг хязгааргүй хэмжээгээр нэмэгдүүлэх боломжийг танд олгоно.
Бид мөн New Relic эсвэл Datadog гэх мэт мониторинг, аналитик үйлчилгээг суулгахыг хүсч байна. Энэ нь танд удаашралтай асуултуудыг тодорхойлж, хаана сайжруулах шаардлагатай байгааг ойлгоход тусална. Хэмжээг нэмэгдүүлэхийн хэрээр бид саад бэрхшээлийг олж, тэдгээрийг арилгахад анхаарлаа төвлөрүүлэхийг хүсч байна - ихэвчлэн өмнөх хэсгүүдийн зарим санааг ашигладаг.
Эх сурвалжууд
Энэ нийтлэлийг нэгээс санаа авсан болно . Би нийтлэлийг төслийн эхний үе шатанд илүү тодорхой болгож, нэг борлуулагчаас салгахыг хүссэн. Хэрэв та энэ сэдвийг сонирхож байвал заавал уншаарай.
Зүүлт
- Хэдийгээр олон тохиолдлуудад ачааллын хуваарилалтын хувьд ижил төстэй боловч Redis кластерын үндсэн хэрэгжилт нь ачаалал тэнцвэржүүлэгчээс тэс өөр юм.
Эх сурвалж: www.habr.com