Добрый вечер! В преддверии старта курса «Backend-разработчик на PHP» мы традиционно провели открытый урок. На нём поговорили о высоконагруженных системах, масштабировании, архитектуре. Детально рассмотрели HighLoad, а также основные подходы и тактики при разработке высоконагруженных систем.
Были поставлены следующие цели занятия:
Преподаватель — Игорь Саханков, разработчик в Booking.com.
Пару сотен лет назад шведский король Густаф II Адольф захотел построить самый большой в мире корабль. Он пригласил голландского кораблестроителя Хенрика Хюбертссона и дал ему свои указания. Мастер никогда не строил ничего подобного, но у него был большой опыт в строительстве кораблей маленьких размеров. Казалось бы, нет ничего сложного — бери чертёж маленького корабля и увеличь его в нужное количество раз. Сказано-сделано. И вот, через несколько лет работы появилось замечательное и грандиозное сооружение:
Всё бы ничего, но при спуске на воду этот корабль не продержался и получаса, сразу пойдя на дно. Это был парусный военный корабль «Vasa», и произошло это в 1628 году.
А теперь представьте, что вас попросили сделать скворечник или конуру для собаки. Разумеется, большинство из нас справятся с этой задачей. А если попросят сделать небоскрёб?
Все эти примеры говорят о том, что чем сложнее система, тем больше она имеет различных взаимозависимостей, нюансов реализации, подводных камней. А для того чтобы успешно справляться с проектированием и созданием сложных систем, как раз и существуют архитектурные паттерны.
Говоря академическим языком, архитектура информационных систем — это концепция, определяющая модель, структуру, выполняемые функции и взаимосвязь компонентов ИС.
Однако давайте вернёмся от строительства кораблей и домов к программированию. Смотрите, у нас всегда есть требования, которые приходят к нам от бизнеса. А конвертировать их в технические требования помогает архитектура. Исходя из полученных технических требований, вы без проблем сделаете декомпозицию системы, напишете зависимости между модулями и приступите к непосредственной реализации.
Таким образом, архитектура:
Само по себе понятие high load весьма относительно, и устоявшегося определения нет. Однако можно с уверенностью сказать, что этот момент наступает тогда, когда ваша текущая инфраструктура перестаёт справляться с нагрузкой. А это значит, что пора делать масштабирование. Оно бывает:
Всем известно такое понятие, как очередь (FIFO). Это способ организации обработки данных, который позволяет обслуживать конфликтные требования путём упорядочения процесса по принципу «первым пришёл — первым ушёл». Очередь можно использовать, как средство балансировки нагрузки, развязывания клиента и сервера и много чего еще.
Достоинства:
Недостатки:
Теперь давайте поговорим о том, что можно делать с хранилищем. Под хранилищем понимаются любые системы хранения, например, реляционные базы данных. Итак, у нас есть следующие варианты решения проблем с хранилищами:
1. Репликация.
Одна из известных проблем с хранилищами связана с ситуацией, когда у нас много чтений и мало записи. Это может быть новостной сайт — все читают новости, но добавляют новые материалы только админы. Так вот, репликация — это как раз про то, когда у нас хранилище упёрлось в чтение, и мы имеем задержки в работе системы. Тут важно отметить, что репликация решает проблему чтения, но никак не записи. Мало того, она несколько ухудшает способность баз данных к записи, потому что ей приходится раздавать порции своих данных на реплики, как заметно на картинке выше. В самом простом случае при настройке репликации у нас имеется один Master — основная БД, на которую происходит запись, и слэйвы — копии БД (реплики, с которых идут все чтения данных).
2. Партиционирование. Допустим, у нас есть большая таблица, но мы пользуемся лишь некоторыми данными. Мы можем её разбить на части. К примеру, берём наши данные и раскладываем их в разные таблички в зависимости от месяца. Результат — маленькие таблицы вместо одной большой и, как следствие, более быстрые выборки по конкретному месяцу. Таким образом оптимизируется время выполнения запросов.
3. Вертикальный шардинг. В случае с партиционированием речь шла об одном сервере и одной БД. В случае с шардингом у нас несколько машин и несколько баз. Мы берём все наши данные, разбиваем их на логические группы, и каждая логическая группа хранится в отдельной БД.
Способ легко реализуется и хорошо масштабирует нагрузку. Но имеет и недостатки, о которых подробнее рассказано в видео.
4. Горизонтальный шардинг. Здесь каждый шард лежит на отдельной машине.
Рецепт
Следующие тезисы помогут вам создать масштабируемую систему:
Коллеги, пересказ вышел довольно сжатым, поэтому лучше смотрите вебинар полностью. Также не пропустите День открытых дверей курса «Backend-разработчик на PHP».
Были поставлены следующие цели занятия:
- обсудить, что такое архитектура систем и зачем она нужна;
- обсудить, что такое High Load;
- рассмотреть архитектурные тактики;
- обсудить курс.
Преподаватель — Игорь Саханков, разработчик в Booking.com.
Архитектура
Пару сотен лет назад шведский король Густаф II Адольф захотел построить самый большой в мире корабль. Он пригласил голландского кораблестроителя Хенрика Хюбертссона и дал ему свои указания. Мастер никогда не строил ничего подобного, но у него был большой опыт в строительстве кораблей маленьких размеров. Казалось бы, нет ничего сложного — бери чертёж маленького корабля и увеличь его в нужное количество раз. Сказано-сделано. И вот, через несколько лет работы появилось замечательное и грандиозное сооружение:
Всё бы ничего, но при спуске на воду этот корабль не продержался и получаса, сразу пойдя на дно. Это был парусный военный корабль «Vasa», и произошло это в 1628 году.
А теперь представьте, что вас попросили сделать скворечник или конуру для собаки. Разумеется, большинство из нас справятся с этой задачей. А если попросят сделать небоскрёб?
Все эти примеры говорят о том, что чем сложнее система, тем больше она имеет различных взаимозависимостей, нюансов реализации, подводных камней. А для того чтобы успешно справляться с проектированием и созданием сложных систем, как раз и существуют архитектурные паттерны.
Говоря академическим языком, архитектура информационных систем — это концепция, определяющая модель, структуру, выполняемые функции и взаимосвязь компонентов ИС.
Однако давайте вернёмся от строительства кораблей и домов к программированию. Смотрите, у нас всегда есть требования, которые приходят к нам от бизнеса. А конвертировать их в технические требования помогает архитектура. Исходя из полученных технических требований, вы без проблем сделаете декомпозицию системы, напишете зависимости между модулями и приступите к непосредственной реализации.
Таким образом, архитектура:
- помогает обеспечить нефункциональные требования системы;
- является средством коммуникации между стейкхолдерами;
- оптимизирует затраты, снижает стоимость больших систем;
- позволяет переиспользовать архитектурные паттерны, учитывать предыдущий опыт, не повторять прошлых ошибок
High Load
Само по себе понятие high load весьма относительно, и устоявшегося определения нет. Однако можно с уверенностью сказать, что этот момент наступает тогда, когда ваша текущая инфраструктура перестаёт справляться с нагрузкой. А это значит, что пора делать масштабирование. Оно бывает:
- вертикальным. Суть проста: если железо не справляется, мы покупаем новое, супермощное, производительное и дорогое;
- горизонтальным. У нас есть один сервер, который не справляется. Мы покупаем второй сервер с теми же характеристиками, потом третий и т. д. На выходе имеем много относительно простеньких машин.
Архитектурные тактики
Всем известно такое понятие, как очередь (FIFO). Это способ организации обработки данных, который позволяет обслуживать конфликтные требования путём упорядочения процесса по принципу «первым пришёл — первым ушёл». Очередь можно использовать, как средство балансировки нагрузки, развязывания клиента и сервера и много чего еще.
Достоинства:
- слабая связанность клиента и сервера;
- известен статус задачи;
- конфигурация на лету;
- балансировка нагрузки.
Недостатки:
- дополнительная сущность в системе;
- более сложная обработка задач;
- потеря/создание копий сообщений.
Теперь давайте поговорим о том, что можно делать с хранилищем. Под хранилищем понимаются любые системы хранения, например, реляционные базы данных. Итак, у нас есть следующие варианты решения проблем с хранилищами:
1. Репликация.
Одна из известных проблем с хранилищами связана с ситуацией, когда у нас много чтений и мало записи. Это может быть новостной сайт — все читают новости, но добавляют новые материалы только админы. Так вот, репликация — это как раз про то, когда у нас хранилище упёрлось в чтение, и мы имеем задержки в работе системы. Тут важно отметить, что репликация решает проблему чтения, но никак не записи. Мало того, она несколько ухудшает способность баз данных к записи, потому что ей приходится раздавать порции своих данных на реплики, как заметно на картинке выше. В самом простом случае при настройке репликации у нас имеется один Master — основная БД, на которую происходит запись, и слэйвы — копии БД (реплики, с которых идут все чтения данных).
2. Партиционирование. Допустим, у нас есть большая таблица, но мы пользуемся лишь некоторыми данными. Мы можем её разбить на части. К примеру, берём наши данные и раскладываем их в разные таблички в зависимости от месяца. Результат — маленькие таблицы вместо одной большой и, как следствие, более быстрые выборки по конкретному месяцу. Таким образом оптимизируется время выполнения запросов.
CREATE TABLE my_table (id INT, amount DECIMAL(7,2), some_date DATE)
ENGINE=INNODB
PARTITION BY HASH( MONTH(some_date) )
PARTITIONS 6;3. Вертикальный шардинг. В случае с партиционированием речь шла об одном сервере и одной БД. В случае с шардингом у нас несколько машин и несколько баз. Мы берём все наши данные, разбиваем их на логические группы, и каждая логическая группа хранится в отдельной БД.
$users = new PDO("pgsql:db_name=my_db;host=192.168.1.1", "user", "password");
$photos = new PDO("pgsql:db_name=my_db;host=192.168.1.2", "user", "password");
$users->prepare('SELECT * FROM users ...');
$photos->prepare('SELECT * FROM photos ...');Способ легко реализуется и хорошо масштабирует нагрузку. Но имеет и недостатки, о которых подробнее рассказано в видео.
4. Горизонтальный шардинг. Здесь каждый шард лежит на отдельной машине.
Рецепт
Следующие тезисы помогут вам создать масштабируемую систему:
- упрощайте на уровне требований!
- не усложняйте решение,
- старайтесь быть stateless,
- кэшируйте,
- мониторинг + алертинг,
- будьте компетентными.
Коллеги, пересказ вышел довольно сжатым, поэтому лучше смотрите вебинар полностью. Также не пропустите День открытых дверей курса «Backend-разработчик на PHP».
