Вертикальное масштабирование. Функциональность информационной системы для управления логистикой сетевой розничной компании

Масштабируемость - способность устройства увеличивать свои
возможности
путем наращивания числа функциональных блоков,
выполняющих одни и
те же задачи.
Глоссарий.ru

Обычно о масштабировании начинают думать тогда, когда один
сервер не справляется с возложенной на него работой. С чем именно он не
справляется? Работа любого web-сервера по большому счету сводится к основному
занятию компьютеров - обработке данных. Ответ на HTTP (или любой другой) запрос
подразумевает проведение некоторых операций над некими данными. Соответственно,
у нас есть две основные сущности - это данные (характеризуемые своим объемом) и
вычисления (характеризуемые сложностью). Сервер может не справляться со своей
работой по причине большого объема данных (они могут физически не помещаться на
сервере), либо по причине большой вычислительной нагрузки. Речь здесь идет,
конечно, о суммарной нагрузке - сложность обработки одного запроса может быть
невелика, но большое их количество может «завалить» сервер.

В основном мы будем говорить о масштабировании на примере
типичного растущего web-проекта, однако описанные здесь принципы подходят и для
других областей применения. Сначала мы рассмотрим архитектуру проекта и простое
распределение ее составных частей на несколько серверов, а затем поговорим о
масштабировании вычислений и данных.

Типичная архитектура сайта

Жизнь типичного сайта начинается с очень простой архитектуры
- это один web-сервер (обычно в его роли выступает Apache),
который занимается всей работой по обслуживанию HTTP-запросов,
поступающих от посетителей. Он отдает клиентам так называемую «статику», то
есть файлы, лежащие на диске сервера и не требующие обработки: картинки (gif,
jpg, png), листы стилей (css), клиентские скрипты (js, swf). Тот же сервер
отвечает на запросы, требующие вычислений - обычно это формирование
html-страниц, хотя иногда «на лету» создаются и изображения и другие документы.
Чаще всего ответы на такие запросы формируются скриптами, написанными на php,
perl или других языках.

Минус такой простой схемы работы в том, что разные по
характеру запросы (отдача файлов с диска и вычислительная работа скриптов)
обрабатываются одним и тем же web-сервером. Вычислительные запросы требуют
держать в памяти сервера много информации (интерпретатор скриптового языка,
сами скрипты, данные, с которыми они работают) и могут занимать много
вычислительных ресурсов. Выдача статики, наоборот, требует мало ресурсов
процессора, но может занимать продолжительное время, если у клиента низкая
скорость связи. Внутреннее устройство сервера Apache предполагает, что каждое
соединение обрабатывается отдельным процессом. Это удобно для работы скриптов,
однако неоптимально для обработки простых запросов. Получается, что тяжелые (от
скриптов и прочих данных) процессы Apache много времени проводят в ожидании (сначала при получении
запроса, затем при отправке ответа), впустую занимая память сервера.

Решение этой проблемы - распределение работы по обработке
запросов между двумя разными программами - т.е. разделение на frontend и
backend. Легкий frontend-сервер выполняет задачи по отдаче статики, а остальные
запросы перенаправляет (проксирует) на backend, где выполняется формирование
страниц. Ожидание медленных клиентов также берет на себя frontend, и если он использует
мультиплексирование (когда один процесс обслуживает нескольких клиентов - так
работают, например, nginx или lighttpd), то ожидание практически ничего не
стоит.

Из других компонент сайта следует отметить базу данных, в
которой обычно хранятся основные данные системы - тут наиболее популярны
бесплатные СУБД MySQL и PostgreSQL. Часто отдельно выделяется хранилище
бинарных файлов, где содержатся картинки (например, иллюстрации к статьям
сайта, аватары и фотографии пользователей) или другие файлы.

Таким образом, мы получили схему архитектуры, состоящую из
нескольких компонент.

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

Пути дальнейшего разделения компонент тоже понятны - например, можно вынести frontend на отдельный сервер. Но обычно frontend
требует мало системных ресурсов и на этом этапе его вынос не даст существенного
прироста производительности. Чаще всего сайт упирается в производительность
скриптов - формирование ответа (html-страницы) занимает слишком долгое время.
Поэтому следующим шагом обычно является масштабирование backend-сервера.

Распределение вычислений

Типичная ситуация для растущего сайта - база данных уже
вынесена на отдельную машину, разделение на frontend и backend выполнено,
однако посещаемость продолжает увеличиваться и backend не успевает обрабатывать
запросы. Это значит, что нам необходимо распределить вычисления на несколько
серверов. Сделать это просто - достаточно купить второй сервер и поставить на
него программы и скрипты, необходимые для работы backend.
После этого надо сделать так, чтобы запросы пользователей распределялись
(балансировались) между полученными серверами. О разных способах балансировки
будет сказано ниже, пока же отметим, что обычно этим занимается frontend,
который настраивают так, чтобы он равномерно распределял запросы между
серверами.

Важно, чтобы все backend-серверы были способны правильно
отвечать на запросы. Обычно для этого необходимо, чтобы каждый из них работал с
одним и тем же актуальным набором данных. Если мы храним всю информацию в единой
базе данных, то СУБД сама обеспечит совместный доступ и согласованность данных.
Если же некоторые данные хранятся локально на сервере (например, php-сессии
клиента), то стоит подумать о переносе их в общее хранилище, либо о более
сложном алгоритме распределения запросов.

