Изграждане на мащабируема облачна инфраструктура за развиващи се бизнеси

Когато започнахме да предлагаме управляван хостинг и облачни услуги в GRADAX, повечето ни клиенти работеха с предвидими натоварвания. Сайтът на местен ресторант получаваше постоянен трафик, може би малък пик през уикендите. Портфолиото на счетоводителя едва забележимо влияеше на сървърните ресурси. Осигурявахме капацитет консервативно и това работеше. Но когато започнахме да обслужваме марки за електронна търговия, SaaS стартъпи и медийни издания, моделите на трафика станаха изключително непредвидими.

Един от нашите клиенти, румънски пазар за мода, проведе флаш разпродажба, която генерира 14 пъти нормалния им трафик за под деветдесет секунди. Предишният им доставчик на хостинг не издържа. На следващия ден дойдоха при нас с искане за гаранция, че това никога повече няма да се случи. Този единствен разговор ни принуди да преосмислим цялата си инфраструктурна философия. Вече не можехме да проектираме за средни стойности, трябваше да проектираме за крайности.

Основното предизвикателство беше тройно: да поемаме внезапни пикове в трафика без ръчна намеса, да поддържаме разумни разходи в спокойни периоди и да запазим времена за отговор под 200 мс за европейска и глобална аудитория. Решаването на всяко едно от тях поотделно е лесно. Решаването и на трите едновременно изискваше фундаментално различна архитектура.

Оценихме няколко подхода, преди да се спрем на текущия си стек. Напълно serverless архитектурата беше изкушаваща, но въвеждаше закъснения при студен старт, които нарушаваха целите ни за производителност, особено за рендираните на сървъра Next.js приложения, на които клиентите ни разчитат. Традиционната настройка с виртуални машини ни даваше контрол, но ѝ липсваше еластичността, от която се нуждаехме. Спряхме се на хибриден модел: базова отделена изчислителна мощност, подкрепена от пулове от облачни сървъри по заявка, които могат да се стартират за под четири секунди.

Нашата контролна равнина работи на Kubernetes, оркестрирайки натоварванията в множество зони за достъпност във всеки регион на центъра за данни. Приложението на всеки клиент е контейнеризирано със стандартизиран образ на средата за изпълнение, който включва нашия агент за мониторинг, препращач на логове и крайна точка за проверка на състоянието. Тази еднородност прави автоматичното мащабиране възможно, всеки контейнер е взаимозаменяем, така че оркестраторът може да добавя или премахва инстанции, без да се тревожи за специфични за средата особености.

За слоя с данни възприехме стратегия за многостепенно съхранение. Горещите данни живеят на NVMe SSD дискове с репликация между два възела. Топлите данни се преместват на стандартни SSD дискове след седем дни. Студените данни се архивират в обектно хранилище след тридесет. Само това намали разходите ни за съхранение с 40% без забележимо влияние върху производителността за клиентите.

Автоматичното мащабиране звучи просто на теория: когато търсенето се увеличи, добавяме капацитет; когато намалее, го премахваме. На практика времето и праговете имат огромно значение. Ако мащабирате твърде късно, потребителите се сблъскват с грешки. Ако мащабирате твърде рано, харчите пари за неизползвани ресурси. Прекарахме три месеца в настройка на политиките си за мащабиране, преди да се почувстваме достатъчно уверени да ги пуснем в продукция без човешки надзор.

Системата ни използва модел за прогнозно мащабиране, надграден върху реактивни тригери. Прогнозният слой анализира исторически модели на трафика, ден от седмицата, час от денонощието, сезонни тенденции и известни събития като пускане на продукти или маркетингови кампании, които клиентите планират през нашото табло. Той осигурява капацитет предварително петнадесет минути преди очакваното търсене. Реактивният слой следи метрики в реално време: натоварване на процесора, натиск върху паметта, дълбочина на опашката от заявки и P95 латентност на отговора. Ако някоя метрика премине прага си, нови контейнери се стартират за секунди.

