Visitors have accessed this post 3479 times.

7 шагов HighLoad

0
0
3479
4 декабря 2020 11:59
Автор: Rebrain Me
HighLoad

Visitors have accessed this post 3479 times.

Автор — Александр Пряхин

Все! Хочу работать с высоконагруженными системами, — решили вы. Начинаю учиться.

Ну что ж, давайте попробуем. Разберем пошагово, какие этапы вам нужно пройти, чтобы стать специалистом по высоким нагрузкам.

Предположим, у нас есть проект. Сайт, который пропускает через себя за день очень много клиентов. Посмотрим, какие шаги нужно пройти специалисту по работе с высокими нагрузками, чтобы обеспечить его корректную и бесперебойную работу.

1. Сперва определяем, где и зачем нам нужен Highload.

Для этого нам нужно формализовано оценить нашу систему. То есть провести мониторинг. Используем

  •         top, htop — средства мониторинга операционных систем,
  •         Zabbix или внешние APM типа New Relic – для внешнего мониторинга.

По результатам мониторинга выделяем «слабые» места, с которыми предстоит поработать особенно плотно.

Я сплошь и рядом встречаю компании, которые занимаются оптимизацией ради оптимизации. И строят огромные кластеры, используя их от силы процентов на 10. Highload не берется по щелчку пальцев. Это результат изучения продукта и понимания его развития. Поэтому в первую очередь надо научиться оценивать свой продукт “в попугаях”. Иначе будет непонятно, насколько быстрее стал работать сайт, в архитектуру которого влили N миллионов рублей.

2. Автоматизируем все, абсолютно все процессы в системе.

  •         Автоматизируем деплой. Используем для этого Jenkins, Gitlab CI, TeamCity.
  •         Автоматизируем процессы бэкапирования — подключаем Bacula.
  •         Усиливаем мониторинг при помощи Prometeus.

Если у вас строится система, которая должна будет выдерживать высокие нагрузки, а код выкатывается ручками через git merge, то вас ждут увлекательные вечера и ночи отладки. Человеческий фактор в этих системах нужно минимизировать, так как скорость реакции нужна молниеносная. Для этого нам и нужен этот шаг.

3. Готовим систему к нагрузкам и повышаем отказоустойчивость.

Чтобы сайт справился, если на него придёт в два раза больше пользователей, чем обычно. И не упал совсем, если откажет один из серверов, например. Потому что в этом случае вся пропускная способность станет бесполезной.

Нам понадобятся

  • Во-первых, еще N серверов для M продуктов.

Затем применяем что-то из нижеперечисленного

  • Nginx – для балансировки нагрузки web-трафика (если нам нужно балансировать только его).
  • HAProxy – для комплексной балансировки (он сложнее в приготовлении, но уже умеет делать TCP-балансировку).
  • Cisco NetScaler – аппаратный балансировщик (самый дорогой вариант, но это уже уровень сурового Энтерпрайза).

Еще нам нужны инструменты, которые позволят расширять и сужать кластер. А для этого удобнее всего использовать виртуальные машины и контейнеры, которые можно быстро собрать или погасить.

Поэтому берем

  • Ansible — SCM для автосборки виртуалок.
  • Kubernetes – для оркестрации контейнеров.

4. Изучаем производительность инфраструктур, с которыми будем работать.

Потому что инфраструктура — это фундамент. Если его заложить неправильно, это точно скажется на всей системе.

Решаем много вопросов, читаем информацию, восполняем недостающие данные.

  • Где стоит применять SSD, где SAS, а где — вообще S3-like хранилища.
  • Какое ПО лучше крутить на «железе», какое — на виртуалках, какое — в контейнерах, а какое — в том же Serverless.
  • Если серверов много, но они небольшие, то имеет смысл присмотреться к облакам, которые отлично представлены компаниями Amazon, Google Cloud и другими. Для этого еще раз внимательно анализируем потребности из предыдущих пунктов, а также не забываем про бюджет. Кстати, AWS предоставляют занятный калькулятор, который помогает быстренько сравнить расходы на облако и классический colocation.

5. Выбираем окружение.

Начиная от операционной системы, и до прикладного ПО.

  • Какая из сборок Linux принесет меньше проблем в тюнинге?
  • Сколько worker-ов выделить у NGINX, чтобы он эффективно использовал ядра процессора?
  • Какой объем буфера innodb задать для PerconaDB, чтобы временные данные запросов не записывались на диск?
  • Какой application сервер для Java-сервисов выбрать?

Все эти вещи уже давно изучены, и по ним есть шпаргалки. Поэтому ничего принципиально нового тут, к счастью, выдумывать не нужно. IT-сообщество уже давно придумало оптимальные паттерны применение тех или иных решений. А потому просто учимся их правильно воспроизводить.

Если требуется (а скорей всего, это так), «тюнингуем» базовые компоненты нашей системы для работы с высокими нагрузками — Nginx, сервера приложений (Jetty, к примеру), РСУБД (Postgres, MySQL, Oracle).

6. А когда же начнется HighLoad?

Все эти хайповые технологии — ClickHouse, Go, BigData, CloudComputing (впишите свой вариант).

А вот только сейчас. Почему? Дело в том, что высокопроизводительные языки, хранилища, операционные системы — это только малая часть средств обеспечения систем под высокие нагрузки. Если среда медленная, то и эти технологии не станут «серебряной пулей» и не смогут дать ожидаемого от них прироста. Поэтому и начинаем мы с фундамента.

Но эти продукты нам тоже нужны, их мы и собираем на следующем шаге.

  • ClickHouse отлично решает задачи построения хранилищ для быстрых отчетов по большим объемам данных.
  • Go — чрезвычайно быстрый язык микросервисов.
  • InMemory-вычисления дают отличную производительность.
  • Продолжите список любыми технологиями, которые, вы считаете, нужны в вашем проекте.