Распределить по нескольким серверам можно не только работу
скриптов, но и вычисления, производимые базой данных. Если СУБД выполняет много
сложных запросов, занимая процессорное время сервера, можно создать несколько
копий базы данных на разных серверах. При этом возникает вопрос синхронизации
данных при изменениях, и здесь применимы несколько подходов.

• Синхронизация на уровне приложения . В этом случае наши
  скрипты самостоятельно записывают изменения на все копии базы данных (и сами несут
  ответственность за правильность данных). Это не лучший вариант, поскольку он
  требует осторожности при реализации и весьма неустойчив к ошибкам.
• Репликация - то есть автоматическое тиражирование
  изменений, сделанных на одном сервере, на все остальные сервера. Обычно при
  использовании репликации изменения записываются всегда на один и тот же сервер - его называют master, а остальные копии - slave. В большинстве СУБД есть
  встроенные или внешние средства для организации репликации. Различают
  синхронную репликацию - в этом случае запрос на изменение данных будет ожидать,
  пока данные будут скопированы на все сервера, и лишь потом завершится успешно - и асинхронную - в этом случае изменения копируются на slave-сервера с
  задержкой, зато запрос на запись завершается быстрее.
• Multi-master репликация. Этот подход аналогичен
  предыдущему, однако тут мы можем производить изменение данных, обращаясь не к
  одному определенному серверу, а к любой копии базы. При этом изменения
  синхронно или асинхронно попадут на другие копии. Иногда такую схему называют
  термином «кластер базы данных».

Возможны разные варианты распределения системы по серверам.
Например, у нас может быть один сервер базы данных и несколько backend (весьма
типичная схема), или наоборот - один backend и несколько БД. А если мы масштабируем
и backend-сервера, и базу данных, то можно объединить backend и копию базы на
одной машине. В любом случае, как только у нас появляется несколько экземпляров
какого-либо сервера, возникает вопрос, как правильно распределить между ними
нагрузку.

Методы балансировки

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

• Балансирующий узел . В этом случае клиент шлет запрос на один
  фиксированный, известный ему сервер, а тот уже перенаправляет запрос на один из
  рабочих серверов. Типичный пример - сайт с одним frontend и несколькими
  backend-серверами, на которые проксируются запросы. Однако «клиент» может
  находиться и внутри нашей системы - например, скрипт может слать запрос к
  прокси-серверу базы данных, который передаст запрос одному из серверов СУБД.
  Сам балансирующий узел может работать как на отдельном сервере, так и на одном
  из рабочих серверов.

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

• Балансировка на стороне клиента . Если мы хотим избежать
  единой точки отказа, существует альтернативный вариант - поручить выбор сервера
  самому клиенту. В этом случае клиент должен знать о внутреннем устройстве нашей
  системы, чтобы уметь правильно выбирать, к какому серверу обращаться.
  Несомненным плюсом является отсутствие точки отказа - при отказе одного из
  серверов клиент сможет обратиться к другим. Однако платой за это является
  усложнение логики клиента и меньшая гибкость балансировки.

Разумеется, существуют и комбинации этих подходов. Например,
такой известный способ распределения нагрузки, как DNS-балансировка, основан на
том, что при определении IP-адреса сайта клиенту выдается
адрес одного из нескольких одинаковых серверов. Таким образом, DNS выступает в
роли балансирующего узла, от которого клиент получает «распределение». Однако
сама структура DNS-серверов предполагает отсутствие точки отказа за счет
дублирования - то есть сочетаются достоинства двух подходов. Конечно, у такого
способа балансировки есть и минусы - например, такую систему сложно динамически
перестраивать.

Работа с сайтом обычно не ограничивается одним запросом.
Поэтому при проектировании важно понять, могут ли последовательные запросы
клиента быть корректно обработаны разными серверами, или клиент должен быть
привязан к одному серверу на время работы с сайтом. Это особенно важно, если на
сайте сохраняется временная информация о сессии работы пользователя (в этом
случае тоже возможно свободное распределение - однако тогда необходимо хранить
сессии в общем для всех серверов хранилище). «Привязать» посетителя к
конкретному серверу можно по его IP-адресу (который, однако, может меняться),
или по cookie (в которую заранее записан идентификатор сервера), или даже
просто перенаправив его на нужный домен.

С другой стороны, вычислительные сервера могут быть и не равноправными.
В некоторых случаях выгодно поступить наоборот, выделить отдельный сервер для
обработки запросов какого-то одного типа - и получить вертикальное разделение
функций. Тогда клиент или балансирующий узел будут выбирать сервер в
зависимости от типа поступившего запроса. Такой подход позволяет отделить
важные (или наоборот, не критичные, но тяжелые) запросы от остальных.

Распределение данных

Мы научились распределять вычисления, поэтому большая
посещаемость для нас не проблема. Однако объемы данных продолжают расти,
хранить и обрабатывать их становится все сложнее - а значит, пора строить
распределенное хранилище данных. В этом случае у нас уже не будет одного или
нескольких серверов, содержащих полную копию базы данных. Вместо этого, данные
будут распределены по разным серверам. Какие возможны схемы распределения?

