High Load

Деректер базасы баяулап, сервер шамадан тыс жүктелгенде

Сайтқа келушілердің немесе деректер базасының көлемі миллиондаған жазбаларға жеткенде, стандартты әзірлеу әдістері төтеп бере алмайды. Беттер бірнеше секунд бойы жүктеле бастайды, сервер процессоры 100%-ға жүктеледі, деректер базасы кестелерді бұғаттайды, ал пайдаланушылар 504 Gateway Timeout қателерін көреді.

Қымбатырақ серверді жай ғана сатып алу мәселені уақытша ғана шешеді — оңтайландырылмаған сұраулар өте нашар масштабталады. Біз жоғары жүктемелі (Highload) жүйелерді архитектура және код деңгейінде оңтайландырамыз. Біз баяу сұраулар логтарын (Slow Query Log) талдаймыз, тиімді индекстер базасын құрамыз, ауыр SQL-сұрауларды қайта жазамыз және оперативті жадта кэштеуді (Redis, Memcached) іске қосамыз.

Терабайттаған деректері бар жобалар үшін біз үлестірілген архитектураларды енгіземіз: оқу және жазу ағындарын бөлу үшін деректер базасын репликациялау (Master-Slave), сондай-ақ көлденең масштабтау (шардинг).

  • Дерекқорлардың (MySQL, PostgreSQL, MongoDB, ClickHouse) өнімділік аудиті
  • Дерекқор құрылымын оңтайландыру, қалыпқа келтіру/денормализациялау және индекстер
  • Redis көмегімен жедел жадта «ауыр» деректерді кэштеу
  • Дерекқор репликациясын баптау (Read/Write ағындарын код деңгейінде бөлу)
  • Серверлік бэкенд-кодты профильдеу (PHP, Node.js, Python, Go)

100x

Индекстерді оңтайландырғаннан кейін баяу SQL-сұрауларын орындау уақытын жылдамдату

10K+

RPS (секундына сұраныс) — оңтайландырылған базаның мақсатты өнімділігі

<50 мсек

Кэштелген режимде ең жоғары жүктеме кезінде бэкендтегі API жауап беру уақыты

10 млн supreme

Деректер жолдары — оңтайландыру аясында біз жұмыс істейтін кестелердің ең аз көлемі

Темірді көбейтпеңіз — алгоритмдерді оңтайландырыңыз

Кірістірілген циклдары бар оңтайлы емес SQL-сұранысы база өскен сайын экспоненциалды түрде баяу орындала бастайды. Біз таза, жылдам бэкенд кодын жазамыз және дұрыс индекстерді баптаймыз, осылайша серверді жалға алу шығыныңызды үнемдейміз.

Біздің әдіс

Бэкендтің жылдам жұмыс істеуіне апаратын үш қадам

Біз жүйелік метрикаларға егжей-тегжейлі зерттеу жүргізіп, тар жерлерді оңтайландырамыз.

Бэкенд-кодты профильдеу

Мамандандырылған профайлерлерді (Blackfire, Xdebug, V8 Profiler) пайдалана отырып, біз серверлік скрипттердің жұмысын миллисекундтар бойынша талдаймыз. «Ауыр» функцияларды, жедел жадтың жылыстауын және артық циклдарды табамыз.

Серверлік кодтың өзін оңтайландыру процессорға (CPU) түсетін жүктемені бірнеше есе азайтуға мүмкіндік береді.

Жедел жадта кэштеу

Дәстүрлі қатты дискілерге және ДББЖ-ге сұраулар салыстырмалы түрде ұзақ орындалады. Біз Redis/Memcached — жедел жадтағы дерекқорларды баптаймыз. «Ыстық» және сирек өзгеретін деректер миллисекундтың үлестерінде беріледі.

Сервер негізгі дерекқорға хабарласпай-ақ, кэштелген бетті немесе блокты бірден береді.

Репликация және ағындарды бөлу

Бір уақытта жазу және оқу кезінде дерекқор кестелерді блоктай алады (Database locks). Біз репликацияны баптаймыз: негізгі сервер (Master) жазу үшін деректерді қабылдайды, ал көшірме серверлер пулы (Slaves) оқу үшін деректерді береді.

Бұл өзара блоктарды алып тастайды және оқу жүктемесін машиналар арасында бөледі.

Кезеңдер

Highload оңтайландыру қалай өтеді

Логтарды жинаудың, сұраныстарды жөндеудің, кэшті баптаудың және жүктемелік тесттердің дәйекті процесі.

