Многи стартапови су прошли кроз ово: гомиле нових корисника се региструју сваког дана, а развојни тим се бори да одржи услугу.

Леп је проблем имати, али на вебу има мало јасних информација о томе како пажљиво скалирати веб апликацију од ничега до стотина хиљада корисника. Обично постоје или решења за пожар или решења за уско грло (а често и једно и друго). Стога, људи користе прилично клишеиране технике како би свој аматерски пројекат претворили у нешто заиста озбиљно.

Покушајмо да филтрирамо информације и запишемо основну формулу. Наш нови сајт за дељење фотографија Граминста повећаћемо корак по корак са 1 на 100 корисника.

Хајде да запишемо које конкретне акције треба предузети када се публика повећа на 10, 100, 1000, 10 и 000 људи.

1 корисник: 1 машина

Скоро свака апликација, било да је веб локација или мобилна апликација, има три кључне компоненте:

• АПИ за
• база података
• клијент (сам мобилна апликација или веб локација)

База података чува трајне податке. АПИ служи захтеве за и око ових података. Клијент преноси податке кориснику.

Дошао сам до закључка да је много лакше говорити о скалирању апликације ако су, са архитектонске тачке гледишта, клијент и АПИ ентитети потпуно раздвојени.

Када први пут почнемо да правимо апликацију, све три компоненте се могу покренути на истом серверу. На неки начин, ово је слично нашем развојном окружењу: један инжењер покреће базу података, АПИ и клијента на истој машини.

У теорији, могли бисмо да га применимо у облаку на једној ДигиталОцеан Дроплет или АВС ЕЦ2 инстанци, као што је приказано у наставку:

С тим у вези, ако ће на сајту бити више корисника, скоро увек има смисла посветити слој базе података.

10 корисника: премештање базе података на посебан ниво

Подела базе података на управљане услуге као што су Амазон РДС или Дигитал Оцеан Манагед Датабасе ће нам дуго служити. То је мало скупље од самосталног хостовања на једној машини или ЕЦ2 инстанци, али са овим услугама добијате много корисних екстензија из кутије које ће вам добро доћи у будућности: резервне копије за више региона, реплике читања, аутоматске резервне копије и још много тога.

Овако систем сада изгледа:

100 корисника: померање клијента на посебан ниво

Срећом, нашим првим корисницима се наша апликација заиста допала. Саобраћај постаје све стабилнији, па је време да се клијент премести на посебан ниво. Треба напоменути да је раздвајање ентитети је кључни аспект изградње скалабилне апликације. Пошто један део система прима више саобраћаја, можемо га поделити да бисмо контролисали како се услуга скалира на основу специфичних образаца саобраћаја.

Због тога волим да мислим о клијенту одвојеном од АПИ-ја. Ово чини веома лаким размишљање о развоју за више платформи: веб, мобилни веб, иОС, Андроид, десктоп апликације, услуге трећих страна, итд. Сви су они само клијенти који користе исти АПИ.

На пример, сада наши корисници најчешће траже да издају мобилну апликацију. Ако одвојите клијента и АПИ ентитете, ово постаје лакше.

Овако изгледа такав систем:

1000 корисника: додајте балансер оптерећења

Ствари се поправљају. Корисници Граминста постављају све више фотографија. Расте и број регистрација. Наш усамљени АПИ сервер има потешкоћа да прати сав саобраћај. Треба још гвожђа!

Балансатор оптерећења је веома моћан концепт. Кључна идеја је да ставимо балансер оптерећења испред АПИ-ја и он дистрибуира саобраћај на појединачне инстанце услуге. Овако скалирамо хоризонтално, што значи да додајемо више сервера са истим кодом, повећавајући број захтева које можемо да обрадимо.

Поставићемо одвојене балансере оптерећења испред веб клијента и испред АПИ-ја. То значи да можете покренути више инстанци са АПИ кодом и кодом веб клијента. Балансатор оптерећења ће усмерити захтеве ка серверу који је мање оптерећен.

Овде добијамо још једну важну предност - редундантност. Када једна инстанца не успе (можда је преоптерећена или срушена), остају нам друге које настављају да одговарају на долазне захтеве. Ако би радила само једна инстанца, онда би се у случају квара цео систем срушио.

Балансатор оптерећења такође омогућава аутоматско скалирање. Можемо да га конфигуришемо да повећа број инстанци пре највећег оптерећења и да га смањи када сви корисници спавају.

Са балансатором оптерећења, ниво АПИ-ја се може скалирати скоро неограничено, једноставним додавањем нових инстанци како се број захтева повећава.

Белешка. Тренутно је наш систем веома сличан ономе што ПааС компаније као што су Хероку или Еластиц Беансталк на АВС нуде из кутије (због чега су толико популарне). Хероку поставља базу података на посебан хост, управља балансом оптерећења са аутоматским скалирањем и омогућава вам да хостујете веб клијент одвојено од АПИ-ја. Ово је одличан разлог да користите Хероку за пројекте у раној фази или стартапе - добијате све основне услуге из кутије.

10 корисника: ЦДН

Можда је то требало да урадимо од самог почетка. Обрада захтева и прихватање нових фотографија почиње да оптерећује наше сервере.

