Ръководство за оразмеряване на облачен сървър: Колко CPU, RAM и дисково пространство?

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

Финансовото въздействие на неправилното оразмеряване е значително. Нашият анализ на над 200 клиентски миграции показва, че средният бизнес прекалено оразмерява облачните ресурси с 35% до 50%, когато конфигурира сървъри без насоки, базирани на данни. При месечна сметка от 200 евро това представлява 70 до 100 евро, похарчени напразно всеки месец, над 800 до 1 200 евро годишно. Обратно, сървърите с недостатъчно ресурси причиняват проблеми с производителността, които пряко засягат приходите. За електронни магазини увеличаването на времето за зареждане на страницата с една секунда може да намали конверсиите със 7%, разход, който далеч надхвърля спестяванията от избора на по-малък сървър.

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

Ядрата на CPU определят колко операции може да изпълнява сървърът ви едновременно. Приложенията, които обработват много едновременни заявки, уеб сървърите, API крайните точки и обработката на данни в реално време, се възползват от по-голям брой ядра. Приложенията, които извършват интензивни еднонишови изчисления, видео кодирането, научните изчисления и определени операции с бази данни, се възползват повече от по-бързи отделни ядра. Разбирането кой модел следва вашето натоварване е първата стъпка при оразмеряването на CPU.

За повечето уеб приложения използването на CPU трябва да е средно между 30% и 60% при нормално натоварване, с резерв за справяне с пикове на трафика до 80%, преди производителността да се влоши. Ако средното използване на CPU е под 20%, вероятно имате прекалено много ресурси и можете безопасно да намалите оразмеряването. Ако редовно надвишава 70%, трябва да обмислите мащабиране нагоре или хоризонтално, преди потребителите да усетят забавяне. WordPress сайт, обслужващ 50 000 месечни посетители, обикновено работи комфортно с 2 vCPU. Node.js API, обработващо 500 заявки в секунда, може да се нуждае от 4 до 8 vCPU в зависимост от сложността на всяка заявка.

Съвременните облачни доставчици предлагат различни типове CPU, оптимизирани за различни натоварвания. Инстанциите, оптимизирани за изчисления, предоставят по-високи честоти и са идеални за задачи, ограничени от CPU. Инстанциите с общо предназначение балансират CPU, памет и мрежа за типични уеб натоварвания. В GRADAX по подразбиране използваме инстанции с общо предназначение за повечето клиентски внедрявания и препоръчваме изчислително оптимизирани само когато профилирането потвърди, че CPU е основното ограничение. Изборът на правилния тип CPU може да осигури 20% до 30% по-добра производителност на същата ценова точка, което си заслужава допълнителния анализ.

Паметта често е ресурсът, който определя дали едно приложение работи гладко, или се срива под натоварване. За разлика от CPU, който може да поставя работа на опашка, когато е наситен (което води до по-бавни отговори), изчерпването на RAM задейства out-of-memory killer на ядрото, който прекратява процесите рязко и може да срине цялото ви приложение. Поради тази причина препоръчваме да оразмерявате RAM с по-голям запас за сигурност в сравнение с CPU, като целите 50% до 70% средно използване, оставяйки значителен резерв за пикове на трафика и изтичане на памет.

Различните технологични стекове имат коренно различни изисквания към паметта. Статичен сайт, обслужван от Nginx, се нуждае от едва 256 MB. PHP WordPress сайт с обектно кеширане и база данни, работещи на един и същ сървър, изискват 2 до 4 GB. Java Spring Boot приложение с вградена Elasticsearch инстанция може да изисква 8 до 16 GB. Node.js приложенията са по средата, като обикновено изискват 1 до 4 GB на процес в зависимост от размера на полезния товар и броя на едновременните връзки. При споделен сървър между няколко услуги сумирайте индивидуалните им изисквания и добавете 20% резерв за операционната система и фоновите процеси.

Сървърите за бази данни заслужават специално внимание при определяне на RAM капацитета. Базите данни работят драстично по-добре, когато работният им набор, данните, които се заявяват активно, се побира изцяло в паметта. MySQL база данни с работен набор от 5 GB, работеща на сървър с 4 GB RAM, ще чете постоянно от диска, което води до това времето за изпълнение на заявки, измервано в милисекунди, да се увеличава до десетки или повече милисекунди. Същата база данни с 8 GB RAM поддържа работния набор в кеша, осигурявайки последователни четения под милисекунда. За отделни сървъри за бази данни препоръчваме като отправна точка да заделяте 1,5x до 2x размера на работния набор в RAM.