01

Slow Query логтарын жинау және талдау

Баяу SQL-сұраныстарды мониторингтеуді қосамыз. Орындалу уақыты 100 мс-тан асатын сұраныстарды анықтаймыз. ДБ-ға түсетін жүктеме картасын құрамыз.

02

Индекстер мен құрылымды оңтайландыру

Сұраныстарды орындау жоспарларын (EXPLAIN) талдаймыз. Құрама индекстерді қосамыз, кестелерді толық сканерлеуді (Full Table Scan) жоямыз, JOIN-қосылыстарды оңтайландырамыз.

03

Серверлік кодты профильдеу

Бэкенд кодын профильдеуді іске қосамыз. Жадтың ағуын, деректерді өңдеудің тиімсіз алгоритмдерін іздейміз, ішкі циклдерді оңтайландырамыз.

04

Redis кэшін интеграциялау

Кэштеу схемасын жобалаймыз: сайттың статикалық блоктары, тауарлар тізімі, мәзірі үшін кэш-асайд (cache-aside). Өмір сүру уақытын (TTL) және кэшті жарамсыз етуді баптаймыз.

05

ДББЖ конфигурациясын баптау

СУБД конфигурациялық файлдарын (my.cnf, postgresql.conf) дәл баптаймыз: жадтың буферлік пулын, қосылымдар кэшін және дискіге жазу параметрлерін бөлу.

06

Жүктемелі стресс-тестілеу

k6/wrk утилиталары арқылы біз мыңдаған пайдаланушылардың ең жоғарғы ағынын имитациялаймыз. Жауап беру уақытының тұрақтылығын, CPU тұтынуын өлшейміз және нәтижені сандармен дәлелдейміз.

Біздің стек

Highload-әзірлеу құралдарының стегі

Біз дерекқорларды профильдеу және кэштеудің озық бағдарламалық қамтамасыз етуін қолданамыз.

Blackfire.io & Xdebug

Кодтың үздік профайлерлері. Інтерактивті «шақыру карталарын» (Call Graphs) ұсынады, бұл PHP немесе Node.js-тің қай жолы процессор ресурстарын алып жатқанын айқын көруге мүмкіндік береді.

Redis & Sentinel / Cluster

ЖЖҚ-дағы аса жылдам кэш-қойма. Ауыр сұраныстардың нәтижелерін, пайдаланушы сессияларын және токендерді сақтау үшін қолданылады, сұраныстарға микросекундтар ішінде жауап береді.

k6.io & wrk

Жүктемелік тестілеуді өткізуге арналған заманауи бағдарламалық қамтамасыз ету. Мыңдаған ағынға асинхронды HTTP-сұрауларын жасайды, бұл бэкендтің шекті төзімділігін бағалауға мүмкіндік береді.

Тарифтер

Дерекқорлар мен бэкендті оңтайландыру тарифтері

Бағасы дерекқор өлшеміне, серверлік логиканың күрделілігіне және талап етілетін RPS көрсеткішіне байланысты.

Мүмкіндіктер SQL және индекстерді оңтайландыру Дерекқорды тазарту және баяу сұраныстарды жеделдету 60 000 ₽ Мерзімі: 7 күнге дейін Тапсырыс беру Танымал Кэштеу және код Redis интеграциясы, бэкенд кодын профильдеу 95 000 ₽ Мерзімі: 14 күнге дейін Тапсырыс беру Highload архитектурасы Дерекқор репликациясы, кілтке дейін көлденең масштабтау 180 000 ₽-ден бастап Мерзімі: 20 күннен бастап Талқылау
Оңтайландырылатын SQL-сұраныстардың саны 30 ауыр сұранысқа дейін 70 сұранымға дейін + кэштеу ДҚ құрылымы мен сұрауларын толық қайта өңдеу
Redis-кэштеуді интеграциялау Блоктарды базалық кэштеу Redis Sentinel үлестірілген кэші
Бэкенд кодын профильдеу (Blackfire / Node) Базалық профильдеу Тар жерлерді терең рефакторингтеу
Репликацияны баптау (Master-Slave) Read/Write ағындарын бөлу
Стресс-тестілеу (k6 / wrk) 1 000 RPS дейінгі тест Есебімен бірге 10 000+ RPS дейінгі тестілер
Серверлер мен ДББЖ конфигурацияларын баптау my.cnf/postgresql.conf баптауы ЖЖҚ буферлерін оңтайландыру ОЖ ядросын, Nginx және ДҚ кешенді баптау (тюнинг)
FAQ

