Көптөгөн стартаптар муну башынан өткөрүштү: жаңы колдонуучулардын саны күн сайын катталып, иштеп чыгуучу топ бул кызматты улантуу үчүн күрөшөт.

Бул жакшы көйгөй, бирок веб-тиркемени кантип кылдаттык менен масштабдоо керектиги жөнүндө интернетте так маалымат жок, жоктон жүз миңдеген колдонуучуларга чейин. Көбүнчө өрткө каршы чечимдер же тоскоолдуктар бар (жана көбүнчө экөө тең). Ошондуктан, адамдар өздөрүнүн ышкыбоздук долбоорун чындап олуттуу нерсеге чейин масштабдоо үчүн абдан клишеленген ыкмаларды колдонушат.

Келгиле, маалыматты чыпкалап, негизги формуланы жазып көрөлү. Биз жаңы Graminsta сүрөт бөлүшүү сайтыбызды кадам сайын 1ден 100 000 колдонуучуга чейин кеңейтебиз.

Аудитория 10, 100, 1000, 10 000 жана 100 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 000 колдонуучу: маалымат катмарын масштабдоо

CDN көп жардам берди: трафик толук ылдамдыкта өсүп жатат. Белгилүү видеоблогер Мавид Мобрик жаңы эле бизге катталып, алар айткандай өзүнүн “окуясын” жарыялады. Жүктөлгөн тең салмактуулуктун аркасында API серверлериндеги CPU жана эстутумдун колдонулушу төмөн бойдон калууда (API он инстанциясы иштеп жатат), бирок биз суроо-талаптар боюнча көп күтүүлөрдү ала баштайбыз... бул кечигүүлөр кайдан келип жатат?

Метрикаларды бир аз казып, биз маалымат базасынын сервериндеги CPU 80-90% жүктөлгөнүн көрөбүз. Биз чекке жеттик.

Маалымат катмарын масштабдоо теңдеменин эң кыйын бөлүгү болсо керек. API серверлери жарандыгы жок суроо-талаптарды тейлейт, ошондуктан биз жөн гана көбүрөөк API инстанцияларын кошобуз. Мурун көпчүлүк маалымат базалары муну кыла албайт. Биз популярдуу реляциялык маалымат базасын башкаруу системалары (PostgreSQL, MySQL ж.б.) жөнүндө сүйлөшөбүз.

кэштөө

Биздин базанын иштешин жогорулатуунун эң оңой жолдорунун бири - жаңы компонентти киргизүү: кэш катмары. Эң кеңири таралган кэштөө ыкмасы - бул Redis же Memcached сыяктуу эс тутумдагы ачкыч-маанилердин рекорддук дүкөнү. Көпчүлүк булуттарда бул кызматтардын башкарылуучу версиясы бар: AWSдеги Elasticache жана Google Булуттагы Memorystore.

Кызмат бир эле маалыматты алуу үчүн маалымат базасына көп кайталанган чалууларды жасаганда кэш пайдалуу. Негизи, биз маалымат базасына бир гана жолу киребиз, маалыматты кэште сактайбыз жана ага кайра тийбейбиз.

Мисалы, биздин Graminsta кызматыбызда кимдир бирөө Mobrik жылдызынын профилдик барагына барган сайын API сервери анын профилинен маалымат алуу үчүн маалымат базасын сурайт. Бул кайра-кайра кайталанат. Мобриктин профилдик маалыматы ар бир суроо-талап менен өзгөрбөгөндүктөн, кэштөө үчүн эң сонун.

Редистеги маалымат базасынан алынган натыйжаларды ачкыч менен кэштейбиз user:id жарактуу мөөнөтү 30 секунд. Эми кимдир бирөө Мобриктин профилине киргенде, биз адегенде Редисти текшеребиз, эгер маалыматтар бар болсо, биз аны түз эле Редистен өткөрүп беребиз. Азыр сайттагы эң популярдуу профилге болгон суроо-талаптар биздин базабызды дээрлик жүктөбөйт.

Көпчүлүк кэш кызматтарынын дагы бир артыкчылыгы, алар маалымат базасынын серверлерине караганда масштабдалышы оңой. Redis орнотулган Redis кластер режимине ээ. Жүктүн тең салмактуулугуна окшош1, ал сизге Redis кэшиңизди бир нече машиналарга (зарыл болсо миңдеген серверлер боюнча) жайылтууга мүмкүндүк берет.

Дээрлик бардык ири масштабдуу тиркемелер кэшти колдонушат; бул тез APIдин ажырагыс бөлүгү. Суроолорду тезирээк иштетүү жана жемиштүү коддун баары маанилүү, бирок кэшсиз миллиондогон колдонуучуларга кызматты масштабдоо дээрлик мүмкүн эмес.

Репликаларды окуу

Маалыматтар базасына суроо-талаптардын саны абдан көбөйгөндө, биз жасай ала турган дагы бир нерсе, маалымат базасын башкаруу системасына окуу репликаларын кошуу. Жогоруда сүрөттөлгөн башкарылуучу кызматтар менен муну бир чыкылдатуу менен жасоого болот. Окулган реплика негизги маалымат базасында учурдагы бойдон калат жана SELECT билдирүүлөрү үчүн жеткиликтүү.

Бул жерде азыр биздин система:

мындан аркы иш-аракеттери

Колдонмонун масштабы уланып жаткандыктан, биз кызматтарды өз алдынча масштабдоо үчүн бөлүүнү улантабыз. Мисалы, эгерде биз Websockets колдоно баштасак, анда Websockets иштетүү кодун өзүнчө кызматка тартуунун мааниси бар. Биз аны жаңы инстанцияларга өзүбүздүн жүк балансташтыргычыбыздын артына жайгаштырсак болот, ал ачык Websockets туташууларынын негизинде жана HTTP сурамдарынын санына карабастан, чоңойтуп жана кичирейте алат.

Биз ошондой эле маалымат базасынын деңгээлинде чектөөлөр менен күрөшүүнү улантабыз. Дал ушул этапта маалымат базасын бөлүүнү жана бөлүүнү изилдөөгө убакыт келди. Эки ыкма тең кошумча чыгымдарды талап кылат, бирок маалымат базасын дээрлик чексиз масштабда колдонууга мүмкүндүк берет.

Биз ошондой эле New Relic же Datadog сыяктуу мониторинг жана аналитика кызматын орноткубуз келет. Бул жай сурамдарды аныктоого жана кайсы жерде жакшыртуу керектигин түшүнүүгө жардам берет. Масштабды кеңейткен сайын биз тоскоолдуктарды табууга жана аларды жоюуга көңүл бургубуз келет — көбүнчө мурунку бөлүмдөрдөгү кээ бир идеяларды колдонуу.

булактар

Бул посттун бири шыктанган жогорку масштабдуулук жөнүндө менин сүйүктүү постторум. Мен макаланы долбоорлордун баштапкы этаптары үчүн бир аз конкреттүү кылып, аны бир сатуучудан чечүүнү кааладым. Бул темага кызыксаңыз сөзсүз окуңуз.

Шилтемелер

1. Бир нече инстанциялар боюнча жүктү бөлүштүрүү жагынан окшош болсо да, Redis кластеринин негизги ишке ашырылышы жүк баланстоочудан абдан айырмаланат. [кайтуу]

Source: www.habr.com