У овој фази, потребно је да користите услугу у облаку за складиштење статичког садржаја – слика, видео записа и још много тога (АВС С3 или Дигитал Оцеан Спацес). Генерално, наш АПИ би требало да избегава руковање стварима као што су сервирање слика и отпремање слика на сервер.

Још једна предност хостинга у облаку је ЦДН (АВС овај додатак назива Цлоудфронт, али многи добављачи складиштења у облаку га нуде одмах). ЦДН аутоматски кешира наше слике у различитим центрима података широм света.

Иако се наш главни центар података може налазити у Охају, ако неко затражи слику из Јапана, добављач у облаку ће направити копију и сачувати је у свом јапанском центру података. Следећа особа која затражи ову слику у Јапану добиће је много брже. Ово је важно када радимо са великим датотекама, попут фотографија или видео записа, чије преузимање и пренос широм планете траје дуго.

100 корисника: скалирање слоја података

ЦДН је много помогао: саобраћај расте пуном брзином. Чувени видео блогер Мавид Мобрицк управо се регистровао код нас и објавио своју „причу“, како кажу. Захваљујући балансеру оптерећења, употреба ЦПУ-а и меморије на АПИ серверима је ниска (покренуто је десет АПИ инстанци), али почињемо да добијамо много тајм-аута на захтеве... одакле ова кашњења долазе?

Копајући мало у метрику, видимо да је ЦПУ на серверу базе података оптерећен 80-90%. На граници смо.

Скалирање слоја података је вероватно најтежи део једначине. АПИ сервери служе захтевима без стања, тако да једноставно додајемо још АПИ инстанци. Носе већина базе података то не могу учинити. Говорићемо о популарним системима за управљање релационим базама података (ПостгреСКЛ, МиСКЛ, итд.).

кеширање

Један од најлакших начина за повећање перформанси наше базе података је увођење нове компоненте: слој кеша. Најчешћи метод кеширања је складиште записа кључ/вредност у меморији, као што су Редис или Мемцацхед. Већина облака има управљану верзију ових услуга: Еластицацхе на АВС-у и Мемористоре на Гоогле Цлоуд-у.

Кеш меморија је корисна када услуга упућује много поновљених позива бази података да би преузела исте информације. У суштини, бази података приступамо само једном, чувамо информације у кешу и не додирујемо је поново.

На пример, у нашем Граминста сервису, сваки пут када неко оде на страницу профила звезде Мобрик, АПИ сервер пита базу података за информације са његовог профила. Ово се дешава изнова и изнова. Пошто се информације о Мобриковом профилу не мењају са сваким захтевом, одличне су за кеширање.

Резултате из базе података у Редис-у ћемо кеширати по кључу user:id са роком важења од 30 секунди. Сада, када неко оде на Мобриков профил, прво проверавамо Редис, а ако су подаци тамо, једноставно их преносимо директно из Редиса. Сада захтеви за најпопуларнији профил на сајту практично не учитавају нашу базу података.

Још једна предност већине услуга кеширања је то што их је лакше скалирати од сервера базе података. Редис има уграђен Редис Цлустер режим. Слично балансеру оптерећења1, омогућава вам да дистрибуирате Редис кеш на више машина (на хиљаде сервера ако је потребно).

Скоро све апликације великих размера користе кеширање; оно је апсолутно саставни део брзог АПИ-ја. Бржа обрада упита и продуктивнији код су важни, али без кеш меморије скоро је немогуће проширити услугу на милионе корисника.

Прочитајте реплике

Када се број упита бази података увелико повећа, још једна ствар коју можемо да урадимо је да додамо реплике читања у систем за управљање базом података. Са горе описаним управљаним услугама, то се може урадити једним кликом. Реплика за читање ће остати актуелна у главној бази података и доступна је за СЕЛЕЦТ наредбе.

Ево нашег система сада:

Следећи кораци

Како апликација наставља да се повећава, наставићемо да одвајамо услуге да бисмо их скалирали независно. На пример, ако почнемо да користимо Вебсоцкетс, онда има смисла превући код за обраду Вебсоцкетс-а у засебну услугу. Можемо га поставити на нове инстанце иза нашег сопственог балансера оптерећења, који може да се повећава и смањује на основу отворених Вебсоцкетс веза и без обзира на број ХТТП захтева.

Такође ћемо наставити да се боримо против ограничења на нивоу базе података. У овој фази је време да се проучи партиционисање и дељење базе података. Оба приступа захтевају додатне трошкове, али вам омогућавају да скалирате базу података скоро неограничено.

Такође желимо да инсталирамо сервис за праћење и анализу као што је Нев Релиц или Датадог. Ово ће вам помоћи да идентификујете споре упите и разумете где је потребно побољшање. Како скалирамо, желимо да се фокусирамо на проналажење уских грла и њихово елиминисање — често користећи неке од идеја из претходних одељака.

izvori

Овај пост је инспирисан једним од моји омиљени постови о високој скалабилности. Желео сам да учиним чланак мало конкретнијим за почетне фазе пројеката и одвојим га од једног добављача. Обавезно прочитајте ако сте заинтересовани за ову тему.

Фусноте

1. Иако слична у погледу расподеле оптерећења на више инстанци, основна имплементација Редис кластера се веома разликује од балансера оптерећења. [повратак]

Извор: ввв.хабр.цом