Высоконагруженные сервисы

В современном мире для разработчиков все острее встает проблема обработки и хранения больших объемов данных. Сообщения в социальных сетях, фотографии, потоковое видео – все это создает высокую нагрузку на программное обеспечение, используемое на серверах. По этой причине стандартные подходы, используемые для проектирования архитектуры настольных приложений, чаще всего будут неэффективны, так как в большинстве случаев они не учитывают нагрузку на приложение со стороны огромного числа пользователей. На сегодняшний день нет четкого определения для высоконагруженных систем. В большинстве случаев этот термин применяются в ситуациях, когда приложение перестает справляться с моментальной нагрузкой, возложенной на него. Нельзя указать конкретных значений, по достижении которых система считается высоконагруженной, поскольку все приложение специфичны и одинаковое количество запросов может приводить к абсолютно разным нагрузкам на ресурсы. В ходе исследования систем управления базами данных было проведено несколько опытов замеряющих скорость выполнения основных операций с базами данных: добавление, выборка и удаление. На основании результатов этих опытов были сделаны выводы и даны рекомендации по выбору системы управления базами данных. В данной статье рассмотрены подходы к разработке высоконагруженных систем, выделены недостатки и преимущества каждого из подходов и приведены примеры использования этих подходов такими популярными сервисами, как ВКонтакте, Facebook, Google и Яндекс. Приведен сравнительный анализ систем управления базами данных MySQL и MongoDB. В заключении даны рекомендации по выбору СУБД в зависимости от подхода к проектированию архитектуры высоконагруженного проекта.
Подходы к построению архитектуры приложения
Существует два подхода к реализации сервис-ориентированной архитектуры. Условно их называют промышленный иэвристический. Разница между подходами заключается в способе разработки средств масштабирования. При эвристическом подходе средства разрабатываются совместно с бизнес-логикой. При промышленном – отдельно.
В приложении, спроектированном промышленным подходом, имеется большая шина (API), на которую отправляются все запросы и от которой приходит обработанный результат. Недостатки данного подхода:
Во-первых, много времени уходит на разработку общего API – набора классов, функций и констант, предоставляемых приложением для использования во внешних программных продуктах.
Во-вторых, из-за высокой нагрузки на API, для его корректной работы необходимо высокопроизводительное аппаратное обеспечение.
Преимущества подхода:
Основным преимуществом данного подхода является быстрая разработка приложений. Поскольку к моменту, когда все API реализовано, приложениям, остается лишь обращаться к его методам и получать необходимые данные.
Второе неоспоримое преимущество – возможность найма разработчиков, далеких от создания сервисов с высокой нагрузкой. Основное API сервисов разрабатывается командой инженеров, специализирующихся на создании высоконагруженных систем. Таким образом, для разработчиков новых приложений, все методы будут реализованы в API, обращаясь к которому уже не стоит беспокоиться о решении проблемы высокой нагрузки.
Обратный подход используется в разработке ВКонтакте. Когда в этой компании разрабатывается какой-либо сервис, разработчику отдают все полномочия и оговаривается, что сервис должен быть масштабируем [6]. Такой подход называется эвристическим.
Основным его недостатком является предъявление высоких требований к квалификации разработчика, поскольку помимо бизнес-логики сервиса он должен позаботиться и о масштабировании своего продукта.
Преимущество данного подхода заключается в том, что отсутствует огромная нагрузка на главную шину, по которой в случае промышленного подхода пропускаются все данные и проходят запросы. В эвристическом подходе каждый сервис борется с высокой нагрузкой самостоятельно. Благодаря этому использование аппаратного обеспечения происходит более эффективно.
Еще одним немаловажным преимуществом сервис-ориентированного подхода является возможность его горизонтального масштабирования.
Масштабируемость — способность системы справляться с увеличением рабочей нагрузки при добавлении ресурсов (обычно аппаратных). Существует два вида масштабирования системы: горизонтальное и вертикальное. Вертикальное – увеличение производительности системы за счет установки более мощного аппаратного обеспечения. Горизонтальное – увеличение за счет количества серверов.
Вертикально масштабировать проект значительно проще, достаточно лишь снабдить сервера более мощными процессорами или добавить оперативной памяти. Проблема такого подхода в том, что на определенном этапе не будет существовать подходящего аппаратного обеспечения, способного справится с текущими нагрузками. Таким образом, в итоге придется масштабировать приложение горизонтально, то есть разносить функционал на модули, которые будут выполняться на отдельных серверах.
Поскольку монолитное приложение представляет из себя единую структуру, его нельзя декомпозировать на модули, а это означает, что горизонтальное масштабирование применить невозможно.