• Вертикальное распределение (vertical partitioning) - в простейшем случае
  представляет собой вынесение отдельных таблиц базы данных на другой сервер. При
  этом нам потребуется изменить скрипты, чтобы обращаться к разным серверам за
  разными данными. В пределе мы можем хранить каждую таблицу на отдельном сервере
  (хотя на практике это вряд ли будет выгодно). Очевидно, что при таком
  распределении мы теряем возможность делать SQL-запросы, объединяющие данные из
  двух таблиц, находящихся на разных серверах. При необходимости можно реализовать
  логику объединения в приложении, но это будет не столь эффективно, как в СУБД.
  Поэтому при разбиении базы данных нужно проанализировать связи между таблицами,
  чтобы разносить максимально независимые таблицы.

  Более сложный случай
  вертикального распределения базы - это декомпозиция одной таблицы, когда часть
  ее столбцов оказывается на одном сервере, а часть - на другом. Такой прием
  встречается реже, но он может использоваться, например, для отделения маленьких
  и часто обновляемых данных от большого объема редко используемых.

• Горизонтальное распределение (horizontal partitioning) - заключается в
  распределении данных одной таблицы по нескольким серверам. Фактически, на
  каждом сервере создается таблица такой же структуры, и в ней хранится
  определенная порция данных. Распределять данные по серверам можно по разным
  критериям: по диапазону (записи с id < 100000 идут на сервер А, остальные - на сервер Б), по списку значений (записи типа «ЗАО» и «ОАО» сохраняем на сервер
  А, остальные - на сервер Б) или по значению хэш-функции от некоторого поля
  записи. Горизонтальное разбиение данных позволяет хранить неограниченное
  количество записей, однако усложняет выборку. Наиболее эффективно можно выбирать
  записи только когда известно, на каком сервере они хранятся.

Для выбора правильной схемы распределения данных необходимо
внимательно проанализировать структуру базы. Существующие таблицы (и, возможно,
отдельные поля) можно классифицировать по частоте доступа к записям, по частоте
обновления и по взаимосвязям (необходимости делать выборки из нескольких
таблиц).

Как упоминалось выше, кроме базы данных сайту часто требуется
хранилище для бинарных файлов. Распределенные системы хранения файлов
(фактически, файловые системы) можно разделить на два класса.

• Работающие на уровне операционной системы . При этом для
  приложения работа с файлами в такой системе не отличается от обычной работы с
  файлами. Обмен информацией между серверами берет на себя операционная система.
  В качестве примеров таких файловых систем можно привести давно известное
  семейство NFS или менее известную, но более современную систему Lustre.
• Реализованные на уровне приложения распределенные
  хранилища подразумевают, что работу по обмену информацией производит само
  приложение. Обычно функции работы с хранилищем для удобства вынесены в
  отдельную библиотеку. Один из ярких примеров такого хранилища - MogileFS, разработанная
  создателями LiveJournal. Другой распространенный пример - использование
  протокола WebDAV и поддерживающего его хранилища.

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

Выводы

Подводя итог сказанному, сформулируем выводы в виде кратких тезисов.

• Две основные (и связанные между собой) задачи масштабирования - это распределение вычислений и распределение данных
• Типичная архитектура сайта подразумевает разделение ролей и
  включает frontend, backend, базу данных и иногда хранилище файлов
• При небольших объемах данных и больших нагрузках применяют
  зеркалирование базы данных - синхронную или асинхронную репликацию
• При больших объемах данных необходимо распределить базу данных - разделить
  ее вертикально или горизонтально
• Бинарные файлы хранятся в распределенных файловых системах
  (реализованных на уровне ОС или в приложении)
• Балансировка (распределение запросов) может быть равномерная или
  с разделением по функционалу; с балансирующим узлом, либо на стороне клиента
• Правильное сочетание методов позволит держать любые нагрузки;)

Ссылки

Продолжить изучение этой темы можно на интересных англоязычных сайтах и блогах.

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

Но в какой-то момент, траффик начинает расти очень медленно, кто-то опубликовал ссылку на ваше приложение в Reddit или Hacker News , что-то случилось с исходниками проекта на GitHub и вообще, все стало как будто против вас.

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

Все ваши усилия по возобновлению работы безрезультатны – даже после перезагрузки, сервер не может справиться с потоком посетителей. Вы теряете трафик!

Никто не может предвидеть проблемы с трафиком. Очень немногие занимаются долгосрочным планированием, когда работают над потенциально высокодоходным проектом, чтобы уложиться в фиксированные сроки.

Как же тогда избежать всех этих проблем? Для этого нужно решить два вопроса: оптимизация и масштабирование .

Оптимизация

Первым делом, стоит провести обновление до последней версии PHP (текущая версия 5.5, использует OpCache ), проиндексировать базу данных и закэшировать статический контент (редко изменяющиеся страницы вроде About , FAQ и так далее).

Оптимизация затрагивает не только кэширование статических ресурсов. Также, есть возможность установить дополнительный не-Apache-сервер (например, Nginx ), специально предназначенный для обработки статического контента.

