CC BY
83
УДК 004.75
Построение отказоустойчивой инфраструктуры
SaaS-сервиса
Зотов С.В.
АО «Концерн «Созвездие» (в составе объединенного холдинга «Росэлектроника» Госкорпорации Ростех)
г. Воронеж
Аннотация: В статье рассмотрена проблема построения отказоустойчивой инфраструктуры для сервиса SaaS, хранящей данные пользователей в распределенной сети телекоммуникационных серверов. Определены методы взаимодействия серверов, работы с базами данных, механизмы отказоустойчивости системы.
Ключевые слова: SaaS, Postgres, nginx, php-fpm, DB, СУБД, вебсервер, http, репликация.
Статья поступила в редакцию 23.10.2017.
Building a fail-safe infrastructure for SaaS service
Zotov S.V.
JSC "Sozvezdie "Concern" Russia, Voronezh
Abstract: The article considers the problem of building a fail-safe infrastructure for the SaaS service that stores user data in a distributed network of telecommunication servers. The methods of interaction of servers, work with databases, mechanisms offault tolerance of the system are defined.
Keywords: SaaS, Postgres, PostgreSQL, nginx, php-fpm, DB, DBMS, web server, http, replication, MySQL, fast-cgi, fcgi.
The article was received on 23.10.2017.
Введение
Проблема построения отказоустойчивых сервисов актуальна для нашего времени. Онлайн-сервис, предоставляющий доступ услугам для тысяч компаний или сотен тысяч (число доходит до нескольких миллионов) пользователей должен быть построен с таким расчетом, что в случае отказа отдельных компонентов пользователи не почувствуют этого. Проблема усугубляется тем, что часто используемые и популярные веб-технологии не сильно подходят для отказоустойчивых сервисов. Наиболее популярный язык программирования PHP, как и другие интерпретируемые языки, малопроизводителен, так в [1-3] указывается, что для хранения массивов в PHP используется в 18 раз больше памяти, чем в C/C++. Поэтому сотрудники таких популярных сервисов как ВКонтакте и Facebook аннонсировали собственные решения компилирующего типа: компилятор kphp (KittenPHP) [4] и HPHPc (HipHop for PHP, компилирует PHP в C++, а затем с помощью g++ в бинарные исполняемые файлы) [5], а затем и HHVM (виртуальная машина, исполняющая PHP 5, PHP 7 и Hack используя just-in-time (JIT) компиляцию) [6].
В ряде случаев для высоконагруженных веб-приложений может использоваться непосредственно написание ПО на C/C++, подключаемое с помощью FastCGI [3] в качестве бэк-енда, при этом фронтендом может выступать Nginx.
Другая проблема PHP заключается в том, что каждый раз скрипт запускается на запрос пользователя, и разные запуски пользовательских запросов (GET и POST протокола HTTP) обрабатываются не одной программой, а разными ее экземплярами, таким образом без применения внешних хранилищ данных невозможно реализовать единую среду обработки данных. В этом плане PHP проигрывает решениям, реализованным с помощью node.js или java.
Другой популярной технологией, сравнимой с PHP является MySQL. Разработанная компанией Oracle, имеющая такие форки, как perconadb и mariadb, данная СУБД является популярной для разработки веб-приложений. При этом MySQL имеет ряд до сих пор не решенных проблем с репликацией [7], которая необходима для полноценной реализации отказоустойчивости системы.
Мы будем разрабатывать архитектуру для небольшого SaaS-сервиса, клиентами которого являются юридические и физические лица, при этом необходимо изначально заложить основы горизонтальной масштабируемости и отказоустойчивости.
Архитектура системы
Выделим две основные задачи, с которыми приходится работать SaaS-сервису:
• Обращения пользователей;
• Хранение информации.
Разберем, какие проблемы могут сопутствовать каждой задаче.
Для первой задачи (обращение пользователей) проблемой является отказ в обслуживании. Среди причин такой ситуации могут быть отказ веб-сервера, избыточная нагрузка на сервер (к серверу подключились большее число пользователей, чем система может поддержать). Решение данной проблемы достигается распределением (балансировкой) нагрузки на множество серверов, возможность увеличить число обрабатывающих серверов, независимость серверов от хранимых данных. Таким образом решается и проблема сбоя одного из используемых серверов, так и проблема распределения нагрузки при большом числе пользователей.
Для второй задачи (хранение информации) проблемой является потеря (утрата) информации. Утрата информации может произойти из-за аппаратных и программных сбоев, ошибочных действий обслуживающего персонала (известный пример такой ситуации произошел 31 января 2017 года на сервисе Gitlab, когда по ошибке была удалена production база сервиса [8]). Решением такой проблемы является резервирование, когда данные сохраняются не в одну БД, а еще и в резервные БД.
В обоих случаях для серверов также необходимо решение проблемы переключения с загруженного/выведенного из строя сервера на другой и с поврежденной СУБД на резервную, хранящую копии.
Дополнительной проблемой является мониторинг работающих серверов, как веб-серверов, так и СУБД-серверов, и в автоматическом режиме принятие решений и выполнение действий для резервирования/копирования/восстановления и оповещения персонала.
Архитектура веб-инфраструктуры
Как было сказано, основная задача при обработке входящих HTTP-запросов - распределение нагрузки. При этом балансировка нагрузки может решаться разными методами, такими как DNS-балансировка (round robin для NS записей, позволяет делать распределение по нескольким дата-центрам [9], round robin для A-записей, позволяет разрешать доменное имя на несколько IP адресов, таким образом изначально запросы будут приходить на несколько фронтенд-серверов), HTTP-кеширование и балансировка (ее выполняет nginx с помощью upstream модуля) [10].
Таким образом мы можем все запросы уже распределять по нескольким фронтенд-серверам, каждый из которых будет распределять запросы по нескольким бэкенд-серверам - обработчикам, при этом кешируя статическое содержимое (например, css-файлы и js-скрипты, изображения и т.д.).
Реализация веб-сервиса подразумевает ПО на PHP7.0 на стороне сервера и js-скрипты, выполняемые на стороне браузера. Непрерывное взаимодействие осуществляется благодаря AJAX запросам. Несмотря на то, что PHP обладает рядом вышеописанных недостатков, имеется ряд современных фреймворков, таких как YII2 и Laravel, значительно упрощающих веб-программирование. Использование Nginx позволит значительно увеличить производительность, основной проблемой останется только про-лизводительность бэкенд-сервера.
Бэкенд-серверы могут быть выполнены на базе Apache2 или Nginx с применением php-fpm. При подключении php-fpm через TCP-сокет, а не UNIX-сокет и наличии высокопроизводительной сети между бэкенд и фронтенд-серверами возможна напрямую организация связи между фронтенд и бэкенд-серве-ром.
Использование php-fpm является более производительным, так как использует более скоростные механизмы, чем mod_php и Apache2, более того php-fpm изначально разрабатывался для вы-соконагруженных сервисов (изначально в компании Badoo, в данный момент входит в состав PHP) [11].
Архитектура СУБД-инфраструктуры
Резервирование БД возможно с применением более высокоуровневых механизмов (PHP-скрипт сам подключается к двум СУБД), либо с применением средств СУБД. В частности, современные СУБД имеют возможности репликации (master-master, master-slave), таким образом при записи в БД на одном сервере (master) мы будем иметь возможность использовать данные с другого (master или slave). В случае использования master-master из-за задержек могут возникнуть разночтения в данных, что не допустимо, поэтому предпочтительнее выглядит репликация master-slave. Более того, в случае краха master-сервера имеется возможность запустить slave в режиме master. Если задача round robin решается автоматически, независимо от того включены или выключены серверы, для этой задачи необходимо использование мониторинга. В случае обнаружения отказа master-сервера необходимо настроить новый master-сервер, при этом работа веб-сервиса по возможности не должна останавливаться.
Основные варианты СУБД, на данный момент, возможные для реализации веб-сервиса, это MySQL и его форки и Post-greSQL.
Как отмечено в [12] у MySQL имеется проблема с репликацией, в частности из-за проблемы со storage-engine, усугубленной уровнем репликации (логической, тогда как в PostgreSQL -физическая). MySQL более проста в освоении, широко используема, имеет низкий порог вхождения, при всем при том, мы полагаем, для высоконагруженного сервиса необходимо изначально выбирать PostgreSQL.
Так как каждый клиент ведет независимую базу, допустимым является создание отдельной БД для каждого клиента, что существенно упрощает работу с БД и репликацию.
Мониторинг
Как уже выше было сказано, для обеспечения беспребой-ной работы и отказоустойчивости, в том числе устойчивости системы к потерям данных, необходимо проведение мониторинга. Существует ряд решений для системы мониторинга, такие как Zabbix, Nagios, Icinga [13] и т.д. В качестве системы мониторинга можно использовать Zabbix.
Zabbix состоит из:
• Zabbix-сервер, который получает данные от Zabbix-агентов, установленных на машинах, для которых необходим мониторинг;
• СУБД, где хранятся все данные (При этом Zabbix может работать с PostgreSQL [14]);
• Zabbix-фронтенд, реализующая веб-интерфейс для АРМ оператора системы мониторинга/системного администратора.
Схема мониторинга изображена на рис.1.
Zabbix-сервер получает данные от Zabbix-агентов (активные, пассивные проверки), сохраняет данные в БД. Zabbix-фронтенд получает данные из БД и может отображать на АРМ оператора. Изначально Zabbix-frontend рассчитан на Apache2, но может работать и с ^тк и php-fpm.
В случае масштабирования системы дополнительно могут использоваться Zabbix-прокси, опрашивающие агентов от имени сервера.
АРМ Мониторинга
Рис.1. Схема мониторинга с применением Zabbix
Не менее важной является задача резервирования самого Zabbix, что подразумевает резервирование сервера мониторинга и СУБД мониторинга, возможность использования резервного сервера и/или СУБД в случае недоступности/остановки основного.
Проблема резервирования Zabbix (как сервера, так и СУБД), описана, например, в [15].
API
Современные сервисы SaaS часто имеют потребность в интеграции с другими SaaS-сервисами. Это означает, что в сервисе должна быть возможность, с одной стороны, подключать модули, реализующие API других сервисов, с другой стороны, иметь собственное API для возможности интеграции клиентам в свои веб-сервисы и веб-приложения.
API веб-приложения может быть построен на базе SOAP, XML-RPC, JSON-RPC или создан с применением REST-подхода. Считаем, что предпочтительно последнее. REST-подход не создает протокол «8 уровня», инкапсулированный в HTTP «7 уровня», а использует возможности HTTP, в том числе методы (GET, POST, PUT, DELETE), коды состояний (200-е -нормальное завершение, 400 - ошибочные состояния), заголовки HTTP.
Пример API клиент-серверного взаимодействия приведен в [16], более того, в реализации SaaS-сервиса он может применяться не только для внешних интеграций, но и при выдаче статического веб-приложения на java script и его работе с PHP-приложением через этот же API.
Выводы
На основе вышесказанного мы можем представить схему отказоустойчивого взаимодействия. На рис.2 отображена схема децентрализованного SaaS-сервиса, устойчивого к отказам, сбоям и высоким нагрузкам.
Frontend и Backend сервера не хранят данных (кроме кэши-руемых), при этом первым уровнем балансировки является DNS-сервер, вторым Frontend (кеширующий и балансирующий Nginx), сервера-обработчики взаимозаменяемы. Для каждого пользователя определяется сервер, где хранится его БД, при этом запись ведется на master, чтение также может вестись со slave.
Для резервирования разные Frontend и Backend-сервера, master и slave СУБД должны находиться в разных дата-центрах.
Для удобства администрирования необходимо использование средств контейнерной виртуализации (LXC или Docker) и возможности живой миграции виртуальных машин.
Рис. 2. Архитектура децентрализованного отказоустойчивого сервиса SaaS.
Библиографический список:
1. How big are PHP arrays (and values) really? (Hint: BIG!) 12. December 2011 // URL: http://nikic.github.io/2011/12/12/ How-big-are-PHP-arrays-really-Hint-BIG.html
2. Насколько большие массивы (и значения) в PHP? [Перевод http://nikic.github.io/2011/12/12/ How-big-are-PHP-arrays-really-Hint-BIG.html ] https://habrahabr.ru/post/141093/
3. Web-приложение на C/C++ с помощью FastCGI // URL: https://habrahabr.ru/post/154187/
4. kPHP. URL: https://github.com/vk-com/kphp-kdb
5. HPHP. URL: http://github.com/facebook/hiphop-php [состояние историческое, производит редирект на URL: https://github.com/facebook/hhvm ]
6. HHVM. URL: https://hhvm.com/
7. Яковлев С. Репликация MySQL // MySQL&PostgreSQL. IBM DeveloperWorks. [URL]
https://www.ibm.com/developerworks/ru/library/os-06_sql/
8. Инцидент с Gitlab. URL: https://habrahabr.ru/post/320988/
9. Отказоустойчивость на базе DNS. URL: https://habrahabr. ru/post/177145/
10. Nginx. URL: http://nginx.org/en/docs/
11. PHP-FPM. URL:https://php-fpm.org/
12. PostgreSQL vs MySQL http://www.pvsm.ru/mysql/80826
13. Nagios&Icinga. [URL] https://habrahabr.ru/post/170751/
14. Zabbix Manual. Debian&Ubuntu Install from Packages [URL] https ://www.zabbix. com/ documentation/ 3.4/ru/ manual/ installation/ install_from_packages/debian_ubuntu
15. Масштабируя Zabbix //URL: http://security-corp.org/ administration/sys_admin/13664-masshtabiruya-zabbix.html
16. Кручинин С.В., Шиков О.Ю. Хранение данных и обмен между клиентом и сервером в реализации CMS с поддержкой визуального редактирования HTML //Научно-исследовательские публикации, 2017, №2, С.47-58
Об авторе:
Зотов Сергей Валерьевич, ведущий инженер-конструктор, АО «Концерн «Созвездие» (в составе объединенного холдинга «Рос-электроника» Госкорпорации Ростех), г. Воронеж
About the author:
Zotov Sergei Valerievich, chief engineer-designer, JSC "Sozvezdie "Concern", Russia, Voronezh.