Облачното съхранение се предлага в три основни нива: NVMe SSD, стандартен SSD и блоково съхранение на базата на HDD. NVMe SSD дисковете предлагат най-висока производителност със скорости на четене над 3 000 MB/s и стотици хиляди случайни I/O операции в секунда. Стандартните SSD предлагат баланс между производителност и цена, като обикновено осигуряват пропускателна способност от 500 до 1 000 MB/s. Съхранението на базата на HDD е най-достъпното, но въвежда значително забавяне при случайно четене, което го прави подходящо само за архивни данни, логове и последователни натоварвания като резервни копия.

При определяне на капацитета за съхранение започнете с текущия обем данни и прогнозирайте растежа за следващите 12 до 18 месеца. Типичен WordPress сайт с медийна библиотека се нуждае от 5 до 20 GB. Електронна търговска платформа с продуктови изображения може да има нужда от 50 до 200 GB. SaaS приложение с потребителско генерирано съдържание може да расте непредвидимо и ползва от мащабируемо съхранение, което позволява разширяване без прекъсване на услугата. Винаги запазвайте поне 20% свободно пространство на всеки том; файловите системи и базите данни губят производителност, когато наближат максималния си капацитет, а изчерпването на дисковото пространство е една от най-честите причини за непланирани прекъсвания.

IOPS (Input/Output Operations Per Second) е метриката за съхранение, която оказва най-голямо влияние върху производителността на приложението, но често се пренебрегва при оразмеряването. Приложение с интензивна работа с бази данни може да се нуждае от 3 000 до 10 000 IOPS, за да поддържа приемлива производителност на заявките. Сайт с много съдържание и предимно операции по четене може да се нуждае само от 500 IOPS. Много облачни доставчици обвързват IOPS с размера на тома; том от 100 GB може да бъде ограничен до 3 000 IOPS, докато том от 500 GB получава 15 000. Това означава, че понякога трябва да осигурите повече място за съхранение, отколкото ви е необходимо, единствено за да получите достатъчно IOPS, нюанс, който изненадва много нови потребители на облачни технологии.

Мрежовата честотна лента определя колко данни вашият сървър може да изпраща и получава в секунда. При уеб приложенията изходящата честотна лента обикновено е тясното място, тъй като сървърите изпращат много повече данни към потребителите, отколкото получават. Страница с размер 2 MB, обслужвана към 100 едновременни потребители, изисква 200 MB/s изходяща честотна лента в пикови моменти. CDN пред вашия сървър намалява това натоварване драстично чрез кеширане на статичните ресурси на крайни възли, но динамичното съдържание все още трябва да се зарежда от вашия основен сървър.

Повечето облачни доставчици включват базова квота за честотна лента към всеки размер на инстанцията и таксуват допълнително за превишаване на този лимит. В GRADAX нашите планове за уеб хостинг включват щедри лимити за честотна лента, защото сме установили, че неочакваните такси за трафик са една от най-големите изненади в сметките за новите потребители на облак. Препоръчваме да следите месечната си консумация на честотна лента през първите три месеца и да настроите известие при достигане на 80% от лимита, за да избегнете неприятни изненади в края на месеца. За сайтове с много медии или приложения, които предоставят големи файлове за изтегляне, включете разходите за честотна лента в решението си за оразмеряване заедно с CPU, RAM и съхранение.

Мрежовото закъснение е също толкова важно, особено за географски разпръснати аудитории. Сървър във Франкфурт осигурява закъснение под 20ms за потребители в Централна Европа, но 150ms или повече за потребители в Азиатско-тихоокеанския регион. Ако аудиторията ви обхваща няколко континента, едно местоположение на сървъра няма да осигури последователно изживяване. Разгръщането в няколко региона или CDN с кеширане на крайни локации е от съществено значение. Обикновено препоръчваме да започнете с един регион, най-близо до по-голямата част от потребителската ви база, и да разширите към допълнителни региони само когато данните за производителността оправдаят добавената сложност и разходи.