Идея заключается в следующем: вы помещаете Nginx перед вашим Apache-сервером (Ngiz будет frontend -сервером, а Apache — backend ), и поручаете ему, перехват запросов на статические ресурсы (т.е. *.jpg , *.png , *.mp4 , *.html …) и их обслуживание БЕЗ ОТПРАВЛЕНИЯ запроса на Apache.

Такая схема называется reverse proxy (её часто упоминают вместе с техникой балансировки нагрузки, о которой рассказано ниже).

Масштабирование

Существует два типа масштабирования – горизонтальное и вертикальное .

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

Вертикальное масштабирование

Представьте, что у вас имеется веб-сервер, обслуживающий веб-приложение. Этот сервер имеет следующие характеристики 4GB RAM , i5 CPU и 1TB HDD .

Он хорошо выполняет возложенные на него задачи, но чтобы лучше справляться с нарастающим трафиком, вы решаете заменить 4GB RAM на 16GB, устанавливаете новый i7 CPU и добавляете гибридный носитель PCIe SSD/HDD .

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

Это хорошо проиллюстрировано на изображении ниже:

Горизонтальное масштабирование

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

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

Если количества ядер процессора недостаточно для выполнения имеющихся потоков, то не имеет значения, насколько мощный установлен CPU – сервер все равно будет работать медленно, и заставит посетителей ждать.

Горизонтальное масштабирование подразумевает построение кластеров из машин (часто достаточно маломощных), связанных вместе для обслуживания веб-сайта.

В данном случае, используется балансировщик нагрузки (load balancer ) – машина или программа, которая занимается тем, что определяет, какому кластеру следует отправить очередной поступивший запрос.

А машины в кластере автоматически разделяют задачу между собой. В этом случае, пропускная способность вашего сайта возрастает на порядок по сравнению с вертикальным масштабированием. Это также известно как «масштабирование вширь ».

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

Он принимает запросы на статические файлы и самостоятельно их обслуживает, не обременяя этим Apache. Другим популярным программным обеспечением для программной балансировки является Squid , который я использую в своей компании. Он предоставляет полный контроль над всеми возможными вопросами посредством очень дружественного интерфейса.

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

При горизонтальном масштабировании происходит следующее:

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

Сложности с разделением данных

Имеется несколько скользких моментов, возникающих при масштабировании PHP-приложений. Узким местом здесь является база данных (мы еще поговорим об этом во второй части данного цикла).

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

Постоянный балансировщик нагрузки

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

Например, если я посещал наш сайт и залогинился там, то балансировщик нагрузки перенаправляет меня, скажем, на Server1 , запоминает меня там, и при следующем клике, я вновь буду перенаправлен на Server1 . Все это происходит для меня совершенно прозрачно.

Но что, если Server1 упал? Естественно, все данные сессии будут утеряны, а мне придется логиниться заново уже на новом сервере. Это очень неприятно для пользователя. Более того, это лишняя нагрузка на балансировщик нагрузки: ему нужно будет не только перенаправить тысячи людей на другие сервера, но и запомнить, куда он их перенаправил.

Это становится еще одним узким местом. А что, если единственный балансировщик нагрузки сам выйдет из строя и вся информации о расположении клиентов на серверах будет утеряна? Кто будет управлять балансировкой? Замысловатая ситуация, не правда ли?

Разделение локальных данных

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

Известно, что данные сессии хранятся в суперглобальном PHP-массиве $_SESSION . Также, ни для кого не секрет, что этот массив $_SESSION хранится на жестком диске.

Соответственно, так как диск принадлежит той или иной машине, то другие к нему доступа не имеют. Тогда как же организовать к нему общий доступ для нескольких компьютеров?

Замечу, что обработчики сессий в PHP могут быть переопределены – вы можете определить свой собственный класс/функцию для управления сессиями.

Использование базы данных

Используя собственный обработчик сессий, мы можем быть уверены, что вся информация о сессиях хранится в базе данных. База данных должна находиться на отдельном сервере (или в собственном кластере). В таком случае, равномерно нагруженные сервера, будут заниматься только обработкой бизнес-логики.

Хотя данный подход работает достаточно хорошо, в случае большого трафика, база данных становится не просто уязвимым местом (потеряв её, вы потеряете все), к ней будет много обращений из-за необходимости записывать и считывать данные сессий.

Это становится очередным узким местом в нашей системе. В этом случае, можно применить масштабирование вширь, что проблематично при использовании традиционных баз данных типа MySQL , Postgre и тому подобных (эта проблема будет раскрыта во второй части цикла).

Использование общей файловой системы

Можно настроить сетевую файловую систему, к которой будут обращаться все серверы, и работать с данными сессий. Так делать не стоит. Это совершенно неэффективный подход, при котором велика вероятность потери данных, к тому же, все это работает очень медленно.

Это еще одна потенциальная опасность, даже более опасная, чем в случае с базой данных, описанном выше. Активация общей файловой системы очень проста: смените значение session.save_path в файле php.ini , но категорически рекомендуется использовать другой способ.

Если вы все-таки хотите реализовать вариант с общей файловой системой, то есть гораздо более лучшее решение — GlusterFS .