Също така изградихме собствен механизъм за охлаждане. След като пикът отшуми, не премахваме веднага допълнителния капацитет. Вместо това го задържаме за конфигурируем период (по подразбиране: десет минути), защото пиковете в трафика често идват на вълни. Това предотвратява скъпото превключване на контейнери нагоре и надолу по време на продължителни събития с висок трафик като Black Friday или вирусни моменти в социалните мрежи.

Балансирането на натоварването в GRADAX работи на две нива. Външното ниво е глобална anycast мрежа, която насочва потребителите към най-близкия център за данни въз основа на латентност, а не само на география. Потребител в Мюнхен може да бъде насочен към нашия възел във Франкфурт или към този в Амстердам в зависимост от условията на мрежата в реално време. Това решение се преоценява на всеки шестдесет секунди чрез активни проверки на състоянието, изпращани от всяка крайна локация.

Вътрешното ниво разпределя трафика между контейнерите в рамките на центъра за данни. Отказахме се от простото кръгово разпределение още в началото, защото то не отчита състоянието на контейнера или текущото натоварване. Нашият балансьор използва алгоритъм за най-малко връзки с тегла, който взема предвид текущия брой заявки на всеки контейнер, натоварването на процесора и скорошния процент грешки. Контейнерите, които се затрудняват, получават по-малко заявки, което им дава време да се възстановят, без да бъдат напълно извадени от ротацията.

Също така внедрихме източване на връзки за плавно спиране. Когато автоматичният мащабиращ механизъм реши да премахне контейнер, първо спира да изпраща нови връзки към него, след което изчаква до тридесет секунди съществуващите заявки да завършат. Това елиминира 502 грешките, които тормозеха по-ранните ни итерации при събития за намаляване на мащаба.

Облачната инфраструктура може да стане скъпа бързо, особено когато управлявате автоматично мащабиране в множество региони. Възприехме дисциплиниран подход към управлението на разходите от първия ден, третирайки разходите за инфраструктура като продуктова метрика, също толкова важна колкото времето за работа или латентността. Всяко архитектурно решение преминава през преглед на влиянието върху разходите, преди да достигне до производство.

Най-големите ни спестявания дойдоха от правилното оразмеряване. Изградихме инструмент за анализ, който взема проби от използването на ресурсите на контейнерите за четиринадесетдневни периоди и препоръчва оптимални разпределения на процесор и памет. Повечето клиенти бяха с надценен капацитет с 30-50% спрямо първоначалните ни оценки. След правилното оразмеряване намалихме базовите изчислителни разходи с 35% в целия парк. Също така договорихме споразумения за резервиран капацитет с нашите доставчици за базовото натоварване, фиксирайки цени с 45% под тези по заявка.

За клиенти, които искат максимална разходна ефективност, предлагаме ниво „burstable“, което работи на споделена инфраструктура в нормални часове и се мащабира към отделени ресурси само в пикови периоди. Това ниво струва с 60% по-малко от стандартната ни оферта и е идеално за бизнеси с предвидими периоди на нисък трафик, като B2B SaaS продукти, които почти не се използват извън работно време.

Не можете да управлявате това, което не можете да измерите, а в разпределена система с автоматично мащабиране видимостта е всичко. Изградихме стека си за наблюдаемост около три стълба: метрики, логове и трасировки. Всеки контейнер излъчва структурирани метрики на петсекундни интервали, обхващащи процесор, памет, дискови I/O операции, мрежова пропускателна способност, брой заявки, процент грешки и персентили на латентност на отговора. Те се вливат в база данни за времеви редове, която съхранява данни с висока резолюция за седем дни и понижени данни за тринадесет месеца.

