Visitors have accessed this post 4086 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.