Memcached

Вы можете использовать memcached для хранения данных сессий в оперативной памяти. Это очень небезопасный способ, так как данные сессий будут перезаписаны, как только закончится свободное дисковое пространство.

Какое-либо постоянство отсутствует – данные о входе будут храниться до тех пор, пока memcached -сервер запущен и имеется свободное пространство для хранения этих данных.

Вы можете быть удивлены – разве оперативная память не отдельна для каждой машины? Как применить данный способ к кластеру? Memcached имеет возможность виртуально объединять всю доступную RAM нескольких машин в единое хранилище:

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

В кэш, помимо сессий могут попадать и любые другие данные по вашему желанию, главное чтобы хватило свободного места. Memcached это прекрасное решение, которое получило широкое распространение.

Использовать этот способ в PHP-приложениях очень легко: нужно изменить значение в файле php.ini :

session.save_handler = memcache session.save_path = "tcp://path.to.memcached.server:port"

Redis Cluster

Redis это не SQL хранилище данных, расположенное в оперативной памяти, подобно Memcached , однако оно имеет постоянство и поддерживает более сложные типы данных, чем просто строки PHP-массива в форме пар «key => value ».

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

Если сравнивать Redis с решениями вроде Memcached , то он представляет собой нечто среднее между обычной базой данных и Memcached .

Другие решения:

• ZSCM от Zend – хорошая альтернатива, но требует установки Zend Server на каждый нод в кластере;
• Прочие не SQL хранилища и системы кэширования также вполне работоспособны – ознакомьтесь с Scache , Cassandra или Couchbase , все они работают быстро и надежно.

Заключение

Как вы могли понять из написанного выше, горизонтальное масштабирование PHP-приложений это не пикник на выходных.

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

Однако это поправимо. И если сейчас вы подумали о масштабировании – вы на правильном пути.

В двух словах, масштабируемость – это способность системы обрабатывать большой объем трафика и приспособляться к его росту, сохраняя при этом необходимый UX. Существует два метода масштабирования:

• Вертикальное (также называется scaling up): увеличение системных ресурсов, например, добавление памяти и вычислительной мощности. Этот метод позволяет быстро устранить проблемы с обработкой трафика, но его ресурсы могут быстро себя исчерпать.
• Горизонтальное (или scaling out): добавление серверов в кластер. Рассмотрим этот метод подробнее.

Что такое горизонтальное масштабирование?

Проще говоря, кластер – это группа серверов. Балансировщик нагрузки – это сервер, распределяющий рабочую нагрузку между серверами в кластере. В любой момент в существующий кластер можно добавить веб-сервер для обработки большего объёма трафика. В этом и есть суть горизонтального масштабирования.

Балансировщик нагрузки отвечает только за то, какой сервер из кластера будет обрабатывать полученный запрос. в основном, он работает как обратный прокси-сервер.

Горизонтальное масштабирование – несомненно, более надёжный метод увеличения производительности приложения, однако оно сложнее в настройке, чем вертикальное масштабирование. Главная и самая сложная задача в этом случае – постоянно поддерживать все ноды приложения обновленными и синхронизированными. Предположим, пользователь А отправляет запрос сайту mydomain.com, после чего балансировщик передаёт запрос на сервер 1. Тогда запрос пользователя Б будет обрабатываться сервером 2.

Что произойдёт, если пользователь А внесёт изменения в приложение (например, выгрузит какой-нибудь файл или обновит содержимое БД)? Как передать это изменение остальным серверам кластера?

Ответ на эти и другие вопросы можно найти в этой статье.

Разделение серверов

Подготовка системы к масштабированию требует разделения серверов; при этом очень важно, чтобы серверы с меньшим объёмом ресурсов имели меньше обязанностей, чем более объёмные серверы. Кроме того, разделение приложения на такие «части» позволит быстро определить его критические элементы.

Предположим, у вас есть PHP-приложение, позволяющее проходить аутентификацию и выкладывать фотографии. Приложение основано на стеке LAMP. Фотографии сохраняются на диске, а ссылки на них – в базе данных. Задача здесь заключается в поддержке синхронизации между несколькими серверами приложений, которые совместно используют эти данные (загруженные файлы и сессии пользователя).

Для масштабирования этого приложения нужно разделить веб-сервер и сервер БД. Таким образом в кластере появятся ноды, которые совместно используют сервер БД. Это увеличит производительность приложения, снизив нагрузку на веб-сервер.

В дальнейшем можно настроить балансировку нагрузки; об этом можно прочесть в руководстве « »

Сессионная согласованность

Разделив веб-сервер и базу данных, нужно сосредоточиться на обработке пользовательских сессий.

Реляционные базы данных и сетевые файловые системы

Данные сессий часто хранят в реляционных базах данных (таких как MySQL), потому что это такие базы легко настроить.

Однако это решение не самое надёжное, потому что в таком случае увеличивается нагрузка. Сервер должен вносить в БД каждую операцию чтения и записи для каждого отдельного запроса, и в случае резкого увеличения трафика база данных, как правило, отказывает раньше других компонентов.