Но! Всегда есть то самое «но». Применять их надо осторожно, чтобы не превратить свою систему в «зоопарк» сотен модных технологий, которые приняты в работу, потому что они на слуху. Нужно помнить, что их кто-то должен обеспечивать. А стоимость отдельно взятого специалиста будет связана с его стеком.

7. На последнем шаге вам надо поработать над многослойностью.

А значит, разделить нашу систему.

Распределяем единую ответственность за каждым из серверов.

  • Используем для логов уже привычный всем ELK стэк.
  • Агрегируем статические файлы в хранилищах.
  • Строим поверх них CDN для ускорения доставки.
  • И так далее.

Потому что, если на одном сервере и логика работает, и логи хранятся, и файлики складываются, высокой производительности с ним вряд ли добьешься. А в случае единой ответственности ее проще взять под контроль и делать максимально производительной. Каждый из этих кусочков становится гораздо проще контролировать, масштабировать и управлять им.

При этом слои должны разделяться и взаимодействовать таким образом, чтобы не допустить каскадного распространения проблемы по системе (когда один упавший сервис тянет за собой всю систему).

Пройдя все шаги, вы должны получить отказоустойчивую систему, готовую к высоким нагрузкам.

Как видите, тут много «базы». Потому что специалист по высоким нагрузкам – это человек, который работает «на стыке». И он хорош не тем, что умеет применять модные технологии, типа ClickHouse, а тем, что может оценить систему и выстроить с самых азов крепкий фундамент, который и станет основой для роста производительности этой системы.

От редакции

Если вам интересно посещать бесплатные онлайн-мероприятия по DevOps, Kubernetes, Docker, GitlabCI и др. и задавать вопросы в режиме реального времени, подключайтесь к каналу DevOps by REBRAIN

*Анонсы мероприятий каждую неделю

Практикумы для специалистов по инфраструктуре и разработчиков — https://rebrainme.com.

Наш Youtube-канал — https://www.youtube.com/channel/UC6uIx64IFKMVmj12gKtSgBQ.

Агентство Fevlake, проектируем и поддерживаем IT-инфраструктуры с 2012 года — https://fevlake.com.

Комментарии (3)
Введено символов из возможных
Не отвечать

Вам также может понравится

Docker Swarm: знакомство
array(1) { [0]=> object(WP_Term)#11536 (16) { ["term_id"]=> int(8) ["name"]=> string(6) "Docker" ["slug"]=> string(6) "docker" ["term_group"]=> int(0) ["term_taxonomy_id"]=> int(8) ["taxonomy"]=> string(8) "category" ["description"]=> string(0) "" ["parent"]=> int(0) ["count"]=> int(8) ["filter"]=> string(3) "raw" ["cat_ID"]=> int(8) ["category_count"]=> int(8) ["category_description"]=> string(0) "" ["cat_name"]=> string(6) "Docker" ["category_nicename"]=> string(6) "docker" ["category_parent"]=> int(0) } } Docker

Автор - Максим Рязанов

Всех приветствую! В этой статье я расскажу о Docker Swarm, его возможностях и основах взаимодействия с ним.

Пройдемся по следующим основным пунктам:

Построение кластера высокой доступности и управление кластером
Сервисы в Docker Swarm:

Режимы Replicated и Global
Файлы конфигурации и секреты
...

30
0
13 ноября 2020
Linux like One-c
array(1) { [0]=> object(WP_Term)#976 (16) { ["term_id"]=> int(6) ["name"]=> string(5) "Linux" ["slug"]=> string(5) "linux" ["term_group"]=> int(0) ["term_taxonomy_id"]=> int(6) ["taxonomy"]=> string(8) "category" ["description"]=> string(0) "" ["parent"]=> int(0) ["count"]=> int(28) ["filter"]=> string(3) "raw" ["cat_ID"]=> int(6) ["category_count"]=> int(28) ["category_description"]=> string(0) "" ["cat_name"]=> string(5) "Linux" ["category_nicename"]=> string(5) "linux" ["category_parent"]=> int(0) } } Linux

Автор статьи - Сергей Попов
Предистория
Мало кто из инфраструктурщиков на просторах России не сталкивался с «Великим и Ужасным» ОДИН-ЭС. Многие после этой встречи безвозвратно уходят в мир *nix, чтобы никогда больше не пересекаться с ним, и не жалеют об этом, остальным приходится устанавливать, обслуживать и поддерживать этого монстра многие...

0
8
3 августа 2020
Как и для чего я автоматизировал проверку количества shapshot’ов
array(1) { [0]=> object(WP_Term)#11536 (16) { ["term_id"]=> int(7) ["name"]=> string(6) "DevOps" ["slug"]=> string(6) "devops" ["term_group"]=> int(0) ["term_taxonomy_id"]=> int(7) ["taxonomy"]=> string(8) "category" ["description"]=> string(0) "" ["parent"]=> int(0) ["count"]=> int(19) ["filter"]=> string(3) "raw" ["cat_ID"]=> int(7) ["category_count"]=> int(19) ["category_description"]=> string(0) "" ["cat_name"]=> string(6) "DevOps" ["category_nicename"]=> string(6) "devops" ["category_parent"]=> int(0) } } DevOps

Автор - Максим Куприенко
Ищем корень зла
Как-то я столкнулся с интересной задачей. А именно - при работе с системой виртуализации VMware vSphere иногда возникала следующая проблема: для некоторых виртуальных машин выполнение штатных операций (старт/стоп/перезапуск) стало занимать гораздо больше времени, а также падала производительность самой...

4
0
28 августа 2020