Highload оңтайландыру туралы жиі қойылатын сұрақтар

Серверіңіз үнемі шамадан тыс жүктелген бе, ал пайдаланушылар сайттың баяулығына шағымдана ма? Бізге жазыңыз — біз жүктеме слепкілерін түсіріп, миллисекундтар қайда жоғалатынын көрсетеміз.

  • Жобамызға деректер базасын оңтайландыру шынымен қажет екенін қалай түсінуге болады?

    Дерекқордағы мәселелердің негізгі белгілері: 1) сайт беттері (әсіресе жеке кабинет немесе сүзгілері бар тауарлар каталогы) 1–2 секундтан ұзағырақ ашылады; 2) онлайн-пайдаланушылар саны өскенде сайт қатты «баяулайды» немесе 504 Gateway Timeout қатесін береді; 3) хостинг мониторингі панеліндегі сервер процессорының (CPU) жүктеме графигі 100%-ға жетеді, ал ДҚБЖ процесі (mysqld немесе postgres) ресурстарды барынша пайдаланады; 4) дерекқор көлемі 5–10 ГБ-тан асады. Осы жағдайлардың барлығында сұраныстарды профильдеу жүктемені айтарлықтай төмендетуге мүмкіндік береді.
  • Бэкендті оңтайландырудың орнына жай ғана қуаттырақ сервер сатып алу көмектесе ме?

    Көбінесе — жоқ. Егер сізде 1 миллион жолдан тұратын кестеде индексіз іздеуді орындайтын SQL-сұраныс болса, сервер процессоры әрбір басу сайын дискідегі барлық деректерді оқуға мәжбүр болады. 8 ядроның орнына 32 ядролық серверді сатып алу мұндай тиімсіз сұраныстарды бір уақытта көбірек орындауға мүмкіндік береді, бірақ белгілі бір пайдаланушы үшін беттердің жүктелуін жеделдетпейді. Оның үстіне, дерекқор 10 миллион жолға дейін өскенде сайт бәрібір қатып қалады. Дұрыс индекстер іздеуді мыңдаған есе жылдамдатады, бұл қымбат жабдықты сатып алудың қажеттілігін жояды.
  • Дерекқор шардингі дегеніміз не және ол қай жағдайда қолданылады?

    Шардинг (көлденең бөлу) — бұл дерекқордың бір үлкен кестесін бөліктерге бөлу және оларды әртүрлі физикалық серверлерге тарату әдісі. Мысалы, интернет-дүкеннің тапсырыстар кестесін бөлуге болады: Мәскеу пайдаланушыларының тапсырыстарын №1 серверде, ал Санкт-Петербургтікілерді №2 серверде сақтауға болады. Шардинг Enterprise ауқымындағы жобаларда, деректер көлемі бір сервердің қатты дискілерінің немесе жедел жадының сыйымдылығынан асқанда және классикалық репликация жүктемеге төтеп бере алмағанда қолданылады.
  • Жүктемелік тестілеуді қалай жүргізесіздер және бұл жұмыс істеп тұрған сайт үшін қауіпсіз бе?

    Біз жұмыс істеп тұрған сайтта стресс-тесттер өткізбейміз, өйткені бұл оның тоқтап қалуына және клиенттерді жоғалтуға әкелуі мүмкін. Біз қуаты жағынан жұмыс серверімен бірдей толық оқшауланған жоба көшірмесін (Staging-сервер) іске қосамыз. Содан кейін k6.io утилитасының көмегімен біз типтік әрекеттерді (іздеу, себетке қосу, мақалаларды қарау) орындайтын виртуалды пайдаланушыларды генерациялаймыз. Біз жүктемені секундтық 10 сұраныстан 1000+ сұранысқа (RPS) дейін біртіндеп көтеріп, сервердің қай көрсеткіште қиналып жатқанын бақылаймыз.
Жоғары жүктемелер

Ауқымды жарнамалық кампания немесе сатылым дайындалып жатыр ма?

Өтінім қалдырыңыз — біздің Highload-сәулетшілеріміз сайтыңызды жүздеген мың келушілердің ағынына дайындайды, сұраныстарды оңтайландырады, кэштеуді баптайды және жүктеме кезінде тұрақты жұмысты кепілдендіреді.

Бэкендті жүктемеге қарай оңтайландыру