Сетевые файловые системы – ещё один простой способ хранения данных; при этом не требуется вносить изменения в базу исходных текстов, однако сетевые системы очень медленно обрабатывают I/O операции, а это может оказать негативное влияние на производительность приложения.

Липкие сессии

Липкие сессии реализуются на балансировщике нагрузки и не требуют никаких изменений в нодах приложения. Это наиболее удобный метод обработки пользовательских сессий. Балансировщик нагрузки будет постоянно направлять пользователя на один и тот же сервер, что устраняет необходимость распространять данные о сессии между остальными нодами кластера.

Однако это решение тоже имеет один серьёзный недостаток. Теперь балансировщик не только распределяет нагрузку, у него появляется дополнительная задача. Это может повлиять на его производительность и привести к сбою.

Серверы Memcached и Redis

Также можно настроить один или несколько дополнительных серверов для обработки сессий. Это самый надёжный способ решения проблем, связанных с обработкой сессий.

Заключительные действия

Горизонтальное масштабирование приложения сначала кажется очень сложным и запутанным решением, однако оно помогает устранить серьёзные проблемы с трафиком. Главное – научиться работать с балансировщиком нагрузки, чтобы понимать, какие из компонентов требуют дополнительной настройки.

Масштабирование и производительность приложения очень тесно связаны между собой. Конечно, масштабирование нужно далеко не всем приложениям и сайтам. Однако лучше подумать об этом заранее, желательно ещё на стадии разработки приложения.

Среди многочисленных функций информационной системы, необходимых для управления сетевой логистикой, остановимся вначале на двух ключевых "сетевых" функциях: управление ассортиментом и поддержка категорийного менеджмента.

1. Управление ассортиментом в сетевой торговой компании.

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

Чем качественнее она решается, тем эффективнее развивается розничное торговое предприятие в целом и тем выше его конкурентоспособность.

Задачу управления ассортиментом можно условно разделить на две подзадачи – "внешнюю" и "внутреннюю".

Первая направлена на работу с покупателем в части ассортимента, вторая – на облегчение работы персонала с ассортиментными категориями.

Успешное решение данных задач должно привести к улучшению результатов продаж товаров.

Для эффективного решения "внешней" группы задач необходимо:

• 1) предоставить информацию о товарах покупателям. Информационные и мультимедийные вспомогательные системы призваны помочь покупателям сориентироваться в безграничном море товаров, сделать правильный выбор и получить ценную информацию в кратчайший срок. В то же время они помогают розничным торговцам проанализировать покупательские предпочтения, стимулировать продажу необходимого товара, оптимизировать компоновку торгового зала, рационально размещать ассортимент, что обеспечивает успешное решение внешних задач автоматизации управления ассортиментом;
• 2) решить задачи персонального маркетинга. Реализация функции персонального маркетинга является одной из важнейших задач управления ассортиментом для форматов "супермаркет" и "гипермаркет". Причем, если для супермаркета наибольшую актуальность имеет ведение именно адресного персонального маркетинга с отслеживанием колебаний в предпочтениях конкретных постоянных клиентов данного магазина, то для гипермаркета имеет значение работа с типовыми группами клиентов, принадлежащими к условно определенной категории постоянных покупателей. Что касается дискаунтеров, то персональный маркетинг для них менее актуален. Для выявления предпочтений постоянных покупателей наличие в информационной системе возможности проведения всестороннего анализа продаж и определения структуры покупок также является крайне важной задачей;
• 3) провести качественный визуальный мерчандайзинг. Эффективная выкладка товаров на полках магазинов существенно увеличивает объемы продаж. Для оценки качества решения задач визуального мерчандайзинга информационная система должна иметь возможность ведения и анализа планограмм, описывающих размещение товаров на полках магазинов.

При решении внутренних задач управления ассортиментом необходимо автоматизировать следующие бизнес-процессы:

1) процесс управления активным ассортиментом (ведение ассортиментных матриц).

Дело в том, что информация о товаре, когда-либо внесенная в базу данных, остается в ней длительное время. Например, при актуальном ассортименте в 7000 наименований товаров в системе может храниться 20–30 тыс. наименований товаров. В этих условиях необходимо предоставить пользователю системы возможность работать только с актуальной информацией об активном ассортименте (рис. 3.4).

Рис. 3.4.

Для решения этой задачи требуется обеспечить выполнение следующих функций:

• введение товара в активный ассортимент. Этому процессу, как правило, предшествует серия пробных маркетинговых мероприятий с данным товаром, подготовка логистики и предпродажная подготовка товара;
• прекращение закупок товара, как первая фаза выведения товара из активного ассортимента. В качестве типовых причин данного процесса можно назвать:
  • а) неудовлетворенность результатами продаж товара;
  • б) смена ассортимента производителем;
  • в) наличие проблем взаимоотношений с поставщиком; и др.;
• прекращение пополнения запасов с распределительного центра компании;
• прекращение работы с товаром, как окончательная фаза вывода товара из ассортимента в информационной

системе (обычно происходит при достижении нулевых запасов);

Удаление информации о товарах на кассовых системах (осуществляется, как правило, после проведения инвентаризации).

Преимущества автоматизации данного бизнес-процесса :