За WordPress сайтове с до 100 000 месечни посетители препоръчваме да започнете с 2 vCPU, 4 GB RAM и 40 GB NVMe SSD съхранение. Тази конфигурация се справя удобно с WordPress, MySQL, Redis обектен кеш и Nginx с резерв за пикове в трафика. Магазините на WooCommerce с активни наличности трябва да добавят допълнителни 2 GB RAM и да обмислят отделна инстанция за база данни, след като трафикът надхвърли 200 000 месечни посетители или продуктовият каталог надхвърли 10 000 артикула.

Node.js приложенията варират значително в зависимост от архитектурата си. Обикновен Express.js API, обслужващ JSON отговори, работи ефективно на 1 vCPU и 1 GB RAM при умерен трафик. Next.js приложение със сървърно рендиране изисква 2 до 4 vCPU и 2 до 4 GB RAM, тъй като всяко рендиране е интензивно за CPU. Приложенията в реално време, използващи WebSockets, се нуждаят от повече памет за поддържане на постоянни връзки, предвидете приблизително 10 KB RAM на едновременна връзка, което означава, че 100 000 едновременни връзки изискват около 1 GB RAM само за състоянието на връзките, плюс това, което изисква логиката на приложението.

Платформите за електронна търговия с инфраструктура от специализирани сървъри имат най-взискателните изисквания поради комбинацията от динамично рендиране на страници, заявки към базата данни за продуктови каталози и наличности, обработка на количка и плащане в реално време и обслужване на изображения. Средно голям сайт за електронна търговия, обслужващ 500 000 месечни посетители, обикновено се нуждае от 4 до 8 vCPU, 8 до 16 GB RAM, 100 GB или повече SSD съхранение и отделен сървър за база данни с поне 8 GB RAM. По време на пикови събития като флаш разпродажби или празнични промоции тези изисквания могат да се удвоят или утроят, което прави възможностите за автоматично мащабиране от съществено значение.

Вертикалното мащабиране означава добавяне на повече CPU, RAM или съхранение към съществуващ сървър. Хоризонталното мащабиране означава добавяне на повече сървъри зад балансьор на натоварването. Всеки подход има компромиси, които трябва да информират решението ви. Вертикалното мащабиране е по-просто: без промени в архитектурата на приложението, без конфигурация на балансьор на натоварването, без грижи за управление на сесии. То работи добре за бази данни, монолитни приложения и натоварвания, които трудно се разпределят между множество възли.

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

Общата ни препоръка е първо да мащабирате вертикално, докато достигнете естествен таван, обикновено около 8 до 16 vCPU и 32 до 64 GB RAM, и след това да мащабирате хоризонтално. Този подход минимизира оперативната сложност, докато натоварването ви е достатъчно малко, за да се побере на една машина. След като надхвърлите вертикалното мащабиране, инвестирайте в архитектурните промени, необходими за хоризонтално мащабиране, което ще ви служи добре, докато трафикът продължава да расте. Свържете се с нашия екип по инфраструктура за персонализирана оценка на оразмеряването въз основа на специфичните характеристики на вашето натоварване.

Първоначалното оразмеряване е обоснована оценка. Оптималното оразмеряване е продължителна практика за коригиране на ресурсите въз основа на действителни данни за използването. Препоръчваме да събирате поне две седмици метрики за производителността, преди да правите корекции в оразмеряването, и в идеалния случай четири до шест седмици, за да обхванете седмичните цикли на трафика, месечните циклични фактурирания и всякакви сезонни вариации. Ключовите метрики за проследяване включват средно и пиково използване на CPU, използване на паметта и активност на swap, време за изчакване на дискови I/O операции и мрежова пропускателна способност.

Инструментите за автоматизирано оптимално оразмеряване могат да анализират моделите на използване и да препоръчат оптимизации. В GRADAX нашата платформа за мониторинг маркира инстанции, при които средното използване на CPU остава под 20% за повече от 14 последователни дни, което показва потенциално свръхосигуряване. Тя също предупреждава, когато който и да е ресурс постоянно надвишава 75% използване, което сигнализира, че трябва да се планира събитие за вертикално или хоризонтално мащабиране, преди производителността да се влоши. Тези предупреждения помогнаха на нашите клиенти да намалят разходите си за инфраструктура средно с 28% в рамките на първите шест месеца на мониторинг.

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