Разпределеното проследяване беше частта, която отне най-дълго да се направи правилно, но донесе най-голяма стойност. Всяка входяща заявка получава идентификатор на трасировка, който я следва през балансьора на натоварването, контейнера на приложението, слоя за кеширане и базата данни. Когато клиент съобщи за бавно зареждане на страници, можем да извадим точната трасировка и да видим точно къде е изразходвано време. В девет от десет случая тесното място е неоптимизирана заявка към базата данни или липсващ кеш ключ, не инфраструктурата.

Системата ни за известяване използва многостепенни нива на сериозност, обвързани с бизнес влиянието, а не само с технически прагове. В комбинация с нашия мониторинг за сигурност на уебсайта, един контейнер с висока температура е информационно. Продължителен процент грешки над 1% в парка на клиент е предупреждение. Всяко падане на наличността под 99,9% за петминутен период веднага вика дежурния инженер. Този подход намали шума от известия със 70% в сравнение с първоначалната ни система, базирана на прагове.

След осемнадесет месеца работа на тази архитектура в реална среда числата говорят сами за себе си. Поддържахме 99,97% време на работа за всички клиентски натоварвания, включително по време на три големи събития с трафик, всяко от които надхвърли 50 пъти базовото натоварване. Платформата обработи над 2,8 милиарда заявки само през последното тримесечие, с глобално време за отговор P95 от 142 милисекунди. Нито един клиент не претърпя прекъсване поради проблеми с мащабирането.

От гледна точка на разходите, нашите клиенти спестяват общо около 40% в сравнение с еквивалентни конфигурации при големите публични доставчици на облачни услуги. Системата за автоматично мащабиране предотврати ненужни разходи за изчислителни ресурси в размер на около 180 000 евро през миналата година, като намаляваше капацитета в часовете с нисък трафик, вместо да работи на пълна мощност 24/7. При нашия клиент в модната търговия, този, чиято разпродажба с ограничено време започна цялото това пътуване, месечната сметка за инфраструктура спадна с 52% след преминаването към нашата платформа, въпреки че обслужва 3 пъти повече трафик от преди.

Оперативните подобрения бяха също толкова значителни. Средното време за откриване на проблеми с производителността спадна от 12 минути на под 90 секунди. Средното време за отстраняване намаля от 45 минути на средно 8 минути. Нашият екип по инфраструктура, който преди отделяше 60% от времето си за реактивно решаване на проблеми, сега отделя 80% от времето си за проактивни подобрения и разработване на нови функционалности.

Още не сме приключили. Следващата фаза от пътната карта на нашата облачна инфраструктура се фокусира върху три области: изчисления на ръба, планиране на капацитета с помощта на изкуствен интелект и планиране съобразно въглеродния отпечатък. В момента тестваме възли за изчисления на ръба в дванадесет допълнителни града, което би позволило натоварвания, чувствителни към закъснението, като оптимизация на изображения и отговори на API, да работят по-близо до крайните потребители. Първоначалните тестове показват 40% намаление на закъснението P99 за потребители на повече от 1000 километра от най-близкия ни център за данни.

Що се отнася до изкуствения интелект, обучаваме модел за прогнозиране на капацитета върху две години исторически данни от всички клиентски натоварвания. Целта е да се прогнозират моделите на трафика 24 часа предварително с достатъчна увереност, за да се осигури капацитет преди пиковете, елиминирайки дори краткото увеличаване на закъснението, което се случва при реактивно мащабиране. Първоначалните резултати са обещаващи, моделът постига 89% точност при прогнозиране на пиковия трафик за следващия ден.

Накрая, проучваме планиране съобразно въглеродния отпечатък, което би преместило несрочни натоварвания като резервни копия, пакетна обработка и предварително рендиране към моменти, когато местната електроенергийна мрежа има най-висок дял възобновяема енергия. Това е в съответствие с нашия по-широк ангажимент към устойчива инфраструктура и дава на клиентите ни с екологично съзнание конкретен показател, на който могат да се позоват. Ако искате да научите как тези подобрения могат да бъдат от полза за Вашия бизнес, свържете се с нашия екип. Очакваме да пуснем и трите възможности преди края на 2026 г.