• удобство для пользователей при работе с товарным ассортиментом;
• существенное уменьшение количества ошибок, связанное с невозможностью включения в документы товара, не принадлежащего к активному ассортименту;
• возможность получения аналитических отчетов только по активному ассортименту;
• повышение производительности труда менеджеров, занимающихся управлением ассортиментом; и др.;
• 2) процесс управления активным ассортиментом торговых предприятий различных форматов , входящих в состав мулътиформатного сетевого торгового предприятия (управление множественными ассортиментными матрицами).

Автоматизация данного бизнес-процесса позволяет не допустить движение товара на объект управления, к ассортиментным матрицам которого этот товар не принадлежит (рис. 3.5).

Рис. 3.5.

Необходимо также отметить, что качественное решение "внутренних" задач управления ассортиментом приобретает наибольшую значимость для мультиформатного сетевого розничного торгового предприятия.

2. Процесс поддержки категорийного менеджмента посредством формирования товарных ракурсов и ракурсов объектов управления, с которыми работает конкретный категорийный менеджер.

Для менеджера, занимающегося управлением конкретными товарными категориями, объединенными в так называемые стратегические бизнес-единицы, при работе с информационной системой важно сконцентрироваться на определенном подмножестве товаров и объектов управления.

Категорийному менеджеру желательно видеть только то, что касается "его категорий товаров", чтобы создавалась иллюзия, что в информационной системе нет ничего, кроме товаров, входящих в его бизнес-единицу, и тех объектов управления, за которые он отвечает.

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

Для обеспечения работы с информационной системой в таком режиме, в ней должны быть реализованы возможности назначения товарных ракурсов и ракурсов объектов управления.

При этом существует как минимум два базовых типа товарных ракурсов – статические и динамические.

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

В случае определения статического товарного ракурса множество товаров фактически фиксируется как поименованный список (рис. 3.6). Он удобен для строгой фиксации множества (например, для проведения анализа).

Рис. 3.6.

С целью эффективного администрирования товарных ракурсов для определения бизнес-единиц лучше их определять на узлах классификатора товаров. Назовем такие ракурсы динамическими (рис. 3.7).

Рис. 3.7.

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

Когда товар перемещается в другую подгруппу (например, в связи с изменением классификатора), он переходит в другую стратегическую бизнес-единицу и автоматически передается для работы другому категорийному менеджеру.

Аналогично формируется ракурс на объекты управления – это статический ракурс, определяющий список магазинов и распределительных центров, в рамках которых осуществляет свою деятельность конкретный категорийный менеджер (рис. 3.8).

Рис. 3.8.

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

Эта функция очень важна при реализации логистической концепции VMI, когда поставщик или производитель участвует в управлении цепи поставок "своих" товаров.

В заключение сформулируем несколько выводов из вышесказанного:

• 1) управление ассортиментом торгового предприятия является важнейшей задачей, от качества решения которой напрямую зависит его успех;
• 2) решения внешней группы задач управления ассортиментом, особенно торговых предприятий больших форматов, призваны обеспечить системы информирования покупателей (информационные киоски, мультимедийные терминалы, информационные тележки и т.п.);
• 3) возможность ведения в информационной системе ассортиментных матриц, товарных ракурсов и ракурсов объектов управления облегчает возможность решения внутренней группы задач управления ассортиментом, которая напрямую связана с качеством реализации функции категорийного менеджмента на торговом предприятии.

Масштабируемость информационной системы

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

При этом надо учитывать два аспекта – адекватность росту и масштабируемость системы.

Если рост компании сопровождается непропорциональным увеличением расходов на ИТ-инфраструктуру, значит, информационная система не способна оптимально поддержать расширение бизнеса.

Информационные системы, неадекватные росту компании, могут привести к опережающему росту затрат на их эксплуатацию.

В первую очередь, архитектура решения должна соответствовать росту компании. Когда компания растет и насчитывает сотни объектов, построить систему на распределенной архитектуре, на наш взгляд, означает столкнуться с все более возрастающим, в пересчете на каждый магазин, ростом расходов на ИТ-сопровождение.

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

Для обеспечения масштабируемости информационной системы (возможность обеспечить работу требуемого числа пользователей, оперировать необходимым объемом информации при удовлетворяющей производительности) необходимо правильно выбрать платформу – соответствующее программное обеспечение и серверное оборудование.

Если розничная компания растет, объемы информации о продажах исчисляются не в гигабайтах, а в терабайтах, и без использования "индустриальных", масштабируемых систем управления базами данных типа Oracle, Progress и др. здесь не обойтись.

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

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

По нашему убеждению, с ростом компании распределенная архитектура становится колоссальным препятствием на пути снижения издержек на управление бизнесом и на эксплуатацию ИТ-инфраструктуры.

Централизованная архитектура информационной системы подразумевает меньшую стоимость владения и не требует постоянного увеличения численности ИТ-персонала при росте розничной сети.

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

