Концепция автоматизированной системы управления физическим размещением данных на MS SQL Server

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

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

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

Структуру такой системы можно изобразить на диаграмме:

Как видно на диаграмме, система разделена на 4 части:

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

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


Задачи подсистемы "Интерфейс администрирования".

1. Позволять регистрировать в системе новые типы данных, определять их структуру (имена атрибутов, их типы и другие свойства).
2. Регистрировать в системе новые физические сервера для размещения данных
3. Задавать настройки расположение данных на каждом сервере
4. Управлять настройками распределения данных между серверами
5. Управлять настройками прав доступа

Задачи подсистемы "Управление расположением".

1. Заблаговременно и по требованию пользователя создавать на физических серверах базы данных, таблицы, элементы партицирования и пр. для размещения данных
2. Исправлять ошибки, возникающие в процессе работы - обрывов связи, сбоев в работе серверов и т.п.
3. Проводить публикацию новых данных, если она требуется
4. Выполнять дефрагментацию и переиндексацию
5. Удалять устаревшие данные
6. Управлять распределением данных между серверами

Задачи подсистемы безопасности.

1. Управление доступом на запись и чтение данных
2. Управление пользовательскими сессиями, мешающими работе с данными

Задачи подсистемы API.

1. Выдавать конечным потребителям данные, хранящиеся в системе
2. Принимать от потребителей новые данные, которые необходимо поместить в систему
3. Получать от потребителей сигналы о необходимости выполнения публикации переданных данных
4. Обеспечение параллельной работы пользователей с системой

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

Нагрузочное тестирование с использованием Amazon Web Services

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

На тот момент у нас уже были автоматизированные сценарии тестирования, которые имитировали поведение обычных пользователей при работе с системой. Сценарии были разработаны с использованием Coded UI Tests и Selenium.

Эти сценарии использовались в рамках текущего автоматизированного регрессионного контроля.

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

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

В качестве платформы размещения тестовых сценариев была выбрана облачная платформа Amazon Web Services (AWS) в следующем виде - мы создали эталонную виртуальную машину в Amazon Elastic Cloud 2 (EC2), на которую установили скрипты автоматизированного тестирования.

Затем, мы разработали отдельное центральное приложение, которое через AWS API дублировало эталонную машину в Amazon EC2 столько раз, сколько нам требовалось (например, создавало 100 одинаковых машин), затем проводило окончательную настройку тестовых сценариев и запускало эти сценарии на выполнение.

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

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

Архитектура небольшой социальной сети

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

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

На следующей диаграмме отображена выбранная нами архитектура:

 

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

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

 

Слои UI и бизнес-логики не хранили в себе никаких состояний (stateless) и могли иметь любое количество независимых инстансов, балансирующих нагрузку.

Слои UI был реализован как Single Page Application (SPA), основанное на технологиях Bootstrap, Angular и jQuery, способное работать на любом виде устройств.

Слой бизнес-логики был реализован в виде ASP.NET Web API-приложения, обменивающегося с UI сообщениями в формате JSON.

 

MySQL хранил информацию о пользователях, денежных транзакциях и т.п., разбитую вертикально (vertical sharding) на несколько инстансов.

Memcached кешировал часто запрашиваемую из MySQL информацию – данные о пользователях, контент сайта и т.п.. Кеш автоматически распределялся между несколькими инстансами Memcached.

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

 

Task processor – сервис для выполнения фоновых задач – отправка писем, СМС. обслуживание баз и пр.

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

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

 

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

YouTube использовался в качестве хранилища видео-данных и средства проведения review.

Облачное хранилище Amazon Web Services (AWS) использовалось для хранения фотографий и музыкального контента.

Google, Facebook, Twitter и Instagram использовались для авторизации в социальной сети.