Масштабируемость достигается на различных уровнях: а) Техническом; б) Системном; в) Сетевом; г) СУБД; д) Прикладном. Для ОС масштабируемость означает, что ОС не привязана к однопроцессорной архитектуре процессора. В случае усложнения стоящих перед пользователем задач и расширения предъявляемых к компьютерной сети требований, ОС должна обеспечивать возможность добавления более мощных и производительных серверов и рабочих станций в корпоративной сети. Можно рассматривать масштабируемость технических средств, программных средств, масштабируемость системы в целом. В основе масштабируемости лежат такие технологии как: а) Международные стандарты; б) Сетевые и телекоммуникационные технологии; в) Операционные системы; г) Технология клиент/сервер и ряд других средств.

Конец работы -

Эта тема принадлежит разделу:

Компьютерные информационные технологии в управлении. Классификация систем управления

Цель КИС подготовка к использованию современных информационных технологий в рамках КИС как инструмента для решения научных и практических задач в.. Понятие информационной технологии Корпоративные информационные..

Если Вам нужно дополнительный материал на эту тему, или Вы не нашли то, что искали, рекомендуем воспользоваться поиском по нашей базе работ:

Что будем делать с полученным материалом:

Если этот материал оказался полезным ля Вас, Вы можете сохранить его на свою страничку в социальных сетях:

Все темы данного раздела:

Понятие информационной технологии. Корпоративные информационные технологии
Технология – сис-ма взаимосвязанных способов обработки материалов и приемов изготовления продукции в производственном процессе. Информационные технологии – система взаимосвязанных мет

Технология обработки информации. Понятие совместимости, открытости и модульности
Информация – совокупность фактов, явлений, событий, представляющих интерес, подлежащих регистрации и обработке. Это подразумевает наличие двух моментов: источник и приемник (потребитель) информации

Виды обеспечения информационных систем
Виды обеспечения АСОЭИ: а) Технические; б)Математические; в)Лингвистические; г)Программные. Информационное обеспечение – система классификации и кодирования информации, технологическая схема обрабо

Архитектура корпоративной информационной системы
Архитектура КИС состоит из нескольких уровней: а)Информационно-логический уровень–представляет собой совокупность потоков данных и центров (узлов) возникновения, потребления

Требования к корпоративным информационным системам
Процессы активного совершенствования технологий обработки информации являются следствием того, что к современным информационным системам (КИС) все чаще предъявляются следующие требования: а) структ

Неоднородность корпоративных информационных систем. Решения проблем неоднородности в корпоративных информационных системах
Важнейшую роль играют вопросы преодоления проблем неоднородности корпоративных систем и обеспечения совместимости компонент, входящих в ее состав. Неоднородность в вычислительных системах может про

Международные стандарты в области компьютерных информационных технологий
В настоящее время всемирное распространение получил комплекс стандартов на систему качества предприятия, разработанный ISO (International Standards Organization), точнее, техническим комитетом ISO/

Информационные модели объекта управления
Современное предприятие можно рассматривать как эффективный информационный центр, источниками информации которого являются внешняя и внутренняя деловая среда. Внешняя деловая среда –

Информационное обеспечение корпоративных информационных систем
Информационное обеспечение – система классификации и кодирования информации, технологическая схема обработки данных, нормативно-справочная информация, система документооборота и т.д. Информационное

Политика формирования информационных ресурсов как единого информационного пространства
Для обеспечения взаимодействия информационных ресурсов различного уровня необходимы: а) Использование современных информационных технологий; б) Современная транспортная информационная среда; в) Еди

Преимущества использования вычислительных систем
В результате использования многомашинных и многопроцессорных ВС оказывается возможным достичь следующих преимуществ:1) Повышение уровня производительности и получения быстродействи

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

Операционные системы (ОС). Технологии ОС
Среди системных программ особое место занимает операционная система (ОС). Под операционной системой (ОС) (Operating System)понимают комплекс программ, осуществляющих управле

OS Unix и структурные решения в корпоративных информационных системах. Понятие мобильности
Начало разработок ОС Unix было положено фирмой Bell Laboratories в 1968 г. Была предложена многопользовательская 32-х разрядная ОС Unix для Main Frame. В 1976 г. компания AT&T (куда входила и B

Понятие компьютерных сетей и их характеристика
Компьютерная сеть – это комплекс территориально рассредоточенных ЭВМ, связанных между собой каналами передачи данных целях эффективного использования вычислительных ресурсов. Целесообразност

Состав компьютерных сетей
В состав компьютерных сетей входят технические, программные и информационные средства. То есть компьютерную сеть можно рассматривать как систему с распределенными по территории аппаратурными, прогр

Архитектура компьютерных сетей
В общем случае архитектуру компьютерных сетей можно рассматривать с двух точек зрения – это физическая организация компьютерной сети (топология сети) и организация сети на логическом уров

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

Структура глобальных компьютерных сетей
Глобальные сети (WAN, Wide Area Networks) это системы с широкополосными каналами и позволяют организовать взаимодействие между компьютерами на больших расстояниях. В идеале глобальная компьютерная

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

Протоколы Internet
Протокол в данном случае - это, образно говоря, «язык», используемый компьютерами для обмена данными при работе в сети. Чтобы различные компьютеры сети могли взаимодействовать, они должны «разговар

Адресация Internet
Интернет- всемирная система объединённых компьютерных сетей, построенная на использовании протокола IP и маршрутизации пакетов данных. Интернет образует глобальное информационное пространство, служ